🥇We bereiden DRP voor — vergeet niet de meteoriet te overwegen

Zelfs tijdens een ramp is er altijd tijd voor een kopje thee

DRP (disaster recovery plan) is iets dat idealiter nooit nodig zal zijn. Maar als plotseling de migrerende bevers tijdens hun paartijd de hoofdvezelkabel doorbijten of een junior admin een productie database verwijdert, wil je zeker zijn dat je een vooraf opgesteld plan hebt over wat je met deze chaos moet doen.

Terwijl klanten in paniek de telefoons van de klantenservice beginnen te verwoesten, en de junior op zoek is naar cyaniden, open jij wijs het rode envelop en begin je alles weer op orde te brengen.

In deze post wil ik aanbevelingen delen over hoe je een DRP moet schrijven en wat erin moet staan. We zullen ook de volgende dingen bespreken:

Laten we leren denken als een schurk.
We bespreken het nut van een kopje thee tijdens de apocalyps.
We bedenken een handige structuur voor de DRP
We kijken hoe je het moet testen

Voor welke bedrijven dit nuttig kan zijn

Het is heel moeilijk om de grens te trekken wanneer de IT-afdeling behoefte krijgt aan dergelijke zaken. Ik zou zeggen dat je een DRP absoluut nodig hebt als:

Het stoppen van een server, applicatie of het verlies van een database leidt tot aanzienlijke verliezen voor het bedrijf als geheel.
Je hebt een volwaardig IT-afdeling. In de zin van een afdeling die als een volwaardige eenheid binnen het bedrijf functioneert, met zijn eigen budget, en niet gewoon een paar vermoeide medewerkers die netwerken aanleggen, virussen opruimen en printers vullen.
Je hebt een echt budget, zelfs voor gedeeltelijke reservering in het geval van een noodsituatie.

Wanneer de IT-afdeling maandenlang om zelfs maar een paar HDD's voor een oude server voor back-ups vraagt, is het onwaarschijnlijk dat je een volledige overplaatsing van een uitgevallen dienst naar reservecapaciteit kunt organiseren. Hoewel ook hier documentatie niet overbodig zal zijn.

Documentatie is belangrijk

Begin met documentatie. Stel dat je dienst draait op een script in Perl, dat drie generaties beheerder geleden is geschreven, en niemand weet hoe het werkt. De opgebouwde technische schuld en het gebrek aan documentatie zullen onvermijdelijk niet alleen je knie, maar ook andere ledematen raken, het is eerder een kwestie van tijd.

Nadat je een goede beschrijving van de servicecomponenten hebt, bekijk je de storingsstatistieken. Die zullen vrijwel zeker typisch zijn. Bijvoorbeeld, je krijgt af en toe een volle schijf, wat leidt tot het uitvallen van de node totdat deze handmatig wordt schoongemaakt. Of de klantenservice wordt onbereikbaar omdat iemand weer vergeten is het certificaat te verlengen, en Let’s Encrypt niet kan of wil instellen.

Denk als een saboteur

Het moeilijkste deel is het voorspellen van de storingen die nog nooit hebben plaatsgevonden, maar die je service volledig kunnen uitschakelen. Hier spelen we meestal een spelletje met de collega's. Neem veel koffie en iets lekkers en sluit jezelf op in een vergaderruimte. Zorg er wel voor dat je ook de ingenieurs hebt opgesloten die de doelservice hebben opgezet of er regelmatig mee werken. Vervolgens begin je op een bord of op papier alles mogelijke angstaanjagende scenario's te schetsen die zich met jouw service kunnen voordoen. Je hoeft niet tot in detail te gaan met specifieke ondersteuningswerkzaamheden; het is voldoende om het scenario 'Inbreuk op de integriteit van het lokale netwerk' te overwegen.

Normaal gesproken vallen de meeste typische noodsituaties onder de volgende soorten:

Netwerkuitval
Uitval van de OS-services
Toepassingsuitval
Hardware-uitval
Virtualisatie-uitval

