🥇Valmistame DRP-d - ärge unustage meteoriiti

Isegi katastroofi ajal on alati aega tassikese teed nautida

DRP (katastroofide taastamiskava) on asi, mis ideaaljuhul ei peaks kunagi vajalikuks osutuma. Aga kui näiteks abieluajal rändavad beebid läbivad peamised kiudoptilised kaablid või noor administraator kustutab tootmisandmebaasi, soovite kindlasti olla kindel, et teil on eelnevalt koostatud plaan, kuidas kogu selle segadusega toime tulla.

Kuna kliendid paanikas nutavad tehnilise toe telefonide otsa, otsib noor kaaslane tsüaniide, avate teie targalt punase ümbriku ja hakkate kõike korda seadma.

Selles postituses soovin jagada soovitusi, kuidas DRP-d kirjutada ja mida see peaks sisaldama. Samuti vaatame järgmisi asju:

Õpime mõtlema nagu kurikael.
Käsitleme tassi tee kasu apokalüpsise ajal.
Mõtleme läbi mugav DRP struktuur
Vaata, kuidas seda testida

Kellele see võiks kasuks olla

Väga keeruline on tõmmata piiri, kui IT-osakond hakkab sellistest asjadest vajama. Ütleksin, et DRP on teil kindlasti vajalik, kui:

Serveri, rakenduse seiskamine või andmebaasi kadumine toob kaasa märkimisväärsed äriotsused.
Teil on korralik IT-osakond. Tahan öelda, et osakond, mis on ettevõtte täieõiguslik üksus oma eelarvega, mitte lihtsalt mõned väsinud töötajad, kes loovad võrku, puhastavad viirusi ja täidavad printereid.
Teil on tegelik eelarve vähemalt osalise varukoopia tegemiseks hädaolukordade korral.

Kui IT-osakond palub kuude kaupa vähemalt paar HDD'd vanasse serverisse varukoopiate jaoks, on teil tõenäoliselt keeruline korraldada korralikku üleviimist langenud teenuse varurežiimile. Kuigi ka siin on dokumentatsioon liialt olematu.

Dokumentatsioon on tähtis

Alustage dokumentatsioonist. Oletame, et teie teenus töötab Perlil põhineva skripti peal, mille on kirjutanud kolm põlvkonda administraatoreid tagasi, ja keegi ei tea, kuidas see töötab. Kogunenud tehniline võlg ja dokumentatsiooni puudumine võivad teile põhjustada mitte ainult põlve, vaid ka teisi jäsemeid, see on pigem ajaküsimus.

Pärast korraliku teenusekomponentide kirjelduse töötamist vaadake üle rikke statistika. Need on tõenäoliselt igati tüüpilised. Näiteks on teil aeg-ajalt kett täis, mis viib sõlme rikke, kuni see käsitsi puhastatakse. Või muutub klientide teenus kättesaamatuks, kuna keegi unustas sertifikaadi pikendamise, samal ajal kui Let’s Encrypti seadistamine ei õnnestunud või ei olnud huvi.

Mõtle nagu diversant.

Kõige keerulisem osa on ennustada neid rikkeid, mida pole kunagi olnud, kuid mis võivad teie teenuse täielikult kokku kukutada. Siin mängime tavaliselt kolleegidega pahategijaid. Võtke palju kohvi ja midagi maitsvat ning lukustage end koosolekuruumi. Ainult veenduge, et olete lukustanud ka need insenerid, kes teenust kohtlesid või kellega nad regulaarselt töötavad. Edasi, kas tahvlil või paberil, hakkate joonistama kõiki võimalikke õudusi, mis võivad teie teenusega juhtuda. Ei ole vajalik detailideni minna, piisab, kui käsitleda stsenaariumi "Kohaliku võrgu puutumatuse rikkumine".

Tavaliselt mahuvad enamik tüüpilisi avariilisi olukordi järgmiste liikide alla:

Võrgu rike.
OS teenuste rike.
Rakenduse rike.
Riistvara rike.
Virtuaalsete keskkondade rike.

