Heeft u werkelijk redundantie nodig: de echte kosten van downtime

Downtime – dat is een woord dat niemand wil horen. Het jaagt bedrijven, bestuurders en in het bijzonder IT-personeel angst aan. Downtime kost geld en veroorzaakt frustratie.

Omdat downtime een emotionele reactie oproept, reageren bedrijven er vaak anders op dan op traditionele bedrijfsfactoren. Deze emotionele benadering zorgt ervoor dat bedrijven, en met name kleinere bedrijven die vaak rationele financiële controles ontberen, downtime als veel erger behandelen dan het in werkelijkheid is. Het komt niet zelden voor dat kleinere bedrijven zichzelf in feite meer financiële schade hebben berokkend door te reageren op de angst voor potentiële downtime dan de gevreesde downtime had aangericht als die zich daadwerkelijk had voorgedaan. Dit is een gevaarlijke overreactie.

De eerste stap is het bepalen van de kosten van downtime. In de IT hebben we vaak te maken met nogal complexe systemen en komt downtime in allerlei vormen voor, zoals verlies van toegang, prestatieverlies of een volledig verlies van een systeem of meerdere systemen. Het bepalen van elk type downtime en de bijbehorende kosten kan behoorlijk complex zijn, maar een overzicht op hoofdlijnen is vaak voldoende om rationele budgetten op te stellen, of vormt op zijn minst een goed startpunt op weg naar inzicht in de bedrijfsrisico's die met downtime samenhangen. Houd er rekening mee dat, net zoals te veel uitgeven om downtime te voorkomen slecht is, ook te veel uitgeven om de kosten van downtime te berekenen slecht is. Besteed niet zoveel tijd en middelen aan het bepalen of u geld zult verliezen dat u beter af was geweest door het simpelweg te verliezen. Pas op voor de hoge kosten van besluitvorming.

We kunnen beginnen door alleen het volledige verlies van een systeem te beschouwen. Wat zijn voor u de kosten van organisatorische downtime – dat wil zeggen, als u een uur of een dag lang alle activiteiten zou moeten stilleggen, hoeveel geld gaat er dan verloren? In sommige gevallen kunnen de verliezen dramatisch zijn, zoals bij een ziekenhuis, waar een dag downtime zou leiden tot verlies van vertrouwen en van een toekomstig klantenbestand en mogelijk tot rechtszaken zou leiden. Maar in veel gevallen heeft een dag downtime nauwelijks financiële gevolgen – veel bedrijven zouden de dag simpelweg tot vrije dag kunnen verklaren, hun personeel die dag laten uitrusten en mensen de daaropvolgende dagen wat harder kunnen laten werken om de achterstand van de verloren dag in te halen. Het komt allemaal neer op hoe uw bedrijf werkt en kan werken en hoe goed u in staat bent verloren tijd op te vangen. Veel bedrijven kijken alleen naar de dagelijkse omzetcijfers om de gederfde omzet te bepalen, maar dat kan enorm misleidend zijn.

Zodra we een ruwe schatting hebben van de kosten van downtime, kunnen we vervolgens het risico op downtime beschouwen. Dit is zeer lastig in te schatten, aangezien betrouwbare cijfers over de betrouwbaarheid van IT-systemen vrijwel niet bestaan en de systemen van elke organisatie zó uniek zijn dat branchegegevens nagenoeg nutteloos zijn. We zijn hier genoodzaakt te vertrouwen op IT-personeel om een overzicht van de risico's te geven en, hopelijk, een betrouwbare inschatting van de waarschijnlijkheid van afzonderlijke risico's. Als we bijvoorbeeld, in grote ronde getallen, een bedrijfskritische toepassing hadden die draaide op een server met slechts één harde schijf, dan zouden we verwachten dat er ergens in de komende vijf tot tien jaar downtime zal optreden door het uitvallen van die schijf. Hebben we diezelfde server met hot-swap-schijven in een gespiegelde array, dan is de kans op downtime door dat opslagsysteem, zelfs over een periode van tien jaar, vrij klein. Dit betekent niet dat een schijf niet waarschijnlijk uitvalt – dat is wel zo – maar dat het systeem er waarschijnlijk geen last van heeft totdat de redundantie is hersteld, zonder dat eindgebruikers merken dat er iets is gebeurd.

Ons laatste instrument voor een ruwe schatting is het toepassen van de relevante bedrijfsuren. Veel bedrijven draaien niet 24×7, sommige uiteraard wel, maar de meeste niet. Is het verlies van een bedrijfskritische toepassing om zes uur 's avonds gelijkwaardig aan het verlies van die toepassing om tien uur 's ochtends? En in het weekend? Maken mensen er op vrijdagmiddag om drie uur productief gebruik van, of zou het verlies ervan nauwelijks iets kosten en juist zorgen voor tevreden werknemers die een uur of twee extra van hun weekend krijgen? Kunnen roosters worden aangepast bij een uitval rond lunchtijd? Deze factoren, hoe triviaal ze ook lijken, kunnen significant zijn. Als de downtime beperkt blijft tot slechts twee tot vier uur, dan kunnen veel bedrijven nagenoeg de gehele financiële impact opvangen door simpelweg werknemers te vragen wat flexibiliteit in hun rooster te tonen om de storing op te vangen, bijvoorbeeld door eerder te lunchen of op een dag eerder weg te gaan en de volgende dag een uur extra te werken.

