Når bør man vurdere høy tilgjengelighet?

“Høy tilgjengelighet er ikke noe du kjøper, det er noe du gjør.” – John Nicholson

Få ting er mer universelt ønsket innen IT enn løsninger for høy tilgjengelighet (HA). Si de ordene, og enhver IT-fagperson vil umiddelbart si at de vil ha det. HA for serverne sine, appene sine, lagringen sin og, selvsagt, selv skrivebordene sine. Hvis det var en avkrysningsboks ved siden av et hvilket som helst system som ganske enkelt sa “HA”, hvorfor skulle vi ikke krysse av? Det ville vi selvfølgelig. Ingen ønsker frivillig et system som feiler mye. Feil er dårlig, suksess er bra.

Først må vi imidlertid definere HA. HA kan bety mange ting. Som et minimum må HA bety at tilgjengeligheten til det aktuelle systemet er høyere enn “normalt”. Hva er normalt? Det alene er vanskelig nok å definere. HA er et løst begrep, i beste fall. I konteksten av den vanligste bruken, som er vanlige applikasjoner som kjører på vanlig enterprise-maskinvare, vil jeg tilby dette utgangspunktet for HA-diskusjoner:

Normal eller standard tilgjengelighet (SA) ville bli definert som tilgjengeligheten fra en vanlig mainline-server som kjører et vanlig enterprise-operativsystem som kjører en vanlig enterprise-applikasjon i et miljø med god praksis og enterprise-støtte. Gode eksempler på dette kan inkludere Exchange som kjører på Windows Server på HP Proliant DL380 (den vanligste mainline commodity-serveren). Eller BIND (DNS-serveren) som kjører på Red Hat Enterprise Linux på Dell PowerEdge R730. Disse er bare eksempler som brukes for å etablere en grov referanseverdi. Det er ingen god måte å måle dette på, men med en god støtteavtale og rask reparasjon eller utskifting i den virkelige verden, antas påliteligheten til et system av denne typen å være mellom fire og fem niere av pålitelighet (99,99 % oppetid eller høyere) når menneskelig svikt ikke er inkludert.

Høy tilgjengelighet (HA) bør vanligvis defineres som å ha en tilgjengelighet som er betydelig høyere enn standard tilgjengelighet. Betydelig høyere bør være minimum én størrelsesorden økning. Så minst fem niere av pålitelighet og mer sannsynlig seks niere. (99,9999 % oppetid.)

Lav tilgjengelighet (LA) ville vanligvis bli definert som å ha en tilgjengelighet som er betydelig lavere enn standard tilgjengelighet, med betydelig, igjen, som betyr minst én størrelsesorden. Så LA ville vanligvis antas å være rundt 99 % til 99,9 % eller lavere tilgjengelighet.

Måling her er svært vanskelig ettersom menneskelige faktorer, miljøfaktorer og andre spiller en massiv rolle i å bestemme oppetiden til forskjellige konfigurasjoner. Det samme utstyret brukt i én rolle kan oppnå fem niere, mens det i en annen feiler i å oppnå selv én. Kvaliteten på datasenteret, ferdighetene til supportstaben, hastigheten på delsutskiftning, granulariteten i overvåking og en mengde andre faktorer vil påvirke den totale påliteligheten betydelig. Dette er ikke nødvendigvis et problem for oss. I de fleste tilfeller kan vi evaluere de delene av et systemdesign som vi kontrollerer på en slik måte at relativ pålitelighet kan bestemmes, slik at vi i det minste kan vise at én tilnærming vil være bedre enn en annen, for at vi deretter kan utnytte velbegrunnet beslutningstaking selv om nøyaktige feilratemodeller ikke lett kan bygges.

Det er viktig å merke seg at bortsett fra å gi et sett med eksempler som et referansepunkt, er det ingenting i definisjonene av høy tilgjengelighet eller lav tilgjengelighet som snakker om hvordan disse nivåene bør oppnås – det er ikke det begrepene betyr. Begrepene er resulterende sett av pålitelighet i forhold til referansen og ingenting annet. Det er mange måter å oppnå høy tilgjengelighet på uten å bruke vanlig antatte tilnærminger, og praktisk talt ubegrensede måter å oppnå lav tilgjengelighet på.