Lihtsalt minge läbi iga liigi ja vaadake, mis teie teenusele kehtib. Näiteks võib Nginxi demon talitlushäire korral alla kukkuda ja mitte enam töötada - see on OS rike. Haruldane olukord, mis viib teie veebirakenduse mittefunktsioneerimiseni - tarkvara rike. Selle etapi töötlemisel on oluline tegeleda probleemide diagnostikaga. Kuidas eristada luksumise tõttu virtuaalses keskkonnas seiskunud liidest kukkumiseks ja võrgu rikkeid, näiteks. See on oluline, et kiiresti leida vastutavad ja hakata neid sabast haarama, kuni rike on kõrvaldatud.

Kui tüüpilised probleemid on kirja pandud, valame veel kohvi ja hakkame arutama kõige veidramate stsenaariumite üle, kus mõned parameetrid hakkavad normist tugevalt välja minema. Näiteks:

Mis juhtuks, kui aktiivse sõlme aeg libiseks ühe minuti võrra tagasi võrreldes klastriga?
Ent kui aeg edasi libiseks, aga 10 aasta võrra?
Mis juhtub, kui klastris oleva sõlme võrguühendus katkeb sümbioosi ajal?
Mis juhtub, kui kaks sõlme ei suuda omavahel juhtimist jagada ajutise võrgu isolatsiooni tõttu?

Sel hetkel aitab väga tagurpidi lähenemine. Võtke oma meeskonna kõige fantaasiarikkaim liige ja andke talle ülesanne võimalikult kiiresti korraldada diversioon, mis teenuse maha võtab. Kui seda on raske diagnoosida — veel parem. Te ei usu, kui imelikke ja lahedaid ideid insenerid esitavad, kui anda neile idee midagi rikkuva. Ja kui lubate neile testkeskkonna — on see juba suurepärane.

Mis asi on see teie DRP?!

Nii et olete tuvastanud ohumudeli. Olete arvesse võtnud ka kohalikke elanikke, kes lõikavad optilisi kaableid vaseotsingul, ja sõjaväeradarit, mis sööstab raadioreleed iga reede kell 16:46. Nüüd peate välja mõtlema, mida kõikide nende asjadega teha.

Teie ülesanne on kirjutada need punased ümbrikud, mis avatakse hädaolukorras. Arvestage kohe, et kui (mitte „kui!”) kõik kokku kukub, on läheduses ainult kõige kogenematum praktikant, kelle käed värisevad hirmust toimuva ees. Vaadake, kuidas on saadud ellu viidud hädaabinäidikud meditsiini kabinetides. Näiteks, mida teha anafülaktilise šoki korral. Meditsiinipersonal teab kõiki protokolle peast, kuid kui keegi hakkab surema, haaravad kõik tihti segaduses kõigest järele. Selle jaoks on seinale lisatud selged juhised punktide kohta, nagu "avatage selle pakendi" ja "manustage intravenoosselt nii palju ühikuid ravimit".

Hädaolukorras on raske mõelda! Peavad olema lihtsad juhised, et selgroog suudaks need tõlgendada.

Hea DRP koosneb mitmest lihtsast osast:

Keda teavitada hädaolukorra algusest. See on oluline, et maksimaalselt paralelleerida vahetegevust.
Kuidas õigesti diagnoosida — teeme jälgimise, vaatame systemctl status servicename ja nii edasi.
Kui kaua tohib iga etapi peale aega kulutada. Kui te ei suuda SLA-s ettenähtud aja jooksul käsitsi parandada — virtuaalmasin lõpetatakse ja taastatakse eilse varukoopiast.
Kuidas kinnitada, et hädaolukord on lõppenud.

Pidage meeles, et DRP algab siis, kui teenus on täielikult ebaõnnestunud, ja lõpeb töövõime taastamisega, isegi kui see on vähenenud efektiivsusega. Lihtne reserveerimise kaotamine ei tohiks aktiveerida DRP-d. Ja võite DRP-sse kirjutada tassi teed. Tõsiselt. Statistika kohaselt muutuvad paljud õnnetused ebameeldivatest katastroofideks, kuna töötajad paanikas üritavad midagi parandada, samal ajal tappes ainus elav sõlm andmetega või hukates klastrit lõpuni. Tüüpiliselt annab 5 minutit tassi teed, et veidi rahuneda ja analüüsida, mis toimub.

