Motståndskraft i design och policy
Frasen man sannolikt kommer att höra oftast tillsammans med "haveriberedskap" är "affärskontinuitet". Kontinuitet har en positiv konnotation. Tanken är att begränsa katastrofer eller mindre händelser så att de håller sig innanför datacentrets väggar.
Däremot är ”kontinuitet” inte någon specifik teknisk term, även om man har försökt göra det till en sådan. Det finns ingen enskild formel, metod eller procedur för att skapa affärskontinuitet. Olika organisationer har unika uppsättningar med regelverk som styr verksamhetens art och tillvägagångssätt. Kontinuitet kommer av en lyckad tillämpning av dessa metoder för att uppnå ett positivt resultat.
Innebörden av motståndskraft
Tekniker förstår begreppet motståndskraft. När ett system presterar väl under olika förhållanden anses det vara motståndskraftigt. Enligt riskhanterare är en verksamhet väl förberedd när den har implementerat säkerhetsmekanismer, säkerhetsåtgärder och katastrofprocedurer som kan hantera eventuell negativ inverkan. En ingenjör kanske inte uppfattar miljön där ett system fungerar i sådana svartvita termer, "normal" och "hotad", "säkerhet" och "katastrof". Den här personen uppfattar systemet som stöder ett företag att vara i rätt körningsordning när det ger kontinuerliga och förutsägbara servicenivåer inför negativa omständigheter.
År 2011, precis som molnbaserad databehandling blev en stigande trend i datacentret, utfärdade Europeiska nätverks- och informationssäkerhetsbyrån (ENISA, en enhet inom Europeiska unionen) en rapport som svar på en eu-statlig begäran om insikt i motståndskraften hos de system som de använde för att samla in och samla in information. I rapporten uppgavs det uttryckligen att det ännu inte fanns någon konsensus bland ICT-personalen – i Europa används termen ”ICT” (IKT, informations- och kommunikationsteknik), som innefattar kommunikation – om vad ”motståndskraft” faktiskt betyder eller hur det ska mätas.
Detta ledde ENISA att upptäcka ett projekt som startats av ett team av forskare vid University of Kansas (KU), ledd av Prof. James P. G. Sterbenz, med avsikt att distribueras vid U.S. Dept. of Defense. Det kallas Resilient and Survivable Networking Initiative (ResiliNets)1 och är en metod för att visualisera det föränderliga tillståndet för motståndskraft i informationssystem som omfattar en rad olika förhållanden. ResiliNets är prototypen för en konsensusmodell för motståndskraftspolicy inom organisationer.
I KU-modellen används ett antal välbekanta och enkla mått, varav vissa redan har introducerats i det här kapitlet. De omfattar:
Feltolerans – enligt den tidigare förklaringen är detta förmågan hos ett system upprätthålla förväntade servicenivåer när fel uppstår
Avbrottstolerans – möjligheten för samma system att underhålla förväntade servicenivåer under oförutsägbara och ofta extrema driftsförhållanden som inte orsakas av själva systemet, till exempel strömavbrott, brist på Internetbandbredd och trafiktoppar
Överlevnadsförmåga – en uppskattning av förmågan i ett system att tillhandahålla rimliga, om än inte alltid normala, nivåer av serviceprestanda under alla tänkbara omständigheter, däribland naturkatastrofer
Den huvudteori som ResiliNets förespråkar är att informationssystem blir mätbart mer motståndskraftiga med en kombination av systemutveckling och mänskligt arbete. Det människor gör – närmare bestämt det de fortsätter att göra som en del av vardagsarbetet – gör system starkare.
Med en signal från hur soldater, sjömän och marinsoldater i en aktiv verksamhetsteater lär sig och minns principerna för taktisk distribution, föreslog KU-teamet en back-of-the-napkin mnemonic för att komma ihåg livscykeln för ResiliNets praxis: D2R2 + DR. Som beskrivs i figur 9 står variablerna här för följande i den här ordningen:**
Defend – försvara systemet mot sådant som hotar dess normala drift
Detect – Identifiera förekomsten av skadliga effekter som beror på möjliga fel samt yttre omständigheter
Remediate – Åtgärda den efterföljande påverkan som dessa effekter kan medföra för systemen, även om sådan påverkan ännu inte har förekommit
Recover – Återställ till normala servicenivåer
Diagnose – Diagnostisera rotorsakerna till händelserna
Refine – Förfina framtida åtgärder efter behov i syfte att förbättra beredskapen när samma problem inträffar igen
Bild 9: Livscykeln för bästa praxis-aktiviteter i en miljö som använder ResiliNets.
Under vart och ett av dessa steg samlas vissa prestanda- och driftsmått in för både personal och system. Kombinationen av dessa mått resulterar i punkter som kan ritas i ett diagram, till exempel det som visas i bild 9.10 med ett euklidiskt geometriskt plan. Varje mått kan reduceras till två endimensionella värden: ett som återspeglar parametrarna P på tjänstnivå och ett annat som representerar drifttillståndet N. Eftersom alla sex stegen i ResiliNets-cykeln implementeras och upprepas ritas tjänsttillståndet S i diagrammet vid koordinaterna (N, P).
Bild 10: ResiliNets tillståndsutrymme och strategi inre loop.
För organisationer som uppfyller sina servicemål håller sig tillståndet S nära diagrammets nedre vänstra hörn och förblir förhoppningsvis där medan den så kallade inre loopen pågår. När servicemålen försämras färdas tillståndet i en oönskad riktning uppåt till höger.
Även om ResiliNets-modellen inte har blivit en allmänt vedertagen modell för IT-motståndskraft hos företag så har dess införande av vissa framträdande organisationer, särskilt i den offentliga sektorn, utlöst några av de ändringar som bidrog till molnrevolutionen:
Prestandavisualisering. Motståndskraft behöver inte vara en filosofi för att dess nuvarande tillstånd ska meddelas till relevanta intressenter. Det kan faktiskt demonstreras med mindre än ett enda ord. Moderna plattformar för prestandahantering som använder mått från molnet har implementerat instrumentpaneler och liknande verktyg som lika tydligt visar på deras värde.
Åtgärder och procedurer för återställning behöver inte vänta på att en katastrof inträffar. I ett robust och väl utformat informationssystem med kontinuerlig uppsyn från tekniker och operatörer implementeras underhållsprocedurer dagligen. Dessa är snarlika de reparationsprocedurer som används under krissituationer. I till exempel en miljö med återställning efter katastrof som präglas av hett vänteläge kan reparation av problem på servicenivå faktisk bli automatisk – huvudroutern dirigerar helt enkelt trafik bort från påverkade komponenter. Med andra ord behöver inte förberedelser inför fel innebära att man väntar på att fel ska uppstå.
Informationssystem består av människor. Automation gör visserligen människors arbete och produktframställningen effektivare. Men det ersätter inte personer i ett system som utformats till att svara på ändringar av förutsättningar och miljön som inte kan förutses.
Återställningsinriktad databehandling
ResiliNets är en implementering av ett begrepp som Microsoft hjälpte till att mynta kort efter millennieskiftet: Recovery-Oriented Computing (ROC, Återställningsinriktad databehandling).2 Huvudprincipen bakom detta var att fel och buggar alltid förekommer i databehandlingsmiljöer. I stället för att lägga ned orimligt mycket tid på att rengöra den här miljön kan det vara bättre om organisationer inför praktiska åtgärder som bidrar till att hålla miljön säker. Det är datormiljöns motsvarighet till idén att människor bör tvätta händerna flera gånger om dagen, något som var kontroversiellt ända fram till slutet av 1800-talet.
Motståndskraft i det offentliga molnet
Leverantörer av offentliga molntjänster använder principer och ramverk för motståndskraft, även om de inte använder just den termen. Dock inför inte en molnplattform motståndskraft i en organisations datacenter såvida den inte absorberar organisationens informationstillgångar till molnet helt och hållet. Implementeringar av hybridmoln är bara så motståndskraftiga som de minst noggranna administratörerna. Om vi antar att administratörerna hos en molnlösningsleverantör noggrant följer principerna bakom motståndskraft (enligt kraven i deras serviceavtal) är det alltid kundens uppgift att upprätthålla motståndskraften i systemet överlag.
Azure Resiliency Framework
Den internationella standardvägledningen för strategi för affärskontinuitet är ISO 22301. Liksom andra ISO-ramverk (International Standards Organization) anger det riktlinjer för bästa praxis och drift vars efterlevnad ger organisationer möjligheten att få professionell certifiering.
I det här ISO-ramverket definieras inte affärskontinuitet eller motståndskraft direkt. I stället definieras innebörden av kontinuitet i organisationens eget sammanhang. I det vägledande dokumentet står det: ”Organisationen ska identifiera och välja strategier för affärskontinuitet baserat på resultat från analys av affärspåverkan och riskbedömning. Strategierna för affärskontinuitet ska bestå av en eller flera lösningar." Den går inte vidare med att lista vilka dessa lösningar kan eller bör vara.3
Bild 11 är Microsofts beskrivning av implementeringen av efterlevnaden med ISO 22301 i Azure. Observera målen för drifttid i serviceavtal (SLA). För kunder som väljer den här nivån av motståndskraft replikerar Azure virtuella datacenter i deras lokala tillgänglighetszoner men etablerar därefter separata repliker vars geoplatser ligger hundratals kilometer från varandra. Av juridiska skäl (särskilt efterlevnad med sekretesslagar i EU) begränsas dock den här geoplatsseparerade redundansen vanligtvis till ”gränser för datahemvist” såsom Nordamerika eller Europa.
![Figure 11: Azure Resiliency Framework, which protects active components on multiple levels, in accordance with ISO 22301. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-11.jpg)
Bild 11: Azure Resiliency Framework, som skyddar aktiva komponenter på flera nivåer, i enlighet med ISO 22301. [Courtesy Microsoft]
ISO 22301 är förknippat med motståndskraft men beskrivs ofta som en uppsättning riktlinjer för motståndskraft. Azure har testats mot dessa motståndskraftsnivåer och de gäller endast för Azure-plattformen, inte för kundtillgångar som den plattformen är värd för. Det är kundens ansvar att hantera, underhålla och regelbundet förbättra sina processer, däribland hur tillgångar replikeras i Azure-molnet och på andra ställen.
Google Container Engine
Fram till nyligen betraktades programvara som ett tillstånd för en dator som i praktiken var identiskt med maskinvara fast i digital form. Sett från det perspektivet kan programvara ofta uppfattas som en relativt statisk komponent i ett informationssystem. Säkerhetsprotokoll krävde att programvara skulle uppdateras ”regelbundet”, vilket oftast innebar några gånger per år, i takt med att uppdateringar och felkorrigeringar gjordes tillgängliga.
Det som blev möjligt tack vare molnfunktioner, och som många IT-tekniker inte hade förväntat sig, var möjligheten att utveckla programvara inkrementellt men ändå ofta. Kontinuerlig integrering och kontinuerlig leverans (CI/CD, Continuous Integration and Continuous Delivery) är en uppsättning principer som är på uppgång. Den automatisering som detta medför gör att inkrementella ändringar av programvara kan mellanlagras ofta – rentav dagligen – på både serversidan och klientsidan. Smartphoneanvändare tar ofta del av CI/CD i form av appar som uppdateras flera gånger i veckan i appbutiken. Ändringar som sker via CI/CD är ofta små, men det faktum att dessa små ändringar kan distribueras snabbt och enkelt medför en oväntad och positiv bieffekt: informationssystem som är mycket mer motståndskraftiga.
Med CI/CD-distributionsmodeller etableras och underhålls helt redundanta serverkluster, ofta i en offentlig molnarkitektur, uteslutande i syfte att testa nya programvarukomponenter efter buggar och sedan mellanlagra dessa komponenter i en simulerad arbetsmiljö där potentiella fel kan upptäckas. Därmed kan reparationsprocesser utföras i en säker miljö utan direkt inverkan på kund- eller användarriktade servicenivåer tills åtgärderna har tillämpats, testats och godkänts för distribution.
Google Container Engine (GKE, där ”K” står för ”Kubernetes”) är Google Cloud Platform-miljön för kunder som distribuerar containerbaserade program och tjänster i stället för VM-baserade program. En fullständig containerbaserad distribution kan omfatta databaser med mikrotjänster (”µ-tjänster) som är skilda från arbetsbelastningar och utformade att fungera oberoende (”tillståndskänsliga datamängder”), bibliotek med beroendekod samt små operativsystem som används i de fall då programkod behöver använda containerns eget filsystem. I bild 9.12 visas en sådan distribution i det format som Google i praktiken föreslår för sina GKE-kunder.
Bild 12: Ett alternativ för frekvent vänteläge som en CI/CD-mellanlagringsmiljö för Google Container Engine.
I GKE liknar projekt data datacenter på så sätt att de förväntas ha alla resurser som datacenter normalt skulle ha, men i ett virtuellt format. Det kan finnas ett eller flera serverkluster som är tilldelade till ett projekt. Containerbaserade komponenter lagras i egna namnrymder, som i princip är deras universum. Var och en består av alla adresserbara komponenter som dess medlemscontainrar ges åtkomst till. Allt som är utanför namnrymden måste adresseras med hjälp av IP-fjärradresser. Tekniker på Google menar att gammaldags klient/server-program (som av containerutvecklare kallas ”monoliter”) kan samexistera med containerbaserade program förutsatt att varje klass använder en egen namnrymd för säkerhet samtidigt som de ingår i samma projekt.
I det här föreslagna distributionsdiagrammet finns det tre aktiva kluster som vart och ett använder två namnrymder: en för gammal programvara och en för ny programvara. Två av dessa kluster har testning som uppgift: ett för inledande utvecklingstestning och ett för slutlig mellanlagring. I en CI/CD-pipeline matas nya kodcontainrar in i ett av testningsklustren. Där måste de godkännas av ett antal automatiserade tester och visa att de är relativt buggfria innan de överförs till mellanlagring. Där genomgår de nya programvarucontainrarna en annan uppsättning med tester. Endast kod som godkänns av den andra nivån med mellanlagringstester kan matas in i det driftsatta produktionskluster som slutkunder använder.
Även i detta steg finns dock säkerhetsmekanismer. I ett A/B-distributionsscenario samexisterar ny kod med den gamla koden under en viss tidsperiod. Om den nya koden inte presterar enligt specifikationerna, eller om den inför fel i systemet, kan den dras tillbaka så att den gamla koden finns kvar. Om provtiden går ut och den gamla koden presterar bra dras den gamla koden tillbaka.
Den här processen är ett systematiskt och halvautomatiskt sätt för informationssystem att undvika införandet av fel som leder till haveri. Ensamt är det här dock inte en katastrofsäker konfiguration, såvida inte själva produktionsklustret replikeras i ett hett vänteläge. Visserligen förbrukar det här replikeringsschemat stora mängder molnbaserade resurser. Men dessa kostnader kan ändå bli mycket lägre än om organisationen skulle drabbas av ett systemavbrott utan ha skydd mot det.
Referenser
Sterbenz, James P.G., et al. "ResiliNets: Multilevel Resilient and Survivable Networking Initiative." https://resilinets.org/main_page.html.
Patterson, David, et al. "Recovery Oriented Computing: Motivation, Definition, Principles, and Examples." Microsoft Research, mars 2002. https://www.microsoft.com/research/publication/recovery-oriented-computing-motivation-definition-principles-and-examples/.
ISO. "Säkerhet och motståndskraft – Hanteringssystem för affärskontinuitet – Krav." https://dri.ca/docs/ISO_DIS_22301_(E).pdf.