Налаштувала зберігання резервних копій бази даних як infrastructure‑as‑code, провела аудит готовності до відновлення й задокументувала процедуру відновлення — назвавши залишкові прогалини, а не залишивши їх на час інциденту.

Ситуація. Продукт, що живе на своїх даних, не може дозволити собі втратити хоч якісь, а «десь є бекапи» — це сподівання, а не план відновлення. Єдиний бекап, який чогось вартий, — це той, про який відомо, що він відновлюється, у середовище, яке відомо, що можна відбудувати. У продукті не було записано жодної з цих двох половин.

Завдання. Визначити реальну готовність до відновлення замість того, щоб її припускати, — дані, середовище навколо них і чесний опис того, наскільки далеко це сягає сьогодні.

Дія. Retention резервних копій налаштовано в Bicep поруч із базою даних, яку він захищає, тож відновлення на конкретний момент часу є властивістю шаблону, а не налаштуванням, яке колись хтось клікнув у порталі. Середовище навколо неї теж описане як infrastructure‑as‑code, а це та тиха половина, про яку люди забувають: відновити базу даних у середовище, яке довелося б відбудовувати вручну по пам’яті, — це не справжнє відновлення. Далі готовність проаудитували й описали — процедуру відновлення, навчання, яке її виміряло б, і прогалини, що досі відкриті: геонадлишковість вимкнено, а цільовий час відновлення запропоновано, а не виміряно, бо навчання ще не проводили.

Результат. Відновлення перестало бути туманною заспокійливою фразою й стало задокументованою позицією з названими прогалинами. Це звучить менш ефектно, ніж «аварійне відновлення: зроблено», і коштує значно більше — той, хто візьметься за це наступним, знає, що покрито, що ні і яке саме навчання закриває різницю. Названу прогалину можна закрити; неназвану знаходять під час інциденту.