Wanneer hoge beschikbaarheid overwegen?

“Hoge beschikbaarheid is niet iets dat je koopt, het is iets dat je doet.” – John Nicholson

Weinig zaken worden in de IT zo universeel begeerd als oplossingen voor hoge beschikbaarheid (HA). Ik bedoel echt, spreek die woorden uit en elke IT-professional zal meteen zeggen dat hij dat wil. HA voor hun servers, hun applicaties, hun opslag en, natuurlijk, zelfs hun desktops. Als er naast elk systeem een selectievakje zou staan met simpelweg “HA”, waarom zouden we dat dan niet aanvinken? We zouden het natuurlijk doen. Niemand wil vrijwillig een systeem dat veel uitvalt. Falen slecht, slagen goed.

Eerst moeten we echter HA definiëren. HA kan vele dingen betekenen. Ten minste moet HA betekenen dat de beschikbaarheid van het betreffende systeem hoger moet zijn dan “normaal”. Wat is normaal? Dat alleen al is moeilijk genoeg te definiëren. HA is op zijn best een vage term. In de context van het meest gangbare gebruik ervan, namelijk gangbare applicaties die draaien op normale enterprisehardware, zou ik echter het volgende uitgangspunt voor HA-discussies willen voorstellen:

Normale of standaardbeschikbaarheid (SA) zou worden gedefinieerd als de beschikbaarheid van een gangbare mainline-server die een gangbaar enterprisebesturingssysteem draait, met een gangbare enterpriseapplicatie, in een omgeving die volgens best practices is ingericht en met enterpriseondersteuning. Goede voorbeelden hiervan zouden Exchange kunnen zijn dat draait op Windows Server op de HP Proliant DL380 (de meest gangbare mainline-commodityserver). Of BIND (de DNS-server) die draait op Red Hat Enterprise Linux op de Dell PowerEdge R730. Dit zijn slechts voorbeelden om een ruwe basislijn vast te stellen. Er is geen geweldige manier om dit te meten, maar met een goed ondersteuningscontract en snelle reparatie of vervanging in de praktijk wordt aangenomen dat de betrouwbaarheid van een systeem van deze aard tussen de vier en vijf negens van betrouwbaarheid ligt (99,99% uptime of hoger) wanneer menselijk falen niet wordt meegerekend.

Hoge beschikbaarheid (HA) zou gewoonlijk gedefinieerd moeten worden als het hebben van een beschikbaarheid die aanzienlijk hoger is dan die van standaardbeschikbaarheid. Aanzienlijk hoger zou een toename van minimaal één orde van grootte moeten zijn. Dus ten minste vijf negens van betrouwbaarheid en waarschijnlijker zes negens. (99,9999% uptime.)

Lage beschikbaarheid (LA) zou gewoonlijk gedefinieerd worden als het hebben van een beschikbaarheid die aanzienlijk lager is dan die van standaardbeschikbaarheid, waarbij aanzienlijk opnieuw ten minste één orde van grootte betekent. LA zou dus doorgaans worden verondersteld rond de 99% tot 99,9% of een lagere beschikbaarheid te liggen.

Meten is hier zeer lastig, aangezien menselijke factoren, omgevingsfactoren en andere een enorme rol spelen bij het bepalen van de uptime van verschillende configuraties. Dezelfde apparatuur die in de ene rol wordt gebruikt, kan vijf negens halen, terwijl ze in een andere rol er niet eens één haalt. De kwaliteit van het datacenter, de vaardigheid van de ondersteuningsmedewerkers, de snelheid van onderdelenvervanging, de granulariteit van de monitoring en een veelheid aan andere factoren zullen de algehele betrouwbaarheid aanzienlijk beïnvloeden. Dit hoeft echter niet noodzakelijkerwijs een probleem voor ons te zijn. In de meeste gevallen kunnen we de onderdelen van een systeemontwerp die wij wel beheersen zodanig evalueren dat de relatieve betrouwbaarheid kan worden vastgesteld, zodat we ten minste kunnen aantonen dat de ene aanpak superieur zal zijn aan de andere, opdat we vervolgens goed onderbouwde besluitvorming kunnen benutten, zelfs als er niet eenvoudig nauwkeurige faalkansmodellen kunnen worden gebouwd.

