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

Что произошло и почему потеря данных оказалась критичной

Первый сбой произошёл 8 октября. Инфраструктура полностью зависела от одного дата-центра. Резервные копии делались раз в сутки, но между бэкапами накопились изменения за 20 часов. Когда площадка стала недоступна, восстановить актуальное состояние было невозможно — пришлось откатываться на последнюю копию. Это сразу показало слабое место: отсутствие репликации в реальном времени и географического разнесения.

Через трое суток после переезда в соседнюю зону того же провайдера отказала и вторая площадка. Стало очевидно, что размещение в одном облаке, пусть и в разных зонах, не даёт достаточной устойчивости. Команда приняла решение переезжать к другому провайдеру, а параллельно ускорить миграцию в Kubernetes, начатую годом ранее.

Как проходил переезд и что помогло ускориться

Первые часы после второго сбоя ушли на оценку масштаба: какие сервисы критичны, какие можно временно отключить. Быстро выяснилось, что часть компонентов уже была контейнеризирована, но не все. Миграцию в Kubernetes завершили за двое суток — помогли заранее подготовленные манифесты и то, что команда уже имела опыт работы с оркестратором, пусть и не в полном объёме.

  • Приоритизация сервисов: сначала поднимали то, что влияет на выручку и доступность для пользователей.
  • Использование инфраструктуры как кода: конфигурации хранились в репозитории, что позволило развернуть окружение у нового провайдера почти автоматически.
  • Отказ от монолитных виртуальных машин в пользу контейнеров — это ускорило горизонтальное масштабирование и упростило переключение между площадками.
  • Чёткое распределение ролей: часть команды занималась восстановлением данных, часть — настройкой сети и доступов у нового провайдера.

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

Какие решения приняли после аварии

Сейчас базы данных хранятся в двух копиях у разных провайдеров. Это не полноценная мультимастер-репликация, но позволяет пережить отказ одной площадки без потери данных. Резервное копирование участилось: теперь бэкапы делаются чаще, а критичные данные дополнительно реплицируются в реальном времени.

Кроме того, команда пересмотрела подход к выбору облачного провайдера. Вот критерии, которые теперь считаются обязательными:

  • Наличие как минимум трёх зон доступности в регионе.
  • Прозрачные SLA с финансовой ответственностью за простои.
  • Возможность быстрого восстановления через API и инфраструктуру как код.
  • Поддержка Kubernetes «из коробки» или managed-сервисов, снижающих операционную нагрузку.
  • Географическая распределённость: возможность разместить копии данных в разных странах или регионах.

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

Типичные ошибки и выводы для команд

История показывает, что даже при наличии резервных копий можно потерять данные, если не настроена репликация. Вот несколько ошибок, которые стоили времени и нервов:

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

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

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