Неясно, кто принимает решения
В момент аварии пятеро инженеров одновременно ищут причину, никто не отвечает за переключение, а решение о запуске резервной площадки некому принять.
Аварийное восстановление
План на случай аварии, проверенный на учениях
Определяем цели восстановления для каждого сервиса, готовим резервную площадку и описываем порядок переключения с ролями и связью. Затем проводим учения и фиксируем, сколько восстановление занимает в реальности.
Или сразу: +7 (962) 368-39-51 Telegram
RTO/RPO
цели по каждому сервису
2 раза в год
учения с замером времени
роли
кто что делает в первые минуты
журнал
фактическая длительность каждого шага
Что превращает сбой в катастрофу
Технические сбои случаются у всех. Разница в том, сколько времени уходит на реакцию и сколько решений приходится принимать в условиях нехватки информации.
Неизвестно, что восстанавливать первым
Все сервисы кажутся одинаково важными. Время уходит на споры о приоритетах, тогда как в первую очередь нужно поднять приём заказов и оплату.
План существует в голове техдира
Порядок действий не записан, поэтому в отпуске или при недоступности одного человека команда импровизирует и повторяет уже пройденные ошибки.
Резервная площадка только на бумаге
Второй контур существует, но данные в него не репликуются, версии кода разошлись, а мощности не хватит на боевой трафик. Проверить это в момент аварии — плохая идея.
Клиентов и поддержку не предупредили
Пользователи узнают о сбое из ошибок при оплате, поддержка не имеет заготовленного сообщения, а менеджеры — объяснения для клиентов и сроков.
Сбой одного сервиса останавливает цепочку
Недоступность интеграции с 1С блокирует выгрузку заказов, платёжный шлюз не получает подтверждений, а склад не видит остатки — продукт встаёт целиком.
Из чего состоит готовность к аварии
Четыре блока: цели, архитектура, регламент и учения. Ни один из них по отдельности не работает.
Цели восстановления
Для каждого сервиса определяем допустимый простой и допустимую потерю данных вместе с бизнесом.
- RTO и RPO по каждому сервису с учётом его роли в выручке
- Приоритеты восстановления: что поднимаем первым, что может подождать
- Оценка стоимости простоя, чтобы цели были обоснованы экономически
- Пересмотр целей при изменении архитектуры и бизнес-модели
Архитектура отказоустойчивости
Готовим техническую возможность пережить отказ узла или целой площадки.
- Резервная площадка или второй контур с актуальными данными
- Репликация базы и периодическая проверка отставания реплики
- Готовность внешних зависимостей: DNS, сертификаты, платёжные шлюзы
- Изоляция отказов, чтобы сбой интеграции не останавливал продажи
План и роли
Документ, по которому может действовать любой инженер из дежурной смены, а не только автор системы.
- Пошаговый сценарий с точными командами и ожидаемым результатом
- Роли: кто принимает решение, кто выполняет, кто коммуницирует
- Порядок оповещения и шаблоны сообщений для клиентов и поддержки
- Точки принятия решения о переходе на резервную площадку
Учения и разбор
План считается готовым только после того, как по нему восстановили сервис под замер времени.
- Учения два раза в год с полным или частичным переключением
- Фиксация фактического времени каждого шага и сравнение с RTO
- Разбор расхождений и корректировка плана по результатам
- Отдельные учения по потере данных и компрометации
Как разрабатывается план восстановления
Начинаем с влияния на бизнес, а не с технологий: сначала договариваемся о целях, потом проектируем под них решение.
-
01 1–2 недели
Анализ влияния на бизнес
Разбираем, какие сервисы и процессы критичны, что происходит при их отказе и сколько это стоит. Согласуем RTO и RPO с владельцами процессов.
-
02 2–4 недели
Проектирование восстановления
Определяем, что нужно для достижения целей: репликация, резервная площадка, изоляция отказов, готовность внешних зависимостей.
-
03 1–2 недели
Документация и подготовка
Пишем пошаговый план с командами и ролями, разворачиваем резервный контур, проверяем доступность инструкций и шаблонов оповещения.
-
04 2 раза в год
Учения и корректировка
Проводим учения, замеряем фактическое время, разбираем отклонения от плана и обновляем документ. Повторяем дважды в год.
Чем план восстановления отличается от резервных копий
Резервные копии отвечают на вопрос, есть ли у нас данные. План аварийного восстановления отвечает на вопрос, что мы делаем в первые минуты: кто принимает решение о переключении, в каком порядке поднимаются сервисы, кто сообщает клиентам и поддержке, как проверяется работоспособность. Без второго первое остаётся заготовкой.
Практика показывает: команда, у которой есть копии, но нет плана, тратит первые часы на согласования и поиск информации. Команда с планом и учениями начинает восстановление сразу, потому что порядок действий и роли известны заранее, а решение о запуске резервной площадки описано критериями, а не интуицией.
Что показывают учения по восстановлению
Учения регулярно вскрывают разрыв между ожиданиями и реальностью. Типичные находки: резервная площадка не может принять боевой трафик из-за квот, реплика отстала на несколько часов, инструкция ссылается на команды, которые изменились после обновления, а часть ключей доступа хранится у человека, который в отпуске.
Именно поэтому мы настаиваем на учениях с замером времени каждого шага. После первых учений фактический RTO обычно оказывается в два-три раза больше заявленного, и это не провал, а полезная информация: появляется точный список работ, чтобы приблизиться к цели. Повторные учения показывают динамику, которую можно предъявить руководству и партнёрам.
Сколько стоит недоступность сервиса
Цели восстановления логично определять через деньги, а не через технические предпочтения. Оценивается прямая потеря выручки за час простоя, стоимость ручной обработки заказов, штрафы по договорам с партнёрами, расходы на восстановление данных и репутационные потери от ухода клиентов.
После такой оценки обычно становится видно, что вкладываться в отказоустойчивость всего подряд нерационально. Разумнее обеспечить жёсткие RTO и RPO для сценариев, приносящих выручку, и более мягкие — для внутренних систем, отчётности и аналитики. Такой подход снижает стоимость решения без потери ключевых гарантий.
Частые вопросы
Это зависит от того, есть ли резервная площадка с актуальными данными и насколько автоматизировано переключение. С подготовленным контуром и DNS с коротким временем жизни записи переключение может занимать десятки минут. Без подготовки восстановление превращается в развёртывание с нуля: установка окружения, загрузка копий, проверка интеграций — это уже сутки и больше, даже при наличии данных.
Минимум два раза в год, а также после значительных изменений архитектуры: переезда на другую площадку, смены базы данных, появления новых критичных интеграций. Если продукт работает в жёстко регулируемой среде, периодичность может задаваться требованиями стандартов. Учения бывают полными и частичными: частичные дешевле и позволяют проверять отдельные шаги плана чаще.
Иногда да, если допустимый простой измеряется часами, а не минутами. В этом случае план строится на быстром развёртывании из копий и заранее подготовленных образах: тогда восстановление сводится к поднятию окружения и загрузке данных по документированной процедуре. Резервная площадка нужна там, где простой недопустим и время восстановления должно измеряться десятками минут.
Мы планируем их так, чтобы не мешать пользователям: переключение проверяется на резервном контуре, либо проводится в окно низкого трафика с возможностью немедленного возврата. Полные учения с реальным переключением продакшена согласуются заранее, сопровождаются дежурной сменой и завершаются проверкой, что основной контур работает штатно.
Поддержка и обслуживание: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Подготовим ваш продукт к аварии
Опишите архитектуру и допустимое время простоя — предложим состав работ и проведём первые учения.