Когда под ударом инфраструктура: Disaster Recovery и восстановление после атак🛡

🧑🏻‍💻В IT-сообществе активно обсуждают физические риски для дата-центров: что делать бизнесу, когда атаки выводят из строя инфраструктуру целых облачных площадок?

🦾 Для АО «Агредатор» этот вопрос в октябре перестал быть теоретическим. Делимся тем, как была устроена наша система, с чем мы столкнулись на практике и к каким фундаментальным архитектурным решениям пришли.

📂 Что было до инцидента
Следуя современным стандартам надёжности, инфраструктура «Агредатора» изначально строилась как высокодоступная, с распределением по трём независимым зонам доступности. СУБД работали в кластерных режимах с автоматическим переключением при сбоях (failover).

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

📛 Работа на опережение и хронология восстановления

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

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

⭐️Главный приоритет и результат:
Когда в ночь на 11 октября был выведен из строя второй дата-центр, эта подготовка дала результат: мы не начинали с нуля.

✔️ 11 октября — восстановили доступ к основному API.

✔️К полуночи 12 октября — заработало большинство сервисов с временными ограничениями.

✔️13 октября — работа платформы была полностью восстановлена, все ограничения сняты.

✔️ В результате восстановительных работ мы сохранили важные данные клиентов в полном объеме на момент уничтожения второго ЦОД: историю данных, прикрепленные файлы, XML-логи взаимодействия со СМЭВ и ЕПГУ-АПИ, а также данные по исполнительным производствам.

⚠️ Главные архитектурные последствия и трансформация

Беспрецедентный инцидент заставил нас кардинально пересмотреть подход к инфраструктуре и зафиксировать четыре ключевых принципа:

1. Полный отказ от Managed-ресурсов. Мы полностью отказались от управляемых СУБД (PostgreSQL) от провайдеров в пользу самостоятельного администрирования. Это вернуло нам прямой контроль над сроками восстановления (RTO) как при локальных сбоях, так и при масштабных катастрофах.

2. Контроль географии и удаленные регионы. Теперь мы контролируем не просто распределение по разным ЦОДам, а физическую географию размещения. Резервные мощности поддерживаются в разных частях страны, включая географически удаленные регионы — например, в Сибири.

3. Ликвидация зависимости от одного провайдера. Мы устранили привязку (vendor lock-in) к единственному поставщику. Постоянный горячий резерв вычислительных мощностей теперь распределен между независимыми операторами федерального уровня, полностью отвечающими нашим повышенным требованиям к надежности и защищенности данных.

4. Disaster Recovery, проверенный на практике. Все регламенты аварийного восстановления прошли валидацию не на бумаге или учениях, а в реальной глобальной аварии инфраструктуры.

✅ Главный приоритет для нас — безопасность вашего бизнеса и непрерывность критически важных процессов.

🔥 С момента инцидента 11 октября и вплоть до 13 октября наша команда работала в аварийном режиме, отдавая максимум сил тому, чтобы вы не ощущали последствий инцидента, а сервисы оставались быстрыми и надежными.

🔋Сейчас все подразделения уже вернулись к штатному расписанию. Ваши интеграции, данные и бизнес-процессы защищены сильнее, чем когда-либо.

Мы готовы к любым внешним штормам, чтобы ваш бизнес продолжал работать непрерывно 🚀