Привет, Хабр! Меня зовут Илья. Долгое время я работал в финтехах и у облачного провайдера. Занимался сопровождением информационных систем, причём не как инфраструктурщик, а как специалист по поддержке целых автоматизированных систем. То есть смотрел на ИТ не с уровня отдельного сервера, а с уровня «работает ли сервис для бизнеса и клиента».
И сразу, пока вы не пролистали до конца, вопрос к вам.
Друзья айтишники, вспомните момент, когда DRP действительно понадобился. Что пошло не так? Бэкап, который не восстановился? Резервная площадка, на которой «забыли» один сервис? Регламент, который лежал на той самой упавшей файловой шаре? Напишите в комментариях свои фэйлы. Чужие ошибки учат лучше любых методичек, а для кого‑то ваш комментарий станет поводом проверить свой план до аварии, а не после.
А теперь поговорим о том, как строятся планы DRP и почему наличие документа ещё не означает, что вы восстановитесь.
Как DRP из «умного слова» стал обязательным
На моей практике планы аварийного восстановления (Disaster Recovery Plan, DRP) получили большую популяризацию после событий 2022 года. Причём даже в 2023-м далеко не весь рынок понимал, что такое DRP и зачем он нужен, если «у нас и так всё зарезервировано».
В 2022–2024 году за тему всерьёз взялись банки и финтех, хотя нормативная база для Указания ЦБ № 2194-У сформировалась ещё в 2009 году. Появились положения о непрерывности деятельности, и DRP стал обязательной частью стратегии восстановления ИТ. Не «хорошей практикой на будущее», а документом, который у тебя спросят.
Проблема в том, что когда документ становится обязательным, его начинают писать для проверяющего, а не для дежурного инженера, который будет открывать его в три часа ночи. Но я верю, что все мои коллеги по цеху отрабатывали на максимуме профессионализма.
От чего вообще спасает DRP
Сценариев много, но я пройдусь по самым интересным и актуальным в наше непростое время.
Потеря данных по любой причине. Ошибка администрирования, человеческий фактор, авария конкретного юнита в компонентах информационной системы. Классика, которая случается чаще, чем хотелось бы.
Потеря важного компонента информационной системы. Необязательно данных. Просто какой‑то компонент перестал работать, а без него не работает и вся цепочка.
Потеря данных конфигурации или бизнес‑данных из‑за действий злоумышленников. Этот сценарий я бы выделил в отдельный блок DRP просто потому, что он сейчас максимально актуален на фоне участившихся атак шифровальщиков.
Потеря существенной части информационной системы. Речь о ситуации, когда разом становятся недоступны компоненты, данные и целые сегменты инфраструктуры. Например, когда отказывает целый ЦОД.
На последнем пункте остановлюсь подробнее, потому что у рынка есть свежий и очень наглядный пример с Яндексом на 08 октября 2026 года.
Когда «падает» целый ЦОД: что увидели пользователи
08 октября 2026 года отказал один из дата‑центров Яндекса, на ресурсах которого работает Yandex Cloud. Причины здесь обсуждать не буду: для темы DRP они вторичны. Важно другое: что произошло с информационными системами, которые жили в этом ЦОДе.
Тут копировать коллегу с Хабра не буду, посмотрите историчность и комментарии к посту.
Список всех пострадавших, боюсь, мы не увидим, но там точно будут Банки, доставка, аптеки, ритейл. Это не «один провайдер прилёг», это десятки компаний, у которых в один момент перестали работать ИТ‑системы, потому что все их критичные компоненты физически находились в одной точке. По сообщению Яндекс на странице инцидента, он начался в 01:31.
Данные, скорее всего, частично восстановят, также как питание и связь, ЦОД вернётся в строй. Но длительная недоступность информационной системы, а тут целых её компонент, для бизнеса означает потерянные заказы, сорванные платежи и звонки злых клиентов в поддержку. Именно этого DRP и должен был помочь избежать. Формально он, возможно, у кого‑то был. Однако, приложения, которые я отслеживал не работали длительное время днём 8 октября 2026.
Золотые правила DRP, которые работают в бою
Все перечисленные угрозы (повторюсь, это далеко не полный список) превращаются в этапы восстановления информационной системы. И здесь есть несколько правил, без которых план остаётся бумажкой.
Сначала RTO и RPO, потом всё остальное. Сколько система может лежать и сколько данных вы готовы потерять. Эти цифры согласует бизнес, а не админ или целое подразделение сопровождения. Без них непонятно, нужен вам горячий резерв или достаточно ночного бэкапа и инфраструктуры как код (IaC).
Полная карта зависимостей. Не «у нас есть приложение и БД», а всё: DNS, сертификаты, очереди, внешние API, сервисы аутентификации, лицензии, секреты. Как правило, DRP ломается именно на компоненте, о котором никто не вспомнил.
Мультицод размещение. Если все критичные компоненты находятся в одном ЦОДе или одной зоне доступности, у вас нет DRP для сценария «отказ площадки». Критичные системы должны быть разнесены минимум на две независимые площадки, а переключение между ними должно быть проверено, а не предполагаться.
Частое резервирование. Частота бэкапов и репликации определяется вашим RPO. Бэкап раз в сутки означает, что вы готовы потерять до суток работы. Плюс копии должны лежать вне основной площадки и, на случай атак злоумышленников, быть защищены от изменения и удаления.
Бэкап, который ни разу не восстанавливали, не бэкап. Регулярно восстанавливайте данные в изолированную среду и замеряйте реальное время.
План доступен, когда всё лежит. Если регламент восстановления лежит в Confluence, который крутится в том же ЦОДе, в момент аварии плана у вас нет.
Люди и роли. Кто принимает решение о переключении, кто выполняет, как связаться, если корпоративный мессенджер тоже недоступен. Контакты должны быть актуальными, а у ключевых ролей должны быть замены.
Проверьте свой DRP до того, как его проверит авария
А теперь главное, ради чего я всё это пишу.
DRP, который ни разу не проверяли на практике, это гипотеза. Он может сработать, а может и нет, и узнаете вы об этом в худший момент из возможных.
Поэтому мой совет простой: проведите аудит инфраструктуры и по‑настоящему проверьте, сработает ли ваш план. Не «прочитать документ на совещании», а выключить площадку на учениях и посмотреть, что будет.
Для начала задайте себе несколько честных вопросов:
Где физически находятся все компоненты критичных систем? Нет ли среди них таких, что живут только в одном ЦОДе или одной зоне?
Когда вы последний раз восстанавливали систему из резервной копии целиком, а не отдельный файл?
Совпадает ли реальное время восстановления с RTO, написанным в плане?
Переживут ли ваши резервные копии атаку, при которой у злоумышленника есть права администратора?
Сможет ли дежурный инженер выполнить план, если автор плана в отпуске?
Когда план последний раз обновлялся и совпадает ли он с текущей архитектурой?
Если хотя бы на один вопрос ответ «не уверен», значит, пора проводить учения. Лучше потратить выходной на плановое переключение, чем десять часов на внеплановое восстановление под звонки руководства.
Вместо заключения
Итак, ещё раз вопрос к сообществу. Друзья айтишники, напишите в комментариях, какие на вашем опыте были ошибки составления DRP, которые привели к невозможности его применения или не дали нужного эффекта. Соберём коллекцию граблей, на которые лучше не наступать.
А если у вас уже есть DRP и хочется понять, выдержит ли он реальную аварию, я готов сформировать быстрое «второе мнение» по вашему плану. Посмотрю на него глазами человека, который много лет сопровождал системы в финтехе и облаке, и подсвечу слабые места. Пишите мне в личку @grayhoax