Edhe në kohë katastrofe, gjithmonë ka kohë për një filxhan çaji
DRP (plani i rikuperimit të katastrofës) është një gjë që në ideale nuk do të nevojitet kurrë. Por, nëse ndodhin situata si, për shembull, duro-kalimi i rrugës kryesore të fibrave optike nga castori gjatë periudhës së çiftimit ose nëse administratori junior heq bazën aktive, ju sigurisht dëshironi të jeni të sigurt që keni një plan të përgatitur paraprakisht se çfarë të bëni me gjithë këtë kaos.
Ndërsa klientët në panik fillojnë të thërrasin linjën e mbështetjes teknike, juniori kërkon cianidë, ju me një pamje të mençur hapni enverdin e kuq dhe filloni të organizoni gjithçka.
Në këtë postim, dua të ndaj rekomandime se si duhet të shkruhet DRP dhe çfarë duhet të përmbajë. Po ashtu, do të shqyrtojmë gjërat në vazhdim:
- Do të mësojmë të mendojmë si një keqbërës.
- Do të analizojmë përfitimet e një filxhani çaji gjatë apokalipsit.
- Do të projektojmë një strukturë të përshtatshme për DRP.
- Do të shohim se si duhet ta testojmë atë.
Për cilat kompanitë mund të jetë e dobishme.
ĂshtĂ« shumĂ« e vĂ«shtirĂ« tĂ« tĂ«rheqĂ«sh njĂ« kufi kur departamenti IT fillon tĂ« ketĂ« nevojĂ« pĂ«r gjĂ«ra tĂ« tilla. Do tĂ« thosha se DRP Ă«shtĂ« absolutisht i nevojshĂ«m nĂ«se:
- Ndërprerja e serverit, aplikacionit ose humbja e ndonjë baze do të çojë në humbje të konsiderueshme për biznesin në tërësi.
- Keni një departament IT të plotë. Për t'u kuptuar, një departament si një njësi e plotë e kompanisë, me buxhetin e tij, dhe jo thjesht disa punonjës të lodhur që shtrijnë rrjetin, pastruan viruset dhe mbushin printerët.
- Keni një buxhet të vërtetë për të paktën rezervat e pjesshme në rast emergjence.
Kur departamenti IT del me muaj për të kërkuar edhe disa HDD në një server të vjetër për backup, me siguri nuk do të jeni në gjendje të organizoni një kalim të plotë të shërbimit të rënë në kapacitetet rezervë. Megjithatë, dokumentacioni gjithmonë do të jetë i dobishëm.
Dokumentacioni është i rëndësishëm
Filloni me dokumentimin. Le të supozojmë se shërbimi juaj funksionon në një skenar Perl, i shkruar tri breza administratorësh më parë, dhe askush nuk e di si funksionon. Borxhi teknik i akumuluar dhe mungesa e dokumentimit do t'ju shkaktojë ndoshta jo vetëm dhimbje në gju, por edhe në pjesë të tjera të trupit, kjo është më shumë çështje e kohës.
Pasi qĂ« keni pĂ«rgatitur njĂ« pĂ«rshkrim tĂ« mirĂ« tĂ« komponenteve tĂ« shĂ«rbimit, ngatĂ«rroni statistikat e shpĂ«rthimeve. Me siguri do tĂ« jenĂ« krejtĂ«sisht tipike. PĂ«r shembull, ndonjĂ«herĂ« disku mbushet, duke çuar nĂ« dĂ«shtimin e nodit deri nĂ« pastrimin e tij manual. Ose shĂ«rbimi pĂ«r klientĂ«t bĂ«het i paqĂ«ndrueshĂ«m sepse dikush pĂ«rsĂ«ri ka harruar tĂ« zgjatet certifikata, dhe Letâs Encrypt nuk ka mundur ose nuk ka dashur ta konfigurojĂ«.
Mendoni si një diversant
Pjesa më e vështirë është parashikimi i atyre shpërthimeve që nuk kanë ndodhur kurrë më parë, por që potencialisht mund të shkatërrojnë krejtësisht shërbimin tuaj. Këtu zakonisht kërkojmë ndihmën e kolegëve për të luajtur rolin e të ligëve. Merrni shumë kafe dhe diçka të shijshme dhe mbylleni në një dhomë takimesh. Sigurohuni që në këtë dhomë të keni mbyllur ata inxhinierë që e ngritën shërbimin e synuar ose punojnë rregullisht me të. Pastaj, ose në bord, ose në letër, filloni të përshkruani të gjitha tmerrët e mundshme që mund të ndodhin me shërbimin tuaj. Nuk është e nevojshme të detajoni deri tek pastruesja specifike dhe tërheqja e kabllove, mjafton të shqyrtoni skenarin e "Shkeljes së integritetit të rrjetit lokal".
Zakonisht, shumica e situatave tipike të shpërthimit përfshihen në lloje të mëposhtme:
- DĂ«shtimi i rrjetit
- Dështimi i shërbimeve të OS
- DĂ«shtimi i aplikacionit
- DĂ«shtimi i harduerit
- DĂ«shtimi i virtualizimit
Thjesht kaloni pĂ«rmes çdo lloji dhe shikoni se çfarĂ« Ă«shtĂ« e aplikueshme pĂ«r shĂ«rbimin tuaj. PĂ«r shembull, mund tĂ« bie dhe tĂ« mos ngrihet demon Nginx â kjo Ă«shtĂ« nĂ« lidhje me dĂ«shtimet nga ana e OS. NjĂ« situatĂ« e rrallĂ« qĂ« nxjerr aplikacionin tuaj web jashtĂ« funksionit â Ă«shtĂ« dĂ«shtimi i softuerit. GjatĂ« kĂ«tij etapi, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rpunoni diagnostikimin e problemit. Si ta dalloni njĂ« ndĂ«rfaqe tĂ« ngrirĂ« nĂ« virtualizim nga njĂ« dĂ«shtim i njĂ« Cisco dhe njĂ« shpĂ«rthim nĂ« rrjet, pĂ«r shembull. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r tĂ« gjetur pĂ«rgjegjĂ«sit shpejt dhe pĂ«r tĂ« filluar tĂ« tĂ«rhiqni ata pĂ«r bisht, derisa shpĂ«rthimi tĂ« jetĂ« eliminuar.
Pasi të jenë regjistruar problemet tipike, derdhni edhe pak kafe dhe filloni të shqyrtoni skenarët më të çuditshëm, kur disa parametra fillojnë të dalin përtej normës. Për shembull:
- ĂfarĂ« do tĂ« ndodhĂ« nĂ«se koha nĂ« nodin aktiv lĂ«viz njĂ« minutĂ« prapa nĂ« krahasim me tĂ« tjerĂ«t nĂ« klaster?
- Dhe çfarë ndodh nëse koha lëviz përpara, dhe nëse për 10 vjet?
- ĂfarĂ« do tĂ« ndodhĂ« nĂ«se gjatĂ« sinkronizimit, nodi i klasterit papritur humb rrjetin?
- ĂfarĂ« do tĂ« ndodhĂ« nĂ«se dy node nuk arrijnĂ« tĂ« ndajnĂ« liderĂ«sinĂ« pĂ«r shkak tĂ« izolimit tĂ« pĂ«rkohshĂ«m nga njĂ«ri-tjetri nĂ« rrjet?
NĂ« kĂ«tĂ« fazĂ«, qasja e kundĂ«rt ndihmon shumĂ«. Merrni anĂ«tarin mĂ« tĂ« pasionuar tĂ« ekipit, i cili ka imagjinatĂ« tĂ« madhe, dhe jepjani detyrĂ«n pĂ«r tĂ« organizuar njĂ« diversion qĂ« do tĂ« ndalonte shĂ«rbimin brenda njĂ« kohe tĂ« shkurtĂ«r. NĂ«se Ă«shtĂ« e vĂ«shtirĂ« pĂ«r t'u diagnostikuar â kaq mĂ« mirĂ«. Nuk do ta besoni se sa ide tĂ« çuditshme dhe tĂ« shkĂ«lqyera japin inxhinierĂ«t, nĂ«se u jepni idenĂ« pĂ«r tĂ« thyer diçka. Dhe nĂ«se u premtoni njĂ« skenĂ« testimi pĂ«r kĂ«tĂ« â do tĂ« ishte shumĂ« mĂ« mirĂ«.
ĂfarĂ« Ă«shtĂ« ky DRP juaj?!
Tani që keni përcaktuar modelin e kërcënimeve. Keni marrë parasysh edhe banorët lokalë që prerë kabllot optike për të kërkuar bakrin, dhe radarët ushtarakë që bien në linjën të radio-relay çdo të premte në 16:46. Tani duheni të kuptoni ç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. Llogaritni menjëherë se kur (jo nëse!) gjithçka shkon keq, do të ketë vetëm stazhin më të papërvojë pranë, i cili do të ketë duar që dridhen nga paniku. Shikoni se si janë realizuar tabelat e emergjencës në zyrat mjekësore. Për shembull, çfarë të bëni në rast të shock anafilik. Stafi mjekësor e di përmendësh të gjitha protokollet, por kur përballet me një person që po vdes, shpesh shumë prej tyre kapen për gjithçka. Për këtë, mbi mur është një udhëzim i qartë me pika të stilit 'hapni paketimin e atij' dhe 'jepni intravenoz aq njësi të preparatit'.
Në një situatë emergjente mendimi është i vështirë! Duhet të kenë udhëzime të thjeshta për të pasur mundësi të kuptoni me instinktin.
Një DRP i mirë përbëhet nga disa blloqe të thjeshta:
- Kënd duhet të njoftoni në fillim të emergjencës. Kjo është e rëndësishme për të shpejtuar procesin e zgjidhjes.
- Si të diagnostikoni saktë - kryejmë një gjurmim, shikojmë në statusin e systemctl servicename e kështu me radhë.
- Sa kohë mund të shpenzohet në secilën fazë. Nëse nuk arrini ta rregulloni manualisht brenda kohës SLA - makina virtuale ndalohet dhe instalohet nga backup-i i djeshëm.
- Si të siguroheni që emergjenca ka përfunduar.
Mos i harroni se DRP fillon kur shërbimi ka dështuar plotësisht dhe përfundon me rikuperimin e funksionalitetit, edhe me efikasitet të reduktuar. Thjesht humbja e rezervimit nuk duhet të aktivizojë DRP. Po ashtu, mund të përfshini një filxhan çaji në DRP. Me të vërtetë. Sipas statistikave, shumë aksidente nga të këqijat bëhen katastrofike për shkak se stafi, në panik, fillon të riparojë diçka, duke e vrarë përfundimisht grupin e vetëm të dhënash ose duke përfunduar klasterin. Në përgjithësi, 5 minuta për një filxhan çaji do t'ju japin pak kohë për të qetësuar veten dhe për të analizuar situatën.
Mos e ngatërroni DRP-në me pasaportën e sistemit! Mos e mbingarkoni me të dhëna të panevojshme. Thjesht ofroni mundësinë që të kaloni shpejt dhe lehtësisht në seksionin e duhur të dokumentacionit për të lexuar në një format të zgjeruar rreth segmenteve të nevojshme të arkitekturës së shërbimit. Dhe në vetë DRP-në, vetëm udhëzime të drejtpërdrejta se ku dhe si të lidheni me komanda specifike për kopjim dhe ngjish.
Si të testoni siç duhet
Sigurohuni qĂ« çdo punonjĂ«s i pĂ«rgjegjshĂ«m tĂ« jetĂ« nĂ« gjendje tĂ« kryejĂ« tĂ« gjitha pikat. NĂ« momentin mĂ« kritik mund tĂ« ndodhĂ« qĂ« inxhinieri nuk ka tĂ« drejta pĂ«r qasje nĂ« sistemin e nevojshĂ«m, nuk ka fjalĂ«kalimet e llogarisĂ« sĂ« nevojshme, ose nuk ka asnjĂ« ide se çfarĂ« do tĂ« thotĂ« "Lidhu me konsolĂ«n e menaxhimit tĂ« shĂ«rbimit pĂ«rmes prokurrimit nĂ« zyrĂ«n qendrore". Ădo pikĂ« duhet tĂ« jetĂ« jashtĂ«zakonisht e thjeshtĂ«.
Gabim â "Shkoni te virtualizimi dhe rinisni nodin e vdekur"
SaktĂ« â "Lidhu pĂ«rmes ndĂ«rfaqes web nĂ« virt.example.com, nĂ« seksionin e nodĂ«s kryeni rinisjen e nodĂ«s qĂ« shkakton gabim".
Mos lejoni dyshime. Kujtoni për stazhin e frikësuar.
Sigurohuni tĂ« testoni DRP-nĂ«. Kjo nuk Ă«shtĂ« thjesht njĂ« plan pĂ«r t'u shĂ«nuar â Ă«shtĂ« ajo qĂ« do t'ju ndihmojĂ« juve dhe klientĂ«ve tuaj tĂ« dilni shpejt nga njĂ« situatĂ« kritike. Idealisht, bĂ«ni kĂ«tĂ« disa herĂ«:
- Një ekspert dhe disa stazhistë punojnë në një skenë testuese që imiton maksimalisht shërbimin real. Eksperti prish shërbimin në mënyra të ndryshme dhe i jep mundësinë stazhistëve të rikuperojnë atë sipas DRP-së. Të gjitha problemet, paqartësitë në dokumentacion dhe gabimet regjistrohen. Pas trajtimit të stazhistëve, DRP vazhdimisht përmirësohet dhe thjeshtohet në vendet e paqarta.
- Testimi nĂ« njĂ« shĂ«rbim real. NĂ« tĂ« vĂ«rtetĂ«, nuk Ă«shtĂ« kurrĂ« e mundur tĂ« krijosh njĂ« kopje perfekte tĂ« njĂ« shĂ«rbimi tĂ« vĂ«rtetĂ«. Prandaj, disa herĂ« nĂ« vit Ă«shtĂ« e nevojshme tĂ« fiket njĂ« pjesĂ« e serverave, tĂ« priten lidhjet dhe tĂ« organizohen katastrofa tĂ« tjera nga lista e kĂ«rcĂ«nimeve, pĂ«r tĂ« vlerĂ«suar rendin e rikuperimit. ĂshtĂ« mĂ« mirĂ« njĂ« katastrofĂ« e planifikuar pĂ«r 10 minuta nĂ« mesnatĂ« sesa njĂ« dĂ«shtim i papritur pĂ«r disa orĂ« nĂ« kulmin e ngarkesĂ«s me humbje tĂ« tĂ« dhĂ«nave.
- Eliminimi real i katastrofës. Po, kjo është gjithashtu një pjesë e testimit. Nëse ndodh një katastrofë që nuk ishte në listën e kërcënimeve, është e nevojshme të plotësoni dhe rregulloni DRP-në sipas rezultateve të hetimit të saj.
Pikat kryesore
- Nëse ndodhi diçka, ajo jo vetëm që do të ndodhë, por do ta bëjë këtë në një skenar sa më katastrofik.
- Sigurohuni që të keni burime për shpërndarjen e ngarkesës në rast katastrofe.
- Sigurohuni që të keni kopje rezervë, ato të krijohen automatikisht dhe kontrollohen rregullisht për qëndrueshmëri.
- Mendoni skenarët tipikë të kërcënimeve.
- Ji i hapur që inxhinierët të gjejnë variante jo tipike për të dështuar shërbimin.
- DRP duhet të jetë një udhëzim i thjeshtë dhe i drejtpërdrejtë. Të gjithë diagnostikimi kompleks vetëm pas rikuperimit të shërbimit për klientët. Edhe nëse është në kapacitet rezervë.
- Sigurohuni që të përfshini 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
