Все бэкапы в одном облаке? Что показали сбои Yandex Cloud и как защитить бизнес

Мы в IQ Dev занимаемся DevOps-аутсорсингом и аутстаффингом: настраиваем CI/CD, Kubernetes и инфраструктуру как код, мониторинг и отказоустойчивость, переносим системы между облаками и физическими серверами. Ниже практическая часть: что проверить, как действовать сейчас и как подготовиться, чтобы следующий сбой не остановил бизнес.

Коротко:

• За одну неделю октября пострадали три площадки «Яндекса», часть зон Yandex Cloud выбыла из работы.
• Схема «несколько зон в одном облаке» защищает не от всего: бэкапы, DNS, секреты и управляющие компоненты часто живут у того же провайдера.
• Первым делом: начните с аудита, чтобы определить масштаб работы, далее вынесите свежий бэкап к другому провайдеру, проверьте, что он разворачивается, и вынесите DNS.
• Затем: опишите окружение кодом и подготовьте резервный контур.
• Чтобы не повторить проблему: закрепите за инфраструктурой владельца и раз в квартал проверяйте восстановление. Здесь помогает DevOps-аудит.
• Паническая миграция «всего и сразу» опаснее, чем ее отсутствие.

Что произошло

С 8 октября «Яндекс» сообщает о повреждениях инфраструктуры на нескольких своих площадках: сначала в Сасово, затем в Калуге и во Владимире. Часть сервисов Yandex Cloud работает с перебоями или недоступна. Для клиентов, у которых системы и бэкапы стояли на одной площадке, это означает остановку работы. «Яндекс» договорился с Selectel, K2Cloud и VK Cloud об ускоренном размещении и резервировании ресурсов клиентов.

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

Причины мы не разбираем: важно, что площадка может выбыть из работы, и к этому нужно быть готовым заранее.

Почему несколько зон не всегда спасают

Облако делится на зоны: это отдельные площадки (дата-центры) внутри одного провайдера. Мультизональность остается правильной практикой: тем, кто был в нескольких зонах, переключение помогло. Но в этой истории проявились ограничения.

• Емкость конечна. Когда выбывает несколько площадок, все клиенты одновременно пытаются подняться в оставшихся зонах и у других провайдеров. По сообщениям из разборов инцидента, выдачу дополнительных ресурсов пришлось ограничивать вручную. Бэкап негде развернуть, если нет квот.
• Управляющие компоненты привязаны к зоне. Если мастер-ноды Kubernetes или хосты управляемой БД были в выбывшей зоне, кластер терял управляемость, хотя рабочие ноды еще жили.
• Общие зависимости. IAM, DNS, registry, секреты, мониторинг и бэкапы часто лежат у того же провайдера и падают вместе с ним.
• Одна зона. Самый частый случай: ве стоит в одной зоне, потому что так проще и дешевле.

Вывод: второй провайдер нужен заранее, а не в момент аварии. Аккаунт, сеть, квоты и проверенный способ развернуть сервис должны быть готовы до того, как все остальные побегут туда же.

Регулярный DevOps без штатного отдела: зачем он нужен

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

Признаки инфраструктуры без владельца:

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

Инфраструктура копит долг так же, как код: чем дольше ее не трогают, тем дороже любое изменение, включая вынужденный переезд. Регулярное внимание к ней дешевая страховка, а заодно ускоритель разработки. В проекте по переносу крупной финансовой организации мы параллельно привели в порядок процессы, время деплоя сократилось с 20-30 до 5-7 минут, среднее время восстановления с примерно 40 до 10-15 минут, а покрытие сервисов мониторингом выросло с около 60% до 95-100%. Результат зависит от исходного состояния системы, но направление обычно такое.

Штатный DevOps-отдел для этого нужен не всем. Достаточно, чтобы у инфраструктуры был ответственный и понятный регламент: это может быть devops инженер на аутстаффе, который встроен в команду, или аутсорсинг devops-задач.

Шаг 1. Выясните, где вы на самом деле

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

Ответьте письменно, без «кажется»:

• В каких зонах живут серверы, диски, БД и управляющие компоненты Kubernetes?
• Где бэкапы: в том же аккаунте, в тех же зонах, у того же провайдера?
• Когда вы в последний раз разворачивали проект из бэкапа и сколько это заняло?
• Где DNS и какой у критичных записей TTL?
• Что еще лежит в этом же облаке: registry, секреты, CI-раннеры, мониторинг, почта, капча?
• Сколько простоя (RTO) и потери данных (RPO) допустимо по каждому сервису?

Если на последний вопрос никто не знает ответа, это и есть первая находка аудита.

