Det svakeste leddet: Hvordan kjedede avhengigheter påvirker systemrisiko

Når man vurderer systemrisikoscenarier, er det svært lett å overse “kjedede” avhengigheter. Vi er opplært til å se på risiko på et “node”-nivå og spørre “hvor sannsynlig er det at denne ene tingen svikter.” Men systemrisiko er langt mer komplisert enn det.

I de fleste systemer er det noen komponenter som er avhengige av andre komponenter. Det vanligste stedet vi ser på dette er i utformingen av lagring for servere, men det forekommer i ethvert systemdesign. Et annet godt eksempel er hvordan webapplikasjoner trenger både applikasjonsverter og databaseverter for å fungere.

Det er enklest å forklare kjedede avhengigheter med et eksempel. Vi vil se på et standard virtualiseringsdesign med SAN-lagring for å forstå hvor feildomene-grenser eksisterer, og hvor kjedede avhengigheter eksisterer, og hvilken rolle redundans spiller i risikoreduksjon på systemnivå.

I et standard SAN (storage area network) design for virtualisering har du virtualiseringsverts-maskiner (som vi for enkelhets skyld vil kalle “servere”), SAN-svitsjer (svitsjer dedikert for lagringsnettverk) og selve diskmatrisene. Hver av disse tre “lagene” er avhengig av de andre for at systemet som helhet skal fungere. Hvis vi hadde det enklest mulige settet med én server, én svitsj og én diskmatrise, har vi tydelig tre enheter som representerer tre distinkte feilpunkter. Hvis noen av de tre svikter, svikter hele systemet. Ingen enkelt del er nyttig alene. Dette er en kjedet avhengighet, og kjeden er bare så sterk som det svakeste leddet.

I vårt forenklede eksempel representerer hver enhet et feildomene. Vi kan redusere risikoen ved å forbedre påliteligheten til hvert domene. Vi kan legge til en andre server og implementere en virtualiseringslag med høy tilgjengelighet eller feiltoleransestrategi for å redusere risikoen for serverfeil. Dette forbedrer påliteligheten til ett feildomene men lar to stå urørt og like risikable som de var før. Vi kan deretter ta opp svitsjelaget ved å legge til en redundant svitsj og konfigurere en multipath-strategi for å håndtere tapet av en enkelt svitsjesti og redusere risikoen på det laget. Nå er to feildomener adressert. Til slutt må vi ta opp lagrings-feildomemet, som gjøres, på lignende vis, ved å legge til redundans gjennom en andre diskmatrise som er speilet mot den første og i stand til å ta over transparent ved svikt.

Nå som vi har styrket systemet vårt, har vi fortsatt tre feildomener i en avhengighetskjede. Det vi har gjort er å gjøre hvert “ledd” i kjeden, hvert feildomene, ekstra robust i seg selv. Men kjeden eksisterer fortsatt. Dette betyr at systemet som helhet er langt mindre pålitelig enn noe enkelt feildomene innenfor kjeden er alene. Vi har gjort noe langt bedre enn der vi startet, men vi har fortsatt mange feildomener. Disse risikoene legger seg opp.

Det som er vanskelig i å bestemme den samlede risikoen, er at vi må vurdere risikoen for hvert element, deretter bestemme den nye risikoen etter risikoreduksjon (gjennom tillegg av redundans) og deretter finne den kumulative risikoen for hvert av feildomener til sammen i en kjede for å bestemme den totale risikoen for hele systemet. Det er ekstremt vanskelig å bestemme risikoen innenfor hvert feildomene ettersom måten risikoreduksjon gjøres på spiller en betydelig rolle. For eksempel kan en klynge av lagringsdiskmatriser som feiler over for sakte resultere i en total systemfeil selv når lagringsklynsteren selv ser ut til å ha fungert korrekt. Selv å definere en klar svikt kan derfor være utfordrende.

