Vi förbereder DRP – glöm inte att ta hänsyn till meteoriter.

Även under en katastrof finns det alltid tid för en kopp te

DRP (disaster recovery plan) är en sak som i idealfallet aldrig behövs. Men om de migrerande boberna av en slump klipper huvudfiberkabeln eller en junior-administratör råkar ta bort en produktionsdatabas, vill du absolut vara säker på att du har en förberedd plan för vad du ska göra med allt detta.

Medan kunderna i panik börjar ringa supporten, letar junioren efter cyanider, öppnar du med visdom det röda kuvertet och börjar få ordning på allt.

I det här inlägget vill jag dela med mig av rekommendationer om hur man skriver en DRP och vad den bör innehålla. Dessutom kommer vi att gå igenom följande saker:

1. Vi lär oss att tänka som en skurk.
2. Vi kommer att diskutera fördelarna med en kopp te under apokalypsen.
3. Vi planerar en bekväm struktur för DRP
4. Vi ser på hur den ska testas

För vilka företag det kan vara användbart

Det är mycket svårt att dra en gräns när IT-avdelningen börjar behöva sådana här saker. Jag skulle säga att DRP verkligen är nödvändigt om:

• Stopp av server, applikation eller förlust av någon databas kommer att leda till betydande affärsförluster i allmänhet.
• Du har en fullt fungerande IT-avdelning. Jag menar en avdelning som är ett fullvärdigt företag, med sin egen budget, och inte bara några trötta anställda som drar nätverk, rengör virus och fyller på skrivare.
• Du har en faktisk budget åtminstone för delvis reservplanering i händelse av en nödsituation.

När IT-avdelningen i månader ber om ens ett par HDD till den gamla servern för backup, är det osannolikt att ni kan organisera en fullständig överflyttning av den nedlagda tjänsten till reservkraft. Även här är dokumentationen dock inte överflödig.

Dokumentation är viktig

Börja med dokumentationen. Anta att din tjänst körs på ett Perl-script som skrevs för tre generationer av administratörer sedan, och ingen vet hur det fungerar. Den ackumulerade tekniska skulden och avsaknaden av dokumentation kommer oundvikligen att skjuta dig i knet och andra lemmar, det är snarare en tidsfråga.

När du har en bra beskrivning av tjänstens komponenter, granska statistiken över incidenter. De kommer sannolikt att vara ganska typiska. Till exempel kan din disk då och då fyllas, vilket leder till att noden misslyckas tills den har rensats manuellt. Eller så blir kundtjänsten otillgänglig för att någon återigen glömde att förnya certifikatet, och ingen kunde eller ville ställa in Let's Encrypt.

Tänk som en sabotör

Den svåraste delen ligger i att förutsäga de incidenter som aldrig har inträffat men som potentiellt kan slå ut din tjänst helt. Här brukar vi vanligtvis leka skurkar med kollegor. Ta mycket kaffe och något gott och lås in er i mötesrummet. Se bara till att ni också låser in de ingenjörer som själva har byggt den aktuella tjänsten eller som jobbar med den regelbundet. Sedan börjar ni antingen på en tavla eller på papper att rita alla möjliga skräcksituationer som kan hända med er tjänst. Det är inte nödvändigt att gå in på detaljer om en viss städerska som drar ur kablar, det räcker med att överväga scenariet "Överträdelse av det lokala nätverkets integritet".

Vanligtvis faller de flesta typiska incidenter inom följande kategorier:

• Nätverksfel
• Fel i operativsystemets tjänster
• Applikationsfel
• Hårdvarufel
• Virtualiseringsfel

Du går helt enkelt igenom varje kategori och ser vad som är tillämpligt för din tjänst. Till exempel kan Nginx-processen krascha och inte starta igen – det är ett OS-fel. En sällsynt situation som gör att din webbapplikation går ner är en programvarufel. Under detta steg är det viktigt att arbeta med problemdiagnos. Hur skiljer man en hängande gränssnitt på virtualisering från en nedfallen switch och ett nätverksfel, till exempel. Detta är viktigt för att snabbt kunna identifiera ansvariga och börja driva dem tills incidenten är åtgärdad.

När de typiska problemen har skrivits ner, häller vi mer kaffe och börjar överväga de mest ovanliga scenarierna när vissa parametrar börjar avvika kraftigt från normen. Till exempel:

• Vad händer om tiden på den aktiva noden flyttas en minut tillbaka i förhållande till de andra i klustret?
• Och om tiden flyttas framåt, vad om det är i 10 år?
• Vad händer om klusternoden plötsligt förlorar nätverket under synkroniseringen?
• Vad händer om två noder inte kan dela ledarskapet på grund av tillfällig isolering från varandra i nätverket?

I det här skedet är det väldigt hjälpsamt att använda en bakvänd metod. Ta den mest besatta medlemmen i teamet med en sjuk fantasi och ge dem en uppgift att på kort tid orsaka en avvikelse som förstör tjänsten. Om den är svår att diagnostisera – ännu bättre. Du kommer inte att tro vilka konstiga och coola idéer ingenjörerna kommer med om du ger dem en idé om att förstöra något. Och om du lovar dem en testmiljö för detta – riktigt bra.

Vad är det här DRP:et ni pratar om?!

Så ni har definierat hotmodellen. Ni har tagit hänsyn till lokala invånare som skär fiberkablar i jakt på koppar, och den militära radarn som släpper en radiolänk strikt på fredagar klockan 16:46. Nu måste ni förstå vad ni ska göra med allt detta.

