20 октября 2026 года в одном из регионов доступности Google Cloud в Лондоне отключилось электричество — почти на 8 часов. За пять дней до этого большую часть утра не работал DeepSeek. Многие разработчики теперь спрашивают: не остановится ли в следующий раз и их AI-приложение?
Никто не знает, когда у провайдера возникнет сбой. Если вы только вызываете API моделей, переносить серверы не нужно. Но нельзя завязывать бизнес на одну модель.
Главное: прочитав статью, вы поймёте, в каких случаях нужно действовать, а в каких — нет, и узнаете, как подготовить запасной вариант для модели.
Что отключилось во время двух сбоев на этой неделе
Начнём с Google Cloud. 20 октября 2026 года с 14:08 до 22:00 по пекинскому времени из-за проблем с электроснабжением не работала одна зона доступности — europe-west2-b в лондонском регионе. Сбой длился 7 часов 52 минуты. Пострадали вычислительные ресурсы, хранилища, базы данных и сети, размещённые в этой зоне. Тех, кто только удалённо вызывает API моделей, сбой напрямую не затронул. Но если ваш сервис как раз работал в этой зоне, то весь день там простаивали фоновые задачи, подключения к базам данных и внешние интерфейсы. Никто не мог выполнить эту работу за них заранее.
Теперь о DeepSeek. С 08:11 15 октября по пекинскому времени частично перестали работать сайт, чат и API моделей V4 Pro и V4.1 Flash. В официальном отчёте о состоянии сервисов указана продолжительность сбоя — 4 часа 52 минуты; работа восстановилась в тот же день в 13:04. Caixin и South China Morning Post писали «почти 5 часов», но за точную продолжительность будем считать официальные данные. Позже DeepSeek начислил пользователям кредиты в размере расходов за период с 8 по 14 октября. Причину компания не назвала, поэтому гадать не будем. Для пользователей тем утром важнее было не то, почему произошёл сбой, а то, есть ли у них запасной вариант.
На изображении: уведомление DeepSeek о восстановлении сервиса и компенсации пользователям. 15 октября с 8:11 до 13:04 по пекинскому времени API работал с перебоями. Пользователям автоматически вернут бонусными средствами всю сумму, потраченную с 8 по 14 октября. Оплата вызовов API сначала будет списываться с бонусного счёта.
Оба сбоя больно ударили по одному и тому же месту: модель — часть рабочего процесса, и когда API перестаёт отвечать, останавливается всё — написание кода, поиск информации, пакетная обработка данных. Пока поставщик восстанавливает сервис, полдня уже прошло. Возврат кредитов компенсирует расходы, но не потерянное рабочее время. Если команда планировала за день перевести партию текстов, провести оценку или успеть с запуском, компенсация не выполнит эту работу за неё. Всё просто сдвинется, заняв место в расписании на следующий день.
| Пункт | Подтверждённые данные о сбое Google Cloud |
|---|---|
| Номер инцидента | Xs2XTHzAVC9YnafnPyzj |
| Масштаб сбоя | Зона доступности europe-west2-b в регионе europe-west2 |
| Причина | Сбой электроснабжения; подробностей от компании нет |
| Время начала | 20 октября 2026 года, 14:08 по пекинскому времени |
| Время окончания | 20 октября 2026 года, 22:00 по пекинскому времени; продолжительность — 7 часов 52 минуты |
| Не пострадал | Looker Studio |
В чём разница между зоной доступности и регионом
Увидев новость об отключении электричества в Лондоне, многие решат, что лёг весь Google Cloud в Лондоне. Но это не так. Регион (europe-west2) — условно целый комплекс дата-центров Google в Лондоне, а зоны доступности (europe-west2-a, b и c) — отдельные здания в этом комплексе. Они устроены так, чтобы иметь независимые источники питания и сетевую инфраструктуру: если в одном здании что-то случится, остальные смогут продолжить работу. На этот раз из трёх зданий одно отключилось, а два других работали как обычно.
Поэтому больше всего пострадали команды, у которых сервисы были размещены только в зоне b. Если же сервисы распределены между зонами a и c, трафик можно переключить на работающие площадки — и последствия будут гораздо меньше. Те, кто только удалённо вызывает API моделей, почти не заметили этого отключения.
Два сбоя рядом
| Параметр | Google Cloud в Лондоне | DeepSeek |
|---|---|---|
| Время (по пекинскому времени) | 20.10.2026, с 14:08 до 22:00 | 15.10.2026, с 08:11 до 13:04 |
| Продолжительность | 7 часов 52 минуты | 4 часа 52 минуты |
| Что отключилось | Вычислительные ресурсы, хранилища, базы данных и сети в зоне europe-west2-b | Сайт, чат и API моделей V4 Pro и V4.1 Flash |
| Причина | Сбой электроснабжения; подробностей нет | Официально не объявлена |
| Что сделали после сбоя | Компания рекомендовала по возможности перенести ресурсы в другую зону доступности или регион | Расходы за период с 8 по 14 октября компенсировали кредитами |
| Пользователи, которые только вызывают API моделей | Не пострадали напрямую | Пострадали напрямую: без запасного варианта остаётся только ждать |
Если сравнить эти два сбоя, разница становится очевидной. В случае Google пострадали те, чьи сервисы работали в зоне b; решение — распределить их между зонами доступности. В случае DeepSeek пострадали те, кто подключился только к одной модели; решение — заранее настроить запасную. В первом случае проблема связана с дата-центром, во втором — с вызовом модели. Дальше речь пойдёт именно о втором.
Какие выводы стоит сделать из этого сбоя
Один сервис может перестать работать, поэтому нужно заранее подготовить второй и третий варианты — желательно у разных провайдеров. Переключение на более дешёвую модель того же провайдера — не запасной вариант: если у него проблемы, обе модели могут отключиться одновременно.
Важно и то, когда переключаться. Менять модель стоит только при ошибках 429, 500, 502, 503, 504 и при тайм-ауте: это может означать, что сервис временно не справляется, и запрос к другой модели сработает. При ошибках 401 и 403, а также при отказе из-за политики безопасности контента переключаться не нужно: проблема в API-ключе или самом запросе, и с десятью другими моделями результат будет таким же. И ещё: если база данных и хранилище размещены в отключившейся зоне, смена модели не поможет. В таком случае нужно оценить возможность развернуть ресурсы в нескольких зонах доступности. Резервирование моделей и отказоустойчивость инфраструктуры — это разные задачи, не стоит их путать.
После настройки резервного варианта не отключайте его, когда сбой закончится. Пока основная модель отвечает с первого раза, дополнительные запросы не отправляются. Но при следующем сбое запасная модель включится автоматически — не придётся вставать среди ночи и менять код. Перед тем как связывать модели в цепочку, отправьте каждой по отдельности самый простой запрос: проверьте, что название указано верно и модель отвечает. У разных моделей может отличаться стиль ответов. Если для вашей задачи важен формат вывода, зафиксируйте его в системном промпте — так разница при переключении будет менее заметна.
Как настроить цепочку резервирования
Просто переключаться на другую модель при сбое недостаточно: если делать это слишком быстро или слишком медленно, тоже возникнут проблемы. Ниже — параметры, о которых спрашивают чаще всего. Универсального ответа нет, подбирайте настройки под свою задачу.
| Настройка | Рекомендация | Почему |
|---|---|---|
| Сколько раз повторять запрос к одной модели | Не больше одного раза; если снова ошибка — переключаться на следующую | Когда у провайдера проблемы, повторные запросы к той же модели часто лишь заставляют ещё раз ждать в очереди |
| Сколько ждать ответ на один запрос | Для диалога — меньше, для генерации длинного текста — больше | Если ждать слишком долго, пользователь закроет страницу раньше, чем произойдёт переключение |
| Что делать при ошибке 429 | Подождать секунду-две и переключиться | Иногда это лишь кратковременный всплеск нагрузки, который быстро проходит |
| Сколько максимум ждать от всей цепочки | Суммарное время для трёх моделей не должно превышать приемлемое для пользователя время ожидания | Это не даст запросу зависнуть, если все три модели отвечают медленно |
| Что записывать в логи | Какая модель сработала, какая выдала ошибку и какой был код ошибки | Так после сбоя будет понятно, у какого провайдера проблемы и нужно ли менять порядок моделей |
| Когда оповещать команду | Когда доля запросов к запасной модели резко возрастает | После переключения пользователь может ничего не заметить — как и команда. Кто-то всё равно должен знать, что с основной моделью проблемы |
Последний пункт чаще всего упускают. Чем лучше настроено резервирование, тем незаметнее сбой основной модели. Если никто не проверяет логи, она может не работать целый день, а все будут думать, что всё в порядке, — пока в счёте не появится куча вызовов запасных моделей.
Чтобы сменить модель, не нужно менять API-ключ
Сложнее всего при настройке резервного варианта — не увлечься масштабной переделкой. Если для каждой модели нужно отдельно регистрировать аккаунт, менять адрес и формат запросов, большинство команд отложит эту работу до следующего сбоя.
В APIYI используется один и тот же адрес https://api.apiyi.com/v1/chat/completions и один API-ключ: в теле запроса достаточно изменить параметр model. Основная модель — claude-opus-5-5. Если она не сработает — переключаемся на claude-sonnet-5-5, а если и она подведёт — на gemini-4-argon. Первые две модели — от одного поставщика, третья — от другого. Если у одного из поставщиков возникнут серьёзные проблемы, останется запасной путь.
Объём доработок небольшой: в бизнес-коде появится только список моделей, которые нужно пробовать по очереди. Формат запросов, способ авторизации и структура ответа останутся прежними — и тестировать всё это будет просто.
| Порядок | Модель | Цена входных токенов | Цена выходных токенов | Роль |
|---|---|---|---|---|
| 1 | claude-opus-5-5 | 4 | 20 | Основная модель |
| 2 | claude-sonnet-5-5 | 2 | 10 | Первый резерв, более доступная модель того же поставщика |
| 3 | gemini-4-argon | 2 | 10 | Второй резерв, другой поставщик |
| На замену | gpt-6-astra | 10 | 50 | Более дорогая запасная модель, работает только через OpenAI API |
| На замену | deepseek-v4.1-flash | 0.30 | 1.20 | Недорогая запасная модель |
Цены в таблице указаны в долларах за миллион токенов. Данные приведены по странице с ценами на 2026-10-21 при коэффициенте 1. Цены могут меняться — актуальную информацию смотрите на api.apiyi.com.
Подключаем резерв за три шага
Шаг 1. Получите API-ключ. Зарегистрируйтесь на api.apiyi.com и создайте API-ключ. Оплата — по факту использования, сервис доступен напрямую из Китая, привязывать зарубежную банковскую карту не нужно. Этим ключом можно вызывать все модели из таблицы.
Шаг 2. Проверьте каждую модель. Укажите адрес API https://api.apiyi.com/v1. Он совместим с форматом OpenAI, поэтому код, написанный с использованием официальной библиотеки OpenAI, заработает после замены адреса и API-ключа. Возьмите один и тот же промпт и по очереди запустите claude-opus-5-5, claude-sonnet-5-5 и gemini-4-argon. Убедитесь, что все модели отвечают и возвращают данные в ожидаемом формате.
Шаг 3. Задайте порядок и проведите тестовый сбой. Добавьте названия трёх моделей в конфигурацию в нужном порядке. Условия переключения выберите по правилам из предыдущего раздела. После настройки не спешите запускать всё в продакшене: сначала временно сильно уменьшите время ожидания основной модели и намеренно вызовите тайм-аут. Проверьте, переключился ли запрос на второй вариант и появилась ли запись об этом в журнале. Только после успешной проверки можно считать, что запасной путь действительно готов. Точные параметры смотрите в документации на docs.apiyi.com.
Как расставить модели для разных задач
В статье модели расположены в порядке приоритета качества, но это не единственный вариант. В зависимости от задачи на первое место можно поставить другую модель.
| Тип задачи | Рекомендуемый порядок | Почему |
|---|---|---|
| Написание кода, сложные рассуждения | claude-opus-5-5 → claude-sonnet-5-5 → gemini-4-argon | Приоритет качества — это вариант по умолчанию в статье |
| Поддержка клиентов, повседневные диалоги | claude-sonnet-5-5 → gemini-4-argon → deepseek-v4.1-flash | При большом числе запросов важна цена: необязательно ставить самую дорогую модель первой |
| Массовый перевод, суммаризация | deepseek-v4.1-flash → gemini-4-argon → claude-sonnet-5-5 | При большом объёме задач первой ставим недорогую модель, а при сбое переключаемся на более мощные |
| Выводы со строгими требованиями к формату | Сначала две модели одного поставщика, в конце — другого | Модели одного поставщика обычно ближе по стилю, поэтому переход между ними менее заметен |
При выборе порядка есть два простых правила: последняя модель по возможности должна быть от другого поставщика, а цена — соответствовать ценности задачи. На примере массового перевода хорошо видна польза резервирования: если бы 15 октября первой стояла DeepSeek, а она отказала, запросы автоматически перешли бы к двум другим поставщикам — и задача всё равно была бы выполнена.
Важно понимать: смена модели помогает обеспечить непрерывность именно на этапе вызова модели, но не спасёт от отключения электричества в дата-центре.
Поставщик может отказать — заранее подготовьте запасной путь
Публичный пример — официальный сбой DeepSeek 15 октября 2026 года. Тогда APIYI переключился на канал Volcano Engine с полной версией модели. Менять название модели не пришлось, и работа в продакшене быстро восстановилась. Источник: раздел «Актуальные события» на docs.apiyi.com.
Сбои у поставщиков случаются — и это не чья-то вина. Заранее подготовить запасной путь полезнее, чем несколько часов ждать восстановления. Обычно это почти ничего не стоит и не отнимает много времени — главное, сделать всё до сбоя. Если заняться этим уже после, придётся менять систему в спешке.
Что проверить в первую очередь при сбое
Если запросы внезапно массово перестали проходить, не спешите менять код. Потратьте две минуты и проверьте три места. Первое — Google Cloud Service Health: нет ли проблем на уровне дата-центра. Второе — официальная страница статуса соответствующего поставщика моделей, в данном случае — DeepSeek. Третье — оперативные обновления на docs.apiyi.com: APIYI публикует там информацию об изменениях маршрутов к поставщикам.
Если во всех трёх местах всё в порядке, проверьте свою сторону: не истёк ли срок действия API-ключа, хватает ли баланса, нет ли проблем с сетевым выходом или DNS. Если действовать в обратном порядке, можно долго искать ошибку в своём коде — и только потом обнаружить, что проблема была у поставщика.
Четыре вещи, которые можно сделать уже сегодня
- Составьте список всех мест в приложении, где вызываются модели, и проверьте, где используется только один поставщик.
- Для каждого такого места добавьте хотя бы одну резервную модель от другого поставщика.
- Настройте переключение только при ошибках 429, 5xx и тайм-ауте по правилам из статьи. Записывайте каждое переключение в журнал.
- Один раз намеренно вызовите тайм-аут основной модели и убедитесь, что запрос действительно перешёл на резервную.
Если выполнить эти четыре пункта, то при следующем сбое дата-центра или поставщика модель в вашем приложении задержится максимум на несколько секунд, а не остановится на полдня.
Частые вопросы
Вопрос 1. Нужно ли сразу переносить сервисы из Лондона после отключения электричества в Google Cloud?
Не обязательно. В официальной рекомендации сказано «по возможности», а не «всем срочно переезжать». Команды, чьи нагрузки работают в europe-west2-b, могут оценить возможность переноса в другую зону или регион. Если вы только вызываете API моделей, переносить сервисы не нужно — достаточно заранее настроить резервные модели.
Вопрос 2. Смена модели обойдётся дороже?
С порядком из таблицы — наоборот, дешевле. Для основной модели claude-opus-5-5 цена входных токенов составляет 4, выходных — 20. У обеих запасных моделей — 2 и 10 соответственно. Расходы вырастут, только если добавить в резервный список модель вроде gpt-6-astra, цена которой составляет 10 за входные и 50 за выходные токены.
Вопрос 3. Можно ли одной парой API-ключа и адреса вызывать модели разных поставщиков?
Да. Все эти модели вызываются через один совместимый с OpenAI адрес и используют один API-ключ — меняется только параметр `model`. Обратите внимание: gpt-6-astra работает только через OpenAI API.
Вопрос 4. Ответы резервной модели будут хуже?
Разница возможна, особенно при переходе с самой мощной модели на более дешёвую. Но для большинства задач медленный или немного менее точный ответ лучше, чем ошибка. Если формат особенно важен, жёстко задайте его в системном промпте и заранее сравните ответы нескольких моделей способом из второго шага. Так вы будете понимать, чего ожидать до запуска в продакшене.
Вопрос 5. Нужно ли платить за резервные модели, если сбоев нет?
Нет. При оплате по факту использования вы платите только за отправленные запросы. Если основная модель успешно ответила с первого раза, резервные не вызываются и расходов не возникает. Потратиться придётся только на настройку и несколько тестовых запросов во время проверки.
Ключевые выводы
- Два сбоя: отключение электричества в Google Cloud europe-west2-b длилось 7 часов 52 минуты; официальный сбой DeepSeek — 4 часа 52 минуты.
- Границы фактов: это не означало отключения всей Европы, и сами модели из-за этого не перестали работать. DeepSeek не публиковала официальную причину сбоя.
- Когда переключаться: только при ошибках 429, 500, 502, 503, 504 и тайм-ауте. При ошибках 401, 403 и отказе из-за политики безопасности переключение не нужно.
- Что делать: по возможности выбирайте резервную модель от другого поставщика. Адрес и API-ключ остаются прежними — меняется только
model. - Как проверить: после настройки намеренно вызовите тайм-аут основной модели и проверьте, перешёл ли запрос на резервную и появилась ли запись в журнале.
Компенсация за простой может покрыть счёт, но не вернёт остановленную работу. Заранее задайте порядок моделей — и при следующем сбое у поставщика пользователи заметят максимум небольшую задержку.
Источники
- Google Cloud Service Health: инцидент с несколькими сервисами в europe-west2 (Xs2XTHzAVC9YnafnPyzj), 2026-10-20
- Google Cloud Service Health: отдельный инцидент с продуктами безопасности Google SecOps в europe-west2, 2026-10-20
- BBC: сообщение о том, как сбой Google Cloud затронул британские банки и государственные службы, 2026-10-20
- Официальная страница статуса DeepSeek: запись о сбое 2026-10-15
- Официальная документация: оперативные обновления на docs.apiyi.com
Автор: техническая команда APIYI
Техническое обсуждение: если при настройке резервных моделей возникнут вопросы, напишите о них в комментариях.
