Chiar și în timpul unui dezastru există întotdeauna timp pentru o ceașcă de ceai
DRP (planul de recuperare în caz de dezastru) este un lucru care în mod ideal nu va fi niciodată necesar. Dar dacă dintr-o dată castorii care migrează în timpul sezonului de împerechere roade prin fibra optică coloana vertebrală sau un administrator junior renunță la baza productivă, cu siguranță vrei să fii sigur că vei avea un plan prestabilit pentru ce să faci cu toată această rușine.
În timp ce clienții în panică încep să taie telefoanele de asistență tehnică, juniorul caută cianura, deschizi cu înțelepciune plicul roșu și începi să pui totul în ordine.
În această postare vreau să împărtășesc recomandări despre cum să scrieți un DRP și ce ar trebui să conțină. De asemenea, ne vom uita la următoarele lucruri:
- Să învățăm să gândim ca un răufăcător.
- Să ne uităm la beneficiile unei cești de ceai în timpul apocalipsei.
- Să ne gândim la o structură DRP convenabilă
- Să vedem cum să-l testăm
Pentru ce companii ar putea fi util acest lucru?
Este foarte greu să tragi linie atunci când departamentul IT începe să aibă nevoie de astfel de lucruri. Aș spune că cu siguranță aveți nevoie de DRP dacă:
- Oprirea unui server, aplicație sau pierderea unei baze de date va duce la pierderi semnificative pentru întreaga afacere.
- Ai un departament IT cu drepturi depline. În sensul unui departament sub forma unei unități cu drepturi depline a companiei, cu buget propriu, și nu doar câțiva angajați obosiți care pun o rețea, curăță viruși și reumple imprimante.
- Ai un buget realist pentru concedieri măcar parțiale în caz de urgență.
Când departamentul IT a cerut de luni de zile cel puțin câteva HDD-uri într-un server vechi pentru copii de rezervă, este puțin probabil să puteți organiza o mutare cu drepturi depline a unui serviciu eșuat pentru a rezerva capacitate. Deși aici documentația nu va fi de prisos.
Documentarea este importantă
Începeți cu documentația. Să presupunem că serviciul tău rulează pe un script Perl care a fost scris acum trei generații de administratori, dar nimeni nu știe cum funcționează. Datoria tehnică acumulată și lipsa documentației te vor împușca inevitabil nu numai în genunchi, ci și în alte membre, este mai mult o chestiune de timp.
Odată ce aveți o descriere bună a componentelor serviciului, căutați statisticile accidentelor. Aproape sigur vor fi complet tipice. De exemplu, discul dvs. devine plin din când în când, ceea ce face ca nodul să eșueze până când este curățat manual. Sau serviciul client devine indisponibil din cauza faptului că cineva a uitat din nou să reînnoiască certificatul, iar Let's Encrypt nu a putut sau nu a dorit să se configureze.
Gânduri ca un sabotor
Partea cea mai dificilă este să preziceți acele accidente care nu s-au mai întâmplat până acum, dar care ar putea să vă blocheze complet serviciul. Aici, eu și colegii mei ne jucăm de obicei ticăloși. Luați multă cafea și ceva gustos și închideți-vă într-o sală de ședințe. Doar asigurați-vă că, în aceleași negocieri, blocați acei ingineri care au dezvoltat ei înșiși serviciul țintă sau lucrează în mod regulat cu acesta. Apoi, fie pe tablă, fie pe hârtie, începi să desenezi toate ororile posibile care s-ar putea întâmpla cu serviciul tău. Nu este necesar să intrați în detaliu până la o anumită doamnă de curățenie și să scoateți cablurile; este suficient să luați în considerare scenariul „Încălcarea integrității rețelei locale”.
De obicei, cele mai obișnuite situații de urgență se încadrează în următoarele tipuri:
- Eșecul rețelei
- Eșecul serviciilor de sistem de operare
- Eșecul aplicației
- Deficiență de fier
- Eșec de virtualizare
Doar parcurgeți fiecare tip și vedeți ce se aplică serviciului dvs. De exemplu, demonul Nginx poate cădea și nu se ridică - asta înseamnă eșecuri din partea sistemului de operare. O situație rară care face ca aplicația dvs. web să eșueze este o defecțiune a software-ului. În timp ce treceți prin această etapă, este important să stabiliți diagnosticul problemei. Cum să distingem o interfață înghețată pe virtualizare de o unitate cis căzută și un accident de rețea, de exemplu. Acest lucru este important pentru a-i găsi rapid pe cei responsabili și a începe să le tragi de coadă până când accidentul este rezolvat.
După ce se notează problemele tipice, turnăm mai multă cafea și începem să luăm în considerare cele mai ciudate scenarii, când unii parametri încep să depășească cu mult norma. De exemplu:
- Ce se întâmplă dacă timpul de pe nodul activ se deplasează cu un minut înapoi în comparație cu alții din cluster?
- Ce se întâmplă dacă timpul merge înainte, ce dacă peste 10 ani?
- Ce se întâmplă dacă un nod de cluster își pierde brusc rețeaua în timpul sincronizării?
- Ce se va întâmpla dacă două noduri nu împart conducerea din cauza izolării temporare unul a celuilalt în rețea?
În această etapă, abordarea inversă este foarte utilă. Îl iei pe cel mai încăpățânat membru al echipei cu o imaginație bolnavă și îi dai sarcina de a organiza un sabotaj în cel mai scurt timp posibil care să doboare serviciul. Dacă este dificil de diagnosticat, cu atât mai bine. Nu o să crezi ce idei ciudate și cool vin inginerii dacă le dai o idee să spargă ceva. Și dacă le promiți un banc de testare pentru asta, este absolut în regulă.
Ce este acest DRP al tău?!
Deci ți-ai definit modelul de amenințare. De asemenea, au ținut cont de localnicii care tăiau cablurile de fibră optică în căutarea cuprului și de un radar militar care aruncă o linie de releu radio strict vineri, la 16:46. Acum trebuie să înțelegem ce să facem cu toate acestea.
Sarcina ta este să scrii acele plicuri foarte roșii care vor fi deschise în caz de urgență. Așteptați-vă imediat ca atunci când (nu dacă!) totul se va sfârșit, doar cel mai neexperimentat stagiar să fie în apropiere, ale cărui mâini îi vor tremura violent de groaza a ceea ce se întâmplă. Vedeți cum sunt implementate semnele de urgență în cabinetele medicale. De exemplu, ce trebuie făcut în caz de șoc anafilactic. Personalul medical știe pe de rost toate protocoalele, dar atunci când o persoană din apropiere începe să moară, de foarte multe ori toată lumea se prinde neputincioasă de tot ce se vede. Pentru a face acest lucru, pe perete există instrucțiuni clare cu elemente precum „deschideți pachetul cu așa și așa” și „administrați atât de multe unități de medicament pe cale intravenoasă”.
E greu să te gândești într-o urgență! Ar trebui să existe instrucțiuni simple pentru analiza măduvei spinării.
Un DRP bun constă din mai multe blocuri simple:
- Pe cine să anunțe despre începutul unui accident. Acest lucru este important pentru a paraleliza cât mai mult procesul de eliminare.
- Cum să diagnosticați corect - efectuați o urmărire, căutați în systemctl status servicename și așa mai departe.
- Cât timp poți petrece pe fiecare scenă? Dacă nu aveți timp să o remediați manual în timpul SLA, mașina virtuală este oprită și este anulată din backup-ul de ieri.
- Cum să vă asigurați că accidentul s-a încheiat.
Rețineți că DRP începe atunci când serviciul a eșuat complet și se termină când serviciul este restabilit, chiar și cu o eficiență redusă. Pur și simplu pierderea unei rezervări nu ar trebui să declanșeze DRP. De asemenea, puteți scrie o ceașcă de ceai în DRP. Serios. Potrivit statisticilor, multe accidente trec de la neplăcute la catastrofale din cauza faptului că personalul se grăbește în panică să repare ceva, ucigând simultan singurul nod viu cu date sau terminând în cele din urmă clusterul. De regulă, 5 minute cu o ceașcă de ceai îți vor oferi timp să te calmezi și să analizezi ce se întâmplă.
Nu confundați DRP și pașaportul de sistem! Nu-l supraîncărcați cu date inutile. Faceți posibilă utilizarea rapidă și convenabilă a hyperlink-urilor pentru a merge la secțiunea dorită a documentației și a citi într-un format extins despre secțiunile necesare ale arhitecturii serviciului. Și în DRP în sine există doar instrucțiuni directe despre unde și cum să vă conectați cu comenzi specifice pentru copiere-lipire.
Cum să testați corect
Asigurați-vă că orice angajat responsabil este capabil să completeze toate articolele. În cel mai crucial moment, se poate dovedi că inginerul nu are drepturi de acces la sistemul necesar, nu există parole pentru contul solicitat sau nu are idee ce „Conectează-te la consola de management al serviciului printr-un proxy la sediul central” înseamnă. Fiecare punct ar trebui să fie extrem de simplu.
greșit — „Mergeți la virtualizare și reporniți nodul mort”
corect - „Conectați-vă prin interfața web la virt.example.com, în secțiunea noduri, reporniți nodul care provoacă eroarea.”
Evita ambiguitatea. Amintește-ți de stagiarul speriat.
Asigurați-vă că testați DRP. Acesta nu este doar un plan pentru spectacol - este ceva care vă va permite dvs. și clienților tăi să ieșiți rapid dintr-o situație critică. Cel mai bine este să faceți acest lucru de mai multe ori:
- Un expert și mai mulți stagiari lucrează pe un banc de testare care simulează cât mai mult posibil un serviciu real. Expertul întrerupe serviciul în diferite moduri și le permite cursanților să-l restabilească conform DRP. Toate problemele, ambiguitățile documentației și erorile sunt înregistrate. După ce cursanții sunt instruiți, DRP este extins și simplificat în zone neclare.
- Testare pe un serviciu real. De fapt, nu puteți crea niciodată o copie perfectă a unui serviciu real. Prin urmare, de câteva ori pe an este necesar să opriți în mod obișnuit unele dintre servere, să întrerupeți conexiunile și să provocați alte dezastre din lista de amenințări pentru a evalua ordinea de recuperare. O defecțiune planificată timp de 10 minute în mijlocul nopții este mai bună decât o defecțiune bruscă de câteva ore în timpul sarcinii de vârf cu pierdere de date.
- Depanare reală. Da, și asta face parte din testare. Dacă are loc un accident care nu a fost pe lista amenințărilor, este necesară completarea și finalizarea DRP pe baza rezultatelor investigației sale.
Puncte cheie
- Dacă rahat se poate întâmpla, nu numai că se va întâmpla, dar se va întâmpla în cel mai catastrofal scenariu posibil.
- Asigurați-vă că aveți resurse pentru transferul de urgență al încărcăturii.
- Asigurați-vă că aveți copii de siguranță, acestea sunt create automat și verificate în mod regulat pentru coerență.
- Gândiți-vă la scenariile tipice de amenințare.
- Oferiți inginerilor posibilitatea de a veni cu opțiuni non-standard pentru furnizarea serviciului.
- DRP ar trebui să fie o instrucțiune simplă și directă. Toate diagnosticele complexe sunt efectuate numai după ce serviciul clienților a fost restabilit. Chiar dacă la capacitate de rezervă.
- Furnizați numere de telefon cheie și contacte în DRP.
- Testați în mod regulat înțelegerea angajaților cu privire la DRP.
- Aranjați accidentele planificate la locurile de producție. Standurile nu pot înlocui totul.
Sursa: www.habr.com