Нават падчас катастрофы заўсёды ёсць час на кубак гарбаты.
DRP (disaster recovery plan) - гэта штука, якая ў ідэале ніколі не спатрэбіцца. Але калі раптам якія мігруюць у шлюбны перыяд бабры перагрызуць магістральнае оптавалакно ці джуніёр-адмін дропне прадуктыўную базу, вы сапраўды жадаеце быць упэўненыя, што ў вас будзе загадзя складзены план, што з гэтым усім бязладдзем рабіць.
Пакуль кліенты ў паніцы пачынаюць абрываць тэлефоны тэхпадтрымкі, джуніёр шукае цыяніды, вы з мудрым выглядам выкрываеце чырвоны канверт і пачынаеце прыводзіць усё ў парадак.
У гэтым пасце я хачу падзяліцца рэкамендацыямі, як трэба пісаць DRP і што ён павінен змяшчаць. А яшчэ мы разгледзім наступныя штукі:
- Навучымся думаць як злыдзень.
- Разбяром карысць кубка гарбаты падчас апакаліпсісу.
- Прадумаем зручную структуру DRP
- Паглядзім, як трэба яго тэсціраваць
Для якіх кампаній гэта можа быць карысна
Вельмі складана правесці мяжу, калі IT-падраздзяленне пачынае мець патрэбу ў падобных рэчах. Я б сказаў, што DRP вам гарантавана трэба, калі:
- Прыпынак сервера, прыкладанні або страта нейкай базы прывядзе да значных страт бізнесу ў цэлым.
- У вас ёсць паўнавартасны IT-аддзел. У сэнсе аддзел у выглядзе паўнавартаснай адзінкі кампаніі, са сваім бюджэтам, а не проста некалькі стомленых супрацоўнікаў, якія пракладаюць сетку, якія чысцяць вірусы і запраўляюць прынтэры.
- У вас ёсць рэальны бюджэт хаця б на частковае рэзерваванне ў выпадку аварыйнай сітуацыі.
Калі IT-аддзел месяцамі выпрошвае хаця б пару HDD у старэнькі сервер для бэкапаў, у вас ці наўрад атрымаецца арганізаваць паўнавартасны пераезд які ўпаў сэрвісу на рэзервовыя магутнасці. Хаця і тут дакументацыя лішняй не будзе.
Дакументацыя важна
Пачніце з дакументацыі. Дапушчальны, што ваш сэрвіс працуе на базе скрыпту на Perl, які быў напісаны тры пакаленні адмінаў назад, а як ён працуе, ніхто не ведае. Назапашаны тэхнічны абавязак і адсутнасць дакументацыі непазбежна вам прастрэліць не толькі калена, але і іншыя канечнасці, гэта хутчэй пытанне часу.
Пасля таго, як у вас на руках ёсць добрае апісанне кампанентаў сэрвісу, падніміце статыстыку па аварыях. Амаль напэўна яны будуць зусім тыпавыя. Напрыклад, у вас часам перапаўняецца дыск, што прыводзіць да адмовы ноды да яе ручной ачысткі. Або становіцца недаступны кліенцкі сэрвіс з-за таго, што нехта зноў забыўся падоўжыць сертыфікат, а Let's Encrypt наладзіць не змог ці не захацеў.
Думкі як дыверсант
Самая складаная частка знаходзіцца ў прагназаванні тых аварый, якіх яшчэ ні разу не было, але якія патэнцыйна могуць абкласці ваш сэрвіс поўнасцю. Тут мы звычайна з калегамі гуляем у зладзеяў. Бераце шмат кавы і чаго-небудзь смачнага і замыкаецеся ў перагаворцы. Толькі пераканайцеся, што ў гэтай жа перагаворцы вы замкнулі тых інжынераў, якія самі паднімалі мэтавы сэрвіс або рэгулярна з ім працуюць. Далей або на дошцы, або на паперы пачынаеце маляваць усе магчымыя жахі, якія могуць адбыцца з вашым сэрвісам. Не абавязкова дэталізаваць аж да канкрэтнай прыбіральшчыцы і вышморгванне кабеляў, дастаткова разгледзець сцэнар «Парушэнні цэласнасці лакальнай сеткі».
Звычайна, большасць тыпавых аварыйных сітуацый укладваецца ў наступныя віды:
- Адмова сеткі
- Адмова сэрвісаў АС
- Адмова прыкладання
- Адмова жалеза
- Адмова віртуалізацыі
Проста ідзяце па кожным выглядзе і глядзіце, што дастасавальна да вашага сэрвісу. Напрыклад, можа зваліцца і не падняцца дэман Nginx - гэта да адмоваў з боку АС. Рэдкая сітуацыя, якая заганяе ваша вэб-прыкладанне ў непрацоўны стан - адмова ПЗ. У час прапрацоўкі гэтага этапа важна прапрацаваць дыягностыку праблемы. Як адрозніць які завіс інтэрфейс на віртуалізацыі ад якая ўпала цыскі і аварыі на сеткі, напрыклад. Гэта важна, каб хутка знайсці адказных і пачаць тузаць іх за хвост, пакуль аварыя не будзе ўхіленая.
Пасля таго, як тыпавыя праблемы запісаны, наліваем яшчэ каву і пачынаем разглядаць самыя дзіўныя сцэнары, калі нейкія параметры пачынаюць моцна выходзіць за межы нормы. Напрыклад:
- Што здарыцца, калі час на актыўнай нодзе ссунецца на хвіліну назад адносна іншых у кластары?
- А калі час наперад ссунецца, а калі на 10 гадоў?
- Што адбудзецца, калі падчас сінхранізацыі нода кластара раптоўна страціць сетку?
- А што будзе, калі дзве ноды не падзеляць лідэрства з-за часовай ізаляцыі адзін аднаго па сетцы?
На гэтым этапе вельмі дапамагае падыход ад адваротнага. Бераце самага зацятага чальца каманды з хворай фантазіяй і даяце яму задачу ў найкароткія тэрміны задаволіць дыверсію, якая пакладзе сэрвіс. Калі яе будзе складана дыягнаставаць - яшчэ лепш. Не паверыце, якія дзіўныя і крутыя ідэі выказваюць інжынеры, калі даць ім ідэю што-небудзь зламаць. А ўжо калі паабяцаць ім для гэтага тэставы стэнд - зусім добра.
Што такое гэты ваш DRP?!
Дык вось, вы вызначылі мадэль пагроз. Улічылі і мясцовых жыхароў, якія рэжуць оптавалакновыя кабелі ў пошуках медзі, і ваенны радар, які губляе радыёрэлейную лінію строга па пятніцах у 16:46. Цяпер трэба зразумець, што з гэтым усім рабіць.
Ваша задача напісаць тыя самыя чырвоныя канверты, якія будуць выкрывацца ў аварыйнай сітуацыі. Адразу разлічвайце, што калі (не калі!) усё навернецца, побач апынецца толькі самы неспрактыкаваны стажор, у якога будуць моцна трэсціся рукі ад жаху адбывалага. Паглядзіце, як рэалізаваны аварыйныя таблічкі ў медыцынскіх кабінетах. Напрыклад, што рабіць пры анафілактычным шоку. Медыцынскі персанал на памяць ведае ўсе пратаколы, але калі побач чалавек пачынае паміраць, вельмі часта ўсё бездапаможна хапаюцца за ўсё запар. Для гэтага на сцяне вісіць выразная інструкцыя з пунктамі выгляду "адкрыць пакаванне таго-то" і "увесці нутравенна гэтулькі-то адзінак прэпарата".
У аварыйнай сітуацыі думаць складана! Павінны быць простыя інструкцыі для парсінгу спінным мозгам.
Добры DRP складаецца з некалькіх простых блокаў:
- Каго апавясціць аб пачатку аварыі. Гэта важна для таго, каб максімальна распаралеліць працэс ухілення.
- Як правільна дыягнаставаць - выконваем трасіроўку, глядзім у systemctl status servicename і гэтак далей.
- Колькі можна патраціць час на кожны этап. Калі не паспяваеце паправіць рукамі за час SLA - віртуальная машына забіваецца і накатваецца з учорашняга бэкапу.
- Як упэўніцца, што аварыя завершана.
Памятайце, што DRP пачынаецца тады, калі сэрвіс цалкам адмовіў і завяршаецца адноўленым працаздольнасці, нават са зніжанай эфектыўнасцю. Проста страта рэзервавання не павінна актываваць DRP. А яшчэ можаце прапісаць у DRP кубак гарбаты. Сур'ёзна. Па статыстыцы, вельмі шматлікія аварыі з непрыемных становяцца катастрафічнымі з-за таго, што персанал у паніцы кідаецца нешта чыніць, адначасна забіваючы адзіную жывую ноду з дадзенымі ці канчаткова дабіваючы кластар. Як правіла 5 хвілін на кубак гарбаты дадуць вам крыху часу супакоіцца і прааналізаваць тое, што адбываецца.
Не трэба блытаць DRP і пашпарт сістэмы! Не перагружайце яго залішнімі дадзенымі. Проста дайце магчымасць хутка і зручна па гіперспасылках перайсці ў патрэбны раздзел дакументацыі і пачытаць у пашыраным фармаце аб патрэбных участках архітэктуры сэрвісу. А ў самым DRP толькі прамыя ўказанні куды і як падлучацца з пэўнымі камандамі для капіпасты.
Як правільна тэсціраваць
Пераканайцеся, што любы адказны супрацоўнік можа выканаць усе пункты. У самы адказны момант можа апынуцца, што ў інжынера няма правоў на доступ у патрэбную сістэму, адсутнічаюць паролі ад патрэбнага ўліку ці ён паняцця не мае, што значыць "Падлучыцеся да кансолі кіравання сэрвісам праз проксі ў галаўным офісе". Кожны пункт павінен быць вельмі просты.
няправільна - «Зайдзіце на віртуалізацыю і рэбутніце мёртвую ноду»
Правільна - "Падлучыцеся праз вэб-інтэрфейс да virt.example.com, у раздзеле ноды выканайце перазагрузку ноды, якая выклікае памылку".
Не дапушчайце двухсэнсоўнасцяў. Памятайце пра спалоханага стажора.
Абавязкова тэсціруйце DRP. Гэта не проста план для галачкі - гэта тое, што дазволіць вам і вашым кліентам хутка выйсці з крытычнай сітуацыі. Аптымальна зрабіць гэта некалькі разоў:
- Адзін эксперт і некалькі стажораў працуюць на тэставым стэндзе, які максімальна імітуе рэальны сервіс. Эксперт ламае сэрвіс рознымі спосабамі і дае магчымасць стажорам аднавіць яго паводле DRP. Усе праблемы, невыразнасці ў дакументацыі і памылкі запісваюцца. Пасля навучання стажораў, DRP дапаўняецца і спрашчаецца ў незразумелых месцах.
- Тэставанне на рэальным сэрвісе. Насамрэч ніколі нельга стварыць ідэальную копію сапраўднага сэрвісу. Таму, пару разоў у год неабходна планава выключаць частку сервераў, ірваць канекты і ўладкоўваць іншыя аварыі са спісу пагроз, каб ацаніць парадак узнаўлення. Лепш планавая аварыя на 10 хвілін пасярод ночы, чым раптоўная адмова на некалькі гадзін у пік нагрузкі са стратай дадзеных.
- Рэальнае ўхіленне аварыі. Так, гэта таксама частка тэсціравання. Калі здараецца аварыя, якой не было ў спісе пагроз, неабходна дапоўніць і дапрацаваць DRP па выніках яе расследавання.
Ключавыя пункты
- Калі бздура можа здарыцца, яна не проста здарыцца, але і зробіць гэта па максімальна катастрафічнаму сцэнару.
- Упэўніцеся, што ў вас ёсць рэсурсы для аварыйнага перакіду нагрузкі.
- Пераканайцеся, што ў вас ёсць бэкапы, яны аўтаматычна ствараюцца і рэгулярна правяраюцца на кансістэнтнасць.
- Прадумайце тыпавыя сцэнары пагроз.
- Дайце магчымасць інжынерам прыдумаць нетыпавыя варыянты пакласці сэрвіс.
- DRP павінен быць простай і тупой інструкцыяй. Уся складаная дыягностыка толькі пасля таго, як у кліентаў аднавіўся сервіс. Няхай нават на рэзервовых магутнасцях.
- Укажыце ключавыя тэлефоны і кантакты ў DRP.
- Рэгулярна тэсціруйце супрацоўнікаў на разуменне DRP.
- Уладкоўвайце планавыя аварыі на прадуктыве. Стэнды не могуць замяніць усё.
Крыніца: habr.com