Настраиваем резервное копирование, из которого действительно восстанавливаются, и план на случай, если площадка или облачный провайдер недоступны: сколько данных допустимо потерять, за какое время поднимаемся и кто что делает. Проверяем план учениями до аварии, а не во время неё.
Ответит инженер, а не менеджер, — в течение рабочего дня.
Официальные партнёры облаков
Неизвестно, поднимется ли база из копии и сколько это займёт.
Или в том же дата-центре. Они защищают от ошибки, но не от недоступности площадки или платформы.
Бизнес не знает, сколько данных может потерять и сколько часов простоя выдержит, поэтому неясно, какой резерв нужен.
Секреты, DNS, конфигурации и порядок запуска сервисов нигде не записаны.
Вместе с бизнесом определяем, какие системы критичны, сколько данных допустимо потерять и за какое время нужно восстановиться.
Несколько копий в разных хранилищах, минимум одна — вне основной площадки или у другого провайдера. Неизменяемые копии от шифровальщиков.
Базы с восстановлением на момент времени, объектное хранилище, тома и манифесты Kubernetes, секреты, код инфраструктуры.
Алерт, если копия не создалась, устарела или аномально изменилась в размере. Об испорченном бэкапе нужно узнать сразу.
Пошаговый сценарий: кто принимает решение о переключении, в каком порядке поднимать сервисы, как переключить DNS и вернуться обратно.
Восстанавливаем систему из копий в изолированном окружении и замеряем реальные RPO и RTO.
Осенью 2026 года сервисы ряда компаний в облаке были недоступны больше недели, а создать ресурсы взамен было нельзя: провайдер ограничил выдачу квот, а у других облаков вырос спрос. Восстановиться быстрее можно, если заранее есть копия данных у другого провайдера и инфраструктура, описанная кодом.
Они защищают от отказа площадки, но не от ограничений самой платформы.
Резерв нужно держать или бронировать заранее, а не создавать при сбое.
Чтобы подняться из бэкапа, нужны инфраструктура в коде, секреты и план.
Значения RPO и RTO — пример. Реальные цифры зависят от объёма данных, архитектуры и бюджета: мы фиксируем их в проекте и проверяем учениями.
Копии в другом регионе или облаке, инфраструктура в коде, поднимаем по требованию. RPO — часы, RTO — от часов до суток. Для внутренних и некритичных систем.
Данные реплицируются во второй контур, вычисления минимальные или выключены. RPO — минуты, RTO — часы. Для большинства продуктовых систем.
Уменьшенная копия инфраструктуры постоянно работает, реплика БД в реальном времени. RPO и RTO — минуты. Для платежей, заказов, клиентских API.
Две площадки обслуживают трафик одновременно. RPO и RTO близки к нулю. Для самых критичных контуров — дорого и сложно, нужно не всем.
Инфраструктура росла стихийно: настройки жили на серверах, изменения нельзя было отследить и повторить.
Высокие требования к непрерывности: сервисы нельзя останавливать, а проблемы нужно видеть раньше пользователей.
Система работала на своём железе, обслуживание дорожало, запас мощности кончался.
TEAM.md
Нас трое, и это осознанно: с вами общаются и работают одни и те же инженеры, без прослойки менеджеров и передачи задач по цепочке.
Основатель
Более 20 лет в IT. В 2014 основал Last.Backend — свой оркестратор контейнеров появился практически одновременно с Kubernetes.
Основатель
7 лет в DevOps, десятки реализованных проектов — от первого пайплайна до production под нагрузкой.
Основатель
5 лет в DevOps. Берёт самые сложные задачи и доводит их до конца.
Опишите, что происходит с инфраструктурой сейчас, — ответим в течение дня и предложим бесплатный разбор.