Разработка DR-документации: где инфраструктура теряет часы
Типовой отказ выглядит одинаково: сервис перезапущен, а данные и связи между системами восстанавливают вручную — по памяти, из старой переписки и заметок. Порядок действий держится на том, что кто-то из инженеров ещё помнит, что за чем поднимать. Простой сервиса растягивается на часы и повторяется при каждой аварии. Разработка DR документации закрывает именно этот разрыв.
Время теряется на стыках: пока поднимается база, приложение уже ждёт соединения, очередь копит сообщения, внешние интеграции перестают отвечать. Каждую зависимость проверяют вручную и заново — в момент, когда думать некогда. Никто не знает заранее, в каком порядке поднимать компоненты и какой из них считать точкой отказа.
Документация переводит это в проверяемую последовательность. Целевое время восстановления и допустимая потеря данных фиксируются до аварии, а не обсуждаются на созвоне в разгар инцидента — это те самые RTO и RPO, на которых строится ISO 22301. Для каждого сервиса определяется владелец, состав зависимостей и критерий, по которому восстановление считают завершённым.
Регламент восстановления — не инструкция на сотню страниц, а короткий документ с командами, ролями и точками принятия решений: когда переключаемся на резервную площадку, кто даёт команду, как откатываемся назад. Его проверяют на учениях и правят по итогам — иначе он устареет после первого же изменения в инфраструктуре.
Ниже разбираем, что входит в такую документацию и как её проверяют заранее — до аварии, а не во время.
Что даёт регламент восстановления: эффект в метриках
Целевое время восстановления и глубина отката данных
Регламент задаёт для каждого сервиса две измеримые величины: целевое время восстановления и глубину отката данных. Первая отвечает на вопрос, за сколько сервис обязан вернуться в работу, вторая — сколько данных допустимо потерять. Без этих чисел «мы быстро всё поднимем» остаётся обещанием, а не обязательством: учения раз в квартал дают фактическое время, разрыв с целью становится виден, а сам простой сокращается в разы относительно сценария «поднимаем по памяти».
За основу целей берём отраслевую рамку NIST по планированию непрерывности, но значения считаем под ваш контур: платёжный контур и вход в личный кабинет получают жёсткие цели, аналитика и отчёты — мягкие. Из целей дальше выводится всё остальное: частота копий, схема и срок хранения, порядок переключения трафика.
Доля аварий, которые закрываются по документу, а не по звонку дежурному
Пока порядок восстановления живёт в голове одного инженера, каждая авария начинается с поиска этого инженера — и всё это время простой идёт. Классы отказов (потеря узла, порча данных, отказ зоны доступности, неудачный релиз) описываются по отдельности: у каждого свой набор шагов и своя точка входа в документ. Дежурный открывает нужный раздел и идёт по нему, не собирая картину по переписке.
Эффект виден в метриках: доля аварий, закрытых по регламенту, растёт, а число случаев, где нужен «тот самый» специалист, падает. Готовность сервиса и стоимость простоя перестают быть случайной величиной — их считают заранее и проверяют на учениях.
Форматы описания процедур восстановления: что выбрать
Формат документации диктует, что произойдёт в момент аварии: восстановление по ручному регламенту или запуск автоматизированного сценария. Мы выбираем формат по двум критериям — частота изменений в инфраструктуре и допустимая цена простоя.
Ручной регламент, автоматизированный сценарий и гибрид
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручной регламент | Редкие изменения, мало сервисов, шаги требуют решения человека | Зависит от конкретного дежурного, время восстановления растёт при ротации |
| Автоматизированный сценарий | Частые релизы, много однотипных сервисов | Требует сопровождения: при дрейфе конфигурации молча ломается |
| Гибрид | Критичное ядро автоматизируем, остальное — по шагам | Дороже в проектировании, нужна синхронизация двух контуров |
Гибридный подход снимает основное противоречие: сценарий восстановления выполняет рутинные шаги, а инженер принимает решения на точках ветвления. Поддерживаемость документа при этом выше, чем у чистого регламента, потому что он проверяется прогоном, а не чтением.
Когда документ нужен только для прохождения внешней проверки
Если восстановление уже отработано скриптами, а документация нужна для проверки требований, она всё равно должна совпадать с реальностью — иначе первая же учебная тревога её опровергнет. Такой документ мы собираем из фактических конфигураций и добавляем раздел с расхождениями: что автоматизировано, что делается руками и почему.
Этапы внедрения: от аудита отказоустойчивости до передачи
Работу ведём от карты отказов к документу, а не наоборот: сначала выясняем, что именно и в какой последовательности восстанавливать, затем фиксируем это в процедурах, которые можно выполнить ночью без автора системы.
Аудит отказоустойчивости и инвентаризация сервисов
- Инвентаризация сервисов. Собираем полный перечень: что запущено, кто владелец, насколько сервис критичен для выручки и какие у него внешние зависимости. Нужны доступы к учётным системам, мониторингу и ответственные от заказчика по каждому направлению.
- Аудит отказоустойчивости. Разбираем точки отказа: единственный узел базы, общий том хранения, ручные шаги в выкладке, отсутствие копий конфигураций. По каждому пункту оцениваем вероятность и последствия.
- Схема зависимостей. Строим карту «сервис — база — очередь — внешний поставщик» с порядком запуска. Она сразу показывает, что именно упадёт каскадом и что восстанавливать первым.
- Целевые показатели. Для каждого сервиса согласуем допустимое время простоя и допустимый объём потерянных данных. Заказчик подтверждает, где достаточно нескольких часов, а где счёт идёт на минуты.
- Разработка процедур. Пишем пошаговые сценарии под конкретные отказы: проверки, команды, ожидаемый результат на каждом шаге, критерий остановки при расхождении.
Проверка на учениях и передача владельцам
- Учения по восстановлению. Прогоняем сценарии на копии среды, замеряем фактическое время и фиксируем расхождения с целевыми показателями. Процедуры после прогона уточняем — обычно обнаруживаются шаги, которые держатся на человеке, а не на регламенте.
- Передача документации. Проводим обучение владельцев сервисов, отдаём комплект в актуальном виде и фиксируем регламент пересмотра: при изменении архитектуры документ обновляется вместе с ней, а не после следующей аварии.
От заказчика на всех этапах нужны доступы, окно на учения и один ответственный, который принимает решения по приоритетам сервисов.
Комплект документов и схем, который остаётся у команды
Комплект собран так, чтобы новый инженер принял дежурство и провёл восстановление без звонков автору. Всё, что обычно живёт в переписке и памяти одного человека, переносится в документы, схемы и записи в репозитории.
Схемы потоков данных и точек отказа
- Схема потоков данных: от входящего трафика до хранилища и резервных копий, с отмеченной границей отказа между зонами.
- Перечень точек отказа с оценкой последствий — что деградирует первым, что отказывает целиком, какой узел продублирован.
- Карта зависимостей между сервисами и внешними поставщиками: видно, что чинить в первой очереди, а что может подождать.
- Сценарии восстановления: полный отказ площадки, потеря данных, недоступность отдельного сервиса — с порядком действий для каждого.
- Инструкция для дежурного: пошаговая последовательность, критерии передачи старшему инженеру и точки, где нужно решение владельца.
Роли, права и порядок согласования изменений
- Матрица доступов: кто из инженеров, поставщиков и подрядчиков что видит и что может менять, включая аварийные учётные записи.
- Порядок согласования изменений — от заявки до выката, с указанием, какие правки конфигурации требуют проверки вторым инженером.
- Журнал изменений конфигурации: что менялось, кем, зачем и как откатить, чтобы восстановление опиралось на факты, а не на догадки.
По этим материалам новый инженер входит в контур за считанные дни, а не недели расспросов.
Кейс: сократили время восстановления после сбоя в разы
Что было до: аварии, ручные обходы и зависимости в голове администратора
О сбое узнавали от пользователей, а не от мониторинга: пока шли жалобы, часть запросов терялась. Восстановление шло по памяти — у каждого инженера был свой порядок подъёма сервисов, часть шагов жила в личных заметках, а знание о моменте переключения основной базы держалось у одного администратора. Повторяющиеся сбои одного класса разбирались заново: после инцидента оставался набор догадок вместо обновлённой процедуры.
Договориться о сроках простоя было нечем: время восстановления не измерялось, смежные команды не знали, когда им подключаться.
Что стало после: предсказуемый порядок действий и подтверждённые проверками сроки
Мы описали и согласовали процедуры восстановления: роли дежурных, точки принятия решений, порядок переключения базы на PostgreSQL, критерии остановки и отката. Регламент проверяется учениями по расписанию: переключение на резервный контур выполняется на живом контуре, результаты фиксируются и уточняются.
| Что измеряем | До | После |
|---|---|---|
| Обнаружение сбоя | по жалобам, десятки минут | до 2 минут, мониторингом |
| Время восстановления | 4-6 часов | 35-50 минут |
| Шаги по регламенту | меньше половины | около 95% |
| Повторные сбои того же класса | регулярно | единичные |
Простой стал предсказуемым: сроки восстановления подтверждены учениями, а не оценками, и повторяющиеся сбои перестали быть нормой — регламент обновляется после каждого разбора.
Чем план восстановления отличается от DR-регламента?
План аварийного восстановления отвечает на вопрос «что поднимаем и в каком порядке», а не «кто делает это руками». В нём зафиксированы перечень систем, порядок восстановления с учётом зависимостей между сервисами и целевые показатели: допустимое время простоя и допустимый объём потери данных. Там же — критерии запуска: при каких признаках аварии план вообще вводится в действие.
Регламент действий описывает исполнение: зоны ответственности по каждой системе, состав аварийной команды, порядок эскалации и то, каким доступом пользуется каждый участник. Отдельным пунктом идёт аварийный доступ в обход штатной схемы — условия выдачи и обязательный отзыв после инцидента.
Ключевая часть — точки принятия решений. Для каждого шага указано, что считается успешной проверкой, кто её подтверждает и что делать, если шаг не сработал: сколько попыток, когда переходить к резервному варианту, в какой момент поднимать копию на второй площадке. Без этого регламент остаётся перечнем серверов, а не порядком восстановления.
Оба документа проверяются на учениях: план уточняет приоритеты, регламент — роли и доступы по факту попыток. Структуру мы выстраиваем по рамкам ISO 22301, а расхождения между документом и реальностью фиксируем после каждого прогона.
Технические сомнения: что уточняют перед стартом работ
Перед стартом почти всегда всплывают одни и те же сомнения — и они не про сроки, а про то, выживет ли документ в реальной инфраструктуре. Собрали вопросы, которые задают чаще всего, и наши ответы по существу.
У нас часть контуров на ручном управлении — документ не будет работать?
Смешанная инфраструктура — норма, а не исключение. Для таких участков описываем не только автоматические шаги, но и ручные операции: кто их выполняет, в какой последовательности, что проверяет после. Отдельно фиксируем границы, где автоматика заканчивается и нужен человек.
Мы не готовы раскрывать схемы сети и доступы
Работаем по соглашению о конфиденциальности, а топологию описываем в обезличенном виде на стороне заказчика. На выходе вы получаете готовые разделы и шаблоны, пригодные для тиражирования внутри вашего контура.
Документ устареет, если команда сменится
Поэтому пишем регламент, а не пересказ текущих настроек: процедуры без имён, с ролями и зонами ответственности. Новый инженер восстанавливает сервис по инструкции, не разыскивая автора прошлой конфигурации.
Что происходит с документацией после сдачи?
Передаём версионируемый набор с чек-листом актуализации и триггерами пересмотра — после изменений в инфраструктуре, учений или смены ответственного. Отдельно показываем вашей команде, как поддерживать документ своими силами.
Остальные сомнения обычно касаются деталей конкретного контура — их снимаем на этапе обсуждения задачи.Обсудим задачу: что подготовить к разговору
Разговор о документации по аварийному восстановлению получается предметным, когда на столе есть факты об инфраструктуре, а не общие пожелания. Готовить полное техническое задание заранее не нужно — достаточно перечня сервисов и вашего собственного представления о допустимом простое и потерях данных.
- Постановка задачи. Что именно беспокоит: требования регулятора, аудит, недавний сбой или план на будущее — от этого зависит глубина и форма документов.
- Перечень критичных сервисов. Что поднимаем первым, а что может подождать сутки. Полезно отметить зависимости: хранилище, очереди, внешние интеграции — без них сервис формально работает, но пользы не приносит.
- История аварий. Что уже ломалось, сколько времени уходило на восстановление, где были ручные шаги, где не хватало прав или инструкций.
- Текущие резервные копии. Что и как часто копируется, где хранится, как давно восстановление проверяли вживую, а не по отчёту.
- Ожидания по срокам восстановления. Для каждого критичного сервиса — допустимое время простоя и допустимый объём потерянных данных. Эти две величины задают всю логику резервирования и порядок действий.
- Ограничения и доступы. Кто отвечает за инфраструктуру, какие площадки задействованы, есть ли требования держать данные внутри контура.
- План работ и приёмка. Как вы хотите проверять готовность: учениями, разбором сценариев или формальным документом с подписями.
Дальше мы вернёмся с оценкой и планом работ: что описываем, в каком порядке, какие проверки нужны на живой инфраструктуре, а что закрывается регламентом.
