Отказоустойчивость облака была рассчитана на потерю одной зоны. Потеряли две. План Б для ИИ-продукта на один вечер

Меня зовут Карим, я занимаюсь автоматизацией в NODA, и эти выходные мы провели не так, как планировали: проверяли, где физически живёт каждый бот наших клиентов и что с ним случится, если его зона исчезнет. Повод известен. С 8 по 11 октября после атак беспилотников остановлены два дата-центра Яндекса, в Сасово и Владимире, а в Калуге выведены из строя несколько модулей. На этих площадках стояли две из трёх зон Yandex Cloud. Облако 11 октября объявило аварийный режим и посоветовало клиентам «задействовать альтернативные планы аварийного восстановления». У кого они были.

Короткий ответ, что с этим делать. У любого ИИ-продукта три внешние зависимости: хостинг, данные и модель. Прошедшая неделя показала все три разом, и для каждой есть дешёвый план Б, который собирается за вечер, если делать его до аварии. Ниже разбираю, что именно произошло с точки зрения архитектуры, что мы нашли у себя и что стоит проверить у вас в понедельник, пока тема не остыла.

Документация Yandex Cloud честно описывала модель отказоустойчивости: облако переживает потерю одной зоны доступности из трёх. Компания говорила и об учениях на потерю одного дата-центра. Модель отработала 8 октября ровно так, как написано: через несколько часов после остановки Сасово нагрузку переключили, остальные зоны работали штатно. Но автоматического переезда не было. Клиенты, у которых всё лежало в одной зоне, переносили ресурсы сами; 9 октября облако открыло ручные операции по переносу управляющих компонентов Kubernetes и удалению хостов из отказоустойчивых кластеров баз.

Дальше случилось то, чего в документации не было: вторая зона. 10 октября облако перешло на ручное управление квотами, отдав приоритет клиентам с критичными сервисами. 11 октября, после остановки Владимира, статус-канал написал, что оставшаяся конфигурация «считается неустойчивой», выдачу квот приостановили. Разбор на Хабре объясняет, почему часть баз ушла в режим «только чтение»: при потере двух зон из трёх региональные кластеры теряют кворум, и это не сбой, а штатное поведение распределённой системы, которая отказывается писать данные, когда не уверена в большинстве. Для клиента это означало ручное вмешательство в выходной.

Третья деталь, самая важная для тех, кто строит бизнес на чужой инфраструктуре. 10 октября Яндекс обновил пользовательское соглашение: к форс-мажору теперь относятся атаки беспилотников и ракет. Что это значит практически, скажу без юридических оценок: простой такого рода не компенсируется, и план Б для вашего сервиса — ваша строка расходов, а не провайдера. У любого провайдера, не только у этого.

Самая очевидная и самая запущенная.

Признаюсь честно: до четверга я не мог ответить на вопрос «в какой зоне стоит бот клиента Х» за минуту. Теперь у нас есть таблица на одну страницу: бот, провайдер, зона, где лежит копия, кто поднимает.

Что проверить у себя. Первое: в какой зоне стоят ваши ресурсы и лежат ли они все в одной. Мультизонность, которую продают как отказоустойчивость, работает до первой зоны, и неделя это показала. Второе: есть ли у вас образ сервиса, который можно поднять у другого провайдера. Разбор на Хабре предупреждает о ловушке: Terraform-модули под провайдер yandex напрямую к другим облакам не применяются, типы ресурсов и аргументы у каждого свои. Переезд по инфраструктурному коду означает переписывание кода, и лучше обнаружить это в спокойный вторник. Третье: DNS. Если время жизни записи сутки, ваш запасной сервер будет готов, а трафик к нему придёт завтра.

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

Когда 11 октября объектное хранилище облака осталось доступным на чтение, но не на запись, автор хабровского разбора дал совет, который стоит повесить на стену: выгружайте бэкапы за пределы облака, пока читается. Это правильный совет и одновременно признание: у многих копии данных лежали в том же облаке, что и данные.

У ИИ-продукта данных три слоя, и у каждого свой адрес. База знаний, по которой отвечает бот, — у нас это база в CRM клиента. Журнал диалогов, без которого нельзя разобрать спорную ситуацию с клиентом, — об этом журнале как условии запуска агента писал юрист в комментариях под моей статьёй про права агента, и неделя добавила к его аргументу ещё один: журнал должен лежать не там, где бот. И третий слой — состояние: кто что заказал, какая запись подтверждена, какой платёж ждёт. Его потеря дороже первых двух вместе.

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

Этот слой есть только у ИИ-продуктов, и о нём на неделе почти не говорили. Среди 84 сервисов облака, затронутых аварией, был и API языковой модели. Если ваш бот отвечает через одного провайдера моделей, у него есть точка отказа, которую не закроет ни второй VPS, ни бэкап.

Три приёма, в порядке дешевизны.

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

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

И третье, долгое. На остановленных площадках стояли все три суперкомпьютера, на которых Яндекс обучает модели; повреждены ли машины, компания не сообщает, а оценки замены, если да, — полтора-два года из-за ограничений на поставки ускорителей. Независимо от исхода отрасль входит в период дорогих вычислений: эксперты уже говорят о росте цен на серверы, облако приостановило резервирование мощностей для новых клиентов. Для продукта это значит одно: цена вызова модели у любого российского провайдера в ближайший год вряд ли будет падать, и запасной режим без модели из первого пункта — ещё и экономия.

Собрал в список то, что мы прошли сами. Семь пунктов, на каждый по строке в таблице.

Это нормальный результат первой проверки. Ненормальный — не знать, какие.

Первое. Хронологию и поведение облака я восстанавливаю по статус-постам Yandex Cloud и по разбору на Хабре, а не по собственному опыту работы с пострадавшими зонами: наши сервисы в них не стояли. Объяснение про кворум принадлежит автору разбора, компания его не подтверждала и не опровергала.

Второе. Статью легко прочитать как «переезжайте из Яндекса». Это не так. Модель «переживаем одну зону» считается отраслевым стандартом, и у других провайдеров она та же; разница только в том, что эта неделя проверила её на практике у одного из них. Урок про архитектуру, а не про бренд.

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

Четвёртое. Причины произошедшего и всё вокруг них лежат вне моей компетенции и вне этой статьи.

Вопрос к тем, кто пережил эту неделю на облаке: сколько из семи пунктов у вас было закрыто в четверг утром? И отдельный вопрос к тем, у кого бот работает через одну модель: пробовали ли вы свои промпты на другой — до того, как пришлось?