Disaster recovery drill: що ламається, якщо план не перевіряли
План аварійного відновлення найчастіше існує у вигляді документа: узгоджений, підписаний, лежить у базі знань. Перевіряють його зазвичай частинами — відновили резервну копію, підняли базу, переконалися, що сервіс відповідає. Цілком, із перемиканням трафіку й обходом усіх залежностей, регламент не виконувався жодного разу.
Перше, що розходиться при реальному збої, — порядок запуску. У документі він виглядає лінійним, а в робочому середовищі залежності виявляються взаємними: база не піднімається без сервісу автентифікації, той не стартує без бази. Черговий інженер витрачає дорогоцінний час на розбір того, чого в регламенті просто немає.
Друге — права доступу. Ключі й сервісні облікові записи видавалися під попередній склад команди, частина вже відкликана або прострочена, у того, хто заступив на зміну, немає прав на перемикання. Виявляється це в момент аварії, коли кожна хвилина простою сервісу видна бізнесу й клієнтам.
Учення з аварійного відновлення, або disaster recovery drill, розкривають саме ці розриви: неузгоджений порядок запуску, прострочені доступи, невраховані зв'язки між сервісами.
Після прогону регламент перетворюється з опису намірів на послідовність дій, яку можна виконати під тиском і без підказок.
Нижче розбираємо, як це закривається і що саме перевіряється на ученнях.
Що дає регулярна перевірка плану відновлення
План відновлення, який жодного разу не виконували цілком, — це гіпотеза. Учення перетворюють її на вимірювану величину: проходимо сценарій від сигналу про аварію до повернення сервісу й фіксуємо фактичний RTO та RPO — не той, що записаний у документі, а той, що вийшов на замірі.
Перевірка плану відновлення йде за класами відмов, а не одним «загальним» сценарієм: втрата вузла, відмова цілої зони, логічне пошкодження даних, помилкова дія, недоступність зовнішнього сервісу.
У кожного класу свій поріг допустимого простою і свій набір кроків — відновлення вузла й відкат даних із резервної копії потребують різного часу й різних рішень.
Регулярність важливіша за одноразовий прогін: вона прибирає розкид. Перше учення зазвичай показує, що фактичний час відновлення в рази більший за цільовий — через ручні кроки, очікування доступів, нечіткий розподіл ролей.
До третього-четвертого прогону ці кроки автоматизуються або формалізуються, а план оновлюється після кожного учення — так само влаштована практика безперервності обслуговування в ITIL.
Результат — передбачуване відновлення. Час повернення перестає бути сюрпризом, розкид між прогонами скорочується, залежність від конкретного чергового падає, а вузькі місця видно до аварії, а не під час неї.
Клас відмов, який раніше означав простій на години, проходить за відпрацьованим сценарієм із відомим результатом.
Формати drill-учень: табличний прогін, часткова й повна відмова
Формати різняться двома речами: скільки людей і часу вони забирають і які класи відмов реально розкривають. Табличний прогін іде за документом — команда послідовно проходить кроки, уточнює ролі й точки ухвалення рішень.
Це дешевий спосіб спіймати розходження в плані, застарілі контакти й неоднозначні формулювання, але жодного реального перемикання такий формат не перевіряє.
Часткова відмова піднімає один вузол — резервний контур, репліку, відновлення з копії — і залишає решту системи працювати. Повне перемикання перевіряє ланцюжок цілком: порядок операцій, приховані залежності між сервісами, фактичний час відновлення. Навчальна тривога без попередження додає до цього перевірку чергових і реального часу реакції.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Табличний прогін | Перевірка плану й ролей після змін в архітектурі, регрес документації | Не виявляє помилок конфігурації та недоступності сервісів: усе залишається на папері |
| Часткова відмова | Перевірка окремих вузлів — резервного контуру, відновлення з копії | Суміжні сервіси не задіяні, залежності між ними залишаються непоміченими |
| Повне перемикання | Перед великими змінами й за регламентом: підтвердження цільового часу відновлення | Потребує переведення основного контуру в резерв і високої готовності команди |
| Навчальна тривога без попередження | Перевірка готовності чергових і реального часу реакції | Ризик хибних спрацювань, потрібен вузький периметр і заздалегідь узгоджені межі |
Вибір формату — це вибір ризиків, які ви готові залишити неперевіреними: табличний прогін раз на квартал і повне перемикання раз на рік закривають різні сценарії.
Етапи проведення учень: від аудиту до розбору результатів
Учення без заздалегідь зафіксованого порядку перетворюються на імпровізацію: команда закриває проблеми в тому порядку, у якому їх виявила, а не в тому, який потрібен бізнесу.
Ми розбиваємо етапи учень так, щоб кожен крок закінчувався артефактом — від карти залежностей до перевипущеного регламенту.
- Інвентаризація й аудит інфраструктури. Збираємо фактичну картину: які сервіси працюють, де розміщені, хто власник, які дані зберігають. Розходження з документацією фіксуємо відразу — зазвичай саме вони й ламають відновлення.
- Карта залежностей. Визначаємо, що від чого залежить і в якому порядку піднімати: сховище, черги, інтеграції, доступи. Без цього відновлення йде навмання й упирається в «сервіс піднявся, а дані не віддає».
- Сценарій і критерії успіху. До старту узгоджуємо, що вважаємо провалом: цільовий час відновлення, допустиму втрату даних, зони відповідальності. Тоді сперечатися про результат постфактум не доведеться.
- Перевірка резервних копій. Дивимося не наявність копій, а їхню розгортуваність: відновлення на ізольований контур, звірка цілісності, відкат на попередній зріз. Копія, яка не розгортається, резервом не є.
- Прогін сценарію із замірами. Ведемо хронометраж кожного кроку й журнал дій: хто, що і коли робив. Заміри показують, де реально втрачаються хвилини, а не де, за відчуттями команди, «усе довго».
- Розбір результатів і розходжень. Порівнюємо план із фактом: які кроки не збіглися, які припущення не підтвердилися, де довелося вигадувати обхідні шляхи. Кожне розходження стає задачею з власником.
- Оновлення плану й передача. Перевипускаємо регламент, чек-листи й схему залежностей, призначаємо відповідальних і дату наступних учень. План живе в документації, а не в голові одного інженера.
Після такого циклу план аварійного відновлення перестає бути формальністю: він перевірений на живій інфраструктурі, а ролі в команді розподілені без підказок.
Що замовник отримує на руки після учень
Учення закінчуються не презентацією, а робочим комплектом: за ним чергова зміна піднімає сервіс без дзвінків, листування й пошуку «того, хто пам'ятає».
Усі документи звірені з фактичним станом інфраструктури, тому розходження між схемою й реальністю вже зафіксовано, а не виявлено в момент аварії.
- Схеми інфраструктури й залежностей: топологія сервісів, вузькі місця й точки відмов, порядок обходу при втраті майданчика.
- Конфігурації та резервні копії: що потрапляє в копії, з якою частотою, де вони лежать і як перевіряється цілісність до відновлення.
- Регламент відновлення: покроковий порядок дій із фактичними часами перемикання, а не з розрахунковими.
- Політики доступу: хто і на що має права в аварійному режимі, як видаються розширені права й коли відкликаються.
- Матриця відповідальних і канали оповіщення: хто ухвалює рішення про перемикання, кого піднімати першим і хто підтверджує повернення.
- Звіт про учення: сценарій, хронометраж, частка пройдених кроків і кожне знайдене розходження з причиною.
- План усунення розходжень: пріоритети, відповідальні та строки за кожним пунктом звіту.
Документи лягають у репозиторій поряд із конфігурацією, а не в особисті папки: їх править той самий регламент змін, що й саму інфраструктуру. Дата наступної перевірки призначається відразу — інакше комплект знову застаріє до першої реальної аварії.
Кейс: як учення розкрили неробочий сценарій перемикання
Замовник — сервіс із постійним потоком замовлень і резервним контуром у другій зоні доступності. Регламент відновлення існував понад рік, але цілком не прогонявся: перевіряли лише підняття копій бази на PostgreSQL, до перемикання трафіку справа не доходила.
Учення провели в робочий день, без попередження чергової зміни, з реальним виведенням основного контуру з ладу.
Прогін розкрив розходження між документом і реальною поведінкою системи.
Повернення в роботу зайняло 3 години 40 хвилин замість заявлених 30: півтори години пішли на ручні узгодження, ще сорок хвилин — на очікування репліки, що відстає, стан якої перед перемиканням ніхто не перевіряв.
Крок «перевести трафік» у регламенті стояв після запуску застосунків, тому частина записів пішла в уже вимкнений контур.
Переписали порядок операцій: спочатку дані, потім застосунки, потім трафік.
Перед перемиканням — обов'язкова перевірка відставання репліки з порогом, на якому операція зупиняється; трафік переводиться через керований балансувальник з однією точкою підтвердження замість ланцюжка узгоджень. Ручних кроків стало 6 замість 31, решту закрили скриптами з перевіркою результату.
Метрики до і після:
| Показник | До учень | Після правок |
|---|---|---|
| Повернення в роботу | 3 год 40 хв | 22 хв |
| Ручних кроків | 31 | 6 |
| Втрата записів при перемиканні | частина замовлень | 0 |
| Відкат на вихідний контур | не відпрацьовано | 9 хв |
Усунено клас відмов «перемикання з пам'яті, без перевірки стану репліки»: сценарій проходить цілком на ученнях двічі на рік, а розходження між документом і реальністю закриваються до наступного прогону.
Чим навчальна тривога відрізняється від справжнього перемикання
Навчальна тривога відтворює аварію на окремому контурі: копія бойового оточення, бази піднімаються з резервних копій, перевіряється порядок запуску сервісів і те, як чергова зміна проходить інструкцію з відновлення.
Це дає чесні межі перевірки — цілісність копій, час накату, повноту документації, наявність доступів у зміни. Усе, що ламається на цьому етапі, ламається без ризику простою для клієнтів, тому такі знахідки найдешевші.
За межами навчального режиму залишається те, що стенд принципово не відтворює: реальний профіль навантаження, поведінка зовнішніх інтеграцій, стан кешів і черг, розходження між версією схеми даних і кодом застосунку.
Тому успішні учення не гарантують, що реальне перемикання пройде так само гладко — вони лише прибирають керовані причини збоїв.
Фактичні цифри дає тільки бойове перемикання: скільки насправді триває недоступність, як швидко оновлюються зовнішні адреси, скільки клієнтів залишається на старому контурі, що відбувається з незавершеними операціями й відкритими сесіями.
Навчальна тривога показує оцінку знизу — яка частина часу залежить від команди, але не закриває ризики, які створює живий трафік.
Звідси й розподіл цілей: тривога перевіряє готовність людей і артефактів, планове перемикання — готовність системи й узгодженість даних між контурами.
Учення проводимо регулярно, з ротацією чергових і розбором кожного розходження з інструкцією, а перемикання — в узгоджене вікно, з порядком повернення й заздалегідь описаними критеріями відкату.
Якщо учення жодного разу не розкрили крок, що відмовив, або забутий доступ, вони надто м'які для аварійного сценарію.
Технічні сумніви перед першими ученнями
Перед першими ученнями ставлять одні й ті самі запитання: чи встоїть сервіс, як часто це повторювати, чи потрібно перевіряти всі системи відразу і скількох людей відволікати від роботи. Нижче — короткі відповіді, які зазвичай знімають сумніви до старту.
Чи доведеться зупиняти сервіс на час перевірки?
Ні. Копії розгортаються в ізольований контур, мережа якого не перетинається з робочою, а користувацький трафік продовжує йти на основний. Узгоджений знімок даних робиться штатним механізмом — наприклад, у PostgreSQL та аналогах він не потребує зупинки запису. Планується заздалегідь лише вікно читання з основного сховища.
Як часто повторювати учення?
Критичні сервіси — раз на квартал, решта — раз на півроку. Позаплановий прогін запускаємо після зміни схеми резервного копіювання, великого релізу або правок у топології.
Частота важливіша за глибину: коротка перевірка раз на квартал корисніша за один довгий прогін раз на рік, бо навичка в команди вивітрюється.
Чи можна почати з частини систем?
Так, зазвичай так і починають: беремо два-три критичні шляхи — авторизація, платежі, обробка черги — і перевіряємо відновлення лише за ними. Охоплення розширюється в міру усунення знахідок, тому учення не перетворюються на багатомісячний проєкт.
Скільки людей потрібно з боку замовника?
Двоє-троє: власник сервісу, черговий інженер і той, хто має доступи до сховищ і панелей управління. Їхня роль — підтвердити доступи, звірити очікування щодо цільового часу відновлення й оцінити результат. Решту роботи беремо на себе.
Обговоримо задачу: з чого почнемо і що підготуємо
Учення починаються не із запуску сценарію, а з інвентаризації: які сервіси вважаємо критичними, де проходять межі між ними, хто відповідає за перемикання і в яке вікно допустимо вронити контур.
Від цих вступних залежить, які сценарії відмов має сенс перевіряти і який рівень ізоляції стенда потрібен, щоб учення не зачепили продакшн.
З цими даними ми повертаємося з оцінкою строків, складом робіт і планом впровадження — за етапами, з точками, де замовник приймає результат. Щоб стартувати, достатньо наступного.
- Перелік сервісів і те, який із них вважається критичним, а який може зачекати до ранку.
- Цільові показники відновлення: за який час контур має підніматися і який обсяг даних допустимо втратити.
- Схема інфраструктури й залежностей — навіть начерк або застаріла версія, розходження ми все одно знайдемо й винесемо у звіт.
- Відповідальні за сервіси й порядок узгодження робіт у вікні учень.
- Обмеження: періоди, коли зупиняти не можна, вимоги регуляторів і внутрішні регламенти.
- Доступи для розгортання ізольованого стенда — або підтвердження, що стенд виділяємо ми.
- Наявні регламенти й чек-листи з відновлення, якщо вони вже є в будь-якому вигляді.
Далі ми фіксуємо сценарії, проганяємо їх на стенді, заміряємо фактичний час відновлення й розходження з цільовими показниками, і передаємо звіт із таймінгами за кожним кроком і списком вузьких місць. Опишіть задачу — повернемося з оцінкою та планом робіт.