Selvfølgelig kan HA defineres på hvert lag. Vi kan ha HA-plattformer eller operativsystemer, men ha sårbare applikasjoner på toppen. Så det er svært viktig å forstå på hvilket nivå vi snakker til enhver tid. Til syvende og sist vil en bedrift bare bry seg om leveransen av tjenester med høy tilgjengelighet, uavhengig av hvordan det oppnås, eller hvor. Sluttresultatet er det som betyr noe, ikke detaljene «under panseret» om hvordan det ble oppnådd eller, som alltid, målet helliger midlet.

Det er svært vanlig i dag at IT-avdelinger blir distrahert av nye og flotte HA-verktøy på plattformlaget og glemmer å se etter HA høyere og lavere i stakken for å sikre at vi leverer tjenester med høy tilgjengelighet til bedriften; i stedet for bare å se på ett lag mens vi lar bedriften være like sårbar, eller mer sårbar, enn noen gang.

I den virkelige verden er imidlertid HA ikke alltid et alternativ, og når det er det, har det en kostnad. Den kostnaden er nesten alltid monetær og kommer generelt med ekstra kompleksitet i tillegg. Og som vi godt vet, bærer enhver kompleksitet også ytterligere risiko, og den risikoen kan, hvis vi ikke er forsiktige, føre til at et forsøk på å oppnå HA faktisk feiler, og kan til og med etterlate oss med LA eller lav tilgjengelighet.

Når vi forstår dette nødvendige språket for å beskrive hva vi mener, kan vi begynne å snakke om når høy tilgjengelighet, standard tilgjengelighet og til og med lav tilgjengelighet kan passe for oss. Vi bruker dette høye granularitetsnivået fordi det er så vanskelig å måle systempålitelighet at det å bli for detaljert blir verdiløst.

Konseptuelt bærer alle systemer risiko for nedetid, og ingenting kan alltid være oppe – det er umulig. Pålitelighet koster penger, generelt, alt annet likt. For å bestemme hvilket tilgjengelighetsnivå som er mest passende for en arbeidsbelastning, må vi bestemme kostnaden for risikoreduksjon (mengden penger det tar å endre den gjennomsnittlige nedetiden) og sammenligne det med kostnaden for selve nedetiden.

Dette blir vanskelig og komplisert fordi det er vanskelig nok å bestemme kostnaden for nedetid, og deretter er det enda vanskeligere å bestemme risikoen for nedetid. I mange tilfeller er nedetid ikke et fast tall, men det kan det være. Denne kostnaden kan uttrykkes som 50 kr/minutt eller 200 000 kr/dag eller lignende. Men et enda bedre verktøy ville være å lage en «tapsvirkning­skurve» som viser hvordan penger tapes over tid (innenfor et rimelig intervall.)

For eksempel kan et selskap lett ikke oppleve noe tap i det hele tatt de første fem minuttene, med sakte tiltagende, men små, tap frem til omtrent fire timer, når arbeidet stopper fordi folk ikke lenger kan gå over til papir eller hva som helst, og tapene går fra nesten null til ganske store. Eller noen selskaper kan ta et stort tap i det øyeblikket systemene er nede, men tapene sakte avtar over tid. Tap kan bare ha effekt på bestemte tider på dagen. Kanskje avbrudd om natten eller i lunsjtiden er trivielle, men midt på formiddagen eller ettermiddagen er store. Hvert selskaps påvirkning, risiko og evne til å redusere den risikoen er forskjellig, ofte dramatisk.