Het is belangrijk om op te merken dat er, behalve het verschaffen van een voorbeeldset aan basislijnvoorbeelden om mee te werken, niets in de definities van hoge beschikbaarheid of lage beschikbaarheid staat dat zegt hoe deze niveaus bereikt zouden moeten worden – dat is niet wat de termen betekenen. De termen zijn resulterende reeksen van betrouwbaarheid in relatie tot de basislijn en niets anders. Er zijn veel manieren om hoge beschikbaarheid te bereiken zonder de algemeen veronderstelde benaderingen te gebruiken, en praktisch onbeperkte manieren om lage beschikbaarheid te bereiken.

Uiteraard kan HA op elke laag worden gedefinieerd. We kunnen HA-platforms of -besturingssystemen hebben maar daarbovenop kwetsbare applicaties. Het is dus erg belangrijk om te begrijpen over welk niveau we het op een bepaald moment hebben. Uiteindelijk geeft een bedrijf alleen om de hoogbeschikbare levering van diensten, ongeacht hoe die wordt bereikt, of waar. Het eindresultaat is wat telt, niet de details onder de motorkap van hoe het werd bereikt of, zoals altijd, het doel heiligt de middelen.

Het is vandaag de dag buitengewoon gangbaar dat IT-afdelingen worden afgeleid door nieuwe en opzichtige HA-tools op de platformlaag en vergeten om hoger en lager in de stack naar HA te kijken om ervoor te zorgen dat we hoogbeschikbare diensten aan het bedrijf leveren; in plaats van alleen naar die ene laag te kijken terwijl het bedrijf net zo kwetsbaar, of nog kwetsbaarder, blijft dan ooit.

In de praktijk is HA echter niet altijd een optie en, wanneer het dat wel is, brengt het kosten met zich mee. Die kosten zijn vrijwel altijd geldelijk en gaan over het algemeen ook gepaard met extra complexiteit. En zoals we maar al te goed weten, draagt elke complexiteit ook extra risico met zich mee, en dat risico zou, als we niet voorzichtig zijn, ervoor kunnen zorgen dat een poging om HA te bereiken juist mislukt en ons zelfs zou kunnen achterlaten met LA, oftewel lage beschikbaarheid.

Zodra we deze noodzakelijke taal begrijpen om te beschrijven wat we bedoelen, kunnen we beginnen te praten over wanneer hoge beschikbaarheid, standaardbeschikbaarheid en zelfs lage beschikbaarheid voor ons geschikt kunnen zijn. We hanteren dit hoge niveau van granulariteit omdat het zo moeilijk is om de betrouwbaarheid van een systeem te meten dat te gedetailleerd worden waardeloos wordt.

Conceptueel brengen alle systemen een risico op downtime met zich mee en kan niets altijd beschikbaar zijn, dat is onmogelijk. Betrouwbaarheid kost over het algemeen geld, als alle andere zaken gelijk zijn. Dus om te bepalen welk niveau van beschikbaarheid het meest geschikt is voor een workload, moeten we de kosten van risicobeperking bepalen (het geldbedrag dat nodig is om de gemiddelde hoeveelheid downtime te wijzigen) en dat afzetten tegen de kosten van de downtime zelf.

Dit wordt lastig en ingewikkeld, omdat het bepalen van de kosten van downtime al moeilijk genoeg is, en het vervolgens bepalen van het risico op downtime nog moeilijker is. In veel gevallen is downtime geen vast bedrag, maar het zou het kunnen zijn. Deze kosten zouden uitgedrukt kunnen worden als $5/minuut of $20K/dag of iets dergelijks. Maar een nog beter instrument zou zijn om een “verliesimpactcurve” te maken die laat zien hoe er in de loop van de tijd (binnen een redelijk interval) geld verloren gaat.

Zo zou een bedrijf de eerste vijf minuten gemakkelijk helemaal geen verlies kunnen lijden, met langzaam oplopende maar kleine verliezen tot ongeveer vier uur, wanneer het werk stilvalt omdat mensen niet langer kunnen terugvallen op papier of wat dan ook, en de verliezen dan van bijna nul naar behoorlijk groot gaan. Of sommige bedrijven lijden mogelijk een enorm verlies op het moment dat de systemen uitvallen, maar de verliezen ebben in de loop van de tijd langzaam weg. Verlies is misschien alleen op bepaalde momenten van de dag van betekenis. Misschien zijn storingen 's nachts of tijdens de lunch onbeduidend, maar zijn ze midden op de ochtend of midden in de middag ingrijpend. De impact, het risico en het vermogen om dat risico te beperken zijn voor elk bedrijf anders, vaak ingrijpend anders.

