Om de begrænsninger det sætter hvis der er folk der skal skifte mellem de forskellige systemer.
Dette er en del af en serie artikler om redundans, som bør læses i rækkefølge. Hvis du ikke har læst indledningen ” Redundans til at løse alle problemer”, så er den her.
Redundans er kun godt, hvis det fungerer i overensstemmelse med de forventninger som brugerne har til det. Da de færreste brugere interesserer sig for hvordan deres backupsystemer virker og hvordan de skal bruge dem. Selv det bedste redundante system kan ende med at medføre at man ikke kan sende, hvis brugernes forventninger er forkerte. Nedenstående er et eksempel fra de virkelige liv på en TV station, som viser hvor galt det kan gå, og som man kan lære meget af. Jeg nævner ingen navne, navnene er sådan set også ligegyldige, for jeg tror det her kunne have været sket hvor som helst.
TV stationen har en Main og en Backup videoserver. Hver videoserver har to outputs, så der er altså 4 i alt. Der er tale om passiv redundans, så Backup laver ingen ting når Main sender, men den har alle videofiler, så den er klar til at afvikle, hvis det skulle være nødvendigt. Produceren har to PCer til styring af video serverne, men kun ét sæt skærm, mus og keyboard, og skifter mellem main og backup med en KVM switch. Styringen af, om det er signalerne Main eller Backup, der kommer videre til preview-monitorer, billed- og lydmixerne sker ved hjælp af en rød knap, som skifter alle signaler. Endelig er der en kontrolmonitor som viser hvilket klip der bliver afviklet, hvor lang tid der er afviklet og hvor lang tid der er tilbage af klippet. Den har en slags auto-sensing, så hvis Main kører, så viser den hvad der foregår på den, og hvis Backup kører og Main ikke kører, så viser den hvad der foregår på Backup.
En dag var der et problem på Main videoserveren, som gjorde at den ikke kunne sende. Produceren brugte så sin KVM switch til at skifte til den PC der styrer Backup videoserveren. Produceren forventede dog at playlisten umiddelbart skulle være synlig på Backup-PC’en. Tidligere havde de haft et aktivt redundant system, som nu var ændret til et passivt system. Efter noget forsinkelse og tilkaldt assistance blev playlisten loadet på Backup-PC’en, og så blev den røde knap brugt for at skifte signalerne. Resultatet var at audiosignalerne blev skiftet som de skulle, men videosignalerne til previewmonitorerne og billedmixeren skiftede ikke. Årsagen viste sig at være en forkert video-routing som gjorde at signalerne ind i billedmixeren var routet direkte fra Main til billedmixeren, altså uden om den omskifter som blev styret af den røde knap. Det blev så opklaret en times tid efter at problemet var opstået – det var så ½ time efter at programmet var slut. Så det program blev altså sendt uden at kunne spille indslag, men heldigvis var der da nogle live-gæster, som fik mere taletid end de nogensinde havde drømt om…
Problemerne her var altså først forkerte forventninger fra en bruger og dernæst et single point of failure. Problemet med de forkerte bruger-forventninger er på samme tid både det letteste og det sværeste at gøre noget ved. Hver gang et rutefly gør klar til afgang checker kaptajnen at flyet virker, både det der skal bruges under normal flyvning og til forskellige nødprocedurer. Havde produceren checket at der var lyd og billede både fra Main og Backup, ville produceren have opdaget at redundansen havde fungeret anderledes end forventet. Hvis producerne havde haft for vane at gøre dette, ville de også have opdaget at den røde knap ikke fungerede som den skulle, og det problem kunne så have været løst længe inden den dag hvor vi fik problemet med Main videoserveren.
Det skulle jo være meget let, og hvis en pilot kan finde ud af det, så må en producer vel også kunne. Problemet er så at hvor man i luftfarten kan ende med at få flyveforbud hvis man ikke checker sine ting (eller endnu værre: styrte ned), så har den slags som regel ingen konsekvenser hos broadcastere. Jeg siger ikke at man skal til at fyre de producere der ikke checker deres backup-systemer. Det er ledelsens opgave at prioritere den slags, og gør man ikke det, skal man heller ikke komme og beklage sig over tekniske fejl.
Tilbage til de røde knapper. Den røde knap viste sig at være et single point of failure. Det var godt nok ikke dens skyld, at det gik som det gjorde, for fejlen lå i at billedmixeren slet ikke fik udgangssignalet fra den. Men det er sådan set underordnet, for der skete ikke det der skulle når man trykkede på den. Hvis vi nu erkender at det er urealistik at lave et ”Pre-Flight-Check” af et TV kontrolrum inden hver udsendelse, så er det endnu vigtigere at den redundans man har, kan betjenes uden forhåndsviden om hvordan den er opbygget. I dette tilfælde var der en rød knap som skiftede audio- og videosignalerne, men det var ikke krystalklart for brugerne hvad det præcis var der blev skiftet. Uklarheden blev ikke mindre af at den tidskode-monitor, som viser hvad vi spiller nu, lever sit eget liv med den her auto-sensing funktion. Den vender vi tilbage til. Den person der havde lavet fejlen med videoroutingen forstod eller kendte i hvert fald ikke konceptet.
Jeg foreslog derfor at den røde knap blev fyret og erstattet af 4 knapper på videomixeren og 4 fadere på lydmixeren i stedet for to. Så har vi både fjernet et single point of failure og man behøver ingen særlig forhåndsviden om hvad man skal gøre hvis man pludselig en dag skal sende fra backupserveren. Den røde knap kommer nok ikke til at forsvinde helt, da den stadig er praktisk at have til at styre hvad de to små monitors der viser videoserver-outputs skal vise. Men hvis den ikke virker nu, så sker der ikke andet end at man så må nøjes med at se hvad der er på videoserverudgangene på Program og Preview monitorne, og det kan man trods alt godt lave en udsendelse med.
Tilbage til den her tidskodemonitor. Tidskodemonitoren er bare en PC der følger med i hvad der kommer fra videoserverne og viser klipnavne og tidskoder og tilbageværende tid. Da vi langt om længe havde fået billede ind det rigtige sted på videomixeren, var der stadig problemer med at få den til at vise aktiviteten på den rigtige server. Nogen gange viste den noget dybt mystisk. Problemet viste sig at komme fra Main systemet. Autosensing-funktionen var måske fin nok hvis Main var helt væk, men det var den ikke. Den var bare så syg, at der ikke kunne afvikles fra den, men den var ikke helt nede. Så resultatet blev en lidt mystisk blanding af informationen fra Main og Backup, som ikke kunne bruges til noget som helst. Og da skift mellem Main og Backup udelukkende skete ved auto-sensing, var der ingen der anede hvordan man fik den til at holde op med det. Ved lidt fælles søgning lykkedes det dog til sidst.
Problemerne med tidskodemonitoren viser at hvis man har noget som skifter fra Main til Backup og tilbage igen automatisk, så skal man kunne slå automatikken fra og selv bestemme om vi skal bruge Main eller Backup. Og hvis automatikken betyder, at det bliver særlig svært eller kræver særlig forhåndsviden at skifte manuelt, så skal det overvejes grundigt om man er bedre stillet ved at skifte manuelt altid, eller om man fortsat ønsker automatik. I dette tilfælde er valget nemt, for her har vi i forvejen en række steder hvor man er nødt til at skifte manuelt, så her bør det hele skiftes manuelt, og når man nu har den røde knap, så kan den passende skifte det også.
Endelig var der så også en dag hvor KVM switchen til de PC’er der styrer videoserverne stod af. Så der var lige et single point of failure mere, som er opstået på grund af redundansen, som der måske også lige skal tænkes over.
