Hətta fəlakət zamanı belə bir fincan çay içməyə həmişə vaxt tapılır.
DRP (fəlakətin bərpası planı) ideal olaraq heç vaxt lazım olmayacaq bir şeydir. Ancaq cütləşmə mövsümündə miqrasiya edən qunduzlar birdən əsas optik lifi dişləsələr və ya kiçik admin məhsuldar bazanı atsa, bütün bu rüsvayçılıqla nə edəcəyiniz barədə əvvəlcədən hazırlanmış bir planınız olacağına əmin olmaq istərdiniz.
Çaxnaşmaya düşən müştərilər texniki dəstəyə zəng etməyə başlasalar, bir gənc siyanid axtarır, siz ağılla qırmızı zərfi açıb hər şeyi qaydasına salmağa başlayırsınız.
Bu yazıda mən DRP-nin necə yazılacağı və tərkibində nələrin olması barədə tövsiyələri bölüşmək istəyirəm. Aşağıdakılara da baxacağıq:
- Bir cani kimi düşünməyi öyrənin.
- Apokalipsis zamanı bir fincan çayın faydalarını təhlil edək.
- Rahat bir DRP strukturu üzərində düşünün
- Bunu necə sınayacağımıza baxaq
Hansı şirkətlər bundan faydalana bilər?
İT departamenti bu şeylərə ehtiyac duymağa başlayanda xətt çəkmək çox çətindir. Deyərdim ki, sizə DRP-yə ehtiyacınız olduğuna zəmanət verilir, əgər:
- Bir serverin, tətbiqin dayandırılması və ya bəzi verilənlər bazasının itirilməsi bütövlükdə biznes üçün əhəmiyyətli itkilərə səbəb olacaq.
- Sizin tam hüquqlu İT departamentiniz var. Demək istədiyim odur ki, bir neçə yorğun işçi şəbəkə çəkib, virusları təmizləyən və printerləri dolduran deyil, öz büdcəsi olan, şirkətin tam hüquqlu bölməsi kimi.
- Fövqəladə vəziyyət zamanı ən azı qismən ixtisar üçün real büdcəniz var.
İT departamenti aylardır ehtiyat nüsxələri üçün köhnə server üçün ən azı bir neçə HDD dilənəndə, çətin ki, düşmüş xidmətin ehtiyat imkanlara tam hüquqlu köçürülməsini təşkil edə bilməyəcəksiniz. Baxmayaraq ki, sənədlər burada da artıq olmayacaq.
Sənədləşmə vacibdir
Sənədlərlə başlayın. Deyək ki, xidmətiniz üç nəsil adminlər əvvəl yazılmış Perl skripti ilə işləyir və onun necə işlədiyini heç kim bilmir. Yığılmış texniki borc və sənədlərin olmaması istər-istəməz sizi təkcə dizinizdən deyil, digər ətraflarınızdan da vuracaq, bu, daha çox vaxt məsələsidir.
Əlinizdə olan xidmət komponentlərinin yaxşı təsviri olduqdan sonra qəza statistikasını qaldırın. Demək olar ki, onlar tamamilə tipik olacaqlar. Məsələn, zaman-zaman dolu bir diskiniz var, bu da qovşağın əl ilə təmizlənməyincə uğursuz olmasına səbəb olur. Və ya kimsə sertifikatı yeniləməyi yenidən unutduğuna və Let's Encrypt konfiqurasiya edilə bilmədiyinə və ya istəmədiyinə görə müştəri xidməti əlçatan olur.
Təxribatçı kimi düşüncələr
Ən çətin hissə əvvəllər heç vaxt baş verməmiş, lakin xidmətinizi tamamilə məhv edə biləcək qəzaları proqnozlaşdırmaqdır. Burada biz adətən həmkarlarla yaramazlar oynayırıq. Çoxlu qəhvə və dadlı bir şey götürün və özünüzü iclas otağına bağlayın. Sadəcə əmin olun ki, eyni görüşdə hədəf xidməti qaldıran və ya onunla müntəzəm işləyən mühəndisləri kilidləmisiniz. Sonra ya lövhədə, ya da kağızda xidmətinizdə baş verə biləcək bütün mümkün dəhşətləri çəkməyə başlayırsınız. Müəyyən bir təmizləyici xanıma qədər ətraflı məlumat vermək və kabelləri çıxarmaq lazım deyil, "Yerli şəbəkənin bütövlüyünün pozulması" ssenarisini nəzərdən keçirmək kifayətdir.
Adətən, ən tipik fövqəladə hallar aşağıdakı növlərə uyğun gəlir:
- Şəbəkə xətası
- ƏS xidmətində nasazlıq
- Tətbiq uğursuzluğu
- dəmir çatışmazlığı
- Virtuallaşdırma uğursuzluğu
Sadəcə hər bir görünüşü nəzərdən keçirin və xidmətinizə nəyin aid olduğuna baxın. Məsələn, Nginx demonu düşə bilər və qalxmaya bilər - bu, OS tərəfindən uğursuzluqdur. Veb tətbiqinizi işləməyən vəziyyətə gətirən nadir bir vəziyyət proqram çatışmazlığıdır. Bu mərhələnin inkişafı zamanı problemin diaqnozunu hazırlamaq vacibdir. Məsələn, virtuallaşdırmada asılmış interfeysi düşmüş cisco və şəbəkə qəzasından necə ayırd etmək olar. Məsul şəxsləri tez tapmaq və qəza aradan qaldırılana qədər quyruğunu çəkməyə başlamaq vacibdir.
Tipik problemlər yazıldıqdan sonra biz daha çox qəhvə tökürük və bəzi parametrlər normadan kənara çıxmağa başlayanda ən qəribə ssenariləri nəzərdən keçirməyə başlayırıq. Misal üçün:
- Aktiv qovşaqdakı vaxt klasterdəki digərlərinə nisbətən bir dəqiqə geri çəkilsə nə olar?
- Bəs zaman irəli gedirsə və əgər 10 ilə?
- Sinxronizasiya zamanı klaster qovşağı qəfildən şəbəkəni itirərsə nə olar?
- Şəbəkə üzərindən bir-birinin müvəqqəti təcrid olunması səbəbindən iki qovşaq liderliyi bölüşməsə nə olar?
Bu mərhələdə tərs yanaşma çox kömək edir. Xəstə bir təxəyyül ilə komandanın ən inadkar üzvünü götürün və ona ən qısa müddətdə bir təxribat təşkil etmək tapşırığını verin, bu da xidməti dayandıracaq. Diaqnoz qoymaq çətindirsə, daha yaxşıdır. Mühəndislərin nəyisə sındırmaq fikri verildikdə ortaya atdıqları qəribə və sərin fikirlərə inanmayacaqsınız. Əgər onlara bunun üçün bir sınaq stendi vəd etsəniz, bu, çox yaxşıdır.
Sizin bu DRP nədir?!
Beləliklə, siz təhlükə modelini müəyyənləşdirdiniz. Mis axtarışında fiber-optik kabelləri kəsən yerli sakinləri və cümə günləri saat 16:46-da radiorele xəttini axan hərbi radarı da nəzərə aldılar. İndi bütün bunlarla nə edəcəyimizi anlamalıyıq.
Sizin vəzifəniz fövqəladə vəziyyətdə açılacaq eyni qırmızı zərfləri yazmaqdır. Dərhal gözləyin ki, (əgər yox!) Hər şey alt-üst olanda yaxınlıqda yalnız ən təcrübəsiz kursant olacaq, onun əlləri baş verənlərin dəhşətindən şiddətlə titrəyəcək. Tibb kabinetlərində təcili yardım əlamətlərinin necə tətbiq olunduğuna baxın. Məsələn, anafilaktik şokla nə etmək lazımdır. Tibb işçiləri bütün protokolları əzbər bilirlər, lakin yaxınlıqdakı bir insan ölməyə başlayanda çox vaxt hamı çarəsizcə hər şeyi tutur. Bunun üçün divarda “filan paketi aç” və “bu qədər dərmanı venadaxili yerit” kimi əşyaların olduğu aydın təlimat asılır.
Fövqəladə vəziyyətdə düşünmək çətindir! Onurğanın təhlili üçün sadə təlimatlar olmalıdır.
Yaxşı DRP bir neçə sadə blokdan ibarətdir:
- Qəzanın başlanması barədə kimə məlumat verilməlidir. Bu, aradan qaldırılması prosesini mümkün qədər paralelləşdirmək üçün vacibdir.
- Necə düzgün diaqnoz qoymaq olar - izləyirik, systemctl statusuna baxırıq xidmət adı və s.
- Hər mərhələyə nə qədər vaxt sərf etmək olar. SLA müddətində onu əllərinizlə düzəltməyə vaxtınız yoxdursa, virtual maşın dünənki ehtiyat nüsxədən öldürülür və yuvarlanır.
- Qəzanın bitdiyinə necə əmin olmaq olar.
Unutmayın ki, DRP xidmət tamamilə sıradan çıxdıqda başlayır və hətta azalmış səmərəliliklə belə bərpa ilə tamamlanır. Sadəcə rezervasiyanı itirmək DRP-ni aktivləşdirməməlidir. DRP-də bir fincan çay da təyin edə bilərsiniz. Ciddi. Statistikaya görə, bir çox qəzalar, çaxnaşma içərisində olan işçilərin bir şeyi düzəltməyə tələsməsi, eyni zamanda məlumatlarla yeganə canlı nodu öldürməsi və ya nəhayət çoxluğu bitirməsi səbəbindən xoşagəlməzdən fəlakətə keçir. Bir qayda olaraq, bir fincan çay üçün 5 dəqiqə sakitləşmək və baş verənləri təhlil etmək üçün bir az vaxt verəcəkdir.
DRP və sistem pasportunu qarışdırmayın! Onu lazımsız məlumatlarla yükləməyin. Sadəcə olaraq, hiperlinklər vasitəsilə sənədlərin tələb olunan bölməsinə tez və rahat şəkildə keçmək və xidmət arxitekturasının lazımi bölmələri haqqında geniş formatda oxumaq imkanı verin. Və DRP-nin özündə, kopyala-yapışdırmaq üçün xüsusi əmrlərlə harada və necə əlaqə qurmaq barədə yalnız birbaşa təlimatlar var.
Necə düzgün test etmək olar
Hər hansı bir məsul işçinin bütün maddələri yerinə yetirə bildiyinə əmin olun. Ən vacib anda, mühəndisin tələb olunan sistemə giriş hüquqlarının olmadığı, tələb olunan hesab üçün parolların olmadığı və ya “Xidmət idarəetmə konsoluna proksi vasitəsilə qoşulmaq haqqında heç bir məlumatı olmadığı ortaya çıxa bilər. baş ofis” deməkdir. Hər bir element mümkün qədər sadə olmalıdır.
Yanlış - "Virtuallaşdırmaya gedin və ölü nodu yenidən başladın"
Düzgün - "Veb interfeysi vasitəsilə virt.example.com saytına qoşulun, qovşaq bölməsində xətaya səbəb olan nodu yenidən yükləyin."
Qeyri-müəyyənlikdən çəkinin. Qorxmuş təcrübəçini xatırlayın.
DRP-ni sınadığınızdan əmin olun. Bu, sadəcə şou planı deyil - bu, sizə və müştərilərinizə kritik vəziyyətdən tez çıxmağa imkan verəcək bir şeydir. Bunu bir neçə dəfə etmək yaxşıdır:
- Bir ekspert və bir neçə təcrübəçi real xidməti mümkün qədər təqlid edən test skamyasında işləyir. Ekspert müxtəlif üsullarla xidməti pozur və kursantlara onu DRP-yə uyğun bərpa etməyə imkan verir. Bütün problemlər, sənədlərdəki qeyri-müəyyənliklər və səhvlər qeydə alınır. Kursantlara təlim keçdikdən sonra DRP qaranlıq yerlərdə tamamlanır və sadələşdirilir.
- Real xidmətdə sınaq. Əslində, əsl xidmətin mükəmməl surətini heç vaxt yarada bilməzsiniz. Buna görə ildə bir neçə dəfə planlı şəkildə serverlərin bir hissəsini söndürmək, əlaqələri kəsmək və bərpa sırasını qiymətləndirmək üçün təhlükələr siyahısından digər qəzaları təşkil etmək lazımdır. Məlumat itkisi ilə pik yükdə bir neçə saat ərzində qəfil uğursuzluqdansa, gecənin ortasında 10 dəqiqəlik planlaşdırılmış kəsilmə daha yaxşıdır.
- Qəzanın real aradan qaldırılması. Bəli, bu da testin bir hissəsidir. Təhdidlər siyahısında olmayan qəza baş verərsə, araşdırmanın nəticələrinə əsasən DRP-ni əlavə etmək və yekunlaşdırmaq lazımdır.
Əsas Nöqtələr
- Əgər cəfəngiyat baş verə bilərsə, bu, sadəcə baş verməyəcək, əksinə, ən fəlakətli ssenaridə bunu edəcək.
- İstifadə etmək üçün resurslarınız olduğundan əmin olun.
- Ehtiyat nüsxələriniz olduğundan əmin olun, onlar avtomatik olaraq yaradılır və ardıcıllıq üçün müntəzəm olaraq yoxlanılır.
- Tipik təhlükə ssenarilərini nəzərdən keçirin.
- Mühəndislərə xidmət göstərmək üçün qeyri-standart variantları təklif etmək imkanı verin.
- DRP sadə və axmaq göstərişlər olmalıdır. Bütün kompleks diaqnostika yalnız müştərilər xidməti bərpa etdikdən sonra aparılır. Gözləmə rejimində olsa belə.
- DRP-də əsas telefon nömrələrini və kontaktları sadalayın.
- DRP anlayışı üçün işçiləri mütəmadi olaraq sınayın.
- Məhsulda planlaşdırılan qəzaları təşkil edin. Stendlər hər şeyi əvəz edə bilməz.
Mənbə: www.habr.com