Noen ganger handler det om menneskene som jobber i selskapet. Vil de alle gjerne ta nødvendige bad-, kaffe-, snacks- eller lunsjpauser på det tidspunktet et system feiler, slik at de kan gå tilbake til arbeidet når det er fikset? Vil folk gå hjem tidlig og komme inn tidlig i morgen for å kompensere for et større avbrudd? Er det maskiner som skal stå stille? Vil evnen til å svare på kunder bli påvirket? Vil livsstøtte­systemer svikte? Det er utallige potensielle virkninger og utallige potensielle måter å redusere forskjellige typer svikt på. Alt dette må vurderes. Kostnaden for nedetid kan være en brøkdel av bedriftsinntektene per minutt, eller nedetid kan forårsake et tap av kunder eller tillit som er mer virkningsfull enn inntektene generert per minutt.

Når vi har noen grove tapstall å forholde oss til, har vi i det minste et utgangspunkt. Selv om vi bare vet at inntekten er ~1 000 kr/minutt og tapene forventes å være rundt ~500 kr/minutt, har vi et slags utgangspunkt. Hvis vi har en fullstendig kurve eller en studie gjort med noen mer detaljerte tall, desto bedre. Nå må vi finne ut omtrent hva vår referanseverdi vil være. En godt vedlikeholdt server, kjørende lokalt, med en god støtteavtale og gode sikkerhets­kopierings- og gjenopprettings­prosedyrer kan ganske enkelt oppnå fire niere av pålitelighet. Det betyr at vi ville oppleve omtrent fem timer nedetid hvert femte år. Dette er faktisk mindre enn den generelt forventede nedetiden til SA i de fleste miljøer, og potensielt langt mindre enn forventede nivåer i utmerkede miljøer som høykvalitets datasentre med nærliggende deler og service.

Basert på vårt referanseeksempel på omtrent fem timer hvert femte år kan vi finne ut vår potensielle risiko. Hvis vi taper omtrent ~500 kr/minutt og forventer omtrent 300 minutter nedetid hvert femte år, ser vi på et potensielt tap på 150 000 kr hvert halvt tiår.

Det betyr at vi i det mest ekstreme tilfellet aldri kunne bruke 150 000 kr for å redusere den risikoen – det ville være økonomisk absurd. Dette skjer av flere grunner. En av de største er at dette bare er en risiko; å bruke 150 000 kr for å beskytte mot å miste 150 000 kr gir liten mening, men det er en svært vanlig feil å gjøre når folk ikke analyserer disse tallene nøye.

Den største faktoren er at enhver reduksjonsteknikk ikke er helt effektiv. Hvis vi klarer å flytte vårt fire-niere system til et fem-niere system, ville vi redusere bare 90 % av gjennomsnittlig nedetid, og flytte oss fra 150 000 kr i tap til 15 000 kr i tap. Hvis vi brukte 150 000 kr for den reduksjonen, ville det totale «tapet» fortsatt være 165 000 kr (kostnaden for beskyttelse er en form for økonomisk tap.) Kostnaden for risikoreduksjonen kombinert med den forventede gjenværende effekten, tatt sammen, må fortsatt være lavere enn den forventede kostnaden for risikoen uten reduksjon, ellers er reduksjonen selv meningsløs eller aktivt skadelig.

Mange kan spørre hvorfor den totale kostnaden for risikoreduksjon må være lavere og ikke bare lik, ettersom det sikkert betyr at vi er ved et «risikojevnt» punkt? Dette virker sant på overflaten, men fordi vi har med risiko å gjøre, er dette ikke tilfelle. Risikoreduksjon er en sikker kostnad – økonomisk skade vi påtar oss på forhånd i håp om å redusere tap i morgen. Men risikoen for i morgen er et gjett, forhåpentligvis et godt begrunnet, men likevel bare et gjett. Kostnaden i dag er sikker. Å ta på seg sikker skade i dag i håp om å redusere mulig skade i morgen gir bare mening når skaden i dag er liten og den forventede eller mulige skaden i morgen er svært stor og effektiviteten av reduksjonen er betydelig.

Inkludert i ideen om «sikker kostnad på forhånd» for å redusere «mulig kostnad i morgen» er ideen om pengenes tidsverdi. Selv om et avbrudd hadde en kjent størrelse og tid, ville vi ikke bruke de samme pengene i dag for å redusere det i morgen, fordi pengene våre er mer verdifulle i dag.

