И снова я говорю с Дмитрием, тимлидом нашей DevOps-команды. На этот раз мы поднимем тему процедур восстановления.

Большинство проектов не имеют нормального плана восстановления после падений. Если план и присутствует, скорее всего, в нем покрыты не все кейсы, и часть из них, возможно, устарела. При этом задач на подготовку восстановительных процедур никто не ставит. Зато сразу после падений начинаются вопросы к технарям: почему вы не заботитесь о сервисах как следует?

Чтобы таких вопросов не возникало, нужен “План Б”.

“Падать” могут не только собственные сервера. Полно свежих примеров того, как останавливаются точки обмена трафиком (вспомним сбой на MSK-IX в московском дата-центре ММТС-9 в феврале 2025 года из-за электропитания), выходят из строя ЦОДы (из-за удара молнии в январе 2025 года отключились сервера Департамента транспорта в столице Бразилии, из-за чего остановилось управление светофорами в городе), сбоят сети (в январе 2025 этим отличился мобильный оператор Three UK в Великобритании). В каждом из этих случаев сбой затронутых сервисов можно было бы предотвратить или существенно сократить, если бы у них был “план Б”.

На самом деле создать disaster recovery план - т.е. набор документов и инструкций, в которых указано, как именно восстанавливать сервис - не так сложно. В этой статье расскажу о подходе, который я почерпнул в рамках обучения проектному управлению в ИТ. Мы применяем его в нашей компании для подготовки disaster recovery планов для инфраструктуры заказчика.

Условие задачи

Дано: ИТ-инфраструктура, которая развивалась годами. Есть множество сервисов, различные сервера и legacy (как же без этого). Настроен какой-то мониторинг, но мы не понимаем, видим ли все. Плана восстановления после аварий нет.

Задача: проработать disaster recovery план.

Начать ее решение придется не с идей о восстановлении, а с выяснения требований бизнеса и полного аудита существующей инфраструктуры.

Требования бизнеса

Первым делом необходимо выяснить, а какие требования к скорости восстановления предъявляет сам бизнес (Risk Assessment & BIA). Кому-то достаточно работы инструментов 5 на 8, а кому-то необходима доступность 24 на 7 в одном из режимов:

• 99,9 (“три девятки”);

• 99,95;

• 99,99 (“четыре девятки”);

• … и так далее.

Ключевые метрики, которые обсуждаются на этом этапе: 

• RTO (Recovery Time Objective);

• RPO (Recovery Point Objective);

• MTD (Maximum Tolerable Downtime).

Предположим, сервис использует в работе базу данных. Может ли бизнес себе позволить восстанавливать ее сутки? Допустима ли разница в данных между пропавшей версией и бекапом в 10 часов?

Полный аудит инфраструктуры

Карта сервисов

Первое, что нужно сделать - создать карту сервисов as is по модели C4 (Context, Containers, Components, Code). Эта модель подразумевает многослойный подход к рисованию архитектурных схем. Но в контексте disaster recovery нас не интересует бизнесовая часть. Берем только слой со связями между микросервисами. Т.е. мы просто накладываем на карту все микросервисы и рисуем необходимые стрелки - кто куда ходит.

SLO (Service Level Objective)

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

Как и мониторинг, SLO можно условно поделить на несколько слоев (несколько отдельных таблиц):

• Уровень дата-центра и сетевого оборудования. У клиента может быть один или несколько дата-центров. Например, у Яндекс Облака и VK Cloud по несколько зон. В таблицу этого слоя пишем, сколько времени потребуется на восстановление сервисов в случае падения одного из ЦОД (или зон в нем).

• Сетевые связи. Из архитектурной схемы понятно, что некоторые сервисы живут на одном сервере, другие же используют сеть. Во вторую таблицу пишем все сервера, их IP, параметры (есть / нет горячее резервирование или бекапы), а также время, за которое сможем восстановить соединение с данным сервером. Очевидно, что в случае с горячим резервированием, автоматическое переключение займет несколько секунд, если же потребуется ручное восстановление из бекапа, время будет другим.

