Edhe gjatë një fatkeqësie, gjithmonë ka kohë për një filxhan çaj.
DRP (plani i rimëkëmbjes nga fatkeqësitë) është një gjë që në mënyrë ideale nuk do të nevojitet kurrë. Por nëse befas kastorët që migrojnë gjatë sezonit të çiftëzimit gërryejnë fibrën kryesore optike ose administratori i ri e heq bazën produktive, patjetër që dëshironi të jeni të sigurt se do të keni një plan të parapërgatitur se çfarë të bëni me gjithë këtë turp.
Ndërsa klientët në panik fillojnë të telefonojnë mbështetjen e teknologjisë, një i ri po kërkon cianid, ju hapni me mençuri zarfin e kuq dhe filloni të vendosni gjithçka në rregull.
Në këtë postim, unë dua të ndaj rekomandime se si të shkruaj një DRP dhe çfarë duhet të përmbajë. Ne do të shikojmë edhe në vijim:
- Mësoni të mendoni si një horr.
- Le të analizojmë përfitimet e një filxhani çaji gjatë apokalipsit.
- Mendoni për një strukturë të përshtatshme DRP
- Le të shohim se si ta testojmë atë
Cilat kompani mund të përfitojnë nga kjo?
Është shumë e vështirë të vendosësh një vijë kur departamenti i IT fillon të ketë nevojë për këto gjëra. Unë do të thoja që ju jeni të garantuar që keni nevojë për DRP nëse:
- Ndalimi i një serveri, një aplikacioni ose humbja e një baze të dhënash do të çojë në humbje të konsiderueshme për biznesin në tërësi.
- Ju keni një departament të plotë IT. Dua të them, një departament si një njësi e plotë e kompanisë, me buxhetin e vet, dhe jo vetëm disa punonjës të lodhur që shtrojnë një rrjet, pastrojnë viruset dhe mbushin printerët.
- Ju keni një buxhet realist për të paktën një tepricë të pjesshme në rast emergjence.
Kur departamenti i IT ka kërkuar të paktën disa HDD për një server të vjetër për kopje rezervë për muaj të tërë, nuk ka gjasa të jeni në gjendje të organizoni një zhvendosje të plotë të shërbimit të rënë në kapacitetet rezervë. Edhe pse dokumentacioni nuk do të jetë i tepërt as këtu.
Dokumentacioni është i rëndësishëm
Filloni me dokumentacionin. Le të themi se shërbimi juaj funksionon në një skript Perl që është shkruar tre breza administratorësh më parë dhe askush nuk e di se si funksionon. Borxhi teknik i akumuluar dhe mungesa e dokumentacionit do t'ju qëllojë në mënyrë të pashmangshme jo vetëm në gju, por edhe në gjymtyrë të tjera, është më tepër çështje kohe.
Pasi të keni në dorë një përshkrim të mirë të komponentëve të shërbimit, ngrini statistikat e përplasjeve. Pothuajse me siguri do të jenë krejtësisht tipike. Për shembull, ju keni një disk të mbushur herë pas here, gjë që bën që nyja të dështojë derisa të pastrohet manualisht. Ose shërbimi i klientit bëhet i padisponueshëm për faktin se dikush përsëri harroi të rinovonte certifikatën, por ai nuk mundi ose nuk donte të konfiguronte Let's Encrypt.
Mendime si diversante
Pjesa më e vështirë është në parashikimin e atyre aksidenteve që nuk kanë ndodhur kurrë më parë, por që mund të shkatërrojnë plotësisht shërbimin tuaj. Këtu zakonisht luajmë zuzar me kolegët. Pini shumë kafe dhe diçka të shijshme dhe mbylluni në sallën e mbledhjeve. Vetëm sigurohuni që në të njëjtin takim të keni mbyllur ata inxhinierë që vetë ngritën shërbimin e synuar ose punojnë me të rregullisht. Pastaj, ose në tabelë ose në letër, ju filloni të vizatoni të gjitha tmerret e mundshme që mund t'i ndodhin shërbimit tuaj. Nuk është e nevojshme t'i detajoni një pastruese specifike dhe të hiqni kabllot, mjafton të merrni parasysh skenarin "Shkelja e integritetit të rrjetit lokal".
Zakonisht, shumica e emergjencave tipike përshtaten në llojet e mëposhtme:
- Dështimi i rrjetit
- Dështimi i shërbimit OS
- Dështimi i aplikimit
- dështimi i hekurit
- Dështimi i virtualizimit
Thjesht kaloni nëpër secilën pamje dhe shikoni se çfarë vlen për shërbimin tuaj. Për shembull, daemon Nginx mund të bjerë dhe të mos ngrihet - ky është një dështim nga ana e OS. Një situatë e rrallë që e çon aplikacionin tuaj të internetit në një gjendje jo-funksionale është një dështim i softuerit. Gjatë zhvillimit të kësaj faze, është e rëndësishme të përpunohet diagnoza e problemit. Si të dalloni një ndërfaqe të varur në virtualizim nga një cisco i rënë dhe një përplasje rrjeti, për shembull. Kjo është e rëndësishme për të gjetur shpejt përgjegjësit dhe për të filluar të tërheqni bishtin e tyre derisa aksidenti të rregullohet.
Pasi të shënohen problemet tipike, hedhim më shumë kafe dhe fillojmë të shqyrtojmë skenarët më të çuditshëm, kur disa parametra fillojnë të shkojnë përtej normës. Për shembull:
- Çfarë ndodh nëse koha në nyjen aktive lëviz një minutë prapa në krahasim me të tjerat në grup?
- Dhe nëse koha ecën përpara, dhe nëse me 10 vjet?
- Çfarë ndodh nëse një nyje grupi humbet papritur rrjetin gjatë sinkronizimit?
- Dhe çfarë ndodh nëse dy nyje nuk ndajnë udhëheqjen për shkak të izolimit të përkohshëm të njëri-tjetrit në rrjet?
Në këtë fazë, qasja e kundërt ndihmon shumë. Merrni anëtarin më kokëfortë të ekipit me një imagjinatë të sëmurë dhe jepini detyrë të organizojë një devijim në kohën më të shkurtër të mundshme, gjë që do të heqë shërbimin. Nëse është e vështirë për të diagnostikuar, edhe më mirë. Ju nuk do t'i besoni idetë e çuditshme dhe të çuditshme që lindin inxhinierët kur u jepet ideja për të thyer diçka. Dhe nëse u premtoni atyre një stendë testimi për këtë, është shumë mirë.
Çfarë është kjo DRP e juaja?!
Pra, ju keni përcaktuar modelin e kërcënimit. Ata morën gjithashtu parasysh banorët vendas që prenë kabllot me fibra optike në kërkim të bakrit dhe një radar ushtarak që lëshon një linjë radiorele rreptësisht të premteve në orën 16:46. Tani duhet të kuptojmë se çfarë të bëjmë me të gjitha.
Detyra juaj është të shkruani të njëjtat zarfe të kuq që do të hapen në rast urgjence. Prisni menjëherë që kur (jo nëse!) gjithçka të prishet, pranë do të jetë vetëm praktikanti më i papërvojë, duart e të cilit do të dridhen fort nga tmerri i asaj që po ndodh. Shihni si zbatohen shenjat e urgjencës në zyrat mjekësore. Për shembull, çfarë të bëni me shokun anafilaktik. Stafi mjekësor i di përmendësh të gjitha protokollet, por kur një person aty pranë fillon të vdesë, shumë shpesh të gjithë kapin të pafuqishëm çdo gjë. Për ta bërë këtë, një udhëzim i qartë varet në mur me artikuj të tillë si "hapni paketën e filanit" dhe "injektoni kaq shumë njësi të drogës në mënyrë intravenoze".
Është e vështirë të mendosh në rast urgjence! Duhet të ketë udhëzime të thjeshta për analizimin e shtyllës kurrizore.
Një DRP e mirë përbëhet nga disa blloqe të thjeshta:
- Kë të njoftoni për fillimin e aksidentit. Kjo është e rëndësishme për të paralelizuar sa më shumë procesin e eliminimit.
- Si të diagnostikoni saktë - ne gjurmojmë, shikojmë në emrin e shërbimit të statusit systemctl dhe kështu me radhë.
- Sa kohë mund të shpenzohet në secilën fazë. Nëse nuk keni kohë për ta rregulluar atë me duart tuaja gjatë kohës SLA, makina virtuale vritet dhe rrotullohet nga rezervimi i djeshëm.
- Si të siguroheni që përplasja të ketë mbaruar.
Mos harroni se DRP fillon kur shërbimi ka dështuar plotësisht dhe përfundon me rikuperim, edhe me efikasitet të reduktuar. Thjesht humbja e një rezervimi nuk duhet të aktivizojë DRP. Ju gjithashtu mund të përshkruani një filxhan çaj në DRP. Seriozisht. Sipas statistikave, shumë aksidente kalojnë nga të pakëndshme në katastrofike për faktin se stafi në panik nxiton të rregullojë diçka, duke vrarë njëkohësisht nyjen e vetme live me të dhëna ose përfundimisht duke përfunduar grupin. Si rregull, 5 minuta për një filxhan çaj do t'ju japë pak kohë për t'u qetësuar dhe për të analizuar atë që po ndodh.
Mos ngatërroni DRP dhe pasaportën e sistemit! Mos e mbingarkoni me të dhëna të panevojshme. Thjesht jepni mundësinë që të shkoni shpejt dhe me lehtësi në seksionin e kërkuar të dokumentacionit përmes hiperlidhjeve dhe të lexoni në një format të zgjeruar në lidhje me seksionet e nevojshme të arkitekturës së shërbimit. Dhe në vetë DRP, ka vetëm udhëzime të drejtpërdrejta se ku dhe si të lidheni me komanda specifike për copy-paste.
Si të testoni saktë
Sigurohuni që çdo punonjës përgjegjës të jetë në gjendje të plotësojë të gjitha pikat. Në momentin më vendimtar, mund të rezultojë se inxhinieri nuk ka të drejta aksesi në sistemin e kërkuar, nuk ka fjalëkalime për llogarinë e kërkuar ose ai nuk e ka idenë se çfarë "Lidhu me konsolën e menaxhimit të shërbimit përmes një përfaqësuesi në zyra qendrore” do të thotë. Çdo artikull duhet të jetë sa më i thjeshtë që të jetë e mundur.
i gabuar - "Shkoni te virtualizimi dhe rindizni nyjen e vdekur"
Правильно - "Lidhu nëpërmjet ndërfaqes së internetit me virt.example.com, në seksionin e nyjeve, ringarkoni nyjen që po shkakton gabimin."
Shmangni paqartësitë. Kujtoni praktikantin e frikësuar.
Sigurohuni që të testoni DRP. Ky nuk është vetëm një plan për shfaqje - është diçka që do t'ju lejojë ju dhe klientët tuaj të dilni shpejt nga një situatë kritike. Është më mirë ta bëni këtë disa herë:
- Një ekspert dhe disa praktikantë punojnë në një stol testimi që imiton sa më shumë një shërbim të vërtetë. Eksperti prish shërbimin në mënyra të ndryshme dhe u mundëson kursantëve ta rikthejnë atë sipas DRP. Të gjitha problemet, paqartësitë në dokumentacion dhe gabimet regjistrohen. Pas trajnimit të kursantëve, DRP plotësohet dhe thjeshtohet në vende të panjohura.
- Testimi në një shërbim të vërtetë. Në fakt, nuk mund të krijoni kurrë një kopje të përsosur të një shërbimi të vërtetë. Prandaj, disa herë në vit është e nevojshme të fikni një pjesë të serverëve në bazë të planifikuar, të prishni lidhjet dhe të organizoni aksidente të tjera nga lista e kërcënimeve për të vlerësuar urdhrin e rikuperimit. Është më mirë të keni një ndërprerje të planifikuar 10-minutëshe në mes të natës sesa një dështim i papritur për disa orë në ngarkesë maksimale me humbje të të dhënave.
- Eliminimi real i aksidentit. Po, edhe kjo është pjesë e testimit. Nëse ndodh një aksident që nuk ishte në listën e kërcënimeve, është e nevojshme të plotësohet dhe të finalizohet DRP bazuar në rezultatet e hetimit të tij.
Pikat kryesore
- Nëse marrëzi mund të ndodhë, nuk do të ndodhë thjesht, por do ta bëjë në skenarin më katastrofik.
- Sigurohuni që keni burimet për dështim.
- Sigurohuni që të keni kopje rezervë, ato krijohen automatikisht dhe kontrollohen rregullisht për konsistencë.
- Merrni parasysh skenarët tipikë të kërcënimit.
- Jepuni inxhinierëve mundësinë për të dalë me opsione jo standarde për të vendosur shërbimin.
- DRP duhet të jetë udhëzime të thjeshta dhe memecë. Të gjitha diagnostikimet komplekse vetëm pasi klientët të kenë rikthyer shërbimin. Edhe nëse është në gatishmëri.
- Listoni numrat kryesorë të telefonit dhe kontaktet në DRP.
- Testoni rregullisht punonjësit për të kuptuar DRP.
- Organizoni aksidente të planifikuara në produkt. Stendat nuk mund të zëvendësojnë gjithçka.
Burimi: www.habr.com