Er uppgift är att skriva de där röda kuverten som kommer att öppnas i en nödsituation. Räkna direkt med att när (inte om!) allt går fel, kommer bara den mest oerfarna praktikanten att finnas i närheten, med händer som skakar av skräck över vad som händer. Titta på hur nödsituationer är implementerade i medicinska kontor. Till exempel, vad man ska göra vid anafylaktisk chock. Medicinsk personal kan allt om protokollen utantill, men när någon börjar dö i närheten, grabbar man ofta förtvivlat efter allt möjligt. För detta hänger det en tydlig instruktion på väggen med punkter som "öppna förpackningen av det där" och "ge intravenöst så många enheter av läkemedlet".

I en nödsituation är det svårt att tänka! Det måste finnas enkla instruktioner för att bearbeta med ryggmärgen.

Ett bra DRP består av några enkla block:

1. Vem ska informeras om att en nödsituation har inträffat. Detta är viktigt för att maximalt kunna parallellisera processen för att åtgärda.
2. Hur man korrekt diagnostiserar – vi utför spårning, kollar systemctl status servicename och så vidare.
3. Hur mycket tid man kan spendera på varje steg. Om du inte hinner fixa det manuellt inom SLA-tiden – stängs den virtuella maskinen av och en backup från igår rullas tillbaka.
4. Hur man säkerställer att nödsituationen är avslutad.

Kom ihåg att DRP börjar när tjänsten helt har slutat fungera och avslutas när funktionaliteten har återställts, även med minskad effektivitet. Bara förlust av reservkapacitet bör inte aktivera DRP. Du kan även skriva in en kopp te i DRP. Seriöst. Statistik visar att många incidenter från obehagliga situationer blir katastrofala eftersom personalen, i panik, börjar försöka fixa något, vilket kan döda den enda aktiva noden med data eller slutligen förstöra klustret. Vanligtvis ger 5 minuter för att ta en kopp te dig lite tid att lugna ner dig och analysera vad som händer.

Blanda inte ihop DRP med systemets pass! Överbelasta det inte med onödiga data. Ge bara möjligheten att snabbt och enkelt navigera via hyperlänkar till rätt avsnitt av dokumentationen och läsa i ett utökat format om de nödvändiga delarna av tjänstens arkitektur. I själva DRP: n ska det bara finnas direkta instruktioner om vart och hur man ansluter sig med specifika kommandon för kopiering och klistring.

Hur man testar korrekt

Se till att varje ansvarig person kan utföra alla punkter. I det mest kritiska ögonblicket kan det visa sig att ingenjören inte har behörighet till det nödvändiga systemet, att lösenord saknas för det nödvändiga kontot, eller att han inte har en aning om vad "Anslut till tjänstens kontrollpanel via proxy i huvudkontoret" betyder. Varje punkt ska vara fullständigt enkel.

Felaktigt — "Gå in på virtualiseringen och starta om den döda noden"
Rätt svar — "Anslut till virt.example.com via webbgränssnittet, gå till nodavsnittet och utför omstart av den nod som ger fel."

Undvik tveksamheter. Tänk på den skrämda praktikanten.

Testa alltid DRP. Det är inte bara en plan för att bocka av — det är vad som gör att du och dina kunder snabbt kan komma ur en kritisk situation. Det är optimalt att göra detta flera gånger:

• En expert och flera praktikanter arbetar på en testmiljö som så mycket som möjligt imiterar den verkliga tjänsten. Experten bryter tjänsten på olika sätt och ger praktikanterna möjlighet att återställa den enligt DRP. Alla problem, oklarheter i dokumentationen och fel noteras. Efter utbildningen av praktikanterna kompletteras och förenklas DRP på oklara ställen.
• Testning på en verklig tjänst. Det går faktiskt aldrig att skapa en perfekt kopia av en riktig tjänst. Därför är det nödvändigt att planera för att stänga av en del av servrarna ett par gånger om året, bryta anslutningar och orsaka andra incidenter från hotlistan för att utvärdera återställningsprocessen. Bättre med en planerad incident på 10 minuter mitt i natten än en plötslig nedgång i flera timmar under högbelastning med dataförlust.
• Verklig incidentutredning. Ja, det är också en del av testningen. Om en incident inträffar som inte fanns med på hotlistan, måste DRP uppdateras och revideras baserat på resultatet av utredningen.

Nyckelpunkter

1. Om något kan gå fel, kommer det inte bara att gå fel, utan det kommer att göra det på det mest katastrofala sättet.
2. Se till att du har resurser för att omdirigera belastningen vid incidenter.
3. Se till att du har säkerhetskopior, de ska skapas automatiskt och regelbundet kontrolleras för konsistens.
4. Tänk ut typiska hot-scenarier.
5. Ge ingenjörerna möjlighet att tänka ut ovanliga sätt att lamslå tjänsten.
6. DRP bör vara en enkel och rak instruktion. All komplicerad diagnostik kommer först efter att tjänsten har återställts för kunderna. Även om det är med reservkapacitet.
7. Ange nyckeltelefoner och kontakter i DRP.
8. Testa regelbundet anställda på deras förståelse av DRP.
9. Genomför planerade incidenter i produktion. Testmiljöer kan inte ersätta allt.

Källa: habr.com