Disaster Recovery

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

Disaster Recovery как инженерная практика — способность вернуть сервис целиком после потери того, без чего он не живёт: площадки, региона, кластера данных, доступа к управлению. Параметров у неё два, и оба числа. RPO говорит, сколько данных допустимо потерять, RTO — за какое время сервис возвращается. Всё остальное в этом листе про то, как эти два числа превращаются в схему репликации, порядок переключения (failover) и набор проверок.

Границы с соседями. DR Policy & Stakeholders отвечает за то, кто принимает решение и что обещано бизнесу; здесь техника под эти обещания. Backup & Restore занимается данными: копии, их проверка, восстановление базы. DR шире, в него входят сервис, площадка и доступ. Game Day описывает учения как ритуал, а этот лист — что именно на них проверять. Resilience Patterns помогают пережить частичный отказ без переключения.

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

Главный навык на уровне L5 — найти в схеме восстановления то, что зависит от сломанного. Я считаю его главным, потому что эта ошибка не видна на схеме. Резервная площадка нарисована, репликация настроена, а доступ к консоли выдаёт сервис, который живёт на основной площадке, и DNS для внутренних инструментов обслуживается оттуда же. В обычный день всё работает. В день катастрофы выясняется, что чинить нечем.

Выполняет переключение по готовой процедуре на стенде и в учениях; знает RTO и RPO своего сервиса и откуда эти числа взялись.
Перед ручным вмешательством в данные или важную конфигурацию делает копию или сохраняет версию рядом, каким бы мелким ни выглядело изменение.

Выбирает репликацию под RPO: синхронная даёт нулевую потерю ценой задержки записи, асинхронная теряет данные в размер своего отставания.
Измеряет RTO по факту: от обнаружения до полного возврата трафика, вместе со временем на решение, и сравнивает результат с обещанным.
Проводит плановое переключение и записывает всё, что пришлось делать руками и чего не было в процедуре.

Выбирает схему площадок под сервис: один писатель с окном переключения или запись в нескольких местах с разрешением конфликтов.
Находит циклические зависимости восстановления и записывает порядок холодного старта: что поднимается первым и без чего не поднимется остальное.
Строит аварийный доступ (break-glass) без онлайновых зависимостей и проверяет его на учениях наравне с остальными резервными путями.
Делает переключение штатной операцией по расписанию, а не событием раз в год.

L6+

Связывает класс сервиса с пакетом обязательств: целевые RTO и RPO, схема площадок, частота учений.
Добивается учений с отключением площадки целиком и защищает их перед бизнесом как единственный способ узнать настоящий RTO.
Вводит правило, по которому сервис не считается готовым без проверенного плана восстановления.

Материалы

Книги

Наталья Савенкова — SRE. Рецепты выживания в продакшне для инженера по надежности (2024). Читал и рекомендую: шестьдесят страниц коротких рецептов без теории. Для этого листа важны три: проверять резервные пути, чаще повторять страшные процедуры и помнить, что механизмы переключения заметно удорожают систему.

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

Santosh Janardhan — More details about the October 4 outage (Engineering at Meta, 2021). Короткий разбор, который обязательно стоит прочитать ради одного абзаца: о том, как отказ сети отрезал инженеров от инструментов, которыми её чинят.
Jason Warner — October 21 post-incident analysis (GitHub, 2018). Лучшее из известных мне описаний того, как автоматическое переключение базы превращает сорок три секунды в сутки. Там же редкая честность: выбор между скоростью возврата и целостностью данных назван прямо.
Cloudflare — Post mortem on the Cloudflare Control Plane and Analytics Outage (2023) и Major data center power failure (again): Cloudflare Code Orange tested (2024). Два отключения одной площадки с разницей в пять месяцев и цифры о том, сколько занимает холодный старт до учений и после.
AWS — Disaster recovery options in the cloud. Четыре стратегии от резервных копий до нескольких активных регионов. Удобная линейка, чтобы назвать свою схему одним словом.
PostgreSQL — Log-Shipping Standby Servers. Раздел о синхронной репликации написан без рекламы: и про задержку записи, и про то, что коммит может не завершиться никогда, если единственная синхронная реплика упала.

Инструменты

Patroni — управление кластером PostgreSQL с автоматическим переключением. По моим наблюдениям, для PostgreSQL чаще берут именно его; цена в том, что к базе добавляется координатор, который тоже надо держать живым.
Переключение трафика — DNS с коротким временем жизни записей, глобальный балансировщик или anycast. Выбор зависит от того, как быстро клиенты перестают ходить на мёртвую площадку; имеет смысл измерить это на учениях, а не брать из документации.
Локальная копия плана и доступов — распечатка, файл на ноутбуке дежурного, аппаратный ключ в сейфе. Инструмент скучный и чаще всего отсутствует: вики с процедурой восстановления обычно живёт на той площадке, которую восстанавливают.

Шаблоны

Disaster Recovery Plan — заготовка плана для одного сервиса из этого репозитория: RTO и RPO с обоснованием, сценарии, копии с датой проверки, учения. Этот лист объясняет, чем заполнять её технические разделы.

Best practices

4 октября 2021 года сервисы Facebook стали недоступны. Причину компания описала сама: команда, выданная при плановом обслуживании магистральной сети, отключила дата-центры друг от друга и от интернета. Для этого листа важнее второй абзац разбора. Потеря DNS сломала внутренние инструменты, которыми такие аварии расследуют и чинят. Основной и резервный доступ к сети не работал. Инженеров отправили в дата-центры физически, и там их задержала собственная защита: здания спроектированы так, чтобы в них было трудно попасть, а оборудование — так, чтобы его было трудно изменить даже стоя рядом.

