Управление непрерывностью ИТ-услуг (ITSCM): DR, BCP и восстановление

BCP, DRP, ITSCM — кто за что

Три уровня, которые часто путают:

• BCP (Business Continuity Plan) — план непрерывности бизнеса: как компания продолжит работать (включая людей, помещения, процессы), если что-то отказало. Самый широкий уровень.
• ITSCM — непрерывность ИТ-услуг как часть BCP: какие ИТ-сервисы и за какое время нужно восстановить, чтобы бизнес выжил.
• DRP (Disaster Recovery Plan) — технический план аварийного восстановления инфраструктуры: конкретные шаги по поднятию серверов, БД, сети.

Иерархия: BCP говорит «отдел продаж должен работать через 4 часа» → ITSCM переводит это в «CRM и телефония — приоритет 1, RTO 2 часа» → DRP описывает технически, как поднять CRM за 2 часа. Без верхнего уровня DRP превращается в «восстанавливаем всё подряд», что в катастрофу невозможно.

RTO и RPO — две ключевые метрики

Вся ITSCM крутится вокруг двух чисел для каждой услуги:

• RTO (Recovery Time Objective) — за какое время услуга должна быть восстановлена. «CRM — 2 часа, корпоративный портал — 24 часа».
• RPO (Recovery Point Objective) — какой объём данных допустимо потерять, измеряется во времени. «RPO 15 минут» = теряем максимум последние 15 минут данных.

Катастрофа в момент T
   ◄── RPO ──►│         │◄────── RTO ──────►
последний     T          услуга снова
валидный                 работает
бэкап/реплика

RPO определяет частоту бэкапов/репликации (RPO 15 минут ≠ ежесуточный бэкап). RTO определяет стратегию резервирования. Эти числа задаёт бизнес, а не ИТ — и они стоят денег: RTO 5 минут и RPO 0 требуют горячего резерва, это дорого. Поэтому услуги ранжируют.

Стратегии резервирования по стоимости

Чем меньше RTO/RPO, тем дороже. Спектр вариантов:

• Backup & restore — бэкап, восстановление вручную. RTO часы-сутки, дёшево. Для некритичных услуг.
• Cold standby — резервное оборудование есть, но выключено; восстановление = развернуть из бэкапа. RTO часы.
• Warm standby — резерв поднят, данные реплицируются периодически. RTO десятки минут, RPO минуты.
• Hot standby / active-active — полная реплика работает параллельно, переключение мгновенное. RTO минуты, RPO≈0. Дорого вдвое.

Здравый подход: разнести услуги по уровням (tiering) и применить разные стратегии. Критичная CRM — warm/hot, вики и архивы — backup & restore. Платить за hot standby всему подряд — деньги на ветер.

Роль ServiceDesk при катастрофе

В час Х ServiceDesk — это командный центр коммуникации, даже если он сам пострадал (поэтому система должна быть либо в резерве, либо иметь offline-канал):

• Единая точка регистрации масштабного сбоя — поднимается Major Incident, по нему идёт вся хронология восстановления.
• Информирование пользователей — статус-страница / рассылка «знаем, чиним, ожидаемое время — X». Это снижает шквал звонков «у вас лежит?».
• Координация команд по DRP-чек-листу: кто поднимает БД, кто сеть, кто проверяет.
• Аудит после — хронология из тикета → материал для постмортема и пересмотра RTO/RPO.

Важно: сам ServiceDesk — тоже критичная услуга со своим RTO. Если он лежит вместе с остальным, координировать восстановление нечем. On-premise-система с резервной копией БД и быстрым развёртыванием (docker compose) здесь выигрывает у облака, доступ к которому в катастрофу может пропасть.

План, который не тестируют, не работает

Главная правда об ITSCM: непротестированный план восстановления равен его отсутствию. На бумаге всё красиво, а в реальности бэкап оказывается битым, пароль от резерва знал уволившийся админ, а «2 часа RTO» превращаются в двое суток. Уровни тестирования:

1. Walkthrough — командой проходим план на бумаге, ищем дыры. Раз в квартал.
2. Частичное восстановление — реально поднимаем одну услугу из бэкапа на тестовом стенде, замеряем фактический RTO/RPO.
3. Полные учения (DR drill) — имитация катастрофы, переключение на резерв. Раз в год, по согласованию с бизнесом.

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