DR Policy & Stakeholders

«У нас есть disaster recovery, мы делаем backup’ы» — фраза, которую я слышу регулярно и которая ничего не означает. Backup — это инженерная практика, она про технологию: где данные, какой PITR, какой restore MTTR. См. Backup & Restore, там подробно. DR Policy — это управленческий документ: какие сценарии мы планируем (полная потеря региона? компрометация cloud account? cyber-attack? физическое уничтожение DC?), какой RTO/RPO на уровне всей организации, кто принимает решение о failover (CTO? владелец сервиса? дежурный IC?), кого информируем и в каком порядке (руководство → совет директоров → регуляторы → клиенты → публика). Лист — про эту вторую часть, которая чаще всего отсутствует или существует в виде слайдов трёхлетней давности.

Граница с backup-restore явная: тот лист — per-service технические артефакты (как делать backup’ы PostgreSQL, как тестировать restore, какой PITR). Этот лист — управление на уровне организации: какие сценарии мы вообще рассматриваем, у кого какие права решения, как выглядит карта стейкхолдеров. Граница с Game Day / Chaos Drills — там про тренировку и проверку реакции команды; здесь про policy, к которой эта реакция привязана. Полный full-scale DR exercise (DiRT-style) — это game day, который тренирует именно эту policy.

Что должен уметь

Главный навык на уровне L5 — записать права решения до катастрофы, а не в ней. В момент катастрофы policy не открывает никто: телефон звенит, все на нервах, руководство ждёт ответа. Если заранее не закреплено «переключение на резервный регион — решение CTO; решения по ходу — за IC; сообщение клиентам Comms Lead согласует с юристами за тридцать минут», каждый из этих вопросов решается на месте, под давлением, с предсказуемо плохим результатом. Я регулярно вижу команды, у которых backup и восстановление работают, runbook’и свежие, а DR policy — это полстраницы из 2019 года, которую никто не читал. В момент катастрофы это то же самое, что её отсутствие.

Знает DR policy своей организации и команды: какие сценарии рассматриваются, какие целевые RTO/RPO, кто владелец документа. Находит его за тридцать секунд, а не «где-то в Confluence».
Понимает своё место на карте стейкхолдеров: при каких сценариях его информируют, что от него ожидается, кому он эскалирует.

Пишет или ревьюит DR policy своей команды: какие сценарии в охвате, какой уровень стратегии (backup-restore / pilot light / warm standby / multi-site), целевые RTO/RPO, права решения, схема оповещения, требования регулятора.
Согласует целевые RTO/RPO с бизнесом: цена простоя за единицу времени, ущерб клиенту, требования регулятора. Без счётного обоснования цифры выглядят взятыми с потолка и не переживают первый же разговор о деньгах.
Проектирует ежегодные учения: полномасштабный tabletop минимум раз в год плюс реальное переключение раз в 6-12 месяцев. Тренировочная сторона разобрана в Game Day / Chaos Drills.
Держит DR policy живой: пересмотр раз в 6-12 месяцев, после каждого заметного инцидента, при смене архитектуры, поставщиков или требований регулятора.

L6+

Внедряет DR policy на уровне организации: согласует с руководством, юристами и compliance; связывает с общим Business Continuity Plan (BCP); ведёт годовую программу учений с бюджетом и поддержкой сверху.
Ведёт переговоры с регуляторами и аудиторами о готовности к катастрофе: SOC 2 Trust Services Criteria (Availability), PCI-DSS req 12, GDPR breach notification, отраслевые требования банков и медицины.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 26 «Data Integrity». Не покрывает DR policy напрямую, но описывает внутренний подход Google к ежегодным учениям DiRT на уровне всей организации. Базовое чтение.
Heather Adkins et al. — Building Secure and Reliable Systems (O’Reilly, 2020), глава 16 «Disaster Planning» (дальше по порядку идут «Crisis Management» и «Recovery and Aftermath» — три главы читаются как одна). Один из немногих публичных источников, объединяющих reliability и security DR (cyber-disaster, не только инфраструктурный). По моим наблюдениям — лучший единичный источник по теме на 2026 год.
ISO 22301 — Business Continuity Management Systems (стандарт). Не книга, а стандарт, но если ваша отрасль регулируется (банки, медицина, госсектор), аудитор спросит именно про него. Платный, публичные пересказы есть.

Статьи и доклады

AWS — Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud. Канонический разбор четырёх уровней стратегии: Backup & Restore / Pilot Light / Warm Standby / Multi-Site Active-Active. По смыслу от облака не зависит.
Atlassian April 2022 outage retrospective. Public postmortem: сайты 775 клиентов были удалены, полное восстановление заняло две недели — backup’ы существовали, но процедуру восстановления к такому масштабу кризиса не готовили. Главный публичный кейс «backup-strategy на бумаге vs реальный RTO». См. ниже в Best practices.
Пожар в дата-центре OVH в Страсбурге (март 2021). Здание SBG2 сгорело физически за несколько часов. Клиенты без off-site backup потеряли всё; клиенты с backup в другом регионе восстановились. Самый яркий публичный кейс «physical disaster — реальный сценарий, не мысленный».
Kripa Krishnan — Weathering the Unexpected (ACM Queue, 2012). DiRT в Google как ежегодные полномасштабные учения; единственный долго живущий публичный рассказ о том, как такая программа держится годами.