I de mest dramatiske tilfellene ser vi noen ganger IT-avdelinger som krever at titusenvis eller hundretusener av kroner brukes på forhånd for å unngå å tape noen tusener av kroner, kanskje, en gang, kanskje mange år frem i tid. En strategi vi kan referere til som «å skyte oss selv i foten i dag for å unngå kanskje å få hodepine i morgen.»

Det er inkludert i konseptet med å evaluere risikoreduksjonen, men det bør nevnes spesifikt at det i tilfellet med IT-utstyr finnes mange eksempler på forsøkt risikoreduksjon som kanskje ikke er like effektive som de antas å være. For eksempel vil det å ha to servere som sitter i samme rack potensielt være svært effektivt for å redusere risikoen for svikt i verts­maskinvare, men vil ikke redusere risikoen mot naturkatastrofer, tap av et nettsted, brann, de fleste tilfeller av elektrisk sjokk, aktivering av brannslokking, nettverksavbrudd, de fleste applikasjonssvikt, ransomware-angrep eller andre rimelig mulige katastrofer.

Det er vanlig at lagringsenheter er utstyrt med «dobbeltkontrollere» som gir et sterkt inntrykk av høy pålitelighet, men generelt er disse kontrollerne inne i ett enkelt chassi med delte komponenter, og selv om komponentene ikke er delt, er firmware ofte delt og kommunikasjonen mellom komponenter er kompleks; dette fører ofte til svikt der svikten til én komponent utløser svikten til en annen – noe som gjør dem ganske ofte til LA-enheter snarere enn SA eller HA som folk forventet da de kjøpte dem. Så det er svært kritisk å vurdere om risikoreduksjons­strategien vil redusere hvilke risikoer og om reduksjonsteknikken sannsynligvis vil være effektiv. Ingen teknikk er helt effektiv; det er alltid en sjanse for svikt, men noen strategier og teknikker er mer bredt effektive enn andre, og noen er rett og slett misvisende eller faktisk kontraproduktive. Hvis vi ikke er forsiktige, kan vi implementere kostbare produkter eller teknikker som aktivt undergraver målene våre.

Noen teknikker og produkter som brukes i jakten på høy tilgjengelighet er ganske kostbare, noe som kan inkludere kjøp av redundant maskinvare, leie av en annen bygning, installasjon av kostbare generatorer eller lisensiering av spesiell programvare. Det finnes rimelige teknikker og programvare også, men i de fleste tilfeller vil enhver bevegelse mot høy tilgjengelighet resultere i en tilsvarende stor utlegg av investeringskapital for å oppnå det. Det er absolutt kritisk å huske at høy tilgjengelighet er en prosess; det er ingen måte å bare kjøpe høy tilgjengelighet på. Å oppnå HA krever god dokumentasjon, prosedyrer, planlegging, støtte, utstyr, ingeniørarbeid og mer. I systemverdenen nærmes HA normalt først fra et miljøperspektiv med reservekraftgeneratorer, redundante HVAC-systemer, strømbetinging, luftfiltrering, brannslokking­systemer og mer for å sikre at miljøet for tilgjengeligheten er på plass. Dette alene kan ofte gjøre videre investering unødvendig ettersom dette kan gi utrolige resultater. Deretter kommer HA-systemdesign som sikrer at ikke bare ett lag av en teknologistakk er høyt tilgjengelig, men at hele stakken tillater de kritiske applikasjonene, dataene eller tjenestene å forbli funksjonelle i så mye tid som mulig. Deretter å se på nettsted-til-nettsted-redundans for å kunne tåle flom, orkaner, snøstormer osv. Det er selvsagt helt forskjellige teknikker som å utnytte cloud computing-tjenester som hostes eksternt på våre vegne. Det som betyr noe er at høy tilgjengelighet krever bred tenkning og planlegging, ikke bare kan kjøpes som en linjepost, og bedømmes etter evnen til å returnere en risikofaktor som gir en resulterende oppetid eller sannsynlighet for oppetid mye høyere enn et «standard» systemdesign ville levere.

