Yandex Cloud — план аварийного восстановления при проблемах нескольких зон
Yandex Cloud: аварийное восстановление при проблемах нескольких зон
Дата подготовки и проверки источников: 11 октября 2026 года. Это редакционный runbook для владельца приложения, а не исполненный сценарий миграции. Восстановление VM, Kubernetes, баз и переключение DNS на реальных системах при подготовке не выполнялись. Версии и доступность конкретного клиентского окружения не установлены.
Хронология событий 8–11 октября хранится отдельно. Актуальное предупреждение провайдера рекомендует использовать альтернативные площадки; работоспособность каждого выбранного сервиса всё равно требуется проверить. Не переносите вывод «API доступен» на сохранность данных и возможность восстановления.
Перед началом: условия безопасной работы
Назначьте ответственного за инцидент и согласующего переключение. Зафиксируйте допустимую потерю данных по времени (RPO) и целевой срок восстановления (RTO). Цели бизнеса не являются измеренным результатом: фактическое время и состояние данных записывают после проверки.
Работайте только с ресурсами, на управление которыми у вас есть полномочия. Сохраните идентификаторы облака, проекта, кластера, дисков и версий в закрытом журнале. Не удаляйте источник, диски, snapshots или последние копии для «освобождения квоты». Не повторяйте массово команды создания и не применяйте Terraform plan, содержащий неожиданные удаления.
1. Инвентаризация зависимостей
Проверьте не только VM: DNS, CDN/балансировщик, БД, объекты и пользовательские файлы, очереди, IAM, KMS/Lockbox, реестр образов, CI, мониторинг и канал связи с командой. Для каждого отметьте «доступно и проверено», «ошибка» или «не проверено», время, источник наблюдения и способ восстановления.
План и необходимые инструкции должны быть доступны вне затронутой инфраструктуры. Секреты храните в защищённом доступном хранилище, не в публичном репозитории или тексте PR. Общий подход к подготовке, ручным контрольным точкам и учениям описан в Microsoft Well-Architected: Disaster Recovery; это общие принципы, не обещание совместимости Azure-инструментов с Yandex Cloud.
2. Установить пригодность резервной копии
| Проверка | Условие перехода к восстановлению |
|---|---|
| Доступ | Можно прочитать саму копию и необходимые части цепочки, а не только запись в каталоге backup |
| Свежесть | Известна точка консистентного восстановления и принята возможная потеря более новых данных |
| Целостность | Проверены доступные контрольные суммы и формат; приложение или СУБД сможет прочитать восстановленные данные |
| Ключи | Есть законный доступ к необходимому расшифрованию; наличие зашифрованного объекта не равно доступности его содержимого |
| Совместимость | Сверены версии СУБД, расширения, архитектура и формат образов; snapshot одного облака не объявлен переносимым в другое |
| Независимость | Копия и доступ к ней не зависят только от той же отказавшей зоны и тех же недоступных служб |
Сохраните исходную копию неизменной; восстанавливайте в новый изолированный экземпляр. Не считайте физическое повреждение ЦОД доказательством потери всех копий, но и не обещайте восстановление до чтения и проверки конкретной копии. При отсутствии пригодного источника данных остановите восстановление записи: зафиксируйте ограничение и согласуйте допустимый временный режим сервиса.
3. Выбрать площадку и проверить ресурсы
Многозонность в одном регионе не заменяет независимый план восстановления. Другая зона, другой регион и другой провайдер — разные варианты, каждый требует проверки сети, доступа, свободной ёмкости, форматов backup, стоимости и ваших ограничений на размещение данных.
Начните с минимальной согласованной конфигурации и проверки зависимостей, не с массового развёртывания. Обращение к альтернативному поставщику не гарантирует наличия CPU, дисков, IP и поддержки. Проверьте также получение образов и доступ к секретам без обращения к недоступным сервисам источника.
Квоты: текущее ограничение отдельно от плановых изменений
10 октября провайдер объявил ручное управление квотами. В обновлении 11 октября сообщается уже о приостановке выдачи дополнительных квот. Поэтому расширение лимита нельзя закладывать как гарантированный шаг восстановления.
Документация Compute Cloud, обновлённая 2 октября, указывает плановый переход девяти квот с регионального на зональный уровень 12 октября 2026 года. На дату этой статьи это ещё будущая дата из документации, а не проверенное изменение в аккаунтах во время аварии. Проверяйте фактические ограничения отдельно для выбранной зоны. Квота не гарантирует физического наличия ресурсов; резерв ёмкости внутри зоны не является резервной площадкой на случай её отказа.
4. Восстановить данные и приложение без конкурирующей записи
| Компонент | Порядок проверки | Что нельзя считать достаточным |
|---|---|---|
| VM | Новая совместимая VM, восстановление данных, конфигурации, сетевых правил и зависимостей | Запуск процесса или успешный SSH |
| PostgreSQL / другие СУБД | Новый экземпляр из поддерживаемого backup; проверить версию, расширения, точку восстановления и основные данные | Наличие HA-реплики, которая может быть read-only, отставать или быть недоступной |
| Kubernetes | Манифесты, CRD, версии, registry, секреты, конфигурация сети и отдельное восстановление постоянных данных | Создание группы узлов без данных PVC и внешних зависимостей |
| Object Storage | Проверить чтение объектов и нужную приложению запись в отдельный тестовый префикс с разрешения владельца | Один успешный GET или наличие списка объектов |
| Очереди и задания | Согласовать повторную обработку, дедупликацию и включение воркеров после проверки БД | Автоматический старт двух независимых наборов потребителей |
До допуска записи установите единственный актуальный источник данных. Изолируйте прежний пишущий экземпляр штатным способом либо подтвердите его fencing; недоступность по одному сетевому маршруту не доказывает, что он перестал принимать записи. При сомнении оставьте восстановленный сервис в согласованном read-only/maintenance-режиме, чтобы не получить расходящиеся базы.
Анонсированную ранее возможность удаления недоступных хостов Managed Databases нельзя применять без проверки кворума, роли узла, целостности данных и актуальных указаний поддержки. Перенос управляющих компонентов Kubernetes не переносит автоматически пользовательские данные.
5. Проверить и согласовать переключение
Через изолированный тестовый адрес проверьте TLS, авторизацию, типовые страницы, чтение и безопасную тестовую запись, загрузку файлов, фоновые задания и интеграции. Для сайта дополнительно проверьте HTTP-коды, robots, canonical, sitemap и отсутствие случайного noindex. Успех должен включать ожидаемое содержимое, а не только код 200.
Только после подтверждения данных и функциональности согласуйте изменение DNS, балансировщика или маршрута. Запишите прежние и новые значения; учитывайте кеширование и существующие соединения. Не ослабляйте TLS, IAM или сетевые ограничения ради ускорения миграции.
Проверяйте результат из независимых сетей. После появления новых записей на резервной площадке откат маршрута на прежнюю БД без сверки данных недопустим. Восстановившаяся основная площадка не должна автоматически включаться как второй writer.
6. Критерии завершения и учебная проверка
Инцидент приложения можно закрывать после согласованной проверки данных, бизнес-сценариев и мониторинга. Зафиксируйте фактические время восстановления, точку данных, оставшиеся ограничения и план последующей сверки. Резервная площадка также нуждается в новом backup и проверке восстановления.
Для проверки runbook используйте отдельную учебную среду: небольшой набор синтетических данных с известными контрольными значениями, резервную копию, новый изолированный экземпляр, тестовые DNS-имена и отключённые реальные платежи/рассылки. Сравните восстановленные данные и сценарии, измерьте время, проверьте отсутствие двух пишущих экземпляров и только затем согласуйте очистку учебных ресурсов.
Статус проверки этого документа: источники и логика контрольных точек проверены редакционно; такое учение ещё не выполнено. Числа RPO/RTO, гарантии сохранности и успешная миграция конкретного приложения не заявляются.