Soms komt het neer op de mensen die bij het bedrijf werken. Zullen ze allemaal blijmoedig hun noodzakelijke toilet-, koffie-, snack- of zelfs lunchpauzes nemen op het moment dat een systeem uitvalt, zodat ze weer aan het werk kunnen wanneer het is gerepareerd? Zullen mensen vroeg naar huis gaan en morgen vroeg komen om een grote storing in te halen? Is er machinerie die stil zal staan? Wordt het vermogen om op klanten te reageren beïnvloed? Zullen levensondersteunende systemen uitvallen? Er zijn talloze mogelijke gevolgen en talloze mogelijke manieren om verschillende soorten storingen te beperken. Dit alles moet worden overwogen. De kosten van downtime zijn misschien op minuutbasis een fractie van de bedrijfsomzet, of downtime kan een verlies aan klanten of vertrouwen veroorzaken dat ingrijpender is dan de op minuutbasis gegenereerde omzet.

Zodra we enkele ruwe verliescijfers hebben om mee te werken, hebben we op zijn minst een uitgangspunt. Zelfs als we alleen weten dat de omzet ~$10/minuut bedraagt en de verliezen naar verwachting rond de ~$5/minuut liggen, hebben we een soort uitgangspunt. Als we een volledige curve hebben of een onderzoek met wat gedetailleerdere cijfers, des te beter. Nu moeten we grofweg uitvogelen wat onze basislijn gaat zijn. Een goed onderhouden server, die op locatie draait, met een goed ondersteuningscontract en goede back-up- en herstelprocedures, kan vrij gemakkelijk vier negens van betrouwbaarheid halen. Dat betekent dat we ongeveer vijf uur downtime per vijf jaar zouden ervaren. Dit is in de meeste omgevingen feitelijk minder dan de over het algemeen verwachte downtime van SA, en mogelijk veel minder dan de verwachte niveaus in uitstekende omgevingen zoals datacenters van hoge kwaliteit met onderdelen en service in de buurt.

Dus op basis van ons voorbeeldbasislijn van ongeveer vijf uur per vijf jaar kunnen we ons potentiële risico uitrekenen. Als we ongeveer ~$5/minuut verliezen en we grofweg 300 minuten downtime per vijf jaar verwachten, kijken we tegen een potentieel verlies van $1.500 per half decennium aan.

Dat betekent dat we, op zijn extreemst, nooit $1.500 zouden kunnen uitgeven om dat risico te beperken; dat zou financieel absurd zijn. Dit gebeurt om verschillende redenen. Een van de grootste is dat dit slechts een risico is; $1.500 uitgeven om bescherming te bieden tegen het verliezen van $1.500 slaat nergens op, maar het is een veelgemaakte fout wanneer mensen deze cijfers niet zorgvuldig analyseren.

De grootste factor is dat geen enkele beperkingstechniek volledig effectief is. Als we erin slagen om ons systeem met vier negens naar een systeem met vijf negens te brengen, zouden we slechts 90% van de gemiddelde downtime verminderen, waardoor we van $1.500 verlies naar $150 verlies gaan. Als we $1.500 zouden uitgeven voor die vermindering, zou het totale “verlies” nog steeds $1.650 bedragen (de kosten van bescherming zijn een vorm van financieel verlies). De kosten van de risicobeperking, gecombineerd met de verwachte resterende impact, moeten samengenomen nog steeds lager zijn dan de verwachte kosten van het risico zonder beperking, anders is de beperking zelf zinloos of zelfs actief schadelijk.

Velen zullen zich misschien afvragen waarom de totale kosten van risicobeperking lager moeten zijn en niet simpelweg gelijk, want dat moet toch zeker betekenen dat we ons op een “break-evenpunt qua risico” bevinden? Aan de oppervlakte lijkt dit waar, maar omdat we met risico te maken hebben, is dit niet het geval. Risicobeperking brengt zekere kosten met zich mee: financiële schade die we vooraf op ons nemen in de hoop de verliezen van morgen te verminderen. Maar het risico voor morgen is een gok, hopelijk een goed onderbouwde, maar slechts een gok. De kosten van vandaag zijn zeker. Vandaag zekere schade op je nemen in de hoop mogelijke schade van morgen te verminderen, is alleen zinvol wanneer de schade van vandaag klein is en de verwachte of mogelijke schade van morgen zeer groot is en de effectiviteit van de beperking aanzienlijk is.

