Аварійне відновлення: перевірка RTO та RPO

·3 хв читання

План відновлення правдоподібний, коли можна повернути придатний до роботи сервіс.

Дві серверні вежі з перерваним шляхом і безперервним маршрутом відновлення.

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

Визначте, що має повернутися

Перелічіть маршрути, бази, ідентичність, DNS, сертифікати й залежності. Установіть допустимий обмежений режим та аварійний доступ за недоступності звичайних систем. Цілі бази недостатньо, якщо застосунок потім не може під’єднатися.

Підготуйте ізольоване навчання

Використовуйте дозволені захищені чи синтетичні дані та блокуйте ненавмисні справжні повідомлення, платежі й виклики. Запишіть точку копії, початок та етапи. Оберіть явний сценарій, наприклад втрату бази, і припущення. Вимірюйте до бізнес-перевірки, а не лише завершення імпорту.

Доведіть реальні втрату й час

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

Приклад і доказ приймання

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

Часті запитання

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

Часом відновлення проти допустимої втрати даних.

Чи правильна копія доводить відновлення?

Ні. Відновлення, залежності й перевірка також мають працювати.

Чи можна брати реальні дані?

Лише з дозволом і захистом; синтетичні можуть бути доречнішими.

Як часто перевіряти?

За ризиком і змінами, особливо після істотної зміни архітектури.

Що робити за недосягнення цілі?

Запишіть результат і причину та явно змініть систему або вимогу.

Від задуму до реалістичного обсягу робіт

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

Переглянути склад послуги →

Читати далі за темою

Операційна інструкція для невеликої команди

Runbook допомагає перейти від конкретного симптому до безпечного рішення.

Чергування у стартапі без окремої SRE-команди

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

Рівні серйозності інцидентів: матриця ескалації

Серйозність описує реальний або правдоподібний бізнес-вплив, а не драматичність повідомлення.