Pregătim DRP - nu uitați să luați în considerare meteoritul.

Chiar și în timpul unei catastrophe, întotdeauna există timp pentru o cană de ceai

DRP (disaster recovery plan) este un lucru care, ideal, nu va fi niciodată necesar. Dar dacă cumva castorii migratori vor tăia fibra optică principală sau un junior admin va șterge baza de date de producție, vrei cu siguranță să fii sigur că ai un plan predefinit despre ce să faci cu toată această haos.

În timp ce clienții, în panică, încep să sune neîncetat la suportul tehnic, juniorul caută cianuri, tu, cu o înțelepciune aparentă, deschizi plicul roșu și începi să pui totul în ordine.

În această postare, vreau să împărtășesc recomandări despre cum să scrii un DRP și ce ar trebui să conțină. De asemenea, vom analiza următoarele aspecte:

1. Învățăm să gândim ca un villain.
2. Analizăm beneficiile unei cești de ceai în timpul apocalipsei.
3. Gândim o structură comodă pentru DRP
4. Vedem cum ar trebui testat

Pentru ce companii ar putea fi util

Este foarte dificil să tragi o linie atunci când departamentul IT începe să aibă nevoie de astfel de lucruri. Aș spune că DRP este garantat necesar dacă:

• Oprirea serverului, aplicației sau pierderea unei baze de date va duce la pierderi semnificative pentru afacere în ansamblu.
• Ai un departament IT complet. Mă refer la un departament ca unitate completă a companiei, cu propriul buget, și nu doar câțiva angajați obosiți care întind rețeaua, curăță viruși și umplu imprimante.
• Ai un buget real, chiar și pentru o rezervare parțială în caz de urgență.

Când departamentul IT cere luni întregi să primească măcar câteva HDD-uri pentru un server mai vechi pentru backup-uri, este puțin probabil să reușești să organizezi o mutare completă a serviciului căzut pe resursele de rezervă. Deși și aici documentația nu ar fi de prisos.

Documentația este importantă

Începe cu documentația. Să presupunem că serviciul tău funcționează pe baza unui script Perl, care a fost scris acum trei generații de administratori, și nimeni nu știe cum funcționează. Datoria tehnică acumulată și lipsa documentației îți va afecta inevitabil nu doar genunchiul, ci și alte membre, este o chestiune de timp.

După ce aveți o descriere bună a componentelor serviciului, analizați statistica accidentelor. Cu siguranță vor fi tipice. De exemplu, din când în când, discul se umple, ceea ce duce la indisponibilitatea nodului până la curățarea manuală. Sau serviciul pentru clienți devine inaccesibil din cauza că cineva a uitat din nou să reînnoiască certificatul, iar Let’s Encrypt nu a fost configurat sau nu a vrut să fie configurat.

Gândește ca un diversant

Cea mai dificilă parte constă în prognozarea acelor accidente care nu s-au întâmplat niciodată, dar care ar putea afecta complet serviciul tău. Aici, de obicei, jucăm rolul răufăcătorilor cu colegii. Pregătiți mult caféa și ceva gustos și închideți-vă în sala de conferințe. Asigurați-vă doar că în aceeași sala de conferințe i-ați închis și pe inginerii care au ridicat serviciul țintă sau care lucrează regulat cu acesta. Apoi, fie pe tablă, fie pe hârtie, începeți să desenați toate grozăviile posibile care ar putea să se întâmple cu serviciul vostru. Nu trebuie să detaliați până la menajera care trage cablurile, este suficient să luați în considerare scenariul „Încălcarea integrității rețelei locale”.

De obicei, majoritatea situațiilor tipice de urgență se încadrează în următoarele categorii:

• Defecțiune de rețea
• Defecțiune a serviciilor sistemului de operare
• Defecțiune a aplicației
• Defecțiune hardware
• Defecțiune de virtualizare

Pur și simplu mergeți prin fiecare categorie și verificați ce se aplică serviciului vostru. De exemplu, demonul Nginx poate cădea și nu se poate ridica – aceasta este o problemă a sistemului de operare. O situație rară care face ca aplicația web să devină nefuncțională este o defecțiune software. În timpul analizei acestei etape, este important să lucrați asupra diagnosticului problemei. Cum să distingeți o interfață blocată pe virtualizare de o cădere a routerului și o defecțiune de rețea, de exemplu. Este esențial să găsiți rapid responsabilii și să începeți să-i atrageți atenția înainte ca problema să fie rezolvată.

După ce problemele tipice sunt notate, turnăm încă o cafea și începem să explorăm cele mai ciudate scenarii în care anumite parametrii încep să depășească semnificativ norma. De exemplu:

• Ce se va întâmpla dacă timpul pe nodul activ se mută cu un minut înapoi în raport cu celelalte din cluster?
• Și dacă timpul se mută înainte, iar dacă se întâmplă asta în 10 ani?
• Ce se va întâmpla dacă, în timpul sincronizării, un nod din cluster își pierde brusc conexiunea la rețea?
• Ce se întâmplă dacă două noduri nu reușesc să împartă conducerea din cauza izolării temporare între ele în rețea?

În această etapă, o abordare de tip invers poate fi foarte utilă. Luați cel mai obsedat membru al echipei cu o imaginație bogată și dați-i sarcina de a provoca o distrugere care să afecteze serviciul în cel mai scurt timp. Dacă va fi greu de diagnosticat – cu atât mai bine. Nu veți crede ce idei ciudate și ingenioase vin inginerii atunci când le dați să spargă ceva. Iar dacă le mai promiteți și un mediu de testare pentru a face acest lucru – e și mai bine.

Ce este acest DRP al vostru?!

