Второй облачный провайдер против лучшей архитектуры: почините это сначала

Сначала определите отказ

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

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

Простой способ отфильтровать шум — записать последние три инцидента простым языком:

• Плохой деплой сломал вход в систему на 27 минут.
• Миграция базы данных заблокировала запись и замедлила приложение.
• Просроченный сертификат вывел API из строя.

Этот короткий список быстро меняет разговор. Если ваши недавние отказы были из‑за релизов, изменений схемы или просрочек — второе облако вас не спасёт. Оно просто даёт вашей команде два места для неверной конфигурации вместо одного.

Размер команды важнее, чем многие основатели хотят признать. Пятеро человек, из которых один несёт большую часть on‑call‑нагрузки, управляют риском совсем иначе, чем компания с круглосуточным покрытием. Бюджет тоже имеет значение. Если вы не можете себе позволить дублированные окружения, кросс‑облачные сети, дополнительный мониторинг и регулярные учения по фейловеру, скорее всего вы не потянете настоящую мультиоблачную операцию.

Задайте четыре прямых вопроса, прежде чем проектировать что‑то новое:

• Какой именно простой мы хотим пережить?
• Как клиенты заметят его первыми?
• Похоже ли что‑нибудь из наших последних трёх инцидентов на это?
• Кто будет поддерживать и тестировать дополнительную настройку каждый месяц?

Для маленьких команд честный ответ часто неприятен. Главный риск обычно не в провайдере. Он в слабом процессе изменений, ненадёжных бэкапах, отсутствующих руктбуках или тонком on‑call‑покрытии. Почините это сначала. Если риск провайдера всё ещё останется главным после этого — тогда второй провайдер начнёт иметь смысл.

Где маленькие команды обычно ломаются первыми

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

Деплои причиняют реальную боль, потому что они происходят постоянно. Облачные сбои редки. Релизы бывают еженедельными, иногда ежедневными. Это обычно делает процесс релиза главным источником риска: нет плана отката, нет проверки в staging, нет feature‑флагов и нет проверки здоровья, которая блокирует плохую версию.

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

Некоторые отказы остаются тихими, пока клиенты не пожалуются. DNS указывает трафик не туда. Сертификат истекает в выходные. Секрет меняется, и фоновые задачи падают, в то время как сайт всё ещё загружается. Эти полу‑сломанные состояния опасны: главная страница выглядит нормально, а платежи не проходят, письма не отправляются или вебхуки не доходят.

Бэкапы дают ложное ощущение безопасности, когда никто не практиковал восстановление. Команды говорят: «у нас есть бэкапы», но никогда не проверяли время полного восстановления. Потом случается инцидент, и они обнаруживают пропавшие файлы, битый дамп или процесс восстановления, который занимает шесть часов вместо сорока минут. Бэкап важен только если команда может восстановить его под давлением.

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

Для маленькой SaaS‑команды пять скучных исправлений обычно дают больше аптайма, чем второй провайдер: безопасные деплои с откатом, проверенное восстановление базы данных, алерты на пользовательские сбои, проверки срока действия сертификатов и секретов, и учения по восстановлению каждые несколько месяцев. Ничто из этого не выглядит эффектно на диаграмме архитектуры. Зато это предотвращает ошибки, которые происходят чаще всего.

Что на самом деле даёт второй провайдер

Второе облако помогает с одной конкретной проблемой: полным провайдерным отказом. Оно также создаёт ежедневную операционную работу, и эта работа появится задолго до любой катастрофы.

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

Данные усложняются очень быстро. Если пользователи пишут данные в обеих облаках, нужны правила синхронизации, обработки конфликтов и восстановления, когда связи падают или задержки растут. Если одна сторона только on‑standby, всё равно нужны свежие бэкапы, проверенные восстановления и ясный ответ, что происходит с недавними записями после фейловера.

Дополнительная работа обычно ложится в одни и те же области: управление доступом, сеть, DNS, балансировка нагрузки, логи, метрики, алерты, репликация, тесты восстановления, руктбуки и ответственность на on‑call. Для небольшой команды этого слишком много.