Det som ofte er overraskende, nesten sjokkerende, for mange bedrifter og spesielt for IT-fagfolk, som sjelden foretar finansiell risikoanalyse og som konstant får fortalt at HA er en nødvendighet for enhver bedrift og at kjøp av de nyeste HA-produktene er uten spørsmål hvordan budsjettene deres bør brukes, er at når tallene regnes ut og virkeligheten av kostnadene og effektiviteten til risikoreduksjons­strategier vurderes, har høy tilgjengelighet svært liten plass i noen organisasjon, spesielt de som er små eller har svært varierende arbeidsbelastninger. I markedet for små og mellomstore bedrifter er det nesten universelt å finne at kostnaden og kompleksiteten (som igjen bringer risiko, for det meste i form av mangel på erfaring rundt teknikker og risikovurdering) ved høy tilgjengelighets­tilnærminger er altfor kostbare til noen gang å oppveie den potensielle skaden av avbruddet som reduksjonen forhåpentligvis skal beskytte mot. Det finnes unntak, selvfølgelig, og det er mange bedrifter for hvilke løsninger for høy tilgjengelighet absolutt er fornuftige, men disse er unntaket og langt fra normen.

Det er også fornuftig å tenke på behovene for høy tilgjengelighet basert på en arbeidsbelastning og ikke avdelingsvis, selskapsmessig eller teknologimessig. I en liten bedrift er det vanlig at alle arbeidsbelastninger deler en felles plattform, og behovet til én arbeidsbelastning for høy tilgjengelighet kan dra med seg andre, mindre kritiske, arbeidsbelastninger. Dette er helt greit og en flott måte å motvirke kostnaden for risikoreduksjonen av den kritiske arbeidsbelastningen gjennom ancillær fordel for de mindre kritiske arbeidsbelastningene. I en større organisasjon der det er et mylder av plattform­tilnærminger brukt for forskjellige arbeidsbelastninger, er det vanlig at bare visse arbeidsbelastninger som er både svært kritiske (i form av risiko fra nedetids­effekt) og som er praktisk sett risikoredusert (evnen til å redusere risiko kan variere dramatisk mellom forskjellige typer arbeidsbelastninger) får høy tilgjengelighet anvendt på dem, og andre arbeidsbelastninger overlates til standard teknikker.

Eksempler på arbeidsbelastninger som kan være kritiske og effektivt kan adresseres med høy tilgjengelighet kan være et bestillingssystem på nett der ventetiden skapt av multi-regional replikering har liten innvirkning på det totale systemet, men å miste bestillinger kan være svært økonomisk virkningsfullt skulle et system svikte. Et eksempel på en arbeidsbelastning der høy tilgjengelighet kan være enkel å implementere, men ineffektiv, ville være et internt intranettsted som betjener ofte stilte HR-spørsmål; det ville rett og slett ikke være kostnadseffektivt å unngå små mengder av innimellom nedetid for et slikt system. Et eksempel på et system der risikoen er høy, men kostnaden eller effektiviteten av risikoreduksjon gjør det upraktisk eller til og med umulig, kan være en finansiell «tick»-database som krever massive mengder lavforsinkelse data å innta, og der evnen til å opprettholde en replika ikke bare ville være utrolig kostbar, men kan introdusere forsinkelse som ville undergrave systemets evne til å fungere tilstrekkelig. Hver bedrift og arbeidsbelastning er unik og bør evalueres nøye.

