Как замерить реальное время восстановления и перестать врать себе про RTO

MAATRIX

В большинстве DR-планов написано «RTO — 30 минут» или «RTO — 1 час», и эта цифра почти никогда не подтверждена ничем, кроме здравого смысла того, кто её написал. Команда искренне верит в неё, пока не случается реальный инцидент — и тогда выясняется, что от первого алерта до момента, когда сервис снова принимает трафик, прошло не 30 минут, а три с половиной часа, и добрая половина этого времени ушла на то, чтобы вообще понять, что сломалось. Ниже — как замерить настоящий RTO, а не тот, что звучит правдоподобно на бумаге.

Заявленный RTO и реальный RTO — это разные числа

Заявленный RTO почти всегда получается расчётным путём: кто-то складывает время выполнения известных команд — «restore бэкапа занимает 15 минут, поднять контейнеры — 5 минут, итого 20 минут, округлим до 30 для запаса». Это число описывает только техническую часть работы, выполненную человеком, который точно знает, что сломалось, где лежит бэкап нужной версии и какую команду набирать не задумываясь. Такой сценарий на практике не встречается почти никогда.

Достижимый RTO — это не расчёт, а измеренная величина. Его можно получить только одним способом: реально запустить восстановление, включить секундомер в момент появления первого симптома (не в момент, когда причина уже известна) и остановить его, когда сервис действительно снова работает под нагрузкой — а не когда последняя команда в терминале вернула 0. Разница между этими двумя числами обычно не в процентах, а в разах, и главная причина разрыва — не техническая скорость команд, а всё, что происходит до и вокруг них: диагностика, согласования, поиск нужного человека, неточная документация.

Полезно сразу развести формулировки, чтобы не путать RTO с соседним показателем — сколько данных вы готовы потерять (RPO) вместо того, сколько времени займёт возврат в строй. Про экономику этой разницы и то, как RTO влияет на выбор схемы хранения бэкапов, подробнее в статье «Цена восстановления: считаем не хранение бэкапа, а время возврата в строй».

Из чего на самом деле складывается время восстановления

Полное время инцидента — это не одна фаза «восстановление», а цепочка из нескольких, и в заявленный RTO обычно попадает только одна из них:

Полное время инцидента =
    Время до обнаружения (алерт сработал / человек заметил)
  + Время диагностики (что именно сломалось и почему)
  + Время принятия решения (какой сценарий восстановления запускать)
  + Техническое восстановление (собственно команды и скрипты)
  + Проверка и подтверждение (сервис действительно работает под нагрузкой)
  + Возврат трафика (DNS, балансировщик, снятие maintenance-режима)

Когда в DR-документе пишут «RTO — 30 минут», почти всегда имеют в виду только четвёртый пункт — техническое восстановление, причём в лучшем случае, когда причина уже известна заранее. Остальные пять пунктов существуют в реальности при каждом инциденте, но в бумажной оценке их либо нет вообще, либо они учтены с большим оптимизмом («диагностика — 5 минут, и так всё ясно»).

Честный замер измеряет всю цепочку целиком, от первого симптома до подтверждённого возврата в строй под реальной нагрузкой — а не от момента «мы поняли, в чём проблема» до конца команды restore. Это принципиальная разница в методологии: не «сколько времени займёт восстановление, если мы уже знаем что делать», а «сколько времени пройдёт от первого гудка будильника до момента, когда всё снова работает».

Как провести честный замер: пошаговая методика

Замер, которому можно доверять, строится на нескольких принципах.

1. Секундомер стартует в момент симптома, а не в момент диагноза. Если вы тренируете сценарий «упал диск», не начинайте отсчёт с фразы «представим, что мы уже знаем — диск умер». Начните с того, что реально увидит дежурный: алерт мониторинга, жалоба пользователя, 5xx в логах. Именно этот момент — точка отсчёта T0.