Планы фейловера тоже лучше выглядят на слайдах, чем в 3 утра. Блок на диаграмме «перенаправить трафик в облако B» не является реальным планом, если инженеры не репетируют его, не засекали по времени и не исправили, что ломается. Задержки DNS, устаревшие данные, истёкшие креденшлы и отсутствующие правила фаервола обычно выявляются на учениях, а не на ревью дизайна.

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

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

Что лучшая архитектура исправит быстрее

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

Начните с availability zones. Если приложение работает только в одной зоне, локальная неисправность всё ещё может вывести всё из строя. Запуск в двух‑трёх зонах обычно снижает риск больше, чем копирование той же хрупкой архитектуры в другое облако.

Состояние — ещё одна распространённая проблема. Если сервис хранит сессии, временные файлы или прогресс задач на одной машине, фейловер становится сложным. Перенесите состояние в разделяемое хранилище или базу данных, где ему место, и сделайте серверы приложений максимально stateless. Тогда вы сможете заменять ноды без драмы.

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

Короткие сбои происходят постоянно. Платёжный API таймаутит. Воркер теряет сеть на 30 секунд. Сервис перезапускается в процессе деплоя. Очереди и ретраи помогают сгладить такие колебания, чтобы они не превращались в видимые простои. Трюк — ретраить с лимитами и задержками, а не долбить сломанный зависимый сервис, пока всё не забьётся.

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

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

Как принять решение, не догадываясь

Начните с ваших инцидентов, а не с маркетинга облаков. Вытяните за последние 6–12 месяцев простои, замедления, ночные алерты и «почти‑провалы». Соберите их в один лист и отметьте, что реально сломалось: плохой деплой, база данных, ошибка в DNS, просроченный сертификат, полный диск или отказ региона.

Затем задайте две метрики перед разговором о провайдерах. Сколько времени сервис может быть недоступен до реального ущерба для бизнеса? Сколько данных вы готовы потерять? Без ясной цели по времени восстановления и пределу потери данных дебаты быстро становятся расплывчатыми.

Далее нарисуйте систему на одной странице и отметьте каждую точку отказа. Будьте откровенны. Если одна инстанс PostgreSQL, одна очередь, один секретный стор или один человек в команде может заблокировать восстановление — обведите это. Большинство маленьких команд обнаруживают, что их слабые места находятся внутри одного облака, а не между облаками.

После этого оцените работу людей, а не только счёт за облако. Второй провайдер — это два набора сетевых правил, IAM, мониторинга, бэкапов, руктбуков и знаний на on‑call. Это также создаёт больше возможностей для конфигурационного дрейфа. Для маленькой команды эта нагрузка на персонал часто стоит больше, чем инфраструктура.

Теперь отсортируйте исправления по стоимости и риску. Команды обычно получают больше пользы от дешёвых и прямых изменений: тесты восстановления бэкапов, реплика базы в другой зоне/регионе, простые откаты деплоев, алерты, которые ловят тихие отказы, и записанные шаги восстановления, которыми кто‑то сможет воспользоваться в 2 утра.

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

Здесь часто помогает внешнее ревью. Человек, который управлял lean‑продакшеном, быстро увидит дешёвые исправления. Oleg Sotnikov делает такие ревью на oleg.is, и для многих малых команд это лучшее первое вложение, чем нести мультиоблачную сложность для неопределённых проблем.

Реалистичный пример для маленькой команды

Представьте SaaS‑продукт с пятью инженерами. Двое фокусируются на фичах, двое занимаются backend и frontend, а один часть недели тратит на инфраструктуру, поддержку и тушение пожаров. Свободного резерва немного.

Выбор становится реальным в плохую пятницу. Деплой вышел в 16:40. Он прошёл базовые проверки, затем начал выдавать ошибки под нормальным трафиком. Почти одновременно одна availability zone дала сбой. Приложение потеряло одну ноду базы данных и одну ноду кеша.

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

Восстановление может выглядеть так:

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

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

Теперь представьте ту же компанию, которая преждевременно добавила второй провайдер. Они скопировали часть сервисов в оба облака, но не всё. База данных всё ещё в основном в одном месте, потому что кросс‑облачные записи были сложны и дороги. Секреты, мониторинг, CI‑раннеры, правила алертов и скрипты деплоя отличаются между провайдерами. Фейловер существует на бумаге, но никто не репетировал его под давлением.