Selvfølgelig kan teknikker for høy tilgjengelighet iverksettes i etapper; det er ikke alt eller ingenting. Det kan være praktisk å redusere risikoen for svikt på systemnivå ved å ha feiltoleranse på applikasjonslaget for å beskytte mot svikt i systemmaskinvare, virtualiseringsplattform eller lagring. Men for den samme arbeidsbelastningen kan det hende at det ikke er verdifullt å beskytte mot tap av ett enkelt nettsted. Hvis en arbeidsbelastning bare betjener et bestemt nettsted, eller rett og slett ikke er verdifull nok for den store investeringen som trengs for å gjøre den feiltolerant mellom nettsteder, kan den lett falle «i midten.» Det er svært vanlig at arbeidsbelastninger bare implementerer delvis høy tilgjengelighets­løsninger, ofte fordi en IT-avdeling kanskje bare er ansvarlig for en del av dem og ikke har noe å si om ting som strømstøtte og HVAC, men sannsynligvis oftest fordi noen teknikker for høy tilgjengelighet sees som svært synlige og enkle å selge til ledelsen, mens andre, som høykvalitets strøm og klimaanlegg, ofte ikke er det, selv om de kanskje gir bedre valuta for pengene. Det er gode grunner til at visse teknikker kan velges og ikke andre, ettersom de påvirker forskjellige risikokomponenter og noen risikoer kan ha en annen innvirkning på en individuell bedrift eller arbeidsbelastning.

Høy tilgjengelighet krever nøye vurdering av om det er verdt å vurdere, og enda mer nøye vurdering av implementering. Å bygge virkelige HA-systemer krever en betydelig mengde innsats og ekspertise og generelt betydelig kostnad. Å forstå hvilke komponenter av HA som er verdifulle og hvilke som ikke er det, krever ikke bare omfattende teknisk ekspertise, men finansielle og ledelsesmessige ferdigheter også. Avdelinger må jobbe tett sammen for virkelig å forstå hvordan HA vil påvirke en organisasjon og når det vil være verdt investeringen. Det er kritisk at det huskes at behovet for høy tilgjengelighet i en organisasjon eller for en arbeidsbelastning slett ikke er en selvfølge, og det bør ikke være det minste overraskende å finne at omfattende høy tilgjengelighet eller til og med tilfeldig høy tilgjengelighets­praksis viser seg å være økonomisk upraktisk.

På mange måter skyldes dette at standard tilgjengelighet har nådd en slik tilstand at det kontinuerlig er stadig mindre og mindre risiko å redusere. Teknologikomponenter brukt i en bedriftsinfrastruktur, særlig servere, nettverksutstyr og lagring, har blitt så pålitelige at mengden nedetid vi må beskytte mot er ganske lav. Det meste av troen på behovet for knefall­messig høy tilgjengelighet stammer fra en annen æra da pålitelig maskinvare var utilgjengelig, og selv det dyreste utstyret var ganske upålitelig etter moderne standarder. Denne følelsen av forestående undergang om at en enhet kan svikte når som helst, stammer fra en eldre æra, ikke den nåværende. Moderne utstyr, selv om det åpenbart fortsatt bærer risikoer, er utrolig pålitelig.

I tillegg til andre risikoer bærer overinvestering i løsninger for høy tilgjengelighet finansielle og forretningsmessige risikoer som kan være betydelige. Det øker teknisk gjeld i møte med forretningsmessig usikkerhet. Hva om bedriften plutselig vokser, eller verre, hva om den plutselig krymper, endrer retning, blir kjøpt opp eller går konkurs helt? Investeringen i høy tilgjengelighet er allerede brukt selv om behovet for dens beskyttelse forsvinner. Hva om teknologi eller lokasjon endres? Noen eller alle av en høy tilgjengelighets­investering kan gå tapt før den ville ha nådd sin forventede slutt på levetiden.

Som IT-fagfolk er evaluering av fordelene, risikoene og kostnadene ved teknologi­løsninger kjernen i det vi gjør. Som alt annet i bedriftsinfrastruktur er det å bestemme typen risikoreduksjon, verdien av beskyttelse og hvor mye som er økonomisk riktig vårt nøkkelansvar og kan ikke overses eller ignoreres. Vi kan aldri bare anta at høy tilgjengelighet er nødvendig, ei heller at det enkelt kan hoppes over. Det er i analyser av denne arten at IT bringer noe av sin største verdi til organisasjoner. Det er her vi har potensialet til å skinne mest.