План аварійного відновлення сайту: RTO, RPO і порядок дій

Коли сайт недоступний, команда часто починає з хаотичних дій: перевстановлює плагіни, змінює DNS, відновлює випадкову копію. Це може ускладнити діагностику й перезаписати новіші дані. План аварійного відновлення задає порядок: стабілізувати, оцінити, відновити, перевірити й лише потім повернути трафік.

RTO: скільки часу сервіс може бути недоступним

Recovery Time Objective — цільовий час, за який потрібно повернути критичну функцію. Для сайту-візитки й магазину з оплатою значення різні. Важливо визначати RTO не для абстрактного «сайту», а для функцій: публічна сторінка, форма, кабінет, оплата, API.

Коротший RTO потребує готовішої інфраструктури, доступів, автоматизації й чергування, тому має прямий вплив на вартість підтримки.

RPO: скільки даних допустимо втратити

Recovery Point Objective визначає допустимий проміжок між останньою придатною копією та інцидентом. Якщо замовлення створюються щохвилини, щоденна копія бази не відповідає реальній потребі. Статичний корпоративний сайт може мати інший профіль.

Файли й база змінюються з різною частотою. Їх можна копіювати за окремими графіками, але відновлена версія повинна бути узгодженою.

Інвентар критичних залежностей

• домен, реєстратор і DNS;
• хостинг, сервер, CDN та SSL;
• файли, база, object cache і cron;
• пошта, SMTP, CRM, платіжні та логістичні API;
• ліцензії тем і плагінів;
• аналітика, Tag Manager і Search Console;
• контакти людей, які мають доступ та відповідальність.

Зберігайте інвентар поза WordPress. Якщо єдиний список доступів лежить у недоступній адмінці, він не допоможе під час інциденту.

Резервні копії: незалежність і перевірюваність

Копія на тому самому сервері не захищає від втрати акаунта, диска або шкідливого видалення. Потрібні окремі місця зберігання, контроль доступу, шифрування за потреби та зрозумілий строк утримання.

Факт успішного запуску backup job не доводить, що дані можна відновити. Перевіряйте архів, базу, повноту файлів і реальний запуск у контрольованому середовищі. Документуйте тривалість — вона показує, чи досяжний RTO.

Класифікація інциденту

Перед відновленням визначте тип проблеми:

• мережа або DNS;
• помилка застосунку після зміни;
• пошкодження бази;
• компрометація або шкідливий код;
• втрата зовнішнього API;
• помилка контенту чи конфігурації.

При компрометації просте повернення копії без усунення точки входу відновить і вразливість. Спочатку ізолюють систему й зберігають потрібні журнали.

Runbook: короткий порядок дій

1. Зафіксувати час, симптоми й останні зміни.
2. Призначити координатора й зупинити непогоджені дії.
3. Визначити масштаб і критичні функції.
4. Обрати точку відновлення відповідно до RPO.
5. Відновити в контрольованому середовищі або на резервному ресурсі.
6. Перевірити безпеку, дані, форми, оплату, email та інтеграції.
7. Перемкнути трафік і спостерігати за журналами.
8. Повідомити зацікавлених осіб перевіреними фактами.

DNS і домен

Доступ до реєстратора та DNS не повинен залежати від одного підрядника. У плані зазначають власника акаунта, увімкнену 2FA, контакти й поточні записи. Перед плановим перемиканням TTL можна зменшити, але це не заміна підготовленого резервного середовища.

Перевірка після відновлення

HTTP 200 на головній недостатньо. Перевірте авторизацію, ролі, пошук, форми, вкладення, оплату, webhooks, email, cron, аналітику, sitemap і robots. Порівняйте контрольні дані: кількість останніх замовлень, час останнього запису, цілісність медіа.

Комунікація

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

Postmortem без пошуку винного

Після стабілізації зафіксуйте часову шкалу, кореневу причину, що спрацювало, що затримало відновлення й які конкретні зміни потрібні. Кожна дія має відповідального й критерій перевірки.

Основу копіювання пояснює правило 3-2-1, а постійний контроль — матеріал про моніторинг доступності. Підготувати й перевірити процес можна в межах технічної підтримки сайту.

FAQ

Поширені запитання

Чим RTO відрізняється від RPO?

RTO описує допустимий час відновлення сервісу, а RPO — допустимий обсяг втрати даних, зазвичай виражений у часі між останньою придатною копією та інцидентом.

Чи достатньо щоденної резервної копії?

Залежить від частоти змін і допустимої втрати. Для магазину з постійними замовленнями добова копія може означати неприйнятну втрату даних.

Як часто тестувати відновлення?

Після суттєвих змін інфраструктури та регулярно за графіком. Частота залежить від критичності, але неперевірена копія не дає надійної гарантії.

Чи потрібно зберігати копії поза хостингом?

Так, принаймні одна актуальна копія має бути незалежною від основного акаунта й сервера, щоб збій або компрометація не знищили все одночасно.

Хто повинен запускати аварійний план?

Заздалегідь визначений відповідальний із доступами та правом приймати рішення. Контакти хостингу, домену, розробника й власника мають бути доступні поза сайтом.