Когда в пятницу всё ломается, перед ними встаёт другой набор проблем. В каком облаке последний рабочий билд? Актуальны ли данные на обеих сторонах? Быстро ли пройдут DNS‑изменения? Какие логи правдивы во время фейловера? Кто знает обе настройки достаточно хорошо, чтобы быстро принять решение?

Эта версия часто восстанавливается дольше. Авария превращается не просто в плохой деплой плюс зону, а в проблему координации. Малые команды обычно теряют на этом больше времени, чем на исходной проблеме.

Ошибки, которые увеличивают риск вместо того чтобы его снизить

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

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

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

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

Некоторые «точки остановки» лежат вне вычислений. Один DNS‑провайдер всё ещё может вывести оба окружения из строя. Один сервис аутентификации может заблокировать все логины. Один вендор платежей, почты или очередей может заморозить приложение. Один усталый инженер на дежурстве всё ещё может пропустить алерт в 3 утра.

Репликация данных вызывает тихие проблемы. Дашборды выглядят здоровыми при нормальном трафике, затем отстают при реальном всплеске записей. Заказы приходят быстрее, чем успевает репликация, и стендбай‑копия отстаёт на минуты. Если вы переключитесь в такой момент, пользователи увидят исчезнувшие или устаревшие данные — это сложнее объяснить, чем ясный простой.

Тонкое on‑call‑покрытие — ошибка, о которой редко хотят говорить. Два облака значит больше алертов, больше дашбордов, больше IAM‑правил, больше сетевых краевых случаев и больше странных отказов, когда люди устали. Команда из трёх человек не становится более устойчивой только потому, что у неё две панели управления.

Для большинства маленьких SaaS‑команд одно облако с проверенными бэкапами, быстрым откатом, понятными руктбуками и регулярными учениями по восстановлению безопаснее, чем шаткое мультиоблако.

Короткий чек‑лист перед мультиоблаком

Большинство маленьких команд не в одном провайдере от безопасности. Они в одном битом восстановлении, одном медленном откате или одном запутанном сообщении об ошибке от того, что их ждёт долгую ночь.

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

Пройдите этот короткий тест перед добавлением чего‑то нового:

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

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

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

Что делать дальше

Большинству маленьких команд больше защиты даст скучная работа, чем второе облако. Укрепите бэкапы, сделайте деплои безопаснее и докажите, что потеря зоны не вырубит вас на часы. Если вы никогда не тестировали время восстановления, откат и фейловер зоны — начните с этого.

Запишите точный отказ, который вы хотите предотвратить. «Сбой облака» — слишком расплывчато. Назовите событие: плохой деплой, удалённые данные, провалившаяся миграция, просроченный сертификат, ошибка в DNS или провал региона. Это держит разговор честным.

Практический порядок действий выглядит так:

• Восстановите бэкапы в чистом окружении и засеките полное восстановление.
• Введите безопасные выкаты с проверками здоровья, поэтапным релизом и быстрым откатом.
• Запустите критичные части в нескольких зонах, если провайдер это поддерживает.
• Измерьте, сколько времени бизнес может терпеть простой.
• Рассмотрите второй провайдер только если одно облако всё ещё оставляет неприемлемый разрыв.

Второй провайдер имеет смысл, когда вы можете указать на режим отказа, который лучшая архитектура внутри одного провайдера не покрывает. Может быть, вашим клиентам нужен уровень аптайма, который один провайдер не может дать, или провайдерный инцидент остановит выручку быстрее, чем вы можете смириться. Если вы не можете объяснить причину одним предложением — скорее всего мультиоблако вам ещё не нужно.

Учтите также стоимость людей. Два провайдера — это два набора сетей, правил безопасности, мониторинга, путей деплоя и руктбуков для on‑call. Для маленькой команды эта нагрузка часто создаёт больше риска, чем убирает.

Если хотите второго мнения, держите его практичным. Короткое ревью архитектуры и операций подскажет, нужно ли вам действительно мультиоблако или просто проще настроенное окружение, которое реже ломается. Oleg Sotnikov через oleg.is работает со стартапами и малыми бизнесами по этим компромиссам.

Выберите один режим отказа, протестируйте его и исправьте самое дешевое слабое место сначала. Это обычно приносит больший эффект, чем открытие ещё одного облачного аккаунта.