Det er ofte fristende å ta en “ovenfra og ned”-vurdering av risiko, noe som er svært farlig, men svært vanlig for folk som ikke er regelmessige risikovurderingspraktikere. Tendensen her er å se på risikoen bare ved å se på det “øverste” feildomenet – generelt serverne i et slikt tilfelle – og ignorere eventuelle risikoer som befinner seg under det punktet og betrakte disse som “under panseret” snarere enn som del av risikovurderingen. Det er lett å ignorere de mer tekniske, mindre eksponerte og mer dårlig forstått komponentene som nettverk og lagring og fokusere på de relativt enkle å forstå og mye markedsførte pålitelighetsaspektene til toppsjiktet. Dette “ovenfra-synet” betyr at risikoene under toppnivået er skjult og generelt ignorert, noe som fører til høy risiko uten god forståelse av hvorfor.

Å forstå konseptet med kjedede avhengigheter forklarer hvorfor komplekse systemer, selv med komplekse risikoreduksjonsstrategier, ofte ender opp med å være langt mer skjøre enn enklere systemer. I eksemplet ovenfor kunne vi gjøre flere ting for å “kollapse” kjeden, noe som resulterer i et mer pålitelig system som helhet.

Den mest åpenbare komponenten som kan kollapses er nettverksfeildomenet. Hvis vi fjernet svitsjene fullstendig og koblet lagringen direkte til serverne (ikke alltid mulig, selvfølgelig) ville vi effektivt eliminere ett helt feildomene og fjerne ett ledd fra kjeden. Nå i stedet for tre kjeder, som hver har potensial til å feile, har vi bare to. Enklere er bedre, alt annet likt.

Vi kunne, i teorien, også kollapse lagringsfeildomenet ved å gå fra ekstern lagring til å bruke lagring lokal for selve serverne, noe som i praksis tar oss fra to feildomener ned til ett enkelt feildomene – det gjenværende domenet bærer selvfølgelig mer kompleksitet enn det gjorde før kollapsen, men den samlede systemkompleksiteten er kraftig redusert. Igjen er dette med alle andre faktorer uendret.

En annen tilnærming å vurdere er å gjøre enkle noder mer pålitelige på egenhånd. Det er trendy i dag å se på større systemer og nærme seg risikoreduksjon på den måten, ved å legge til redundante, lavkost-noder for å legge til pålitelighet til feildomener. Men tradisjonelt var ikke dette standardveien til pålitelighet. Det var langt mer vanlig tidligere, som vist i den tidligere utbredelsen av stormaskiner og lignende systemer, å bygge inn høye grader av pålitelighet i en enkelt node. Stormaskiner og høyendelagringssystemer gjør for eksempel fortsatt dette i dag. Dette kan faktisk være en ekstremt effektiv tilnærming, men den adresserer ikke mange scenarier og er generelt ekstremt kostbar, ofte forsterket av et behov for å ha systemer delvis eller til og med fullstendig vedlikeholdt av leverandøren. Dette har en tendens til å fungere bare i spesielle nisjemessige omstendigheter og er ikke praktisk i et mer generelt omfang.

Så i ethvert system av denne naturen har vi tre viktige risikoreduksjonsstrategier å vurdere: forbedre påliteligheten til en enkelt node, forbedre påliteligheten til et enkelt domene eller redusere antall feildomener (ledd) i avhengighetskjeden. Å sette disse sammen på en fornuftig måte kan hjelpe oss med å oppnå det risikoreduksjonsnivået som er passende for vårt forretningsscenario.

