Сообщить об ошибкеКороткий ответ
Нужно детально разобрать таймлайн восстановления по шагам (обнаружение, принятие решения, выполнение технических шагов) и сравнить с тем, что предполагал DR-документ — расхождение почти всегда возникает из-за неучтённых шагов (ручное согласование, недоступность нужного человека, устаревшие учётные данные/права) или из-за того, что документ не тестировался на практике.
Как это работает подробнее
заявленное RTO обычно рассчитывается оптимистично, исходя из "чистого" времени выполнения технических шагов, но реальное восстановление включает также время на обнаружение проблемы (Time to Detect), время на принятие решения об активации DR-плана (часто требует согласования нескольких людей) и неожиданные технические препятствия, которые не встречались при последнем тестировании плана (если оно вообще было).
Пример / кейс
Ожидаемое поведение: после разбора команда должна предоставить дежурному заранее определённые полномочия активировать DR без длительного согласования для чётко описанных сценариев, сокращая фазу Decide, и обновить DR-документ, включив реалистичные оценки всех фаз, а не только Execute.
Пример кода
Разбор инцидента по фазам:
Detect (алерт → подтверждение дежурным): 8 минут
Decide (согласование активации DR с 3 людьми): 47 минут ← основная потеря времени
Execute (технические шаги по runbook): 25 минут
Verify (проверка работоспособности): 10 минут
Итого: 90 минут вместо заявленных 25 минут (только фаза Execute была учтена в документе).Что использовать на практике
- Практический подход. Нужно декомпозировать общее время инцидента на фазы (detect → decide → execute → verify) и для каждой фазы искать, где именно ушло больше времени, чем планировалось; типичные находки — устаревшие секреты/доступы для DR-окружения, отсутствие заранее прописанного права принимать решение об активации DR без долгого согласования, или сам DR-план, рассчитанный на идеальные условия без учёта реальной скорости выполнения вручную.
Подводные камни
- Частые ошибки. Рассчитывать RTO только по времени выполнения скриптов восстановления, не учитывая время на обнаружение и принятие решения; не обновлять DR-документ после изменений в архитектуре (новые зависимости, новые секреты), из-за чего план устаревает незаметно; делегировать решение об активации DR слишком большому числу согласующих, что само по себе съедает значимую часть времени при реальном инциденте.