Isegi katastroofi ajal on alati aega tassikese tee jaoks.
DRP (katastroofi taastamise plaan) on asi, mida ideaaljuhul kunagi vaja ei lähe. Kui aga paaritumishooajal rändavad koprad äkitselt peamise optilise kiu läbi närivad või nooremadmin produktiivse baasi maha laseb, tahad kindlasti olla kindel, et sul on valmis plaan, mida kogu selle häbiga peale hakata.
Samal ajal kui paanikas kliendid hakkavad helistama tehnilisele toele, juunior otsib tsüaniidi, avad targalt punase ümbriku ja hakkad kõike korda seadma.
Selles postituses tahan jagada soovitusi, kuidas DRP-d kirjutada ja mida see peaks sisaldama. Vaatame ka järgmist:
- Õppige mõtlema nagu kaabakas.
- Analüüsime tassi tee kasulikkust apokalüpsise ajal.
- Mõelge mugavale DRP-struktuurile
- Vaatame, kuidas seda testida
Millised ettevõtted võivad sellest kasu saada?
Väga raske on tõmmata joont, millal IT-osakonnal neid asju vaja läheb. Ma ütleksin, et teil on kindlasti vaja DRP-d, kui:
- Serveri, rakenduse peatamine või mõne andmebaasi kaotamine toob ettevõttele tervikuna kaasa märkimisväärse kahju.
- Teil on täisväärtuslik IT-osakond. Pean silmas osakonda kui ettevõtte täisväärtuslikku üksust, millel on oma eelarve, mitte ainult paar väsinud töötajat, kes panevad võrku, puhastavad viiruseid ja täidavad printereid.
- Teil on realistlik eelarve hädaolukorras vähemalt osaliseks koondamiseks.
Kui IT-osakond on kuude kaupa kerjanud vähemalt paari kõvaketast vanasse serverisse varukoopiate tegemiseks, ei suuda te tõenäoliselt korraldada ebaõnnestunud teenuse täieõiguslikku kolimist võimsuse reservimiseks. Kuigi siin ei ole dokumentatsioon üleliigne.
Dokumentatsioon on oluline
Alustage dokumentatsioonist. Oletame, et teie teenus töötab Perli skriptil, mis on kirjutatud kolm põlvkonda administraatoreid tagasi, ja keegi ei tea, kuidas see töötab. Kogunenud tehniline võlg ja dokumentatsiooni puudumine lööb paratamatult mitte ainult põlve, vaid ka teistesse jäsemetesse, see on pigem aja küsimus.
Kui teil on teenuseosade hea kirjeldus, vaadake õnnetuste statistikat. Need on peaaegu kindlasti täiesti tüüpilised. Näiteks saab teie ketas aeg-ajalt täis, mis põhjustab sõlme tõrke kuni selle käsitsi puhastamiseni. Või muutub klienditeenindus kättesaamatuks seetõttu, et keegi unustas taas sertifikaati uuendada ja Let's Encrypt ei saanud või ei tahtnud seadistada.
Mõtted nagu sabotöör
Kõige keerulisem on ennustada neid õnnetusi, mida pole kunagi varem juhtunud, kuid mis võivad teie teenuse täielikult rikkuda. Siin mängime tavaliselt kolleegidega kurikaela. Võtke palju kohvi ja midagi maitsvat ning lukustage end koosolekuruumi. Lihtsalt veenduge, et samal koosolekul lukustasite need insenerid, kes ise sihtteenust tõstsid või sellega regulaarselt töötavad. Seejärel hakkate kas tahvlile või paberile joonistama kõiki võimalikke õudusi, mis teie teenistusega võivad juhtuda. Konkreetse koristaja ja kaablite väljatõmbamiseni pole vaja täpsustada, piisab stsenaariumiga "Kohaliku võrgu terviklikkuse rikkumine".
Tavaliselt jagunevad tüüpilised hädaolukorrad järgmistesse tüüpidesse:
- Võrgu viga
- OS-i teenuse rike
- Rakenduse rike
- rauapuudus
- Virtualiseerimise tõrge
Vaadake lihtsalt iga tüüp läbi ja vaadake, mis teie teenusele kehtib. Näiteks võib Nginxi deemon langeda ja mitte tõusta - see tähendab OS-i tõrkeid. Harv olukord, mis põhjustab teie veebirakenduse tõrke, on tarkvara rike. Selle etapi läbimisel on oluline välja töötada probleemi diagnoos. Kuidas eristada virtualiseerimisel külmunud liidest näiteks kukkunud cis-draivist ja võrguõnnetusest. See on oluline, et kiiresti leida vastutajad ja hakata sabast tõmbama, kuni õnnetus on lahendatud.
Pärast tüüpiliste probleemide kirjapanemist valame kohvi juurde ja hakkame kaaluma kõige kummalisemaid stsenaariume, kui mõned parameetrid hakkavad ületama normi. Näiteks:
- Mis juhtub, kui aktiivses sõlmes olev aeg liigub klastri teistega võrreldes minuti võrra tagasi?
- Ja kui aeg liigub edasi ja kui 10 aasta võrra?
- Mis juhtub, kui klastri sõlm kaotab sünkroonimise ajal ootamatult võrgu?
- Ja mis juhtub, kui kaks sõlme ei jaga juhtpositsiooni üksteise ajutise isoleerimise tõttu üle võrgu?
Selles etapis aitab vastupidine lähenemine palju. Võtke haige kujutlusvõimega meeskonna kõige kangekaelsem liige ja andke talle ülesanne korraldada võimalikult lühikese aja jooksul kõrvalepõik, mis ajab teenistuse alla. Kui seda on raske diagnoosida, siis veelgi parem. Te ei usu veidraid ja lahedaid ideid, mis inseneridel tekivad, kui neile antakse idee midagi lõhkuda. Ja kui lubate neile selle jaoks katsestendi, on see väga hea.
Mis see sinu DRP on?!
Seega olete määratlenud ohumudeli. Samuti võtsid nad arvesse kohalikke elanikke, kes lõikasid vaske otsides kiudoptilisi kaableid, ja sõjaväeradarit, mis langetab raadioreleeliini rangelt reedeti kell 16. Nüüd peame välja mõtlema, mida selle kõigega peale hakata.
Sinu ülesandeks on kirjutada samad punased ümbrikud, mis hädaolukorras avatakse. Kohe oodake, et kui (mitte kui!) kõik sassi läheb, on läheduses vaid kõige kogenematum praktikant, kelle käed toimuva õudusest ägedalt värisevad. Vaadake, kuidas meditsiinikabinettides rakendatakse hädaolukorra märke. Näiteks mida teha anafülaktilise šokiga. Meditsiinitöötajad teavad kõiki protokolle peast, kuid kui lähedal asuv inimene hakkab surema, haaravad kõik väga sageli abitult kõigest kinni. Selleks ripub seinale selge juhis selliste asjadega nagu "avage sellise ja sellise pakend" ja "süstige intravenoosselt nii palju ravimiühikuid".
Hädaolukorras on raske mõelda! Lülisamba parsimiseks peaksid olema lihtsad juhised.
Hea DRP koosneb mitmest lihtsast plokist:
- Keda teavitada õnnetuse algusest. See on oluline kõrvaldamisprotsessi võimalikult paralleelseks muutmiseks.
- Kuidas õigesti diagnoosida - me jälgime, vaatame süsteemictl-i staatust teenusenimi ja nii edasi.
- Kui palju aega saab igal etapil kulutada. Kui teil pole SLA ajal aega seda oma kätega parandada, siis virtuaalmasin tapetakse ja veeretatakse eilsest varukoopiast.
- Kuidas veenduda, et krahh on möödas.
Pidage meeles, et DRP käivitub siis, kui teenus on täielikult ebaõnnestunud ja lõpeb taastamisega, isegi kui tõhusus on vähenenud. Lihtsalt broneeringu kaotamine ei tohiks DRP-d aktiveerida. Võite välja kirjutada ka tassi teed DRP-s. Tõsiselt. Statistika järgi muutuvad paljud õnnetused ebameeldivatest katastroofilisteks seetõttu, et paanikas töötajad tormavad midagi parandama, tappes samal ajal ainsa andmetega elava sõlme või lõpetades klastri. Reeglina annab 5 minutit tassi tee jaoks veidi aega rahuneda ja toimuvat analüüsida.
Ärge ajage DRP-d ja süsteemipassi segamini! Ärge koormake seda tarbetute andmetega. Lihtsalt võimaldage hüperlinkide abil kiiresti ja mugavalt liikuda dokumentatsiooni soovitud jaotisse ja lugeda laiendatud formaadis teenuse arhitektuuri vajalikke jaotisi. Ja DRP-s endas on konkreetsete kopeerimis-kleepimise käskudega ainult otsesed juhised selle kohta, kus ja kuidas ühenduse luua.
Kuidas õigesti testida
Veenduge, et iga vastutav töötaja suudab kõik esemed täita. Kõige olulisemal hetkel võib selguda, et inseneril ei ole vajalikule süsteemile juurdepääsuõigusi, nõutava konto jaoks pole paroole või tal pole aimugi, mida „Ühenda teenusehalduskonsooliga puhverserveri kaudu peakontor” tähendab. Iga üksus peaks olema võimalikult lihtne.
Vale - "Minge virtualiseerimisse ja taaskäivitage surnud sõlm"
Õigesti - "Ühendage veebiliidese kaudu saidiga virt.example.com, laadige sõlme jaotises uuesti tõrke põhjustav sõlm."
Vältige ebaselgust. Pidage meeles hirmunud praktikanti.
Testige kindlasti DRP-d. See ei ole lihtsalt etteaste plaan – see on midagi, mis võimaldab teil ja teie klientidel kriitilisest olukorrast kiiresti välja tulla. Parim on seda teha mitu korda:
- Üks ekspert ja mitu praktikanti töötavad katsestendil, mis imiteerib võimalikult tõelist teenust. Ekspert rikub teenust mitmel viisil ja võimaldab praktikantidel seda DRP järgi taastada. Kõik probleemid, ebaselgused dokumentatsioonis ja vead registreeritakse. Pärast koolitatavate koolitamist täiendatakse ja lihtsustatakse DRP-d ebaselgetes kohtades.
- Testimine reaalses teenuses. Tegelikult ei saa te kunagi luua tõelise teenuse täiuslikku koopiat. Seetõttu tuleb sissenõudmiskorralduse hindamiseks paar korda aastas plaanipäraselt välja lülitada osa servereid, katkestada ühendusi ja korraldada muid ohtude nimekirjast sattunud õnnetusi. Parem on 10-minutiline planeeritud katkestus keset ööd kui äkiline mitmetunnine rike tippkoormusel koos andmekaoga.
- Tõeline tõrkeotsing. Jah, ka see on osa testimisest. Kui juhtub õnnetus, mida ohtude nimekirjas ei olnud, on vaja DRP-d selle uurimise tulemuste põhjal täiendada ja lõplikult vormistada.
Võtmepunktid
- Kui jama võib juhtuda, siis see ei juhtu niisama, vaid teeb seda kõige katastroofilisema stsenaariumi korral.
- Veenduge, et teil oleks tõrkesiirde jaoks ressursid.
- Veenduge, et teil oleks varukoopiaid, need luuakse automaatselt ja nende järjepidevust kontrollitakse regulaarselt.
- Mõelge tüüpilistele ohustsenaariumidele.
- Andke inseneridele võimalus pakkuda teenuse kasutuselevõtuks mittestandardseid võimalusi.
- DRP peaks olema lihtne ja nüri juhis. Kogu kompleksne diagnostika viiakse läbi alles pärast klienditeeninduse taastumist. Isegi reservvõimsusel.
- Loetlege peamised telefoninumbrid ja kontaktid DRP-s.
- Kontrollige regulaarselt töötajate arusaamist DRP-st.
- Korraldada planeeritud õnnetused tootmisobjektidel. Stendid ei saa kõike asendada.
Allikas: www.habr.com