In het idee van “zekere kosten vooraf” om “mogelijke kosten morgen” te verminderen, zit het idee van de tijdswaarde van geld besloten. Zelfs als een storing van een bekende omvang en duur zou zijn, zouden we niet hetzelfde geld vandaag uitgeven om die morgen te beperken, omdat ons geld vandaag waardevoller is.

In de meest dramatische gevallen zien we soms IT-afdelingen die eisen dat er tienduizenden of honderdduizenden dollars vooraf worden uitgegeven om een paar duizend dollar te vermijden, misschien, ooit, misschien pas over vele jaren in de toekomst. Een strategie die we kunnen omschrijven als “onszelf vandaag in het gezicht schieten om morgen misschien hoofdpijn te voorkomen.”

Het zit besloten in het concept van het evalueren van de risicobeperking, maar het zou specifiek vermeld moeten worden dat er in het geval van IT-apparatuur veel voorbeelden zijn van pogingen tot risicobeperking die mogelijk niet zo effectief zijn als men gelooft. Twee servers die bijvoorbeeld in hetzelfde rack staan, zullen mogelijk zeer effectief zijn voor het beperken van het risico op het uitvallen van de hosthardware, maar zullen niet beschermen tegen natuurrampen, het verlies van een locatie, brand, de meeste gevallen van elektrische schokken, het in werking treden van een brandblussysteem, netwerkonderbrekingen, de meeste applicatiestoringen, een ransomwareaanval of andere redelijkerwijs mogelijke rampen.

Het is gangbaar dat opslagapparaten zijn uitgerust met “dubbele controllers”, wat een sterke indruk van hoge betrouwbaarheid wekt, maar over het algemeen bevinden deze controllers zich binnen één enkel chassis met gedeelde componenten, en zelfs als de componenten niet worden gedeeld, wordt de firmware vaak wel gedeeld en is de communicatie tussen componenten complex; wat er vaak toe leidt dat het uitvallen van één component het uitvallen van een andere veroorzaakt – waardoor het nogal eens LA-apparaten worden in plaats van de SA, of de HA, die men verwachtte bij de aanschaf ervan. Het is dus van groot belang om te overwegen of de risicobeperkingsstrategie welke risico's zal beperken en of de beperkingstechniek waarschijnlijk effectief zal zijn. Geen enkele techniek is volledig effectief, er is altijd een kans op falen, maar sommige strategieën en technieken zijn breder effectief dan andere en sommige zijn simpelweg misleidend of zelfs daadwerkelijk contraproductief. Als we niet voorzichtig zijn, implementeren we mogelijk kostbare producten of technieken die onze doelen actief ondermijnen.

Sommige technieken en producten die worden ingezet bij het streven naar hoge beschikbaarheid zijn nogal duur, waaronder de aanschaf van redundante hardware, het huren van een ander gebouw, het installeren van dure generatoren of het in licentie nemen van speciale software. Er zijn ook goedkope technieken en software, maar in de meeste gevallen zal elke beweging richting hoge beschikbaarheid resulteren in een navenant grote uitgave aan investeringskapitaal om die te bereiken. Het is absoluut cruciaal om in gedachten te houden dat hoge beschikbaarheid een proces is; er is geen manier om hoge beschikbaarheid simpelweg te kopen. Het bereiken van HA vereist goede documentatie, procedures, planning, ondersteuning, apparatuur, engineering en meer. In de systeemwereld wordt HA normaal gesproken eerst vanuit een omgevingsperspectief benaderd, met failover-stroomgeneratoren, redundante HVAC-systemen, stroomconditionering, luchtfiltering, brandblussystemen en meer om te waarborgen dat de omgeving voor de beschikbaarheid aanwezig is. Dit alleen al kan verdere investeringen vaak onnodig maken, omdat dit ongelooflijke resultaten kan opleveren. Vervolgens komt het ontwerp van een HA-systeem, dat ervoor zorgt dat niet alleen één laag van een technologiestack hoogbeschikbaar is, maar dat de hele stack het mogelijk maakt dat de kritieke applicaties, gegevens of diensten zo veel mogelijk van de tijd functioneel blijven. Daarna kijken we naar redundantie tussen locaties om bestand te zijn tegen overstromingen, orkanen, sneeuwstormen, enzovoort. Uiteraard zijn er compleet andere technieken, zoals het benutten van cloudcomputingdiensten die op afstand namens ons worden gehost. Wat ertoe doet, is dat hoge beschikbaarheid breed denken en plannen vereist, niet simpelweg als een regelitem kan worden aangeschaft en wordt beoordeeld op het vermogen om een risicofactor terug te dringen die resulteert in een uptime, of waarschijnlijkheid van uptime, die veel hoger is dan een “standaard” systeemontwerp zou opleveren.