Der den sanne vanskeligheten eksisterer, og vil forbli, er i sammenligningen av ulike risikoreduksjonsstrategier. Risikoen for en enkelt node kan generelt estimeres med en viss grad av sikkerhet. En redundansstrategi innenfor et enkelt domene har langt mindre evne til å estimeres – noen redundansstrategier er svært effektive og skaper ekstremt pålitelige feildomener, mens andre faktisk kan slå tilbake og redusere påliteligheten til et domene! Kompleksiteten som ofte følger med redundansstrategier er aldri uten forbehold, og selv om det vanligvis vil lønne seg, bærer det sjelden graden av pålitelighetsgevinst som opprinnelig forventes. Å estimere risikoen for en avhengighetskjede er derfor mye vanskeligere ettersom det krever en klar forståelse av risikoene knyttet til hvert av feildomener individuelt samt en forståelse av sviktsmulighetene som eksisterer ved domenegrensene (som feiltoleransforsinkelsen for lagring nevnt tidligere).

La oss utforske problemene rundt å bestemme risiko i to svært vanlige tilnærminger til det samme scenariet, bygget på det vi har diskutert ovenfor.

To ekstreme eksempler på den samme situasjonen vi har diskutert er en enkelt server med intern lagring brukt til å hoste virtuelle maskiner versus en seks-enheters “kjede” med to servere og bruk av en høy-tilgjengelighetsløsning på serverlaget, to svitsjer med redundans på svitsjelaget og to diskmatriser som gir høy tilgjengelighet på lagringslaget. Hvis vi endrer en stor faktor her, kan vi generelt gi et ganske klart estimat av relativ risiko – hvis noen av feildomener mangler pålitelig redundans, for eksempel – kan vi ganske tydelig fastslå at den enkle serveren er det mer pålitelige samlede systemet, unntatt i tilfeller der en ekstrem mengde av enkelt-node-pålitelighet er tildelt en enkelt node, noe som generelt er en upraktisk strategi finansielt sett. Men med hvert feildomene som opprettholder redundans er vi tvunget til å sammenligne de relative risikoene for intra-domenepålitelighet (den redundante kjeden) mot inter-domenepålitelighet (den kollapsede kjeden, enkeltserver).

Med de to helt ulike tilnærmingene er det ingen rimelig måte å vurdere de komparative risikoene ved de to risikoreduksjonsmidlene. Det er generelt akseptert at seks (eller flere) node-tilnærmingen med omfattende intra-domene risikoreduksjon er den mer pålitelige av de to tilnærmingene, og dette er nesten sikkert, generelt sett, sant. Men det er ikke alltid sant, og sjelden overgår denne tilnærmingen enkeltnode-strategien med en virkelig betydelig margin, mens den ofte koster fire til ti ganger så mye som enkeltserver-strategien. Det er potensielt en svært høy kostnad for det som sannsynligvis er en liten gevinst i pålitelighet og en liten potensiell risiko for tap av pålitelighet. Hvert ekstra stykke redundans legger til kompleksitet som et menneske må implementere, overvåke og vedlikeholde, og med kompleksitet og menneskelig interaksjon kommer mer og mer risiko. Å unngå menneskelige feil kan ofte være viktigere enn å unngå mekanisk svikt.

Vi må også vurdere gjenopprettingskostnaden. Hvis svikt skulle inntreffe, er det generelt trivielt å komme seg fra svikten til et enkelt system. Et ekstremt komplekst system som har sviktet kan kreve stor innsats for å gjenopprette til en fungerende tilstand. Komplekse systemer krever også mye bredere og dypere grad av erfaring og trygghet for å vedlikeholde.

Det er ikke noe enkelt svar på å bestemme påliteligheten til systemer. Moderne systemer for informasjonslevering er rett og slett for store og for komplekse med for mange ubestemmelige faktorer til å kunne evalueres i alle tilfeller. Med en god forståelse av kjedede avhengigheter, imidlertid, og en forståelse av risikoreduksjonsstrategier, kan vi ta praktiske skritt for å bestemme omtrent relative risikonivåer, se hvor lignende risikoscenarier sammenligner seg kostnadsmessig, identifisere skjørhetspoeng, gjenkjenne feildomener og avhengighetskjeder, og sette pris på hvordan endringer i systemdesign tydelig vil flytte oss mot eller bort fra pålitelighet.