ProHoster > Blogs > Administrācija > DRP sagatavoÅ”ana - neaizmirstiet ņemt vērā meteorÄ«tu

DRP sagatavoÅ”ana - neaizmirstiet ņemt vērā meteorÄ«tu

DRP sagatavoÅ”ana - neaizmirstiet ņemt vērā meteorÄ«tu
Pat katastrofas laikā vienmēr ir laiks tējas tasei

DRP (avārijas atjaunoÅ”anas plāns) ir lieta, kas ideālā gadÄ«jumā nekad nebÅ«s vajadzÄ«ga. Bet, ja pēkŔņi pāroÅ”anās sezonas laikā migrējoÅ”ie bebri izgrauž mugurkaula optisko Ŕķiedru vai jaunākais administrators nomet produktÄ«vo bāzi, noteikti vēlaties bÅ«t pārliecināts, ka jums bÅ«s iepriekÅ” izstrādāts plāns, ko darÄ«t ar visu Å”o negodu.

Kamēr klienti panikā sāk nogriezt tehniskā atbalsta tālruņus, juniors meklē cianīdu, jūs gudri atverat sarkano aploksni un sākat visu sakārtot.

Å ajā ierakstā es vēlos dalÄ«ties ar ieteikumiem, kā uzrakstÄ«t DRP un kam tajā vajadzētu bÅ«t. ApskatÄ«sim arÄ« Ŕādas lietas:

  1. Mācīsimies domāt kā nelietis.
  2. ApskatÄ«sim tējas tases priekÅ”rocÄ«bas apokalipses laikā.
  3. Padomāsim par ērtu DRP struktūru
  4. Apskatīsim, kā to pārbaudīt

Kuriem uzņēmumiem tas varētu būt noderīgi?

Ir ļoti grūti novilkt robežu, kad IT nodaļai Ŕādas lietas sāk būt vajadzīgas. Es teiktu, ka jums noteikti ir nepiecieŔams DRP, ja:

  • Servera, lietojumprogrammas apturÄ“Å”ana vai kādas datu bāzes zaudÄ“Å”ana radÄ«s ievērojamus zaudējumus uzņēmumam kopumā.
  • Jums ir pilnvērtÄ«ga IT nodaļa. Nodaļas izpratnē pilnvērtÄ«ga uzņēmuma struktÅ«rvienÄ«ba, ar savu budžetu, nevis tikai daži noguruÅ”i darbinieki, kas klāj tÄ«klu, tÄ«ra vÄ«rusus un uzpilda printerus.
  • Jums ir reāls budžets vismaz daļējai atlaiÅ”anai ārkārtas situācijā.

Kad IT nodaļa jau mēneÅ”iem ilgi lÅ«dz vismaz pāris HDD vecā serverÄ« rezerves kopijām, diez vai izdosies noorganizēt pilnvērtÄ«gu neveiksmÄ«ga pakalpojuma pārvietoÅ”anu, lai rezervētu jaudu. Lai gan Å”eit dokumentācija nebÅ«s lieka.

Dokumentācija ir svarīga

Sāciet ar dokumentāciju. Pieņemsim, ka jÅ«su pakalpojums darbojas ar Perl skriptu, ko pirms trim paaudzēm rakstÄ«ja administratori, taču neviens nezina, kā tas darbojas. Uzkrātais tehniskais parāds un dokumentācijas trÅ«kums neizbēgami Å”aus ne tikai ceļgalā, bet arÄ« citās ekstremitātēs, tas vairāk ir laika jautājums.

Kad esat labi aprakstījis pakalpojuma sastāvdaļas, meklējiet negadījumu statistiku. Tie gandrīz noteikti būs pilnīgi tipiski. Piemēram, jūsu disks laiku pa laikam kļūst pilns, kas izraisa mezgla atteici, līdz tas tiek manuāli notīrīts. Vai arī klientu pakalpojums kļūst nepieejams, jo kāds atkal aizmirsa atjaunot sertifikātu un Let's Encrypt nevarēja vai nevēlējās konfigurēt.