Ärge segage DRP-d ja süsteemi passit! Ärge koormake seda liigsete andmetega. Lihtsalt andke võimalus kiiresti ja mugavalt hüperlinkide kaudu liikuda vajalikes dokumentatsiooni osades ja lugeda laiemalt teenuse arhitektuuri kohta. DRP-sse sisestage vaid otsesed juhised, kuhu ja kuidas подключиться, koos konkreetsete käskudega копипасты jaoks.

Kuidas õigesti testida

Veenduge, et iga vastutav töötaja suudab täita kõiki punkte. Kõige kriitilisemal hetkel võib juhtuda, et inseneril ei ole õigusi ligipääsuks vajalikku süsteemi, vajalikud paroolid puuduvad või ta ei saa aru, mida tähendab "Ühendage teenuse juhtimise konsooli kaudu proksi pealinna". Iga punkt peaks olema äärmiselt lihtne.

Vale — "Minge virtualiseerimise juurde ja taaskäivitage surnud sõlm"
Õige — "Ühendage veebiliidese kaudu virt.example.com, секtsioonis sõlm minge edasi ja taaskäivitage tõrke põhjustav sõlm."

Ärge lubage kahemõttelisust. Pidage meeles hirmul praktikanti.

Kohustuslikult testige DRP-d. See ei ole lihtsalt plaan, mis tuleb ära märkida – see on see, mis võimaldab teil ja teie klientidel kiiresti kriitilisest olukorrast väljumiseks. Optimaalselt tuleks seda teha mitu korda:

Üks ekspert ja mõned praktikandid töötavad testkeskkonnas, mis maksimaalselt imiteerib reaalset teenust. Ekspert rikub teenust erinevatel viisidel ja annab praktikantidele võimaluse seda vastavalt DRP-le taastada. Kõik probleemid, dokumentatsioonis esinevad ebaselgused ja vead registreeritakse. Pärast praktikantide koolitust täiendatakse ja lihtsustatakse DRP-d ebaselgete kohtade osas.
Testimine reaalses teenuses. Tegelikult ei saa kunagi luua täiuslikku ko copies tõelisest teenusest. Seetõttu on paar korda aastas vajalik plaanipäraselt sulgeda osa serveritest, katkestada ühendusi ja korraldada muid õnnetusi ähvarduste loendist, et hinnata taastumise korda. Paremini on plaanipärane õnnetus 10 minutiks keset ööd, kui äkiline rike mitu tundi tipukoormuse ajal andmete kaotusega.
Tõeline õnnetuse kõrvaldamine. Jah, see on samuti osa testimisest. Kui juhtub õnnetus, millel ei olnud ähvarduste loendis, tuleb DRP-d täiendada ja täiustada selle uurimise tulemuste põhjal.

Peamised punktid

Kui midagi võib juhtuda, siis see mitte ainult ei juhtu, vaid juhtub ka maksimaalselt katastroofilises stsenaariumis.
Veenduge, et teil on ressursid hädaolukorraks koormuse ümbersuunamiseks.
Veenduge, et teil on varukoopiad, need luuakse automaatselt ja neid kontrollitakse regulaarselt järjepidevuse osas.
Mõelge tüüpiliste ähvarduste stsenaariumidele.
Andke inseneridele võimalus leida ebatüüpilisi viise teenuse nurjamiseks.
DRP peab olema lihtne ja lamba juhend. Kõik keeruline diagnostika alles pärast seda, kui klientide teenus on taastatud. Olgu see isegi varuressurssidel.
Määrake DRP-s võtme telefoninumbrid ja kontaktid.
Regulaarselt testige töötajaid DRP mõistmise osas.
Korraldage plaanipäraseid õnnetusi tootmisvõimes. Seismised ei saa asendada kõike.