Проверьте план восстановления бизнеса до того, как случится сбой

План восстановления полезен, только если люди могут выполнить его в правильном порядке и теми ресурсами, что есть. Список экстренных контактов и солидное название документа не говорят, сколько времени бизнесу на самом деле нужно, чтобы возобновить критичную работу. В примере ниже план, который на бумаге занимает 80 минут, на учениях требует 90 минут, не укладывается в цель 60 минут на 30 минут, а сам простой обходится в 530 $ — или в 130 $ плюс 40 отложенных заказов, в зависимости от того, что сделают клиенты.

Начните с одного определённого сценария

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

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

Без записанных границ оценки расползаются: один останавливает часы, когда заработала первая касса, другой — когда синхронизировался последний заказ.

Сделайте зависимости явными

Шаги восстановления редко идут простым списком. Одни можно делать параллельно, другие можно начать, только когда закончено что-то ещё. Если сначала нужно вернуть доступ, проверка системы не может начаться в нулевую минуту.

Возьмём вымышленный магазин товаров для дома из демо — восемь сотрудников, одна точка:

Раннее начало каждого шага — это самое позднее раннее окончание его предварительных условий; раннее окончание — начало плюс длительность:

• A: 0 → 30
• B: 30 → 50
• C: 30 → 70
• D: 70 → 80 (ждёт C, более длинную ветку)

Плановое восстановление — самое позднее окончание среди критических действий: 80 минут. Определяет его цепочка A → C → D. Ускорение B ничего не изменит, ускорение C — изменит.

Цель восстановления — это цель

RTO магазина — 60 минут. План требует 80, отставание — 20 минут. Это число полезно своей конкретностью: проблема на цепочке A → C → D, а не «план надо бы ускорить».

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

Проверьте общие ресурсы

Второе допущение ломается удивительно часто. В магазине шаги B и C выполняет ответственный за IT — один и тот же человек. План выше ставит оба шага между 30-й и 50-й минутой. Хороший инструмент планирования не должен молча «исправлять» это перестановкой шагов; он должен предупредить, что один ресурс занят дважды, и оставить решение вам.

Если оба шага действительно делает один человек, добавьте условие, чтобы они шли друг за другом, — и оценка вырастет. Если шаг B может взять кто-то другой, укажите его роль. В любом случае решение видно, а не спрятано в «оптимальном» графике.

Для среднего бизнеса это ещё важнее. Во втором демо у дистрибьютора три филиала и шесть подразделений и одна центральная IT-команда. План каждого филиала по отдельности выглядит разумно, но подключение касс шоурума, сканеров склада у аэропорта и выгрузка для зарплаты запланированы на одни и те же полчаса — три предупреждения о пересечении на одну команду. Центральный ресурс может стать узким местом, даже когда у каждой площадки план выглядит нормально.

Запишите учения — и честно

План становится доказательством, только когда кто-то его выполнил. Магазин провёл учения до открытия и записал, когда каждый шаг начался и закончился:

Шаг C занял 50 минут вместо 40 — ответственный за IT ещё настраивал резервный картридер. Раз D зависит от C, задержка переходит дальше. Записанное восстановление — 90 минут, а не 80, и оно не укладывается в RTO 60 минут на 30 минут.

Три правила делают запись учений надёжной:

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

Те же учения проверяют резервную копию. Последняя успешная копия сделана в 06:30, учения начались в 08:00. Копии было 90 минут при RPO 60 минут — на 30 минут больше. Обратите внимание, что именно это проверяет: возраст одной копии против вашей цели. Это не доказывает, что копию можно восстановить или что данные полны. Это покажет только проверка восстановления.

Отличайте прошедшие часы от рабочих

Теперь оценим последствия. Здесь двое часов:

• Прошедшие часы простоя — все часы от начала сбоя до восстановления.
• Часы простоя в рабочее время — только часы, когда точка была бы открыта.

Для денежного расчёта магазин использует отдельный финансовый вариант: простой 240 минут с 10:00 во вторник. Магазин работает с 09:00 до 19:00, поэтому все четыре часа рабочие. Держите этот вариант отдельно от 80-минутной оценки плана и 90 минут учений: они отвечают на разные вопросы и не должны выдаваться за один реальный инцидент.

Магазин вводит свои цифры:

• маржинальный доход за час работы (выручка минус переменные затраты): 100 $
• дополнительные затраты за час простоя (например, ожидающий персонал): 20 $
• фиксированные затраты на инцидент: 50 $

Маржинальный доход уже за вычетом переменных затрат, поэтому постоянные расходы к потере повторно не прибавляются.

Спрос потерян или отложен — не одновременно

Если продажи пропадают, потерянный доход — 4 рабочих часа × 100 $ = 400 $. Дополнительные затраты — 4 прошедших часа × 20 $ + 50 $ = 130 $. Итоговая оценка — 530 $.

Если заказы ждут, немедленной потери дохода нет: 400 $ отложены, а не потеряны. Дополнительные затраты 130 $ всё равно возникают. При 10 заказах в час четыре часа дают очередь из 40 заказов.

Это два сценария, а не один. Отчёт, где одновременно стоят потеря 530 $ и 40 ожидающих заказов, считает одних и тех же клиентов дважды.

Проверьте, рассосётся ли очередь

Очередь уходит, только если после восстановления есть запас мощности. Магазин обычно обрабатывает 10 заказов в час, а после восстановления с дополнительным персоналом — 20, то есть запас — 10 заказов в час. 40 заказов ÷ 10 = 4 рабочих часа на разбор при допущении постоянного темпа. Восстановление в 14:00 во вторник — очередь разобрана к 18:00 того же дня.

Если мощность после восстановления равна обычной — как на складе дистрибьютора у аэропорта, — конечного времени разбора в этой модели нет. Отчёт должен прямо это сказать, а не показывать число.

Нерабочие часы снова ведут себя иначе. На складе свет пропадает в 17:00 в пятницу и возвращается через 15 часов, в 08:00 субботы. Рабочими из них были только 3 часа, поэтому потерянный доход считается за 3 часа, а дополнительные затраты за час простоя (например, арендованный генератор) — за все 15.

Держите документ рабочим

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

«Восстановление бизнеса и учебные проверки» связывает план, цель и записанные учения и добавляет последствия по графику работы и часовому поясу каждого филиала. Откройте демо, чтобы увидеть невыполненную цель, пересечение ресурсов и разницу между потерянными и отложенными заказами. Чтобы найти уязвимые места бизнеса, используйте Business Fragility X-Ray; чтобы подготовить и проверить последовательность восстановления — этот инструмент. Никаких догадок ИИ нет: каждое число выше рассчитано из показанных вводных.