Domas kā diversants

Sarežģītākā daļa ir paredzēt tos negadÄ«jumus, kas nekad agrāk nav notikuÅ”i, bet kas potenciāli varētu pilnÄ«bā sagraut jÅ«su pakalpojumu. Å eit mēs ar kolēģiem parasti spēlējam nelieÅ”us. Paņemiet daudz kafijas un kaut ko garŔīgu un ieslēdzieties sanāksmju telpā. VienkārÅ”i pārliecinieties, ka tajās paŔās sarunās tiek iesaistÄ«ti tie inženieri, kuri paÅ”i izstrādāja mērÄ·a pakalpojumu vai regulāri ar to strādā. Pēc tam vai nu uz tāfeles, vai uz papÄ«ra jÅ«s sākat zÄ«mēt visas iespējamās Å”ausmas, kas varētu notikt ar jÅ«su dienestu. Nav nepiecieÅ”ams iedziļināties detaļās lÄ«dz konkrētai apkopējai un kabeļu izvilkÅ”anai, pietiek apsvērt scenāriju ā€œVietējā tÄ«kla integritātes pārkāpumsā€.

Parasti tipiskākās ārkārtas situācijas iedala Ŕādos veidos:

  • TÄ«kla kļūda
  • OS pakalpojumu kļūme
  • Lietojumprogrammas kļūme
  • Dzelzs mazspēja
  • Virtualizācijas kļūme

VienkārÅ”i apskatiet katru veidu un uzziniet, kas attiecas uz jÅ«su pakalpojumu. Piemēram, Nginx dēmons var nokrist un nepaaugstināties - tas nozÄ«mē OS kļūmes. Reta situācija, kas izraisa jÅ«su tÄ«mekļa lietojumprogrammas kļūmi, ir programmatÅ«ras kļūme. Strādājot Å”ajā posmā, ir svarÄ«gi noteikt problēmas diagnozi. Kā, piemēram, atŔķirt iesaldētu virtualizācijas interfeisu no nokrituÅ”a cis diska un tÄ«kla kļūmes. Tas ir svarÄ«gi, lai ātri atrastu atbildÄ«gos un sāktu vilkt viņu asti, lÄ«dz negadÄ«jums ir atrisināts.

Pēc tipisko problēmu pierakstÄ«Å”anas mēs ielejam vēl kafiju un sākam apsvērt dÄ«vainākos scenārijus, kad daži parametri sāk pārsniegt normu. Piemēram:

  • Kas notiek, ja laiks aktÄ«vajā mezglā pavirzās par minÅ«ti atpakaļ attiecÄ«bā pret citiem klasterÄ«?
  • Ko darÄ«t, ja laiks virzās uz priekÅ”u, ja par 10 gadiem?
  • Kas notiek, ja klastera mezgls sinhronizācijas laikā pēkŔņi zaudē tÄ«klu?
  • Kas notiks, ja divi mezgli nedalÄ«s vadÄ«bu Ä«slaicÄ«gas viens otra izolācijas dēļ tÄ«klā?

Å ajā posmā apgrieztā pieeja ir ļoti noderÄ«ga. JÅ«s paņemat spÄ«tÄ«gāko komandas locekli ar slimu iztēli un uzdodat viņam pēc iespējas Ä«sākā laikā sarÄ«kot sabotāžu, kas sagraus dienestu. Ja ir grÅ«ti diagnosticēt, vēl labāk. JÅ«s neticēsiet, kādas dÄ«vainas un forÅ”as idejas izdomā inženieri, ja iedosiet viņiem ideju kaut ko salauzt. Un, ja jÅ«s apsolāt viņiem Å”im nolÅ«kam izveidot testÄ“Å”anas stendu, tas ir pilnÄ«gi labi.

Kas tas par taviem DRP?!