Wat voor veel bedrijven, en vooral voor IT-professionals, die zelden financiële risicoanalyses uitvoeren en die voortdurend te horen krijgen dat HA een noodzaak is voor elk bedrijf en dat het kopen van de nieuwste HA-producten zonder enige twijfel de manier is waarop hun budgetten besteed zouden moeten worden, vaak verrassend, bijna schokkend is, is dat wanneer de cijfers worden doorgerekend en de realiteit van de kosten en de effectiviteit van risicobeperkingsstrategieën in overweging worden genomen, hoge beschikbaarheid maar zeer weinig plaats heeft binnen welke organisatie dan ook, vooral organisaties die klein zijn of die sterk uiteenlopende workloads hebben. In de markt voor het midden- en kleinbedrijf is het bijna universeel om te ontdekken dat de kosten en complexiteit (die op hun beurt risico met zich meebrengen, voornamelijk in de vorm van een gebrek aan ervaring rond technieken en risicobeoordeling) van benaderingen voor hoge beschikbaarheid veel te duur zijn om ooit op te wegen tegen de potentiële schade van de storing waartegen de beperking geacht wordt te beschermen. Er zijn natuurlijk uitzonderingen, en er zijn veel bedrijven waarvoor oplossingen voor hoge beschikbaarheid absoluut zinvol zijn, maar dit zijn de uitzonderingen en verre van de norm.

Het is ook verstandig om de behoefte aan hoge beschikbaarheid op basis van een workload te beschouwen en niet afdelings-, bedrijfs- of technologiebreed. In een klein bedrijf is het gangbaar dat alle workloads een gemeenschappelijk platform delen, en de behoefte van één enkele workload aan hoge beschikbaarheid kan andere, minder kritieke workloads mee de hoogte in trekken. Dit is volkomen prima en een uitstekende manier om de kosten van de risicobeperking van de kritieke workload te compenseren via een bijkomend voordeel voor de minder kritieke workloads. In een grotere organisatie waar een overvloed aan platformbenaderingen wordt gebruikt voor uiteenlopende workloads, is het gangbaar dat alleen op bepaalde workloads die zowel zeer kritiek zijn (in termen van risico door de impact van downtime) als waarbij het risico praktisch te beperken is (het vermogen om risico te beperken kan dramatisch verschillen tussen verschillende soorten workloads) hoge beschikbaarheid wordt toegepast, en dat andere workloads aan standaardtechnieken worden overgelaten.

Voorbeelden van workloads die kritiek kunnen zijn en effectief met hoge beschikbaarheid kunnen worden aangepakt, zijn bijvoorbeeld een onlinebestelsysteem waarbij de latentie die door multiregionale replicatie ontstaat weinig impact heeft op het algehele systeem, maar waarbij het verliezen van bestellingen financieel zeer ingrijpend zou kunnen zijn mocht een systeem uitvallen. Een voorbeeld van een workload waarbij hoge beschikbaarheid eenvoudig te implementeren maar nutteloos zou zijn, is een interne intranetsite die veelgestelde HR-vragen bedient; het zou simpelweg niet kosteneffectief zijn om kleine hoeveelheden incidentele downtime voor een systeem als dit te vermijden. Een voorbeeld van een systeem waarbij het risico hoog is maar de kosten of de effectiviteit van risicobeperking het onpraktisch of zelfs onmogelijk maken, zou een financiële “tick”-database kunnen zijn die enorme hoeveelheden gegevens met lage latentie moet inlezen, waarbij het vermogen om een replica te onderhouden niet alleen ongelooflijk kostbaar zou zijn, maar ook latentie zou kunnen introduceren die het vermogen van het systeem om adequaat te presteren zou ondermijnen. Elk bedrijf en elke workload is uniek en zou zorgvuldig geëvalueerd moeten worden.

