Net ir ištikus nelaimei visada lieka laiko arbatos puodeliui
DRP (atkūrimo planas po nelaimių) yra dalykas, kurio idealiu atveju niekada neprireiks. Bet jei staiga poravimosi sezono metu migruojantys bebrai apgraužia stuburinį šviesolaidį arba jaunesnysis administratorius numeta produktyvią bazę, tikrai norite būti tikri, kad turėsite iš anksto susiplanuotą planą, ką daryti su visa šita gėda.
Kol panikuoti klientai pradeda nutraukti techninės pagalbos telefonus, jaunesnysis ieško cianido, jūs protingai atidarote raudoną voką ir pradedate viską tvarkyti.
Šiame įraše noriu pasidalinti rekomendacijomis, kaip parašyti DRP ir kas jame turėtų būti. Taip pat apžvelgsime šiuos dalykus:
- Išmokime mąstyti kaip piktadarys.
- Pažvelkime į arbatos puodelio naudą apokalipsės metu.
- Pagalvokime apie patogią DRP struktūrą
- Pažiūrėkime, kaip tai išbandyti
Kurioms įmonėms tai gali būti naudinga?
Labai sunku nubrėžti ribą, kada IT skyriui pradeda prireikti tokių dalykų. Sakyčiau, kad jums tikrai reikia DRP, jei:
- Sustabdžius serverį, taikomąją programą ar praradus tam tikrą duomenų bazę, visa verslas patirs didelių nuostolių.
- Turite visavertį IT skyrių. Departamento prasme kaip pilnavertis įmonės padalinys, turintis savo biudžetą, o ne tik keli pavargę darbuotojai, klojantys tinklą, valantys virusus ir pildantys spausdintuvus.
- Turite realų biudžetą bent daliniam atleidimui kritinės situacijos atveju.
Kai IT skyrius kelis mėnesius prašo bent poros HDD į seną serverį atsarginėms kopijoms, vargu ar pavyks suorganizuoti visavertį sugedusios paslaugos perkėlimą į talpos rezervavimą. Nors čia dokumentai nebus nereikalingi.
Dokumentacija yra svarbi
Pradėkite nuo dokumentų. Tarkime, kad jūsų paslauga veikia naudojant Perl scenarijų, kurį prieš tris kartas parašė administratoriai, bet niekas nežino, kaip tai veikia. Susikaupusi techninė skola ir dokumentų trūkumas neišvengiamai šaus ne tik į kelį, bet ir į kitas galūnes, tai daugiau laiko klausimas.
Kai gerai aprašysite paslaugų komponentus, peržiūrėkite nelaimingų atsitikimų statistiką. Jie beveik neabejotinai bus visiškai tipiški. Pavyzdžiui, jūsų diskas retkarčiais prisipildo, todėl mazgas sugenda, kol jis nebus išvalytas rankiniu būdu. Arba klientų aptarnavimas tampa nepasiekiamas dėl to, kad kažkas vėl pamiršo atnaujinti sertifikatą, o Let's Encrypt negalėjo arba nenorėjo sukonfigūruoti.
Mintys kaip diversantas
Sunkiausia yra nuspėti tuos nelaimingus atsitikimus, kurių niekada anksčiau nebuvo, bet dėl kurių jūsų paslauga gali visiškai sugriauti. Čia mes su kolegomis dažniausiai vaidiname piktadarius. Išgerkite daug kavos ir ką nors skanaus ir užsidarykite posėdžių salėje. Tiesiog įsitikinkite, kad tame pačiame susitikime įtrauksite tuos inžinierius, kurie patys sukūrė tikslinę paslaugą arba nuolat su ja dirba. Tada lentoje arba popieriuje pradedi piešti visus įmanomus baisumus, kurie gali nutikti tavo tarnybai. Nereikia gilintis į konkrečią valytoją ir laidų ištraukimą, pakanka apsvarstyti „Vietinio tinklo vientisumo pažeidimo“ scenarijų.
Paprastai tipiškos avarinės situacijos skirstomos į šiuos tipus:
- Tinklo gedimas
- OS paslaugų gedimas
- Programos gedimas
- Geležies gedimas
- Virtualizavimo gedimas
Tiesiog peržiūrėkite kiekvieną tipą ir sužinokite, kas taikoma jūsų paslaugai. Pavyzdžiui, „Nginx“ demonas gali kristi ir nepakilti – tai reiškia OS gedimus. Reta situacija, dėl kurios sugenda žiniatinklio programa, yra programinės įrangos gedimas. Atliekant šį etapą, svarbu išsiaiškinti problemos diagnozę. Pavyzdžiui, kaip atskirti užšaldytą virtualizacijos sąsają nuo nukritusio cis įrenginio ir tinklo avarijos. Svarbu greitai surasti atsakingus asmenis ir pradėti traukti už uodegos, kol avarija bus išspręsta.
Užrašę tipines problemas, pilame daugiau kavos ir pradedame svarstyti keisčiausius scenarijus, kai kai kurie parametrai pradeda gerokai viršyti normą. Pavyzdžiui:
- Kas atsitiks, jei aktyvaus mazgo laikas pasislenka minute atgal, palyginti su kitais klasteryje?
- O jei laikas juda į priekį, o jei 10 metų?
- Kas atsitiks, jei klasterio mazgas sinchronizacijos metu staiga praranda tinklą?
- Kas atsitiks, jei du mazgai nepasidalins lyderystės dėl laikino vienas kito izoliavimo tinkle?
Šiame etape atvirkštinis metodas yra labai naudingas. Jūs paimate atkakliausią komandos narį su liguista fantazija ir duodate jam užduotį per trumpiausią laiką surengti sabotažą, kuris sužlugdys paslaugą. Jei sunku diagnozuoti, dar geriau. Nepatikėsite, kokių keistų ir šaunių idėjų sugalvoja inžinieriai, jei duosite jiems idėją ką nors sulaužyti. Ir jei pažadėsite jiems bandymų stendą, tai visiškai gerai.
Kas tas tavo DRP?!
Taigi jūs apibrėžėte savo grėsmės modelį. Jie taip pat atsižvelgė į vietinius gyventojus, kurie pjauna šviesolaidinius kabelius ieškodami vario, ir karinį radarą, kuris radijo relės liniją nuleidžia griežtai penktadieniais 16 val. Dabar turime suprasti, ką su visu tuo daryti.
Jūsų užduotis yra parašyti tuos labai raudonus vokus, kurie bus atplėšti kritiniu atveju. Iškart tikėkitės, kad kai (ne jei!) viskas baigsis, šalia bus tik labiausiai nepatyręs praktikantas, kurio rankos smarkiai drebės iš siaubo, kas vyksta. Pažiūrėkite, kaip medicinos kabinetuose įgyvendinami avariniai ženklai. Pavyzdžiui, ką daryti ištikus anafilaksiniam šokui. Medicinos personalas mintinai žino visus protokolus, tačiau kai šalia pradeda mirti žmogus, labai dažnai visi bejėgiškai įsikimba į viską, ką mato. Norėdami tai padaryti, ant sienos yra aiškios instrukcijos su tokiais elementais kaip „atidaryti tokio ir tokio pakuotę“ ir „į veną suleisti tiek vaisto vienetų“.
Sunku mąstyti kritiniu atveju! Turėtų būti paprastos stuburo smegenų analizės instrukcijos.
Gerą DRP sudaro keli paprasti blokai:
- Kam pranešti apie avarijos pradžią. Tai svarbu siekiant kuo labiau suvienodinti pašalinimo procesą.
- Kaip teisingai diagnozuoti – atsekti, ieškoti systemctl status servicename ir pan.
- Kiek laiko galite skirti kiekviename etape? Jei neturite laiko taisyti rankiniu būdu per SLA laikotarpį, virtualioji mašina užmušama ir atšaukiama iš vakarykštės atsarginės kopijos.
- Kaip įsitikinti, kad avarija baigėsi.
Atminkite, kad DRP prasideda, kai paslauga visiškai sugenda, ir baigiasi, kai paslauga atkuriama, net ir sumažėjus efektyvumui. Paprasčiausias rezervacijos praradimas neturėtų suaktyvinti DRP. Taip pat į DRP galite įrašyti puodelį arbatos. Rimtai. Remiantis statistika, daugelis nelaimingų atsitikimų iš nemalonių virsta katastrofiškomis dėl to, kad darbuotojai panikuodami skuba ką nors taisyti, kartu nužudydami vienintelį gyvą mazgą, turintį duomenis, arba galiausiai užbaigdami klasterį. Paprastai 5 minutės prie arbatos puodelio suteiks laiko nusiraminti ir paanalizuoti, kas vyksta.
Nepainiokite DRP ir sistemos paso! Neperkraukite jo nereikalingais duomenimis. Tiesiog sudarykite galimybę greitai ir patogiai naudoti hipersaitus, kad patektumėte į norimą dokumentacijos skyrių ir išplėstu formatu skaitytumėte apie reikalingas paslaugos architektūros dalis. Ir pačiame DRP yra tik tiesioginės instrukcijos, kur ir kaip prisijungti, naudojant specialias kopijavimo ir įklijavimo komandas.
Kaip teisingai atlikti testą
Įsitikinkite, kad bet kuris atsakingas darbuotojas gali atlikti visus elementus. Svarbiausiu momentu gali paaiškėti, kad inžinierius neturi teisių pasiekti reikiamos sistemos, nėra reikiamos paskyros slaptažodžių arba jis neįsivaizduoja, ką „Prisijunkite prie paslaugų valdymo konsolės per tarpinį serverį pagrindinė buveinė“ reiškia. Kiekvienas punktas turėtų būti labai paprastas.
Klaidinga — „Eikite į virtualizaciją ir iš naujo paleiskite mirusį mazgą“
Teisingai - „Prisijunkite per žiniatinklio sąsają prie virt.example.com, mazgų skiltyje iš naujo paleiskite klaidą sukeliantį mazgą“.
Venkite dviprasmybių. Prisiminkite išsigandusį interną.
Būtinai patikrinkite DRP. Tai ne tik pasirodymo planas – tai kažkas, kas leis jums ir jūsų klientams greitai išeiti iš kritinės situacijos. Geriausia tai padaryti kelis kartus:
- Vienas ekspertas ir keli praktikantai dirba bandymų stende, kuris kiek įmanoma labiau imituoja tikrą paslaugą. Ekspertas įvairiais būdais nutraukia paslaugą ir suteikia galimybę stažuotojams ją atkurti pagal DRP. Visos problemos, dokumentacijos neaiškumai ir klaidos yra fiksuojamos. Po stažuotojų apmokymo DRP plečiamas ir supaprastinamas neaiškiose srityse.
- Išbandymas naudojant tikrą paslaugą. Tiesą sakant, niekada negalite sukurti tobulos tikros paslaugos kopijos. Todėl porą kartų per metus reikia reguliariai išjungti kai kuriuos serverius, nutraukti ryšius ir sukelti kitas nelaimes iš grėsmių sąrašo, kad būtų galima įvertinti atkūrimo nurodymą. Suplanuotas gedimas 10 minučių vidury nakties yra geriau nei staigus kelių valandų gedimas didžiausios apkrovos metu ir prarasti duomenys.
- Tikras trikčių šalinimas. Taip, tai taip pat yra testavimo dalis. Įvykus nelaimingam atsitikimui, kurio nebuvo grėsmių sąraše, būtina papildyti ir suformuluoti DRP, remiantis jos tyrimo rezultatais.
Pagrindiniai klausimai
- Jei gali nutikti šūdas, tai ne tik atsitiks, bet ir atsitiks pagal patį katastrofiškiausią įmanomą scenarijų.
- Įsitikinkite, kad turite išteklių avariniam krovinio perkėlimui.
- Įsitikinkite, kad turite atsargines kopijas, jos sukuriamos automatiškai ir reguliariai tikrinamos dėl nuoseklumo.
- Pagalvokite apie tipiškus grėsmės scenarijus.
- Suteikite inžinieriams galimybę pasiūlyti nestandartines paslaugos teikimo galimybes.
- DRP turėtų būti paprastas ir aiškus nurodymas. Visa kompleksinė diagnostika atliekama tik atkūrus klientų aptarnavimą. Net ir esant rezerviniam pajėgumui.
- Pateikite pagrindinius telefono numerius ir kontaktus DRP.
- Reguliariai tikrinkite darbuotojų supratimą apie DRP.
- Sutvarkyti planuojamus nelaimingus atsitikimus gamybos vietose. Stovai negali pakeisti visko.
Šaltinis: www.habr.com