Инструменты

DR Policy как markdown в репозитории — основной артефакт практики. Один документ на организацию или направление, ревью через pull request, история в git. По моим наблюдениям, это самый частый формат там, где документация и так живёт в репозитории; в регулируемых компаниях рядом держат Word или PDF для аудита.
Stakeholder Map / RACI matrix — простая таблица: сценарий × роль × responsibility (Responsible / Accountable / Consulted / Informed). По моим наблюдениям, в кризисе RACI на полстраницы ценится выше, чем policy на двенадцать страниц.
Схема оповещения — кого и когда информируют: руководство сразу, совет директоров в течение часа на SEV1, регуляторы по типу инцидента и юрисдикции, клиенты через статус-страницу и почту, публика через согласованное заявление. Без явной схемы вопрос «звать ли юристов» решается на месте и каждый раз заново.
AWS Resilience Hub / Azure Site Recovery — управляемые платформы оркестрации: целевые RTO/RPO на каждое приложение, автоматические сценарии переключения, расписание учений. Имеет смысл, когда стратегия — warm standby или multi-site с автоматическим переключением.
Годовой календарь учений — фиксированные даты tabletop’ов и реальных переключений, подписанные кем-то из руководства. Без календаря учения сползают в «когда будет время», то есть в никогда.

Best practices

Главный публичный кейс — Atlassian outage 5 апреля 2022. За двадцать три минуты, с 07:38 до 08:01 UTC, скрипт удаления устаревшего приложения снёс 883 сайта, принадлежавших 775 клиентам. Backup’ы существовали (Atlassian активно инвестировал в backup strategy), но процедуру восстановления никто не проверял на масштабе кризиса: одного клиента поднимали часами вручную, параллелить получалось плохо. Первых клиентов вернули 8 апреля, последних — только 18-го, то есть до 14 дней для части пострадавших. В собственном разборе Atlassian признаёт, что RPO в один час они выдержали, а RTO — нет: заявленная цель измерялась часами, фактическое восстановление — двумя неделями. Главный урок — не «backup’ы не работали» (они работали), а «политику никто не проверял на катастрофе такого масштаба». Я считаю это самым ценным публичным кейсом последних лет именно для DR policy: он показывает разницу между «у нас есть DR» и «мы знаем, за сколько поднимемся, когда упадёт всё сразу».

Первое различение — самое частое. DR Policy не равна backup strategy, хотя «у нас же делаются backup’ы, значит DR есть» я слышу постоянно. Backup живёт в технологическом слое, а policy отвечает за управление: какие сценарии мы рассматриваем, у кого какие права решения, как выглядит карта стейкхолдеров. Backup без policy — это технология без правил применения.

Права решения фиксируются до катастрофы, а не «когда понадобится». В момент, когда телефоны разрываются и руководство ждёт ответа, policy не открывает никто. Значит, записано заранее: решение о переключении принимает CTO, решения по ходу — IC, а сообщение клиентам Comms Lead согласует с юристами за тридцать минут.

Отдельно про цифры. «Как можно быстрее, как можно меньше потерь» — это не RTO и не RPO, это пожелание. Работают конкретные числа: RTO 4 часа для tier-1, 24 часа для tier-2, 7 дней для tier-3, — и каждое обосновано через стоимость простоя за единицу времени, регуляторные требования и SLA перед клиентами. Без чисел стратегия резервного копирования строится по ощущениям.

Учения имеет смысл проводить в масштабе катастрофы, а не в удобном. Кейс Atlassian ровно об этом: тренировка на восстановление одного клиента не равна способности восстановить семьсот с лишним одновременно. Я регулярно вижу команды, у которых restore-drill для одного сервиса проходит за 30 минут — и в policy стоит RTO в один час. Настоящая катастрофа означает одновременное восстановление десятка сервисов с параллельной нагрузкой на runbook’и, людей и инструменты. RTO в кризисе и RTO в учении на одном сервисе — разные величины. Честное число — это MTTR полного сценария на реалистичном масштабе, измеренный на ежегодных учениях. Без него RTO в policy остаётся оптимистичной фантазией.

Четыре уровня стратегии — это про деньги, а не про защиту. Схему AWS (Backup & Restore / Pilot Light / Warm Standby / Multi-Site Active-Active) часто читают как «выберите свой уровень». Это половина правды. Настоящий выбор — размен стоимости на RTO. Multi-Site Active-Active даёт RTO ≈ 0 ценой удвоения инфраструктуры; Backup & Restore — RTO часы / дни ценой почти нулевой дополнительной стоимости. Решение принимается на каждый класс сервисов, а не одно на всю компанию: tier-1 (деньги, требования регулятора) — Warm Standby или Multi-Site; tier-2 (внутренние, но важные) — Pilot Light; tier-3 (пакетная обработка, аналитика) — Backup & Restore. Единый уровень для всех сервисов либо разоряет (всё Multi-Site), либо оставляет риск на самом видном месте (всё Backup & Restore). И вот здесь у практики есть чёткая граница: пока у команды один сервис и один регион, отдельная DR policy не работает как инструмент — выбор всё равно один, и он умещается в пару строк рядом с runbook. Смысл появляется с момента, когда сервисов несколько и они разного веса для бизнеса.