Je loopt gewoon elk type door en kijkt wat van toepassing is op jouw service. Bijvoorbeeld, de Nginx-daemon kan crashen en niet meer opstarten — dat is gerelateerd aan de OS-uitval. Een zeldzame situatie die jouw webapplicatie in een niet-werkende staat brengt — software-uitval. Tijdens het verwerken van deze fase is het belangrijk om de diagnose van het probleem goed te doorlopen. Hoe onderscheid je een vastgelopen interface op virtualisatie van een uitgevallen switch en een netwerkstoring, bijvoorbeeld. Dit is belangrijk om snel verantwoordelijken te vinden en hen aan te spreken voordat de storing is verholpen.

Nadat de typische problemen zijn genoteerd, inschenken we nog meer koffie en beginnen we de meest vreemde scenario's te overwegen, wanneer bepaalde parameters ver buiten de norm gaan. Bijvoorbeeld:

Wat gebeurt er als de tijd op de actieve node met een minuut achterloopt ten opzichte van anderen in het cluster?
En als de tijd vooruit verschuift, wat als het met 10 jaar verschuift?
Wat zal er gebeuren als een node in het cluster plotseling het netwerk verliest tijdens de synchronisatie?
Wat gebeurt er als twee knooppunten niet kunnen beslissen over het leiderschap vanwege tijdelijke isolatie in het netwerk?

In dit stadium helpt het heel goed om van de andere kant te kijken. Neem het meest fanatieke teamlid met een drukke fantasie en geef hem de taak om in korte tijd een sabotageactie te organiseren die de dienst laat falen. Als deze moeilijk te diagnosticeren is, nog beter. Je zult niet geloven welke vreemde en geweldige ideeën ingenieurs uiten als je ze de opdracht geeft om iets kapot te maken. En als je ze ook nog een testomgeving belooft, is het helemaal geweldig.

Wat is deze DRP van jullie?!

Dus je hebt het dreigingsmodel vastgesteld. Je hebt rekening gehouden met lokale bewoners die glasvezelkabels doorknippen op zoek naar koper, en met de militaire radar die de radiorelaisverbinding elke vrijdag om 16:46 onderbreekt. Nu moet je begrijpen wat je met dit alles moet doen.

Je taak is om die rode enveloppen te schrijven die geopend zullen worden in geval van een noodsituatie. Reken er meteen op dat wanneer (niet als!) alles misgaat, er alleen de meest onervaren stagiair bij zal zijn, die van angst trillende handen heeft. Kijk eens naar hoe noodinstructies in medische praktijkruimtes zijn geïmplementeerd. Bijvoorbeeld, wat te doen bij een anafylactische shock. Medisch personeel kent alle protocollen uit het hoofd, maar wanneer er iemand overleden raakt, grijpen ze vaak wanhopig naar alles wat voorhanden is. Daarom hangt er op de muur een duidelijke instructie met stappen zoals 'open de verpakking van dit' en 'voer intraveneus zoveel eenheden van het medicijn in'.

In een noodsituatie is het moeilijk om te denken! Er moeten eenvoudige instructies zijn voor het verwerken met de reflexen.

Een goede DRP bestaat uit een aantal eenvoudige blokken:

Wie te waarschuwen bij het begin van de noodsituatie. Dit is belangrijk om het proces van probleemoplossing zo veel mogelijk parallel te laten verlopen.
Hoe je juist diagnosticeert — we voeren een trace uit, kijken naar systemctl status servicename, enzovoort.
Hoeveel tijd er besteed kan worden aan elke fase. Als je het ondanks SLA niet handmatig kunt oplossen, wordt de virtuele machine gewist en opnieuw geïnstalleerd vanaf de back-up van gisteren.
Hoe je ervoor zorgt dat de noodsituatie is beëindigd.