2. Исполнитель не должен знать сценарий заранее в деталях. Если человек, который тушит «условный» пожар, заранее в курсе, что именно сломано, замер меряет не RTO, а скорость набора команд из головы. Насколько это реалистично сделать в вашей команде — зависит от размера и культуры, но минимум — не давать исполнителю открытый runbook с точным диагнозом за секунду до старта.

3. Фиксируйте промежуточные тайминги, а не только итог. Одна итоговая цифра «восстановились за 2 часа 40 минут» бесполезна для анализа — вы не поймёте, где терялось время. Ведите лог по фазам прямо во время учений:

T0  09:02:00  Алерт: 5xx spike на API, sentry + uptime-kuma
T1  09:04:15  Дежурный увидел алерт, начал смотреть дашборд
T2  09:19:40  Гипотеза №1 (диск) отвергнута, найдена реальная причина — миграция БД
T3  09:24:10  Решение принято: откат к бэкапу перед миграцией
T4  09:26:00  Старт restore из бэкапа
T5  09:41:30  Restore завершён, база поднята
T6  09:47:00  Приложение запущено, health-check зелёный
T7  09:52:45  Проверка под реальным трафиком, ошибок нет — инцидент закрыт

Такой лог проще всего вести командой date '+%H:%M:%S' перед каждым значимым шагом или обернуть сессию через script -q -c "bash" timing.log, чтобы восстановить хронологию по таймстампам в выводе. Один человек в команде должен быть выделен на роль хронометриста и не участвовать в самом восстановлении — тогда тайминги не теряются в суете.

4. Проверяйте не «команда отработала», а «сервис реально работает». Часто в учениях восстановление считается завершённым, когда контейнер поднялся и отдаёт 200 на /health. В реальности это не то же самое, что сервис готов принимать продакшен-трафик: прогрев кэша, подключение воркеров к очереди, актуальность конфигурации — всё это может занять ещё заметное время после того, как формальный health-check уже позеленел.

5. Повторяйте замер с разными исполнителями. Один прогон учений одним и тем же опытным инженером даёт оптимистичную нижнюю границу. Настоящая ценность появляется, когда сценарий проходит второй и третий человек в команде — обычно именно на втором прогоне всплывают шаги, которые «все и так знают», но нигде не записаны.

Готовый почасовой сценарий для такой репетиции, который можно взять и провести с командой без импровизации на ходу, разобран в статье «Репетиция восстановления: сценарий учений на час».

Диагностика съедает половину времени — и её обычно не считают

Самая недооценённая фаза во всей цепочке — не техническое восстановление, а диагностика: понять, что именно сломалось, до того как запускать какой-либо сценарий. В бумажном RTO эта фаза либо отсутствует, либо сведена к одной строке «выявляем причину — 5 минут», потому что автор плана мысленно уже знает ответ.

В реальном инциденте дежурный видит симптом, а не причину. Алерт «5xx spike на API» может означать что угодно: упал диск, закончилось место, легла миграция БД, кончились коннекшены к базе, деплой унёс с собой конфиг, зависла очередь задач, или причина вовсе внешняя — упал апстрим-провайдер. Первые минуты, а иногда и десятки минут, уходят на то, чтобы отсечь неверные гипотезы одну за другой: посмотреть логи, проверить метрики диска и памяти, свериться с историей деплоев.

Здесь стоит замерять отдельную подметрику — время до первой верной гипотезы (в примере выше это T0→T2, около 17 минут). Она отделяется от времени технического восстановления и часто оказывается сравнима с ним по длительности или даже больше. Разрыв между заявленным и достижимым RTO почти всегда концентрируется именно здесь, а не в скорости выполнения restore.

Что реально сокращает время диагностики, по опыту команд, которые ведут такие замеры регулярно:

