Valmistame DRP-d — ärge unustage arvestada meteoriidiga

Isegi katastroofi ajal on alati aega tassitäite tee joomiseks

DRP (disaster recovery plan) — see on asi, mida ideaalis ei peaks kunagi vaja minema. Kuid kui äkki, rändamisaegsed kobraste, närivad peamise kiudoptilise kaabli läbi või noor administraator kustutab töökeskkonna andmebaasi, soovite kindlasti olla kindel, et teil on eelnevalt koostatud plaan selle kõigega tegelemiseks.

Kui kliendid paanikas hakkavad tehnilise toe telefoniliine katkestama, otsib noor administreerija tsüaniide, samal ajal kui te olete tarkad silmadega punase ümbriku avanud ja hakkate kõike korda seadma.

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

1. Õpime mõtlema nagu kurikael.
2. Käime läbi tassi tee kasu apokalüpsise ajal.
3. Mõtleme mugava DRP struktuuri peale
4. Vaadake, kuidas seda testida

Millistele ettevõtetele see võib olla kasulik

On väga keeruline tõmmata piir, kui IT-osakond hakkab selliseid asju vajama. Ütlesin, et DRP on teile kindlasti vajalik, kui:

• Server, application, or database downtime can lead to significant business losses overall.
• You have a full IT department. A department as a complete unit of the company, with its own budget, not just a few exhausted employees managing the network, cleaning viruses, and refilling printers.
• You have an actual budget for at least partial backup in case of emergencies.

When the IT department begs for months for just a couple of HDDs for an old server for backups, it’s unlikely you'll be able to organize a full migration of a downed service to backup resources. However, documentation will still be invaluable.

Documentation is important.

Start with documentation. Let's say your service operates on a Perl script written three generations of admins ago, and no one knows how it works. The accumulated technical debt and lack of documentation will inevitably shoot you not only in the knee but also in other extremities; it is merely a matter of time.

Kui teil on olemas teenuse komponentide hea kirjeldus, koguge statistikat avariide kohta. Peaaegu kindlasti on need täiesti tüüpilised. Näiteks, kui teie kettaruumi aeg-ajalt täitub, viib see sõlme tõrkuseni kuni käsitsi puhastamiseni. Või on klienditeenindus kergesti ligipääsetav, kuna keegi unustas uuendada sertifikaati, ja Let’s Encrypt'i seadistamine ei õnnestunud või ei olnud soovitud.

Mõtle nagu diversant

Kõige keerulisem osa on ennustada neid rikkeid, mida pole kunagi varem esinenud, aga mis võivad teie teenuse täielikult välja lülitada. Siinkohal mängime tavaliselt kolleegidega kurikaelu. Võtke palju kohvi ja midagi maitsvat ning lukustuge koosolekuruumi. Ainult veenduge, et lukustasite sinna ka need insenerid, kes teenuseid üles tõstsid või töötavad pidevalt nendega. Seejärel joonistage kas tahvlile või paberile kõik võimalikud õudused, mis võivad teie teenusega juhtuda. Ei ole vajalik detailideni minna, piisab, kui arutada stsenaariumi „Kohaliku võrgu terviklikkuse rikkumine“.

Tavaliselt mahub enamik tüüpilisi avariisituatsioone järgmiste kategooriate alla:

• Võrguhäired
• OS teenuste haprused
• Rakenduse rikked
• Riistvara rikete
• Virtualiseerimise probleemid

Lihtsalt lähege läbi iga tüübi ja vaadake, mis teie teenusele kehtib. Näiteks võib Nginx'i demon kukkuda ja mitte tõusta – see on OS-i poolt põhjustatud tõrge. Harv olukord, mis toob teie veebirakenduse tööseisaku – tarkvara tõrge. Selle etapi läbimise ajal on oluline tõrke diagnoosimine. Kuidas eristada virtuaalisse jääkidest eri interfeyssi võrgu ja riistvara tõrgetest? See on oluline, et kiiresti leida vastutavad ja hakata neid segama, kuni hädaolukord on lahendatud.

Pärast seda, kui tüüpilised probleemid on üles kirjutatud, valame veel kohvi ja hakkame vaatama kõige kummalisemaid stsenaariume, kus teatud parameetrid hakkavad normist tugevalt väljumiseks. Näiteks:

• Mida juhtub, kui aktiivse sõlme aeg nihkub minuti võrra tagasi võrreldes teistega klastris?
• Ent kui aeg nihkub ettepoole, ja mis siis, kui 10 aastat?
• Mida juhtub, kui klastrisõlm kaotab võrgus ootamatult ühenduse sünkroniseerimise ajal?
• Ja mis juhtub, kui kaks sõlme ei saa omavahel juhtimist jagada, kuna nad on ajaliselt võrgu kaudu eraldatud?

Selles etapis aitab väga tagurpidi lähenemine. Võta kõige rohkem hullumeelne tiimiliige, kellel on haige fantaasia, ja anna talle ülesanne lühikese aja jooksul korraldada diversioon, mis rikub teenuse. Kui seda on raske diagnoosida — veel parem. Sa ei usu, kui kummalisi ja lahedaid mõtteid insenerid väljendavad, kui anda neile idee midagi purustada. Ja kui lubada neile selleks testimisseade — on asi täiesti hea.

Mis on see teie DRP?!