Houd er rekening mee dat DRP begint wanneer de service volledig heeft gefaald en eindigt wanneer de functionaliteit is hersteld, zelfs met verminderde efficiëntie. Gewoon het verlies van reservering mag DRP niet activeren. En je kunt zelfs een kopje thee in DRP opnemen. Serieus. Statistisch gezien worden veel storingen die vervelend zijn, catastrofaal omdat personeel in paniek iets probeert te repareren, terwijl ze de enige live node met gegevens of de cluster definitief beschadigen. Over het algemeen geven 5 minuten voor een kopje thee je de tijd om te kalmeren en de situatie te analyseren.

Verwarren DRP en het systeemboekje is niet nodig! Overlaad het niet met overbodige gegevens. Geef eenvoudig de mogelijkheid om snel en gemakkelijk via hyperlinks naar het juiste deel van de documentatie te gaan en in uitgebreidere vorm over de relevante delen van de servicearchitectuur te lezen. En in de DRP zelf alleen directe instructies over waar en hoe in te loggen met specifieke commando's voor copy-paste.

Hoe je correct test

Zorg ervoor dat elke verantwoordelijke medewerker in staat is om alle punten uit te voeren. Op het meest kritieke moment kan blijken dat de engineer geen toegang heeft tot het benodigde systeem, de wachtwoorden van het juiste account ontbreken of dat hij geen idee heeft wat "Verbind met de service management console via de proxy in het hoofdkantoor" betekent. Elk punt moet volkomen eenvoudig zijn.

Onjuist — "Ga naar de virtualisatie en reboot de dode node"
Juist — "Verbinden via de webinterface met virt.example.com, in het node-gedeelte de reboot uitvoeren van de node die de fout veroorzaakt."

Vermijd dubbelzinnigheden. Denk aan de bangerige stagiair.

Test DRP absoluut. Het is niet alleen een plan voor de vorm, het is wat jou en je klanten in staat stelt snel uit een kritieke situatie te komen. Het is optimaal om dit meerdere keren te doen:

Een expert en verschillende stagiaires werken op een teststand dat de echte service maximaal imiteert. De expert breekt de service op verschillende manieren en geeft de stagiaires de mogelijkheid om deze te herstellen volgens de DRP. Alle problemen, onduidelijkheden in de documentatie en fouten worden genoteerd. Na de training van de stagiaires wordt de DRP aangevuld en vereenvoudigd op onduidelijke plaatsen.
Testen op een echte service. Het is in feite nooit mogelijk om een perfecte kopie van een echte service te maken. Daarom is het noodzakelijk om een paar keer per jaar een gedeeltelijke uitschakeling van servers te plannen, verbindingen te onderbreken en andere storingen uit de lijst van bedreigingen te veroorzaken, om het herstelproces te evalueren. Een geplande storing van 10 minuten midden in de nacht is beter dan een onverwachte storing van meerdere uren tijdens piekbelasting met gegevensverlies.
Reële storingsoplossing. Ja, dit is ook een onderdeel van het testen. Als er zich een storing voordoet die niet op de lijst van bedreigingen staat, moet het DRP worden aangevuld en herzien op basis van de resultaten van het onderzoek.

Sleutelpunten

Als er iets fout kan gaan, zal het niet alleen foutgaan, maar ook op de meest catastrofale manier.
Zorg ervoor dat je middelen hebt voor noodlastverdeling.
Zorg ervoor dat je back-ups hebt die automatisch worden gemaakt en regelmatig op consistentie worden gecontroleerd.
Denk na over typische bedreigscenario's.
Geef ingenieurs de mogelijkheid om ongewone manieren te bedenken waarop de service kan falen.
DRP moet een simpele en duidelijke instructie zijn. Alle complexe diagnostiek komt pas na het herstel van de service voor klanten. Zelfs als dit op reservecapaciteiten gebeurt.
Vermeld belangrijke telefoonnummers en contactpersonen in het DRP.
Test regelmatig het begrip van de medewerkers over het DRP.
Voer geplande storingen uit op productie. Testomgevingen kunnen niet alles vervangen.