Строим резервный или рабочий контур у второго облачного провайдера, чтобы недоступность одного облака, региона или дата-центра не останавливала бизнес. Инфраструктура описана кодом под каждого провайдера, данные реплицируются, переключение отрепетировано.
Ответит инженер, а не менеджер, — в течение рабочего дня.
Официальные партнёры облаков
Если его платформа работает с ограничениями, ни переключиться, ни быстро переехать некуда.
Модули одного провайдера нельзя просто применить к другому — их придётся переписывать в момент аварии.
Аналога у другого провайдера нет, и переносить такие сервисы долго.
Крупные клиенты и отраслевые требования всё чаще спрашивают про резервную площадку и план непрерывности.
Сравниваем провайдеров по географии, сервисам, цене и наличию мощности. Проверяем адреса ЦОД: разные бренды иногда стоят в одном здании.
Terraform-модули для основного и резервного облака с одинаковой структурой окружений, Kubernetes как общий слой для приложений.
Для критичного пути — то, что есть у обоих провайдеров: PostgreSQL, S3, Kafka, Kubernetes. Проприетарное — там, где его потеря не остановит бизнес.
Репликация баз, синхронизация объектного хранилища, зеркалирование очередей и контроль отставания реплики.
DNS-failover с проверками доступности, короткий TTL, резервный DNS-провайдер. Порядок переключения и возврата описан в runbook.
Регулярно поднимаем нагрузку во втором облаке и следим, чтобы резервный контур не отставал по версиям и конфигурации.
Мультиоблако не обязательно вдвое дороже: формат подбираем по допустимому простою и считаем стоимость до начала работ.
Копии и код инфраструктуры во втором облаке, вычисления поднимаются при аварии. Минимальная стоимость, восстановление дольше.
Реплика базы и минимальный набор сервисов постоянно работают во втором облаке и масштабируются при переключении.
Оба облака обслуживают трафик. Максимальная устойчивость, но и наибольшие стоимость и сложность.
Свои серверы и облако — или облако как резервная площадка для собственного ЦОД.
Нагрузка идёт пиками — в дни запуска курсов, — а платить за постоянный запас мощности не хотелось.
Развёртывания у разных заказчиков в закрытых контурах приходилось повторять руками.
Система работала на своём железе, обслуживание дорожало, запас мощности кончался.
TEAM.md
Нас трое, и это осознанно: с вами общаются и работают одни и те же инженеры, без прослойки менеджеров и передачи задач по цепочке.
Основатель
Более 20 лет в IT. В 2014 основал Last.Backend — свой оркестратор контейнеров появился практически одновременно с Kubernetes.
Основатель
7 лет в DevOps, десятки реализованных проектов — от первого пайплайна до production под нагрузкой.
Основатель
5 лет в DevOps. Берёт самые сложные задачи и доводит их до конца.
Опишите, что происходит с инфраструктурой сейчас, — ответим в течение дня и предложим бесплатный разбор.