Из этой истории я забираю главный вопрос для любой схемы восстановления: от чего зависит то, чем мы будем чинить? Доступ, DNS, система прав, мониторинг, вики с процедурой — у каждого пункта есть площадка, на которой он живёт, и чаще всего это та же площадка. Есть в разборе и хорошая новость. Возвращать нагрузку после простоя в компании умели, потому что годами проводили учения с отключением сервиса, дата-центра или целого региона. Учений с отключением магистрали не было, и авторы прямо пишут, что теперь будут искать способ их проводить.

Резерв, на который не переключались, — предположение. У Cloudflare в ноябре 2023 года обесточилась основная площадка, и в разборе есть честная фраза: полное её отключение ни разу не проверяли. Холодный старт занял около 72 часов. Через пять месяцев та же площадка обесточилась снова, уже после учебного отключения, и на холодный старт ушло около 10 часов. Подробнее эта пара разобрана в Problem Tracking. Здесь мне важна одна цифра: семикратная разница между непроверенным планом и проверенным. Отсюда же правило про страшные процедуры. Чем страшнее операция, тем чаще её стоит повторять, пока она не станет скучной.

RPO и RTO полезно считать проектными параметрами, которые спорят друг с другом. Нулевая потеря данных означает синхронную репликацию, и документация PostgreSQL называет её цену без обиняков: минимальное ожидание коммита равно времени пути до реплики и обратно, а при падении единственной синхронной реплики коммит может не завершиться вовсе. Поэтому синхронно реплицируют на близкую площадку, а на далёкую — асинхронно, с потерей в размер отставания. Выбор между скоростью возврата и целостностью данных лучше сделать заранее. GitHub в октябре 2018 года делал его в разгар инцидента: 43-секундный разрыв связи запустил автоматическое переключение MySQL, в кластерах на двух побережьях оказались расходящиеся записи, и компания сознательно выбрала целостность данных ценой 24 часов 11 минут деградации.

Схема площадок следует из тех же двух чисел. Один писатель и резерв дают предсказуемое поведение при сбое и окно недоступности на время переключения. Запись в нескольких местах убирает окно и приносит конфликты, разрешать которые придётся всегда, а не только в аварию. Там, где операция читает, проверяет и записывает общий остаток или счётчик, один писатель остаётся честным вариантом, и окно переключения — плата за него. Автоматика переключения тоже не бесплатна: ей нужен надёжный координатор, и история GitHub показывает, что бывает, когда координатор принимает решение, к которому приложение не готово.

Аварийный доступ не зависит от того, что чинит. Рабочий вариант выглядит неудобно и именно поэтому работает: локальные учётные записи, сертификаты, выданные заранее, аппаратный ключ в сейфе. Такой доступ по определению обходит обычную систему прав, поэтому его делают громким. Каждое использование поднимает алерт, уходит в безопасность и разбирается потом. И его тренируют наравне с переключением: кнопка, которую никто ни разу не нажимал, в день аварии окажется просроченной.

Отдельно про автоматическое восстановление. Есть жёсткая формулировка: сервис, который не переживает отключение части инфраструктуры без рук, спроектирован плохо. Для типовых сбоев я с ней согласен. Для катастрофы мне ближе формулировка мягче: сервис обязан давать быстрый путь восстановления, и этот путь не обязан быть автоматическим. Человек с проверенной процедурой и рабочим доступом часто надёжнее автоматики, которая в непредусмотренной ситуации переключит не туда.

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

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

DR Policy & Stakeholders — откуда берутся RTO и RPO и кто вправе объявить переключение; без неё техника из этого листа не знает, под какие числа строиться.
Backup & Restore — нижний уровень восстановления: если копии не проверены, остальное в этом листе не поможет.
Game Day — как устроить учения; этот лист даёт им список того, что отключать и что мерить.
Chaos Engineering — эксперименты малого радиуса; отключение площадки стоит на другом конце той же шкалы.
Resilience Patterns — чем сервис держится при частичном отказе, когда переключаться ещё рано.
Access Control & IAM — аварийный доступ как часть модели прав, а не дыра в ней.
Capacity Planning — хватит ли резервной площадке мощности, когда на неё придёт весь трафик.
Problem Tracking — зависимость от одной площадки как проблема со своей записью и своим владельцем.

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

Частоту плановых переключений я для себя не закрыл. Раз в квартал звучит разумно, но у меня нет данных, при какой частоте процедура перестаёт быть событием и становится рутиной. Подозреваю, что ответ зависит от того, сколько в ней ручных шагов, а не от календаря.

Рядом лежит холодный старт. Проверить переключение на резерв можно без остановки бизнеса. Проверить запуск площадки с нуля, когда выключено всё, включая то, чем обычно запускают, почти нельзя. Cloudflare узнала своё время холодного старта из настоящей аварии. Как узнать его раньше, я не знаю.

И граница между аварийным доступом и безопасностью. Доступ в обход системы прав оправдан только тем, что его нельзя открыть незаметно. Какой набор сигналов делает его достаточно громким и не превращает каждое учение в инцидент безопасности, я не знаю. Если у вас есть работающая схема, расскажите через PR.