Tātad jÅ«s esat definējis savu draudu modeli. Viņi ņēma vērā arÄ« vietējos iedzÄ«votājus, kuri, meklējot varu, grieza optiskās Ŕķiedras kabeļus, un militāro radaru, kas piektdienās pulksten 16:46 stingri nolaiž radioreleja lÄ«niju. Tagad mums ir jāsaprot, ko ar to visu darÄ«t.

Tavs uzdevums ir uzrakstÄ«t tās ļoti sarkanās aploksnes, kuras tiks atvērtas ārkārtas situācijā. Nekavējoties sagaidiet, ka tad, kad (ne jau!) viss beigsies, blakus bÅ«s tikai visnepieredzējuŔākais praktikants, kuram no Å”ausmām par notiekoÅ”o varoÅ”i trÄ«cēs rokas. Skatiet, kā medicÄ«nas iestādēs tiek ieviestas ārkārtas zÄ«mes. Piemēram, ko darÄ«t anafilaktiskā Å”oka gadÄ«jumā. MedicÄ«nas personāls visus protokolus zina no galvas, bet, kad cilvēks tuvumā sāk mirt, ļoti bieži visi bezpalÄ«dzÄ«gi Ä·eras pie visa, kas redzams. Lai to izdarÄ«tu, uz sienas ir skaidri norādÄ«jumi ar tādiem priekÅ”metiem kā "atveriet Ŕādu un tādu iepakojumu" un "ievadiet tik daudz zāļu vienÄ«bu intravenozi".

Ārkārtas situācijā ir grÅ«ti domāt! Ir jābÅ«t vienkārÅ”iem norādÄ«jumiem par muguras smadzeņu parsÄ“Å”anu.

Labs DRP sastāv no vairākiem vienkārŔiem blokiem:

  1. Kam jāpaziņo par negadÄ«juma sākumu. Tas ir svarÄ«gi, lai pēc iespējas vairāk paralēli likvidÄ“Å”anas procesu.
  2. Kā pareizi diagnosticēt - veiciet izsekoÅ”anu, skatieties systemctl statusa pakalpojuma nosaukums un tā tālāk.
  3. Cik daudz laika varat pavadÄ«t katrā posmā? Ja jums nav laika to manuāli labot SLA laikā, virtuālā maŔīna tiek iznÄ«cināta un noņemta no vakardienas dublējuma.
  4. Kā pārliecināties, ka negadījums ir beidzies.

Atcerieties, ka DRP sākas, kad pakalpojums ir pilnÄ«bā neizdevies, un beidzas, kad pakalpojums tiek atjaunots, pat ar samazinātu efektivitāti. VienkārÅ”i pazaudējot rezervāciju, nevajadzētu aktivizēt DRP. Varat arÄ« ierakstÄ«t tasi tējas DRP. Nopietni. Saskaņā ar statistiku daudzi negadÄ«jumi no nepatÄ«kamiem kļūst par katastrofāliem tādēļ, ka darbinieki panikā steidzas kaut ko labot, vienlaikus nogalinot vienÄ«go dzÄ«vo mezglu ar datiem vai beidzot pabeidzot kopu. Parasti 5 minÅ«tes ar tasi tējas dos jums laiku nomierināties un analizēt notiekoÅ”o.

Nejauciet DRP un sistēmas pasi! Nepārslogojiet to ar nevajadzÄ«giem datiem. VienkārÅ”i dodiet iespēju ātri un ērti izmantot hipersaites, lai pārietu uz vajadzÄ«go dokumentācijas sadaļu un paplaÅ”inātā formātā lasÄ«tu par nepiecieÅ”amajām pakalpojuma arhitektÅ«ras sadaļām. Un paŔā DRP ir tikai tieÅ”as instrukcijas par to, kur un kā izveidot savienojumu ar Ä«paŔām kopÄ“Å”anas-ielÄ«mÄ“Å”anas komandām.

Kā pareizi pārbaudīt