Deci, ați definit modelul amenințărilor. Ați luat în considerare și localnicii care taie cabluri de fibră optică în căutare de cupru, și radarul militar care dă peste linia de radiorelee strict vinerea la 16:46. Acum trebuie să înțelegeți ce să faceți cu toate acestea.

Sarcina dumneavoastră este să scrieți acele plicuri roșii care se vor deschide în caz de situație de urgență. Planificați din start că, atunci când (nu dacă!) se întâmplă ceva, lângă voi va fi doar cel mai nepregătit stagiar, cu mâinile tremurând de groază. Uitați-vă cum sunt realizate instrucțiunile de urgență în cabinetele medicale. De exemplu, ce trebuie să faceți în caz de șoc anafilactic. Personalul medical cunoaște pe de rost toate protocoalele, dar atunci când o persoană începe să moară, de multe ori toți se agită neputincioși. De aceea, pe perete atârnă un ghid clar cu pași de tipul „deschideți ambalajul celui de-al X-lea” și „administrați intravenos atâtea unități de medicament”.

În situații de urgență este greu să gândești! Trebuie să existe instrucțiuni simple pentru a fi procesate instinctiv.

Un DRP bun constă din mai multe blocuri simple:

1. Pe cine să anunțăți la începutul unei urgențe. Acest lucru este important pentru a maximiza desfășurarea procesului de remedii.
2. Cum să diagnosticați corect – efectuăm un tracert, ne uităm la systemctl status servicename și așa mai departe.
3. Cât timp se poate petrece pe fiecare etapă. Dacă nu reușiți să reparați manual în timpul SLA – mașina virtuală va fi distrusă și restaurată din backup-ul de ieri.
4. Cum să ne asigurăm că urgența s-a încheiat.

Amintiți-vă că DRP începe atunci când serviciul a eșuat complet și se încheie odată cu restaurarea funcționalității, chiar și cu o eficiență redusă. Simplă pierdere a rezervării nu ar trebui să activeze DRP. Și mai puteți include în DRP o ceașcă de ceai. Serios. Conform statisticilor, foarte multe accidente devin catastrofale din cauza panicii personalului care începe să repare ceva, omorând în același timp singura nodul activ de date sau distrugând complet clusterul. De obicei, 5 minute pentru o ceașcă de ceai vă vor oferi puțin timp pentru a vă calma și a analiza situația.

Nu confundați DRP cu pașaportul sistemului! Nu-l suprasolicitați cu date inutile. Pur și simplu oferiți posibilitatea de a naviga rapid și ușor prin hyperlinkuri către secțiunea dorită din documentație și de a citi în format extins despre zonele necesare ale arhitecturii serviciului. Iar în DRP să existe doar indicații directe despre unde și cum să te conectezi cu comenzi specifice pentru copiere și lipire.

Cum să testați corect

Asigurați-vă că orice angajat responsabil poate îndeplini toate punctele. În cel mai important moment, se poate dovedi că inginerul nu are drepturi de acces în sistemul dorit, nu are parolele pentru contul necesar sau nu înțelege ce înseamnă „Conectați-vă la consola de control a serviciului prin proxy în biroul central”. Fiecare punct trebuie să fie extrem de simplu.

Greșit — „Accesați virtualizarea și reporniți nodul mort”
Corect — „Conectați-vă prin interfața web la virt.example.com, în secțiunea noduri, efectuați repornirea nodului care provoacă eroarea”.

Nu permiteți ambiguități. Amintiți-vă de internul speriat.

Asigurați-vă că testați DRP. Nu este doar un plan pentru a bifa — este ceea ce vă va permite vouă și clienților voștri să ieșiți rapid dintr-o situație critică. Ideal ar fi să faceți acest lucru de câteva ori:

• Un expert și câțiva stagiari lucrează pe un stand de testare care imită cât mai bine serviciul real. Expertul distruge serviciul în diverse moduri și le permite stagiariilor să-l restabilească conform DRP. Toate problemele, neclaritățile din documentație și erorile sunt înregistrate. După instruirea stagiariilor, DRP este completat și simplificat în locurile neclare.
• Testare pe un serviciu real. De fapt, nu poți crea niciodată o copie perfectă a unui serviciu autentic. De aceea, de câteva ori pe an, este necesar să oprești planificat o parte din servere, să întrerupi conexiunile și să organizezi alte accidente din lista de amenințări pentru a evalua modul de recuperare. O avarie planificată de 10 minute în miezul nopții este mai bună decât o defecțiune bruscă de câteva ore în timpul vârfurilor de trafic, cu pierderi de date.
• Eliminarea reală a avariilor. Da, aceasta este și o parte din testare. Dacă apare o avarie care nu se afla pe lista de amenințări, este necesar să completezi și să ajustezi DRP-ul în baza rezultatelor investigației acesteia.

Puncte cheie

1. Dacă ceva rău se poate întâmpla, nu doar că se va întâmpla, dar o va face în cel mai catastrofal mod posibil.
2. Asigurați-vă că aveți resurse pentru a redirecționa sarcina în caz de urgență.
3. Asigurați-vă că aveți backup-uri, acestea sunt create automat și verificate periodic pentru consistență.
4. Gândiți-vă la scenariile tipice de amenințare.
5. Oferiți inginerilor ocazia să găsească variante neobișnuite de a compromite serviciul.
6. DRP-ul trebuie să fie un manual simplu și la obiect. Toată diagnostica complexă trebuie să vină doar după ce serviciul clienților a fost restabilit. Chiar și pe capacități de rezervă.
7. Indicați numerele și contactele cheie în DRP.
8. Testați regulat angajații pentru a verifica înțelegerea DRP-ului.
9. Organizați avarii planificate în producție. Standurile nu pot înlocui totul.

Sursa: habr.com