Шаг 2. Срочные действия

1. Сделайте свежий дамп баз и конфигураций, зашифруйте и отправьте в S3 другого провайдера.
2. Проверьте доступы: кто может зайти в консоль и API, где хранятся ключи (не только в этом же облаке), есть ли аварийные учетки и 2FA.
3. Снизьте TTL критичных DNS-записей до 300 секунд и убедитесь, что у вас есть доступ к DNS-панели вне облака.
4. Составьте список «без чего бизнес стоит»: обычно это 3-5 сервисов.
5. Подготовьте текст сообщения клиентам и независимую страницу статуса.

Не забывайте про безопасность. Именно в такие моменты хакеры ищут слабые места, а в спешке чаще всего можно забыть закрыть внешние доступы и порты, открытые «на время», из-за чего персональные данные становятся уязвимыми. Поэтому на новой площадке сначала настройте сеть и правила доступа, и только потом запускайте сервисы и переносите данные. Закройте все лишнее снаружи и проверьте, что шифрование и права доступа к данным клиентов не ослаблены ради скорости.

Шаг 3. Проверьте, что восстановление работает

• Разверните бэкап на чистой машине у другого провайдера и замерьте время. Это ваша первая настоящая цифра RTO.
• Заведите аккаунт у резервного провайдера, пройдите верификацию и оплату, проверьте квоты. В кризис очереди растут у всех.
• Зафиксируйте окружение: версии ПО, расширения БД, переменные, секреты.

Шаг 4. Подготовьте резервный контур и регламент

• Соберите минимальный резервный контур: репозиторий с Docker Compose, Helm или Terraform, который поднимается из Git плюс бэкап.
• Напишите runbook на 1-2 страницы: кто, что и в каком порядке переключает, кто говорит с клиентами.
• Поставьте внешний мониторинг и алерты вне вашего облака. Если мониторинг стоит на той же площадке, что и сервисы, он падает вместе с ними, и вы не узнаете о проблеме. Поэтому нужен «мониторинг мониторинга» на отдельной площадке, который сообщит, что сервис замолчал.
• Закрепите план минимум за двумя-тремя людьми, а не за одним DevOps-инженером: если он окажется недоступен, срочное восстановление встанет.
• Заранее договоритесь о доступе к команде разработки продукта: DevOps не знает всех нюансов приложения и не справится без разработчиков.

Бэкапы, которые реально спасают

Минимум: три копии, на двух разных носителях, одна из них вне основного провайдера. И главное правило: бэкап, который ни разу не разворачивали, считается несуществующим.

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

Вход в сервис: DNS и защитный слой

• Держите DNS у провайдера, не зависящего от вашего облака, с низким TTL и проверками доступности.
• Любой прокси, CDN или anti-DDoS перед сайтом сам становится зависимостью. Заранее продумайте путь обхода: переключение DNS прямо на origin, закрытый по списку допустимых адресов. Это снижает защиту, поэтому решение должно быть осознанным и описанным в runbook.
• Если вы принимаете заявки или вебхуки, поставьте перед основным сервисом маленький прокси на независимом VPS: при недоступности бэкенда он сохраняет событие в очередь и отвечает отправителю, а потом проигрывает очередь обратно. Не забудьте об идемпотентности (повторная отправка не должна создавать дубли) и о шифровании диска, ведь там окажутся персональные данные.

Уровни резерва: выберите свой

1. Только бэкапы вне провайдера. Восстановление от часов до суток, расходы минимальны. Подходит для некритичных систем.
2. Холодный резерв. Аккаунт, сеть и инфраструктурный код готовы, ресурсы не запущены. Восстановление за часы, расходы почти нулевые.
3. Pilot light. У второго провайдера работают реплика БД и минимум сервисов. Восстановление от десятков минут до часов.
4. Теплый резерв. Уменьшенная копия всей системы, регулярно обновляется. Восстановление за минуты.
5. Active-active. Обе площадки работают в бою. Самое надежное, самое сложное и дорогое, нужно немногим.

Два практических замечания. Kubernetes переносится проще всего, если все описано Helm-чартами и GitOps. А вот репликация из управляемой БД наружу бывает ограничена: проверьте заранее, можно ли настроить логическую репликацию на внешний сервер.

Как не столкнуться с этим снова

Один раз настроить резерв мало: он устаревает вместе с системой. Вот минимальный ритм, который удерживает готовность.

Раз в месяц. Проверяйте внешний мониторинг и разбирайте алерты: ложные и, что важнее, пропущенные. Так вы узнаете о сбое раньше клиентов.

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

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