В кризисе карта стейкхолдеров важнее идеальных runbook’ов. Ключевой вопрос в катастрофе — не «как восстановить», а «кому звонить и кто решает». Наблюдаю это устойчиво: команды с безупречными runbook’ами и без карты теряют час-полтора на выяснение, кто разрешает переключение, будить ли CEO и когда выпускать публичное заявление. Команды с матрицей RACI на полстраницы и простой схемой оповещения реагируют быстрее, даже когда сами runbook’и среднего качества. Это не значит, что runbook’и не важны, — про них соседние листья. Это значит, что отсутствие карты обходится дороже всего и встречается чаще всего.

Ежегодные учения — единственный способ проверить политику. Я регулярно вижу документы, которые звучат разумно на ревью, а в катастрофе оказываются нерабочими: ссылаются на людей, которых давно нет, на инструменты, которые сменились, на права решения, ушедшие в другую команду. Найти это до катастрофы больше нечем. Формат такой: tabletop на четыре-восемь часов без всякой инъекции отказов, только разговор, минимум раз в год; реальное переключение в резервный регион — раз в 6-12 месяцев. Тренировочная часть подробно разобрана в Game Day / Chaos Drills.

Требования регулятора — не «прихоть compliance». SOC 2 Trust Services Criteria (Availability), PCI-DSS requirement 12.10, GDPR Article 32 — все требуют документированную DR или BCP с доказательствами того, что её проверяли. Аудитор спросит не «есть ли политика», а «когда было последнее учение и что на нём вскрылось». В регулируемых отраслях — банки, медицина, платежи — это обязательный документ со следом проверок, а не факультативный. Я регулярно вижу стартапы, которые откладывают политику «до раунда B», а потом упираются в корпоративного клиента, для которого доказанная готовность к катастрофе — условие сделки. Откладывать дальше первого разговора про compliance — это технический долг с явным дедлайном.

Связанные листья

Backup & Restore — техническая основа стратегии: механика резервных копий, учения по восстановлению, RPO и RTO на каждый сервис. Без работающего восстановления любая политика — обещание; без политики у восстановления нет правил применения на уровне компании.
Service Ownership — каталог сервисов хранит класс каждого сервиса (1/2/3), его целевые RTO/RPO и выбранную стратегию. Политика задаёт рамку, каталог показывает, как она разложена по конкретным сервисам.
Game Day / Chaos Drills — ежегодные учения как полномасштабный game day. Здесь — политика и карта стейкхолдеров; там — тренировочная сторона.
Incident Response — катастрофа — особый класс инцидентов: SEV1 и выше с реакцией, растянутой на дни. Обычный процесс здесь расширяется эскалацией до руководства, уведомлением регулятора и длинным war room.
Customer Communications — схема оповещения — часть политики; частота сообщений по severity и выбор каналов живут на пересечении двух листьев.
Playbooks — playbook на катастрофу — отдельный артефакт: роли (CTO, IC, Comms, юристы), первые шестьдесят минут, точки решения, уведомления регулятора.
Vendor Reliability — политика включает сценарии с чужой стороной: авария облачного провайдера, инцидент у поставщика SaaS. План ухода от поставщика — тоже часть DR.
Compliance Frameworks — SOC 2 Availability, PCI-DSS 12.10 и ISO 22301 требуют документированную политику с доказательствами проверок; для аудита это один из первых запрашиваемых документов.
Status Page Management — в катастрофе статус-страница живёт в другом ритме — не часы, а дни, — и этот ритм задаётся политикой заранее.
Stakeholder Management — карта стейкхолдеров для катастрофы — управление по заранее описанному сценарию; тот лист про постоянные отношения, этот — про кризис.

Открытые вопросы

Business Continuity Plan (BCP) — более широкий документ: люди, процессы, помещения, а не только IT. DR — его часть. Я не уверен, что BCP заслуживает отдельного листа в карте SRE: бо́льшая его часть — про кадры и здания, то есть не про нас. Возможно, хватит короткого раздела внутри DR Policy.
Cyber-disaster recovery (TBD) — ransomware, account compromise, supply-chain attack как DR-сценарии. Пересечение с Information Security; см. Security Chaos Engineering и Supply Chain Security. Возможно отдельный лист «Cyber-Disaster Recovery» под Information Security.
Multi-cloud DR — резервная копия у другого облачного провайдера как защита от компрометации всего аккаунта. На начало 2026 года практика частая в финтехе и крупных компаниях, в стартапах — редкая: дорого и сложно. Хорошей публичной литературы по проектированию такой схемы я не нашёл, разобранных случаев мало.