Edhe gjatë një katastrofe, gjithmonë ka kohë për një filxhan çaji
DRP (plani i rikuperimit pas katastrofave) është diçka që idealisht nuk duhet të nevojitet kurrë. Por nëse ndodhin situata të papritura, si kur bebot migrues gjatë periudhës së të dashuruarve shqyejnë kabllon kryesor të fibra optike ose një admin i ri shemb bazën produktive, ju me siguri doni të jeni të sigurt se do të keni një plan të përgatitur paraprakisht për të menaxhuar gjithë këtë kaos.
Ndërkohë që klientët në panik fillojnë të shqetësojnë mbështetje teknike, admini i ri kërkon zgjidhje ekstreme, ju me një pamje të mençur hapni një letër të kuqe dhe filloni të vënit gjithçka në rregull.
Në këtë postim, dëshiroj të ndaj rekomandime se si duhet të shkruhet DRP dhe çfarë duhet të përmbajë. Gjithashtu do të shqyrtojmë këto pika:
- Do të mësojmë të mendojmë si një antihéro.
- Do të analizojmë përfitimet e një filxhani çaji gjatë apokalipsit.
- Do të mendojmë për një strukturë të përshtatshme për DRP.
- Do të shohim si duhet testuar ai.
Për cilat kompani mund të jetë i dobishëm.
ĂshtĂ« shumĂ« e vĂ«shtirĂ« tĂ« tĂ«rhiqet njĂ« kufi kur departamenti IT fillon tĂ« ketĂ« nevojĂ« pĂ«r kĂ«to gjĂ«ra. Do tĂ« thoja qĂ« DRP ju nevojitet patjetĂ«r nĂ«se:
- Ndërprerja e serverit, aplikacionit ose humbja e ndonjë baze do të çojë në humbje të konsiderueshme për biznesin në përgjithësi.
- Keni një departament IT të plotë. Domethënë, një njësi e plotë brenda kompanisë, me buxhetin e saj, dhe jo thjesht disa punonjës të lodhur që menaxhojnë rrjetin, pastrimin e viruseve dhe mbushjen e_printuesve.
- Keni një buxhet të vërtetë për të paktën rezervimin e pjesshëm në rast situatash emergjente.
Kur departamenti IT lutet për muaj me radhë për disa HDD për një server të vjetër për backup, ju me siguri nuk do të jeni në gjendje të organizoni një shpërngulje të plotë të shërbimit të rënë në kapacitetet rezervë. Edhe këtu, dokumentimi do të ishte i dobishëm.
Dokumentimi është i rëndësishëm
Filloni me dokumentimin. Le të themi që shërbimi juaj funksionon mbi një skenar në Perl, i shkruar tri breza administratash më parë, dhe askush nuk di se si funksionon. Borxhi teknik i akumuluar dhe mungesa e dokumentimit do t'ju sjellë probleme serioze, kjo është thjesht një çështje kohe.
Pasi qĂ« keni njĂ« pĂ«rshkrim tĂ« mirĂ« tĂ« komponenteve tĂ« shĂ«rbimit, analizoni statistikĂ«n e aksidenteve. Me shumĂ« mundĂ«si, ato do tĂ« jenĂ« krejtĂ«sisht tipike. PĂ«r shembull, ndonjĂ«herĂ« mund tĂ« ketĂ« mbushje tĂ« diskut, qĂ« sjell nĂ« disfunksion tĂ« nodit deri nĂ« pastrimin e tij manual. Ose shĂ«rbimi pĂ«r klientĂ«t mund tĂ« bĂ«het i paaksesueshĂ«m sepse dikush pĂ«rsĂ«ri e harroi tĂ« rinovojĂ« certifikatĂ«n, ndĂ«rsa tĂ« vendosĂ«sh Letâs Encrypt nuk arriti ose nuk deshi.
Mendoni si një diversant
Pjesa mĂ« e vĂ«shtirĂ« Ă«shtĂ« parashikimi i aksidenteve qĂ« nuk kanĂ« ndodhur ende, por qĂ« potencialisht mund tĂ« pengojnĂ« plotĂ«sisht shĂ«rbimin tuaj. KĂ«tu zakonisht luajmĂ« me kolegĂ«t si keqbĂ«rĂ«s. Merrni shumĂ« kafe dhe diçka tĂ« shijshme, dhe bllokoheni nĂ« njĂ« dhomĂ« takimesh. Sigurohuni qĂ« nĂ« tĂ« njĂ«jtĂ«n dhomĂ« keni bllokuar inxhinierĂ«t qĂ« kanĂ« ngritur shĂ«rbimin ose qĂ« punojnĂ« rregullisht me tĂ«. Pastaj, ose nĂ« njĂ« tabelĂ«, ose nĂ« letĂ«r filloni tĂ« vizatoni tĂ« gjitha tmerret qĂ« mund tĂ« ndodhin me shĂ«rbimin tuaj. Nuk Ă«shtĂ« e nevojshme tĂ« detajoni deri te pastruesja e caktuar dhe tĂ« tĂ«rhequrit e kabllove, mjafton tĂ« shqyrtoni skenarin âShkelja e integritetit tĂ« rrjetit lokalâ.
Zakonisht, shumica e rasteve tipike të aksidenteve përfshihen në lloje të mëposhtme:
- DĂ«shtimi i rrjetit
- Dështimi i shërbimeve të sistemit operativ
- DĂ«shtimi i aplikacionit
- DĂ«shtimi i harduerit
- DĂ«shtimi i virtualizimit
Thjesht kaloni pĂ«rmes çdo lloji dhe shihni se çfarĂ« Ă«shtĂ« e aplikueshme pĂ«r shĂ«rbimin tuaj. PĂ«r shembull, mund tĂ« bjerĂ« dhe tĂ« mos ngrihet shĂ«rbimi Nginx â kjo i pĂ«rket dĂ«shtimeve nga ana e OS. NjĂ« situatĂ« e rrallĂ«, e cila e çon aplikacionin tuaj nĂ« njĂ« gjendje jo-funksionale â dĂ«shtimi i software-it. GjatĂ« kĂ«tij procesi, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« shqyrtoni diagnostikimin e problemit. Si tĂ« dalloni njĂ« ndĂ«rfaqe tĂ« ngrirĂ« nĂ« virtualizim nga njĂ« dĂ«shtim i switch-it dhe njĂ« aksident nĂ« rrjet, pĂ«r shembull. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r tĂ« gjetur shpejt ata qĂ« janĂ« tĂ« pĂ«rgjegjshĂ«m dhe filloni t'i nxirrni ata deri sa aksidenti tĂ« jetĂ« zgjidhur.
Pasi të jenë regjistruar problemet tipike, derdhni më shumë kafe dhe filloni të shqyrtoni skenarët më të çuditshëm kur disa parametra fillojnë të dalin shumë jashtë normave. Për shembull:
- ĂfarĂ« ndodh nĂ«se koha nĂ« nodin aktiv zhvendoset njĂ« minutĂ« mbrapa nĂ« krahasim me tĂ« tjerĂ«t nĂ« klaster?
- Dhe nëse koha zhvendoset përpara, dhe nëse është për 10 vjet?
- ĂfarĂ« do tĂ« ndodhĂ« nĂ«se, gjatĂ« sinkronizimit, nodi i klasterit papritur humbet rrjetin?
- E çfarë do të ndodhte nëse dy nodet nuk ndajnë udhëheqjen për shkak të izolimit të përkohshëm njëri nga tjetri në rrjet?
Në këtë hap, qasja nga mbrapa ndihmon shumë. Merrni anëtarin më të çmendur të ekipit me një imagjinatë të sëmurë dhe jepini atij detyrë të organizojë një diversitet në një kohë të shkurtër që do të bjerë shërbimin. Nëse është e vështirë për tu diagnostikuar, edhe më mirë. Nuk do e besoni se sa ide të çuditshme dhe të shkëlqyera japin inxhinierët nëse u jepni idenë për të prishur diçka. Dhe tashmë, nëse u premtoni një përmirësim për këtë, është ashtu si duhet.
ĂfarĂ« Ă«shtĂ« ky DRP juaj?!
Kështu, ju keni përcaktuar modelin e kërcënimeve. Keni marrë parasysh edhe vendasit që presin kabllot optikë për të kërkuar bakrin, dhe radarët ushtarakë që bien mbi linjat e radiorele në mënyrë strikte të premteve në orën 16:46. Tani duhet të kuptoni se çfarë të bëni me të gjitha këto.
Detyra juaj është të shkruani ato letra të kuqe që do të hapen në rast emergjence. Tani llogaritni se kur (jo nëse!) gjithçka të shkojë keq, do të jenë pranë vetëm stazhierët më të papërvojë, të cilët do të kenë duar trembëse nga frika që po ndodh. Shikoni si janë realizuar tabelat emergjente në zyrat mjekësore. Për shembull, çfarë të bëni në rast të anafalaksisë. Stafi mjekësor e di përmendsh të gjitha protokollet, por kur ka një njeri që fillon të vdesë, shpesh të gjithë përpiqen të kapin gjithçka që u vie nën dorë. Për këtë, në mur është një udhëzues i qartë me pika si "hap paketimin e atij" dhe "jepni intravenoz aq njësi të ilaçit".
Në një situatë emergjente, është e vështirë të mendosh! Duhet të ketë udhëzime të thjeshta për të pasuruar trurin.
Një DRP i mirë përbëhet nga disa blloqe të thjeshta:
- Kë të njoftoni në fillim të emergjencës. Kjo është e rëndësishme për të maksimalizuar procesin e zgjidhjes.
- Si tĂ« diagnostikoni siç duhet â bĂ«jmĂ« gjurmimin, shikojmĂ« nĂ« statusin systemctl servicename dhe kĂ«shtu me radhĂ«.
- Sa kohĂ« mund tĂ« shpenzohet pĂ«r çdo fazĂ«. NĂ«se nuk arrini ta rregulloni me duar brenda kohĂ«s SLA â makina virtuale shkatĂ«rrohet dhe rikthehet nga backupi i djeshĂ«m.
- Si të siguroheni që emergjenca ka përfunduar.
Mbani se që DRP fillon atëherë kur shërbimi ka dështuar plotësisht dhe përfundon kur rikuperimi është realizuar, madje edhe me efikasitet të reduktuar. Thjesht humbja e rezervimit nuk duhet të aktivizojë DRP-në. Dhe, për më tepër, mund të përfshini një gotë çaj në DRP. Seriouz. Sipas statistikave, shumë incidente nga të papriturat bëhen katastrofike për shkak se stafi, në panik, nxiton të rregullojë diçka, duke vrarë përfundimisht nodin e vetëm të gjallë me të dhëna ose duke e bërë klasterin të pamundshëm. Në përgjithësi, 5 minuta për një gotë çaj do t'ju japin pak kohë për t'u qetësuar dhe për të analizuar situatën.
Mos e ngatërroni DRP-në me pasaportën e sistemit! Mos e ngarkoni atë me informacione të tepruara. Thjesht jepni mundësinë për të kaluar shpejt dhe lehtësisht në seksionet përkatëse të dokumentacionit për të lexuar në një format më të zgjeruar në lidhje me elementet e nevojshme të arkitekturës së shërbimit. Ndërsa në vetë DRP-në vetëm udhëzime të drejtpërdrejta përkujtese se ku dhe si duhet të lidhesh me komanda specifike për kopje-ngjitje.
Si të testoni siç duhet
Sigurohuni qĂ« çdo punonjĂ«s pĂ«rgjegjĂ«s Ă«shtĂ« nĂ« gjendje tĂ« kryejĂ« tĂ« gjithĂ« pikat. NĂ« momentin mĂ« kritik mund tĂ« ndodhĂ« qĂ« inxhinieri nuk ka tĂ« drejta pĂ«r qasje nĂ« sistemin e nevojshĂ«m, i mungojnĂ« fjalĂ«kalimet e llogarisĂ« sĂ« nevojshme ose ai nuk ka asnjĂ« ide se çfarĂ« do tĂ« thotĂ« "Lidhuni me konsolĂ«n e menaxhimit tĂ« shĂ«rbimit pĂ«rmes proxy nĂ« zyrĂ«n kryesore". Ădo pikĂ« duhet tĂ« jetĂ« jashtĂ«zakonisht e thjeshtĂ«.
Gabim â "Shkoni nĂ« virtualizim dhe rifilloni nodin e vdekur"
E saktĂ« â "Lidhuni pĂ«rmes ndĂ«rfaqes web nĂ« virt.example.com, nĂ« seksionin e nodit kryeni rifillimin e nodit qĂ« shkakton gabim".
Mos lejoni dykuptimësi. Mbani mend për stazhierin e frikësuar.
Sigurohuni qĂ« tĂ« testoni DRP-nĂ«. Kjo nuk Ă«shtĂ« vetĂ«m njĂ« plan pĂ«r tĂ« bĂ«rĂ« njĂ« kontroll â Ă«shtĂ« ajo qĂ« do t'ju lejojĂ« juve dhe klientĂ«ve tuaj tĂ« dilni shpejt nga njĂ« situatĂ« kritike. Optimalisht, Ă«shtĂ« mirĂ« ta bĂ«ni kĂ«tĂ« disa herĂ«:
- Një ekspert dhe disa stazhier punojnë në një skenë testimi që imiton sa më shumë shërbimin real. Eksperti prish shërbimin në mënyra të ndryshme dhe u jep mundësi stazhierëve ta rikuperojnë sipas DRP-së. Të gjitha problemet, paqartësitë në dokumentacion dhe gabimet shkruhen. Pas trajnimit të stazhierëve, DRP është plotësuar dhe thjeshtuar në vendet e paqarta.
- Testimi në një shërbim të vërtetë. Në të vërtetë, nuk është kurrë e mundur të krijoni një kopje ideale të një shërbimi të vërtetë. Prandaj, disa herë në vit, është e nevojshme të planifikoni ndalesa të pjesës së serverëve, të prishni lidhjet dhe të organizoni katastrofa të tjera nga lista e kërcënimeve, për të vlerësuar rendin e rikuperimit. Një katastrofë e planifikuar për 10 minuta në mes të natës është më mirë se një dështim i papritur për disa orë në një pikë ngarkese me humbje të të dhënave.
- Eliminimi i vërtetë i një katastrofe. Po, kjo gjithashtu është pjesë e testimit. Nëse ndodh një katastrofë që nuk ishte në listën e kërcënimeve, është e nevojshme ta plotësoni dhe rishikoni DRP-në në bazë të rezultateve të hetimit të saj.
Pikat kyçe
- Nëse diçka e keqe mund të ndodhë, ajo jo vetëm që do të ndodhë, por do ta bëjë këtë në skenarin më katastrofik.
- Sigurohuni që keni burime për shpërndarjen emergjente të ngarkesës.
- Sigurohuni që keni backup-e, ato krijohen automatikisht dhe kontrollohen rregullisht për konsistencë.
- Mendoni për skenarët tipikë të kërcënimeve.
- Jepni mundësi inxhinierëve të krijojnë variante jo-typike për të goditur shërbimin.
- DRP duhet të jetë një udhëzues i thjeshtë dhe i qartë. Të gjitha diagnostikimet e komplikuara pasojnë vetëm pasi shërbimi të rikuperohet për klientët. Edhe nëse është në kapacitetet rezervë.
- Specifikoni numrat dhe kontaktet kryesore në DRP.
- Testoni rregullisht punonjësit për të kuptuar DRP-në.
- Organizoni katastrofa të planifikuara në prodhim. Stendat nuk mund të zëvendësojnë gjithçka.
Burimi: habr.com