После каждого инцидента. Разбирайте его без поиска виноватых и сразу правьте инструкцию действий (runbook): так ошибки не повторяются.

И два организационных шага. Назначьте ответственного за аварийное восстановление, даже если это подрядчик. И зафиксируйте допустимые RTO и RPO в документе, который утверждает бизнес, а не только ИТ: тогда расходы на резерв обсуждаются на языке потерь, а не «технических хотелок».

Сколько это стоит и как решать

Сравните два числа: сколько бизнес теряет за час простоя и сколько стоит резерв в месяц. Условный пример: если час простоя обходится в 30 000 ₽, то неделя восстановления с нуля стоит миллионы, и резерв за несколько десятков тысяч в месяц окупается при первом же инциденте. Если простой почти ничего не стоит, хватит уровня 1 или 2.

Чего не делать

• Начинать срочный перенос без аудита и оценки масштаба.
• Переезжать все за одну ночь без тестовой миграции.
• Удалять исходную инфраструктуру до того, как новая проверена.
• Менять одновременно и провайдера, и архитектуру.
• Хранить единственный бэкап рядом с продакшеном.
• Переносить персональные данные за рубеж «потому что быстро». По 152-ФЗ базы с персональными данными граждан РФ должны храниться на территории РФ, детали уточните у юриста.
• Полагаться на SaaS без выгрузки данных. Спросите вендора письменно, где он размещен и где лежат его бэкапы, держите свою регулярную выгрузку и независимый канал связи с клиентами (email, телефон).
• Переносить все подряд. При срочном переносе важно отличать нужное от лишнего: например, логи на 15 ГБ не нужны в первые часы и только замедляют восстановление. Сначала критичные сервисы и данные, остальное потом.
• Оставлять открытыми «временные» доступы и порты после запуска.
• Поручать восстановление одному человеку и не подключать разработчиков.

Наш опыт: как выглядит нормальный перенос

Один из недавних проектов: перенос инфраструктуры финансовой организации на новую площадку. Порядка 25-30 сервисов, PostgreSQL и MongoDB, десятки гигабайт активных транзакционных данных, 8-10 критичных интеграций, среди них платежные шлюзы и антифрод. Мы строили параллельную инфраструктуру: контуры dev, test и prod в Kubernetes, мониторинг на Prometheus, Loki и Grafana, пересобранные CI/CD-пайплайны, ротация секретов и сертификатов. Подготовка и перенос заняли около четырех месяцев, данные переехали без потерь.

Что оказалось решающим:

• карта реально используемых секретов и реестр интеграций до начала работ;
• несколько репетиций восстановления баз и короткое окно для финального переноса изменений;
• переключение сначала небольшой группы клиентов (два дня) и неделя наблюдения за метриками и логами;
• контрольные сверки и ручные чек-листы после переключения трафика.

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

Чем полезен DevOps-аудит и что можно сделать за 2 дня

Аудит нужен не ради отчета, а чтобы заранее узнать, что сломается первым и чем на это ответить. Любая срочная работа начинается именно с него: учесть все невозможно, но без оценки масштаба начинать нельзя. Что вы получаете:

• карту зависимостей: какие сервисы, данные, секреты и интеграции где живут и что от чего зависит;
• реальные RTO и RPO по каждому сервису вместо предположений;
• список рисков с приоритетами: что чинить сегодня, что на этой неделе, что в квартал;
• план резерва под ваш бюджет и допустимый простой;
• оценку затрат на инфраструктуру: где переплата, а где экономия опасна.

Минимальный пакет «базовая живучесть» за 2 дня:

• карта зависимостей и список критичных сервисов;
• автоматический шифрованный бэкап у другого провайдера;
• тест восстановления с замером RTO;
• DNS вне облака и сниженный TTL;
• runbook на несколько страниц.

Старт работ от 2 дней, а глубина зависит от размера системы и формата: берем задачу под ключ (аутсорсинг) или подключаем инженера в вашу команду (аутстаффинг). Штатный DevOps для этого не обязателен.

Частые вопросы

Что делать, если зона недоступна прямо сейчас? Перенести нагрузку в рабочие зоны, если там есть ресурсы, развернуть критичное из внешнего бэкапа у другого провайдера, снизить TTL и переключить DNS, предупредить клиентов.

Можно ли восстановиться, если бэкапы тоже в этом облаке? Только когда вернётся доступ к ним. Поэтому хотя бы одна копия должна лежать у другого провайдера.

Нужен ли multi-cloud? Не всем. Но почти всем нужны бэкапы вне провайдера, DNS вне облака и проверенный план восстановления.