Technieken voor hoge beschikbaarheid kunnen uiteraard in fasen worden uitgevoerd; het is geen alles-of-nietsonderneming. Het zou praktisch kunnen zijn om het risico op falen op systeemniveau te beperken door fouttolerantie op de applicatielaag te hebben die beschermt tegen het uitvallen van systeemhardware, het virtualisatieplatform of de opslag. Maar voor diezelfde workload zou het misschien niet waardevol zijn om te beschermen tegen het verlies van één enkele locatie. Als een workload slechts één bepaalde locatie bedient of simpelweg niet waardevol genoeg is voor de grote investering die nodig is om hem tussen locaties te laten failoveren, zou hij gemakkelijk “in het midden” kunnen vallen. Het is heel gangbaar dat voor workloads slechts gedeeltelijk hoogbeschikbare oplossingen worden geïmplementeerd, vaak omdat een IT-afdeling mogelijk slechts voor een deel ervan verantwoordelijk is en geen zeggenschap heeft over zaken als stroomvoorziening en HVAC, maar waarschijnlijk het meest gangbaar omdat sommige technieken voor hoge beschikbaarheid worden gezien als zichtbaar en eenvoudig aan het management te verkopen, terwijl andere, zoals stroom en airconditioning van hoge kwaliteit, dat vaak niet zijn, ook al leveren ze mogelijk gemakkelijk meer waar voor je geld. Er zijn goede redenen waarom bepaalde technieken wel en andere niet gekozen kunnen worden, aangezien ze verschillende risicocomponenten beïnvloeden en sommige risico's een uiteenlopende impact kunnen hebben op een individueel bedrijf of een individuele workload.

Hoge beschikbaarheid vereist zorgvuldig nadenken over de vraag of het de moeite van het overwegen waard is en nog zorgvuldiger nadenken over de implementatie. Het bouwen van echte HA-systemen vereist een aanzienlijke hoeveelheid inspanning en expertise en over het algemeen substantiële kosten. Begrijpen welke onderdelen van HA waardevol zijn en welke niet, vereist niet alleen uitgebreide technische expertise, maar ook financiële en managementvaardigheden. Afdelingen moeten intensief samenwerken om werkelijk te begrijpen hoe HA een organisatie zal beïnvloeden en wanneer het de investering waard zal zijn. Het is cruciaal om in herinnering te houden dat de behoefte aan hoge beschikbaarheid in een organisatie of voor een workload allesbehalve een uitgemaakte zaak is en het zou in het minst niet verrassend moeten zijn om te ontdekken dat uitgebreide hoogbeschikbaarheidspraktijken of zelfs terloopse hoogbeschikbaarheidspraktijken economisch onpraktisch blijken te zijn.

In veel opzichten komt dit doordat standaardbeschikbaarheid een zodanig niveau heeft bereikt dat er steeds minder risico te beperken valt. Technologiecomponenten die in een bedrijfsinfrastructuur worden gebruikt, met name servers, netwerkapparatuur en opslag, zijn zo betrouwbaar geworden dat de hoeveelheid downtime waartegen we ons moeten beschermen vrij laag is. Het grootste deel van het geloof in de noodzaak van reflexmatige hoge beschikbaarheid komt uit een ander tijdperk, toen betrouwbare hardware onbetaalbaar was en zelfs de duurste apparatuur naar moderne maatstaven nogal onbetrouwbaar was. Dit gevoel van dreigend onheil dat elk apparaat op elk moment zou kunnen uitvallen, komt uit een ouder tijdperk, niet het huidige. Moderne apparatuur is, hoewel uiteraard nog steeds met risico's behept, verbazingwekkend betrouwbaar.

Naast andere risico's brengt het overinvesteren in oplossingen voor hoge beschikbaarheid financiële en zakelijke risico's met zich mee die substantieel kunnen zijn. Het verhoogt de technische schuld in het aangezicht van zakelijke onzekerheid. Wat als het bedrijf plotseling groeit, of erger nog, wat als het plotseling krimpt, van richting verandert, wordt overgenomen of volledig ophoudt te bestaan? De investering in de hoge beschikbaarheid is al uitgegeven, ook al verdwijnt de behoefte aan de bescherming ervan. Wat als de technologie of de locatie verandert? Een deel of de gehele investering in hoge beschikbaarheid zou verloren kunnen gaan voordat die het einde van haar verwachte levensduur zou hebben bereikt.

Als IT-professionals vormt het evalueren van de voordelen, risico's en kosten van technologieoplossingen de kern van wat we doen. Net als al het andere in een bedrijfsinfrastructuur is het bepalen van het soort risicobeperking, de waarde van bescherming en hoeveel financieel gepast is onze kernverantwoordelijkheid die niet kan worden afgedaan of genegeerd. We kunnen nooit zomaar aannemen dat hoge beschikbaarheid nodig is, noch dat die simpelweg kan worden overgeslagen. Het is in analyses van deze aard dat de IT enkele van haar grootste waarde aan organisaties levert. Het is hier dat we de meeste kans hebben om het meest te schitteren.