Nu we deze factoren hebben – de kosten van downtime, het vermogen om de impact van downtime op basis van de duur te beperken en de risico's van uitvalgebeurtenissen – kunnen we beginnen een beeld te schetsen van hoe een downtimegebeurtenis er waarschijnlijk uitziet. Hieruit kunnen we vervolgens afleiden hoeveel geld het waard zou zijn om het risico op een dergelijke gebeurtenis te verkleinen. Voor sommige bedrijven zal dit bedrag uiterst hoog zijn en voor andere verrassend laag. Deze oefening kan veel blootleggen over hoe een bedrijf functioneert dat normaal gesproken niet bijzonder zichtbaar is.

Het is op dit punt belangrijk op te merken dat waar we hier naar kijken een verlies van beschikbaarheid van systemen is, en niet een verlies van gegevens. We gaan ervan uit dat er goede back-ups worden gemaakt en dat die back-ups niet zijn aangetast. Redundantie en downtime zijn geen onderwerpen die verband houden met gegevensverlies, alleen met verlies van beschikbaarheid. Scenario's van gegevensverlies dienen met gelijke of grotere zorgvuldigheid te worden behandeld, maar vormen een afzonderlijk onderwerp. Het is een zeldzaam bedrijf dat catastrofaal gegevensverlies kan overleven, maar het is gangbaar om zelfs aanzienlijke downtime te ervaren en gemakkelijk te overleven.

Er zijn meerdere manieren om downtime af te wenden; redundantie is zeer zichtbaar en wordt bijna als een modewoord behandeld en krijgt daarom veel aandacht, maar er bestaan ook andere middelen. Goed systeemontwerp is belangrijk; het vermijden van systeemcomplexiteit kan downtime sterk verminderen, simpelweg door punten van onnodig risico en kwetsbaarheid weg te nemen. Het gebruik van kwalitatief goede hardware en software is eveneens belangrijk – aangezien goedkope hardware die redundant is vaak net zo vaak uitvalt als niet-redundante hardware van enterpriseklasse. Het beschikken over een snelle toeleveringsketen van vervangende onderdelen kan een belangrijke factor zijn, vaak in de vorm van contracten met hardwareleveranciers voor de levering van vervangende onderdelen binnen vier uur. Deze lijst gaat door. Waar wij ons op zullen richten is redundantie, en dat is precies waar we het meest geneigd zijn te veel uit te geven wanneer we met de angst voor downtime worden geconfronteerd.

Nu we de kosten kennen van het ontbreken van adequate redundantie, kunnen we deze potentiële kosten vergelijken met de zeer reële kosten vooraf van het bieden van die redundantie. Sommige zaken, zoals harde schijven, vallen zeer waarschijnlijk uit en zijn relatief eenvoudig en kosteneffectief redundant te maken – waarmee een significant risico wordt genomen en getrivialiseerd. Dit zijn doorgaans de eerste aandachtspunten. Maar er zijn vele gebieden van redundantie om te overwegen, zoals voedingen, netwerkapparatuur, internetverbindingen en complete systemen – vaak redundant gemaakt door moderne virtualisatietechnieken die nieuwe mogelijkheden voor redundantie bieden die voorheen voor veel kleinere bedrijven niet toegankelijk waren.

Nieuwe vormen van redundantie, met name die welke door virtualisatie beschikbaar zijn geworden, vormen vaak een punt waarop bedrijven in de verleiding komen te veel uit te geven, mogelijk in dramatische mate, in verhouding tot de risico's van downtime. Erger nog, in de drang om de nieuwste rages op het gebied van redundantie aan te schaffen, implementeren bedrijven deze technieken vaak onjuist en introduceren ze in feite een groter risico en een grotere kans op downtime dan wanneer ze niets hadden gedaan. Het wordt steeds gangbaarder om te horen dat bedrijven tienduizenden of zelfs honderdduizenden euro's uitgeven in een poging een geldelijk verlies door downtime van slechts enkele duizenden euro's te beperken – en vervolgens in die poging te falen en hun risico hoe dan ook te vergroten.

Bij het inschatten van de kosten van beperkende maatregelen is het cruciaal te onthouden dat een beperkende maatregel een gegarandeerde uitgave is, terwijl een risico slechts een risico is. Vergelijkbaar met een autoverzekering, waarbij u een gegarandeerd klein maandbedrag betaalt om een enorme, onverwachte uitgave af te wenden. De gedachte achter risicobeperking is om nu een betrekkelijk klein bedrag uit te geven om het risico op een grote uitgave later te verkleinen, maar als de kosten van de beperkende maatregel te hoog worden, dan wordt het beter om de risico's simpelweg te aanvaarden.

Systemen kunnen uiteraard afzonderlijk worden beoordeeld. Het te allen tijde operationeel houden van een webaanwezigheid en een telefoonsysteem is veel belangrijker dan een e-mailsysteem, waarbij zelfs uren van downtime waarschijnlijk niet door externe klanten waarneembaar zijn. Alleen betalen om die systemen te beschermen waarbij de kosten van downtime significant zijn, is een belangrijke strategie.

Wees niet verbaasd als wat u ontdekt is dat, afgezien van enige zeer basale redundantie (zoals gespiegelde harde schijven), een eenvoudig netwerkontwerp met goede back-ups en herstelplannen en een goed hardware-ondersteuningscontract alles is wat nodig is voor het merendeel, zo niet alle, van uw systemen. Door de complexiteit van uw systemen te verlagen, maakt u ze van nature stabieler en eenvoudiger te beheren – waarmee u de kosten van uw IT-infrastructuur verder verlaagt.