• Виртуалки и микросервисы. Как быстро мы сможем восстановить вышедший из строя микросервис? Мы знаем, сколько времени в среднем занимает та или иная процедура по развертыванию или переносу. Так что достаточно сложить это время выполнения типовых операций.

Заполненные таблицы позволяют оценить, сколько времени займет восстановление сервиса при наиболее негативном стечении обстоятельств. Фактически, они защищают технарей от претензий менеджеров в случае падения сервисов. По сути в нем ограничена ответственность технарей по части скорости восстановления.

Аудит мониторинга

Мы составили полное представление об инфраструктуре. Теперь нужно понять, все ли мы видим - нет ли у нас слепых зон в мониторинге.

Метрики мониторинга - это четыре слоя абстракции:

• Базовые метрики: CPU, RAM, диск, загрузка сети и т.п.

• Здоровье приложений: что приложение работает на определенном порту и доступно в данный момент.

• Здоровье связей сервисов: мониторинг, как правило, находится снаружи и не всегда понимает, способно ли приложение сходить в свою БД или во внешний сервис по API, нужны дополнительные метрики, чтобы покрыть и эти возможные точки отказа.

• Бизнесовые метрики: например, скорость прохождения транзакции через последовательность статусов.

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

Преобразования в инфраструктуре

Описанные исследования в типовой инфраструктуре с Kubernetes в среднем занимают 80 - 140 часов. Это время необходимо на то, чтобы везде пройти и все посмотреть. 

Disaster recovery план - это набор документов и инструкций, в которых указано, как восстанавливать сервис. Он создается по заполненным таблицам SLO.

В процессе скорее всего всплывут самые “больные” точки - ошибки в построении инфраструктуры, которые влияют на ее отказоустойчивость. Мы наглядно видим, где требования от бизнеса, собранные на первом шаге, попросту невыполнимы. Все эти моменты нужно явно прописать в журнал рисков и отнести клиенту.

Из собранной информации понятно, какие действия надо совершить, чтобы скорость восстановления в случае аварии все-таки соответствовала бизнес-требованиям. Именно бизнес-требования определяют, какими инструментами мы будем решать эту задачу. 

Допустим, необходимо покрыть кодом инфраструктуру, создать Ansible плейбуки, чтобы с помощью них быстро поднимать новые сервера. Или же нужно подключить технологии горизонтального масштабирования (любые технологии избыточности: для баз данных - кластеризация, для серверов - дублирование, для данных на диске - облачные сервисы, типа S3, а то и их сочетания и т.п.). А возможно, требованиям удовлетворит только отложенная реплика в другом ЦОД, данные в которую отправляются в режиме реального времени.

Важно понимать, что любые технологии избыточности стоят денег. Та же “живая” реплика потребует оплаты второго ЦОД (х2 стоимости инфраструктуры). И в этот момент начинается управление рисками. Возможно, в каких-то моментах можно отойти от первоначальных бизнес-требований, но использовать какие-то более дешевы гибридные комбинации, позволяющие чуть медленнее (но дешевле) восстанавливаться после падений.

Решения о том, где именно можно изменить требования, принимает бизнес. И здесь важно наладить коммуникацию технарей с бизнесом. Но поговорим об этом подробнее мы в следующей части.

Тестирование и валидация плана

Само по себе наличие disaster recovery плана и подготовленные инструменты уже помогают “выйти из штопора” в случае аварии. Но на разовом написании набора документов эта работа не заканчивается.

Тут работает принцип 20 на 80: 20% усилий дают 80% результата. И написание disaster recovery плана - те самые 20% работы. Тестирование и валидация этого плана - входят уже в 80% работы, которые дадут только 20% результата.

Но это вопрос культуры в компании. Важно, чтобы disaster recovery план соответствовал действительности. А значит, нужно выработать правильный подход к поставарийному анализу. Каждая авария - возможность научиться избегать аналогичных проблем в будущем. Всегда нужно разбирать инциденты: что произошло, почему, можно ли было сделать нечто, чтобы этого не произошло и т.п. Результаты анализа стоит взять в работу и также внести в disaster recovery план.

Параллельно необходимо обучать персонал и поддерживать их знания на актуальном уровне. И это тоже история про внутреннюю культуру работы.

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