Ook tijdens een calamiteit is er altijd tijd voor een kopje thee.
DRP (noodherstelplan) is iets dat idealiter nooit nodig zal zijn. Maar als plotseling de bevers die tijdens het paarseizoen migreren door de belangrijkste optische vezel knagen of als de junior admin de productieve basis laat vallen, wil je er zeker van zijn dat je een vooraf gemaakt plan hebt van wat je met al deze schande moet doen.
Terwijl paniekerige klanten technische ondersteuning beginnen te bellen, een junior op zoek is naar cyanide, open jij wijselijk de rode envelop en begin je alles op orde te brengen.
In dit bericht wil ik aanbevelingen delen over het schrijven van een DRP en wat deze moet bevatten. We kijken ook naar het volgende:
- Leer denken als een slechterik.
- Laten we de voordelen van een kopje thee tijdens de apocalyps analyseren.
- Denk na over een handige DRP-structuur
- Laten we eens kijken hoe we het kunnen testen
Welke bedrijven kunnen hiervan profiteren?
Het is heel moeilijk om een grens te trekken wanneer de IT-afdeling deze dingen nodig begint te krijgen. Ik zou zeggen dat je DRP gegarandeerd nodig hebt als:
- Het stopzetten van een server, een applicatie of het verliezen van een database leidt tot aanzienlijke verliezen voor het bedrijf als geheel.
- Je hebt een volwaardige IT-afdeling. Ik bedoel, een afdeling als een volwaardige eenheid van het bedrijf, met een eigen budget, en niet alleen een paar vermoeide medewerkers die een netwerk aanleggen, virussen opschonen en printers bijvullen.
- Je hebt een realistisch budget voor in ieder geval gedeeltelijke boventalligheid in geval van calamiteiten.
Als de IT-afdeling al maanden smeekt om minstens een paar HDD's voor een oude server voor back-ups, is het onwaarschijnlijk dat u een volledige verhuizing van de uitgevallen dienst naar vrije capaciteit kunt organiseren. Hoewel de documentatie hier ook niet overbodig zal zijn.
Documentatie is belangrijk
Begin met documentatie. Laten we zeggen dat uw service draait op een Perl-script dat drie generaties beheerders geleden is geschreven en niemand weet hoe het werkt. De opgebouwde technische schuld en het gebrek aan documentatie zullen je onvermijdelijk niet alleen in de knie schieten, maar ook in andere ledematen, het is eerder een kwestie van tijd.
Zodra u een goede beschrijving van de servicecomponenten bij de hand heeft, verhoogt u de crashstatistieken. Vrijwel zeker zullen ze volledig typisch zijn. U hebt bijvoorbeeld van tijd tot tijd een volle schijf, waardoor het knooppunt uitvalt totdat het handmatig wordt opgeschoond. Of de klantenservice valt weg doordat iemand weer vergeten is het certificaat te verlengen, maar Let's Encrypt niet kon of wilde instellen.
Gedachten als een saboteur
Het moeilijkste is het voorspellen van die ongevallen die nog nooit eerder zijn gebeurd, maar die uw service mogelijk volledig kunnen ruïneren. Hier spelen we meestal schurken met collega's. Neem veel koffie en iets lekkers mee en sluit je op in de vergaderruimte. Zorg er wel voor dat u in dezelfde vergadering die technici hebt vergrendeld die zelf de doelservice hebben verhoogd of er regelmatig mee werken. Dan begin je, op het bord of op papier, alle mogelijke verschrikkingen te tekenen die je dienst kunnen overkomen. Het is niet nodig om uit te werken tot een specifieke schoonmaakster en het trekken van kabels, het volstaat om het scenario “Schending van de integriteit van het lokale netwerk” te beschouwen.
Gewoonlijk passen de meeste typische noodsituaties in de volgende typen:
- Netwerkstoring
- OS-servicefout
- Applicatie mislukt
- ijzer falen
- Virtualisatie mislukt
Doorloop gewoon elke weergave en kijk wat van toepassing is op uw service. De Nginx-daemon kan bijvoorbeeld vallen en niet stijgen - dit is een fout van het besturingssysteem. Een zeldzame situatie die ervoor zorgt dat uw webtoepassing niet meer werkt, is een softwarefout. Tijdens de ontwikkeling van deze fase is het belangrijk om de diagnose van het probleem uit te werken. Hoe een vastgelopen interface op virtualisatie te onderscheiden van bijvoorbeeld een gevallen cisco en een netwerkcrash. Dit is belangrijk om snel de verantwoordelijken te vinden en aan hun staart te trekken totdat het ongeval is verholpen.
Nadat de typische problemen zijn opgeschreven, schenken we meer koffie in en beginnen we de vreemdste scenario's te overwegen, wanneer sommige parameters buiten de norm beginnen te gaan. Bijvoorbeeld:
- Wat gebeurt er als de tijd op het actieve knooppunt een minuut teruggaat ten opzichte van andere in het cluster?
- En als de tijd vooruit gaat, en als met 10 jaar?
- Wat gebeurt er als een clusterknooppunt plotseling het netwerk verliest tijdens synchronisatie?
- En wat gebeurt er als twee knooppunten het leiderschap niet delen vanwege tijdelijke isolatie van elkaar over het netwerk?
In dit stadium helpt de omgekeerde benadering veel. Neem het meest koppige lid van het team met een zieke fantasie en geef hem de taak om in de kortst mogelijke tijd een afleiding te regelen, waardoor de dienst stilvalt. Als het moeilijk te diagnosticeren is, nog beter. Je zult de rare en coole ideeën niet geloven die ingenieurs bedenken wanneer ze het idee krijgen om iets kapot te maken. En als je ze hiervoor een proefstand belooft, is dat heel goed.
Wat is dat voor DRP van jou?!
Dus je hebt het dreigingsmodel gedefinieerd. Ze hielden ook rekening met lokale bewoners die glasvezelkabels doorknipten op zoek naar koper, en een militaire radar die strikt op vrijdag om 16:46 een radiorelaislijn laat vallen. Nu moeten we bedenken wat we er allemaal mee gaan doen.
Jouw taak is om dezelfde rode enveloppen te schrijven die in geval van nood worden geopend. Verwacht meteen dat wanneer (niet als!) Alles in de war is, alleen de meest onervaren stagiair in de buurt zal zijn, wiens handen hevig zullen trillen van de gruwel van wat er gebeurt. Zie hoe alarmsignalen worden geïmplementeerd in medische kantoren. Wat te doen bijvoorbeeld bij anafylactische shock. De medische staf kent alle protocollen uit het hoofd, maar wanneer een persoon in de buurt begint te sterven, grijpt iedereen vaak hulpeloos naar alles. Hiervoor hangt een duidelijke instructie aan de muur met items als "open de verpakking van die en die" en "injecteer zoveel eenheden van het medicijn intraveneus".
Het is moeilijk om na te denken in een noodgeval! Er moeten eenvoudige instructies zijn voor het ontleden van de wervelkolom.
Een goede DRP bestaat uit een paar simpele blokken:
- Wie te informeren over het begin van het ongeval. Dit is belangrijk om het eliminatieproces zoveel mogelijk parallel te laten verlopen.
- Hoe correct te diagnosticeren - we traceren, kijken in systemctl status servicenaam enzovoort.
- Hoeveel tijd kan aan elke fase worden besteed. Als u tijdens de SLA-tijd geen tijd heeft om het met uw handen te repareren, wordt de virtuele machine gedood en uit de back-up van gisteren gerold.
- Hoe u ervoor kunt zorgen dat de crash voorbij is.
Onthoud dat DRP begint wanneer de service volledig is mislukt en wordt voltooid door herstel, zelfs met verminderde efficiëntie. Het simpelweg verliezen van een reservering zou DRP niet moeten activeren. U kunt ook een kopje thee voorschrijven in DRP. Ernstig. Volgens de statistieken gaan veel ongelukken van onaangenaam naar catastrofaal, omdat het personeel in paniek haast om iets te repareren, waarbij tegelijkertijd het enige actieve knooppunt met gegevens wordt gedood of uiteindelijk het cluster wordt afgemaakt. In de regel geeft 5 minuten voor een kopje thee je wat tijd om te kalmeren en te analyseren wat er gebeurt.
Verwar DRP en systeempaspoort niet! Overlaad het niet met onnodige gegevens. Geef gewoon de mogelijkheid om snel en gemakkelijk naar het vereiste deel van de documentatie te gaan via hyperlinks en lees in een uitgebreid formaat over de noodzakelijke delen van de servicearchitectuur. En in de DRP zelf zijn er alleen directe instructies over waar en hoe verbinding te maken met specifieke commando's voor kopiëren en plakken.
Hoe correct te testen
Zorg ervoor dat elke verantwoordelijke medewerker alle items kan voltooien. Op het meest cruciale moment kan blijken dat de engineer geen toegangsrechten heeft tot het benodigde systeem, er geen wachtwoorden zijn voor het benodigde account, of hij geen idee heeft wat “Maak verbinding met de service management console via een proxy op de hoofdkantoor” betekent. Elk item moet zo eenvoudig mogelijk zijn.
Неправильно - "Ga naar virtualisatie en start de dode node opnieuw op"
Правильно - "Verbind via de webinterface met virt.example.com, in de node-sectie, herlaad de node die de fout veroorzaakt."
Voorkom onduidelijkheid. Denk aan de bange stagiaire.
Test zeker DRP. Dit is niet alleen een plan voor de show - het is iets waarmee u en uw klanten snel uit een kritieke situatie kunnen komen. Het is het beste om dit meerdere keren te doen:
- Een expert en meerdere stagiaires werken aan een testbank die een echte dienst zoveel mogelijk nabootst. De deskundige verbreekt de service op verschillende manieren en stelt de cursisten in staat deze te herstellen volgens de DRP. Alle problemen, onduidelijkheden in de documentatie en fouten worden vastgelegd. Na het trainen van de trainees wordt DRP op onduidelijke plekken aangevuld en vereenvoudigd.
- Testen op een echte dienst. In feite kun je nooit een perfecte kopie maken van een echte dienst. Daarom is het een paar keer per jaar nodig om een deel van de servers op geplande basis uit te schakelen, verbindingen te verbreken en andere ongevallen uit de lijst met bedreigingen te regelen om de herstelopdracht te evalueren. Het is beter om midden in de nacht een geplande storing van 10 minuten te hebben dan een plotselinge storing van enkele uren bij piekbelasting met gegevensverlies.
- Echte eliminatie van het ongeval. Ja, ook dit is onderdeel van de toetsing. Indien zich een ongeval voordoet dat niet in de lijst met dreigingen stond, is het noodzakelijk om het DRP aan te vullen en af te ronden op basis van de resultaten van het onderzoek.
Kernpunten
- Als onzin kan gebeuren, zal het niet zomaar gebeuren, maar het zal het doen in het meest catastrofale scenario.
- Zorg ervoor dat u over de middelen voor failover beschikt.
- Zorg voor back-ups, deze worden automatisch aangemaakt en regelmatig gecontroleerd op consistentie.
- Overweeg typische dreigingsscenario's.
- Geef ingenieurs de mogelijkheid om niet-standaard opties te bedenken om de service te plaatsen.
- DRP moet eenvoudige en domme instructies zijn. Alle complexe diagnostiek alleen nadat klanten de service hebben hersteld. Ook als hij stand-by staat.
- Maak een lijst van belangrijke telefoonnummers en contacten in DRP.
- Test medewerkers regelmatig op DRP-begrip.
- Regel geplande ongevallen op het product. Statieven kunnen niet alles vervangen.
Bron: www.habr.com