Pārliecinieties, vai jebkurÅ” atbildÄ«gais darbinieks spēj nokomplektēt visus priekÅ”metus. IzŔķirÄ«gākajā brÄ«dÄ« var izrādÄ«ties, ka inženierim nav tiesÄ«bu piekļūt vajadzÄ«gajai sistēmai, vajadzÄ«gajam kontam nav paroļu vai arÄ« viņam nav ne jausmas, ko ā€œIzveidojiet savienojumu ar pakalpojumu pārvaldÄ«bas konsoli caur starpniekserveri galvenais birojsā€ nozÄ«mē. Katram punktam jābÅ«t ļoti vienkārÅ”am.

Nepareizi - ā€œDodieties uz virtualizāciju un pārstartējiet miruÅ”o mezgluā€
Pareizi - "Izveidojiet savienojumu, izmantojot tīmekļa saskarni ar virt.example.com, mezglu sadaļā atsāknējiet mezglu, kas izraisa kļūdu."

Izvairieties no neskaidrībām. Atcerieties nobiedēto praktikantu.

Noteikti pārbaudiet DRP. Tas nav tikai izrādes plāns ā€“ tas ļaus jums un jÅ«su klientiem ātri izkļūt no kritiskās situācijas. Vislabāk to darÄ«t vairākas reizes:

  • Viens eksperts un vairāki praktikanti strādā uz pārbaudes stenda, kas pēc iespējas vairāk simulē reālu pakalpojumu. Eksperts dažādos veidos pārtrauc pakalpojumu un dod iespēju praktikantiem to atjaunot atbilstoÅ”i DRP. Visas problēmas, dokumentācijas neskaidrÄ«bas un kļūdas tiek reÄ£istrētas. Pēc praktikantu apmācÄ«bas DRP tiek paplaÅ”ināts un vienkārÅ”ots neskaidrās jomās.
  • TestÄ“Å”ana reālā servisā. PatiesÄ«bā jÅ«s nekad nevarat izveidot perfektu reāla pakalpojuma kopiju. Tāpēc pāris reizes gadā regulāri jāatslēdz daži serveri, jāpārtrauc savienojumi un jāizraisa citas katastrofas no draudu saraksta, lai novērtētu atkopÅ”anas procedÅ«ru. Plānota kļūme 10 minÅ«tes nakts vidÅ« ir labāka nekā pēkŔņa kļūme vairākas stundas maksimālās slodzes laikā ar datu zudumu.
  • ÄŖsta problēmu novērÅ”ana. Jā, arÄ« Ŕī ir daļa no testÄ“Å”anas. Ja notiek negadÄ«jums, kas nebija draudu sarakstā, ir nepiecieÅ”ams papildināt un pabeigt DRP, pamatojoties uz tā izmeklÄ“Å”anas rezultātiem.

Galvenie punkti

  1. Ja var notikt sūdi, tas ne tikai notiks, bet tas notiks pēc iespējas katastrofālākā scenārija.
  2. Pārliecinieties, vai jums ir resursi ārkārtas slodzes pārsūtīŔanai.
  3. Pārliecinieties, vai jums ir dublējumkopijas, tās tiek automātiski izveidotas un regulāri tiek pārbaudÄ«tas, lai nodroÅ”inātu konsekvenci.
  4. Pārdomājiet tipiskus draudu scenārijus.
  5. Dodiet inženieriem iespēju piedāvāt nestandarta iespējas pakalpojuma sniegÅ”anai.
  6. DRP ir jābÅ«t vienkārÅ”ai un strupai instrukcijai. Visa kompleksā diagnostika tiek veikta tikai pēc klientu apkalpoÅ”anas atjaunoÅ”anas. Pat ja ar rezerves jaudu.
  7. Norādiet galvenos tālruņu numurus un kontaktpersonas DRP.
  8. Regulāri pārbaudiet darbinieku izpratni par DRP.
  9. Sakārtot plānotos nelaimes gadījumus ražotnēs. Statīvi nevar aizstāt visu.

DRP sagatavoÅ”ana - neaizmirstiet ņemt vērā meteorÄ«tu

DRP sagatavoÅ”ana - neaizmirstiet ņemt vērā meteorÄ«tu

Avots: www.habr.com

Pievieno komentāru