• Дашборд с корреляцией событий. Если время последнего деплоя, последней миграции БД и графики нагрузки видны на одном экране, гипотезы отсекаются быстрее, чем при ручном сопоставлении логов из разных систем.
• Чёткое разделение «известная причина» / «неизвестная причина» в runbook. Отдельный короткий чек-лист именно для фазы диагностики — куда смотреть в первую очередь и в каком порядке — экономит минуты на каждом шаге, если он реально используется, а не просто существует в вики.
• Разбор инцидентов постфактум с фиксацией именно этой фазы. Если в постмортеме диагностика описана одной строкой «нашли причину», в следующий раз команда снова потеряет то же время на те же грабли. Как вести разбор так, чтобы из него реально учились, а не просто закрывали тикет — в статье «Как писать разбор инцидента, чтобы из него учились».

Типичный разрыв между бумагой и реальностью

По опыту команд, которые проводили честные замеры вместо расчётов на бумаге, разрыв почти никогда не бывает нулевым и чаще всего он не в проценты, а в разы. Ниже — иллюстрация того, как обычно распределяется разрыв по фазам (это ориентир, а не универсальный бенчмарк — у вас цифры будут другими и зависят от масштаба системы и зрелости процессов):

Главный практический вывод не в конкретных цифрах, а в самом факте: если вы ни разу не гоняли полный сценарий с секундомером от первого симптома до подтверждённой работы под нагрузкой, ваш заявленный RTO — это гипотеза, а не факт. И бизнес, который строит SLA или внутренние ожидания на этой гипотезе, рискует не техническим провалом, а репутационным и финансовым — узнав правду о собственном RTO в момент, когда это уже дорого стоит. Про то, во что превращается час незапланированного простоя для бизнеса — в статье «Час простоя SaaS: прямые потери, отток и штрафы по SLA».

Что делать с разрывом: ускорять или менять ожидания

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

Вариант 1: сократить реальное время. Это работает, когда разрыв концентрируется в фазах, которые поддаются автоматизации и подготовке:

• Перенести решения из фазы «согласование во время инцидента» в фазу «заранее прописанный и утверждённый playbook» — часть решений (какой бэкап поднимать, кто имеет право запустить restore без ожидания менеджера) можно принять один раз заранее, а не каждый раз заново под давлением.
• Автоматизировать технический этап восстановления скриптом или IaC-конфигурацией вместо ручных команд по памяти — это не убирает диагностику, но заметно сокращает четвёртую фазу и убирает риск опечатки в стрессовой ситуации.
• Держать заранее готовый и протестированный сервер под восстановление — арендованный заранее, а не выбираемый и настраиваемый в момент инцидента, чтобы не тратить время на конфигурацию тарифа поверх и без того горящей задачи.
• Улучшить наблюдаемость именно под задачу диагностики: единый дашборд с деплоями, миграциями и метриками рядом — самое дешёвое вложение относительно того, сколько времени оно экономит на фазе «понять, что сломалось».

Вариант 2: честно пересмотреть ожидания бизнеса. Иногда разрыв связан не с тем, что процесс плохой, а с тем, что заявленная цифра изначально была нереалистичной для сложности системы — и это нормально признать, если инвестиции в дальнейшее ускорение стоят дороже, чем реальная цена лишнего часа простоя. В этом случае задача — не тратить деньги на закрытие разрыва любой ценой, а пересчитать SLA, договор с клиентами или внутренние ожидания под измеренное число, а не под красивое.

Практический критерий выбора простой: сравните стоимость закрытия разрыва (время инженеров на автоматизацию, стоимость горячего резерва, подготовленного сервера) со стоимостью самого разрыва (цена лишних часов простоя, штрафы по SLA, репутационные потери). Если сокращение RTO на час стоит дороже, чем сам этот час обходится бизнесу за обозримое число инцидентов в год — рациональнее пересмотреть цифру в договоре, а не героически бороться за недостижимую метрику. Удобно не делать это разовым мероприятием, а привязать повторный замер RTO к плановому регламенту обслуживания наравне с другими регулярными задачами — так он не забудется под текучкой.

Оба варианта требуют одного и того же исходного условия — честного числа на руках. Без него любое решение (инвестировать в автоматизацию или менять договор) принимается вслепую.

Частые вопросы