Навіть під час катастрофи завжди є час на чашку чаю
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