Nii, olete määratlenud ohtude mudeli. Olete arvestanud ka kohalikke elanikke, kes lõikavad kiudoptilisi kaableid vaskematerjali otsinguil, ning sõjaväeradarit, mis kukutab raadioside liini täpselt reedeti kell 16:46. Nüüd tuleb aru saada, mida kõigega peale hakata.

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 vähem kogenud praktikant, kelle käed värisevad hirmust, mis toimub. Vaadake, kuidas hädaabitabletid on rakendatud meditsiinilistes kabinetides. Näiteks, mida teha anafülaktilise šoki korral. Meditsiinipersonal teab kõik protokollid peast, kuid kui läheduses on inimene, kes hakkab surema, haaravad nad sageli eksimatult kõike. Selleks on seinal selge juhend punktide kujul nagu „avatud pakend” ja „sisestada veeni nii palju ravimit”

Hädaolukorras on raske mõelda! Peavad olema lihtsad juhised, et töötada sisemise instinkti järgi.

Hea DRP koosneb mitmest lihtsast plokkist:

1. Keda teavitada hädaolukorra algusest. See on oluline, et maksimaalselt jagada likvideerimise protsessi.
2. Kuidas õigesti diagnoosida — teeme jälgimise, vaatame systemctl status servicename ja nii edasi.
3. Kui kaua võib iga etapi jaoks aega võtta. Kui te ei suuda SLA aja jooksul käsitsi parandada — virtuaalne masin hävitatakse ja taastatakse eilse varukoopia põhjal.
4. Kuidas veenduda, et rike on lõpetatud.

Pidage meeles, et DRP algab siis, kui teenus on täielikult tõrgenenud ja lõpeb töövõime taastamisega, isegi vähendatud tõhususega. Lihtne varukoopia kaotamine ei peaks DRP-d aktiveerima. Ja võite DRP-sse lisada ka tassi teed. Tõsiselt. Statistika kohaselt muutuvad paljud rikkeolukorrad ebameeldivatest katastroofilisteks, kuna töötajad kiirustavad midagi parandama, samal ajal hävitades viimase elava sõlme andmete jaoks või lõpetades klastrit täielikult. Üldiselt annavad 5 minutit tassi tee tarbimiseks teile veidi aega rahuneda ja toimuvale analüüsida.

Ärge segage DRP-d süsteemi passiga! Ärge koormake seda liialdaste andmetega. Lihtsalt võimaldage kiiresti ja mugavalt hüperlinkide kaudu dokumentatsiooni õigetesse osadesse liikuda ning lugeda määratud teenuse arhitektuuri kohta laiemas vormingus. DRP-s peaksid olema ainult otsesed juhised, kuhu ja kuidas ühenduda, koos konkreetsete koopiatena sisestamiseks sobivate käskudega.

Kuidas õigesti testida

Veenduge, et iga vastutav töötaja suudab täita kõiki punkte. Kõige olulisemal hetkel võib selguda, et inseneril pole vajalikke õigusi vajalikku süsteemi sisenemiseks, puuduvad paroolid õigete kontode jaoks või ta ei tea, mida tähendab „Ühenduge teenuste juhtpaneeli kaudu proxy kaudu peakorterisse.“ Iga punkt peab olema äärmiselt lihtne.

Vale — „Minge virtualiseerimise juurde ja taaskäivitage surnud sõlm“
Õige — „Ühenduge virt.example.com veebiliidese kaudu, valige sõlmede jaotises taaskäivitus sõlm, mis põhjustab vea.“

Ärge lubage ebaselgust. Pöörake tähelepanu hirmunud praktikandile.

Testige kindlasti DRP-d. See pole lihtsalt dokumendi koostamine — see on osa, mis aitab teil ja teie klientidel kiiresti kriisist üle saada. Parim on seda teha mitu korda:

• Üks ekspert ja mitmed praktikandid töötavad testimistempli peal, mis simuleerib tõeliselt teenust. Ekspert katkestab teenuse erinevatel viisidel ja annab praktikantidele võimaluse seda taastada vastavalt DRP-le. Kõik probleemid, dokumentatsiooni ebaselgused ja vead on kirja pandud. Pärast praktikantide koolitust täiustatakse ja lihtsustatakse DRP-d arusaamatutes kohtades.
• Testimine reaalsetes teenustes. Tõeliselt ei saa kunagi luua täiuslikku kopeerimist tõelisest teenusest. Seepärast tuleb paar korda aastas plaanipäraselt välja lülitada osa serveritest, katkestada ühendusi ja korraldada muid õnnetusi, et hinnata taastamise korda. Paremini on kümme minutit plaanitud avariid keset ööd, kui äkiline rike, mis kestab mitu tundi tipptunnil andmete kadumisega.
• Tõeline avariide kõrvaldamine. Jah, see on samuti osa testimisest. Kui juhtub avarii, mida pole ohtude nimekirjas, tuleb DRP-d täiendada ja täiendada tulemuste põhjal, mille leiate selle uurimise käigus.

Peamised punktid

1. Kui midagi halvasti juhtub, ei juhtu see lihtsalt, vaid toimub maksimaalselt katastroofilise stsenaariumi järgi.
2. Veenduge, et teil on ressursid hädaolukorra koormuse üleviimiseks.
3. Veenduge, et teil on varukoopiad, mis luuakse automaatselt ja kontrollitakse regulaarselt järjepidevuse osas.
4. Mõelge tüüpiliste ohu stsenaariumide peale.
5. Andke inseneridele võimalus välja mõelda ebatüüpilisi viise teenuse katkemiseks.
6. DRP peab olema lihtne ja arusaadav juhend. Kõik keeruline diagnostika toimub alles siis, kui klientide teenus on taastatud. Olgu see isegi varuresursside peal.
7. Määrake DRP-s võtmete telefoond ja kontaktid.
8. Regulaarselt katsetage töötajate arusaama DRP-st.
9. Korraldage planeeritud avariisid tootmisprotsessis. Seisundid ei saa kõike asendada.

Allikas: habr.com