Когда под ударом инфраструктура: 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 октября наша команда работала в аварийном режиме, отдавая максимум сил тому, чтобы вы не ощущали последствий инцидента, а сервисы оставались быстрыми и надежными.
🔋Сейчас все подразделения уже вернулись к штатному расписанию. Ваши интеграции, данные и бизнес-процессы защищены сильнее, чем когда-либо.
Мы готовы к любым внешним штормам, чтобы ваш бизнес продолжал работать непрерывно 🚀
🧑🏻💻В IT-сообществе активно обсуждают физические риски для дата-центров: что делать бизнесу, когда атаки выводят из строя инфраструктуру целых облачных площадок?
🦾 Для АО «Агредатор» этот вопрос в октябре перестал быть теоретическим. Делимся тем, как была устроена наша система, с чем мы столкнулись на практике и к каким фундаментальным архитектурным решениям пришли.
📂 Что было до инцидента
Следуя современным стандартам надёжности, инфраструктура «Агредатора» изначально строилась как высокодоступная, с распределением по трём независимым зонам доступности. СУБД работали в кластерных режимах с автоматическим переключением при сбоях (failover).
📌Однако все ключевые узлы были сосредоточены у одного облачного провайдера. И когда в октябре в результате прямых атак последовательно были физически уничтожены сразу две зоны дата-центров, система столкнулась с потерей кворума.
📛 Работа на опережение и хронология восстановления
После первого удара 8 октября мы оценили риски повторной атаки и сразу запустили переход на мультиоблачную архитектуру.
Задача осложнялась тем, что специфика нашей работы с критически важными сервисами исключает использование большинства типовых площадок: нам подходят только дата-центры, отвечающие самым строгим стандартам информационной безопасности и государственной защиты данных.
⭐️Главный приоритет и результат:
Когда в ночь на 11 октября был выведен из строя второй дата-центр, эта подготовка дала результат: мы не начинали с нуля.
✔️ 11 октября — восстановили доступ к основному API.
✔️К полуночи 12 октября — заработало большинство сервисов с временными ограничениями.
✔️13 октября — работа платформы была полностью восстановлена, все ограничения сняты.
✔️ В результате восстановительных работ мы сохранили важные данные клиентов в полном объеме на момент уничтожения второго ЦОД: историю данных, прикрепленные файлы, XML-логи взаимодействия со СМЭВ и ЕПГУ-АПИ, а также данные по исполнительным производствам.
⚠️ Главные архитектурные последствия и трансформация
Беспрецедентный инцидент заставил нас кардинально пересмотреть подход к инфраструктуре и зафиксировать четыре ключевых принципа:
1. Полный отказ от Managed-ресурсов. Мы полностью отказались от управляемых СУБД (PostgreSQL) от провайдеров в пользу самостоятельного администрирования. Это вернуло нам прямой контроль над сроками восстановления (RTO) как при локальных сбоях, так и при масштабных катастрофах.
2. Контроль географии и удаленные регионы. Теперь мы контролируем не просто распределение по разным ЦОДам, а физическую географию размещения. Резервные мощности поддерживаются в разных частях страны, включая географически удаленные регионы — например, в Сибири.
3. Ликвидация зависимости от одного провайдера. Мы устранили привязку (vendor lock-in) к единственному поставщику. Постоянный горячий резерв вычислительных мощностей теперь распределен между независимыми операторами федерального уровня, полностью отвечающими нашим повышенным требованиям к надежности и защищенности данных.
4. Disaster Recovery, проверенный на практике. Все регламенты аварийного восстановления прошли валидацию не на бумаге или учениях, а в реальной глобальной аварии инфраструктуры.
✅ Главный приоритет для нас — безопасность вашего бизнеса и непрерывность критически важных процессов.
🔥 С момента инцидента 11 октября и вплоть до 13 октября наша команда работала в аварийном режиме, отдавая максимум сил тому, чтобы вы не ощущали последствий инцидента, а сервисы оставались быстрыми и надежными.
🔋Сейчас все подразделения уже вернулись к штатному расписанию. Ваши интеграции, данные и бизнес-процессы защищены сильнее, чем когда-либо.
Мы готовы к любым внешним штормам, чтобы ваш бизнес продолжал работать непрерывно 🚀