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

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

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

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

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