Четыре заметных AI-сервиса почти синхронно начали сыпать ошибки утром 3 сентября по восточному времени США: проблемы затронули ChatGPT, Claude, Grok и, судя по косвенным данным, Gemini. Для рынка, который уже привык считать облачные модели чем-то вроде электричества из розетки, такой сбой AI-сервисов выглядит неприятным напоминанием: даже у крупнейших игроков отказоустойчивость все еще не абсолютна, а зависимость команд от одного-двух API быстро превращается в операционный риск.
О редком совпадении перебоев сообщает Ars Technica. Первой о проблемах заявила Anthropic: в 9:23 утра компания зафиксировала partial outage с повышенным числом ошибок в запросах к Claude Mythos 5.1, Claude Fable 5.1 и Claude Opus 5. Примерно через 15 минут там сообщили, что нашли причину, затем отчитались о развернутом исправлении, а окончательно инцидент был закрыт к 12:16. Отдельно Anthropic указала на кратковременный рост ошибок у Claude Sonnet 5 уже после полудня. Формально это не тот случай, когда сервис лег полностью, но для разработчика, чьи запросы внезапно начинают возвращать ошибки, разница между «частичным» и «полным» отказом не всегда принципиальна.
У OpenAI проблемы начались немного позже. В 10:43 утра по восточному времени компания сообщила о повышенном числе ошибок в ChatGPT и Codex, из-за чего сервисы работали с деградацией. Примерно через полчаса с небольшим была включена mitigation-мера, а к 12:55 инцидент перевели в resolved. На бумаге это выглядит как сравнительно короткий эпизод. На практике для компаний, которые строят внутренние инструменты, саппорт-ботов, генерацию кода или контентные конвейеры поверх ChatGPT и Codex, даже час-полтора нестабильности могут ломать очереди задач, таймауты, ретраи и SLA перед внутренними заказчиками.
С Grok ситуация оказалась менее аккуратно упакована в статус-страницы. На момент публикации исходного материала пользователи видели сообщение, что модель «испытывает проблемы» и сервис восстанавливают. На DownDetector число пользовательских жалоб по Grok выросло с менее чем 10 до 1365 к 9:45 утра, а затем снизилось до 273. У Gemini история еще интереснее: Google публично не признала сбой, но на DownDetector жалобы подскочили с 23 примерно в 10:30 до 412 вскоре после 11 утра. Дополнительно сервис мониторинга StatusGator показал то, что сам классифицировал как likely outage для Gemini API в промежутке с 10:45 до 11:15. Это не официальный постмортем и не признание со стороны Google, но для отрасли такой сигнал обычно читается однозначно: если в одни и те же минуты растут пользовательские жалобы и внешние метрики ошибок, проблема, скорее всего, была реальной.
На этом фоне особенно показательно, чего не произошло. По состоянию на момент публикации у Amazon Web Services, Microsoft Azure и Cloudflare не было сообщений о крупных авариях, хотя количество жалоб у всех трех сервисов утром тоже немного подросло. Прямая причинно-следственная связь из этого не следует: в материале нет подтверждения, что общий инфраструктурный сбой у внешнего поставщика одновременно задел всех участников. Но сама картина выглядит для индустрии довольно нервно. Когда почти одновременно начинают спотыкаться несколько ведущих моделей от разных компаний, у разработчиков и IT-руководителей возникает неприятный, но закономерный вопрос: насколько на самом деле независимы эти экосистемы друг от друга и где именно проходят общие точки отказа — от сетевой инфраструктуры до цепочек поставщиков вычислений и балансировки нагрузки.
Еще один важный слой здесь — статистический. По данным, приведенным в исходном материале, за последние 90 дней Claude показывал 99,4% доступности, а у OpenAI ChatGPT имел 99,63% uptime, тогда как ChatGPT Codex — 100%. Для облачных сервисов это хорошие цифры, но они же создают обманчивое ощущение, что редкие сбои можно игнорировать на уровне архитектуры продукта. Нельзя. Если ваш процесс продажи, поддержки, найма, генерации кода, аналитики или внутренней автоматизации привязан к одной модели, то даже высокий средний uptime не защищает от момента, когда именно в нужный час ваш пайплайн встанет. И именно такие совпадающие инциденты особенно болезненны: запасной сценарий «переключимся на другого вендора» внезапно может не сработать, потому что у соседа в это же время те же симптомы.
Для русскоязычной IT-аудитории вывод здесь предельно прикладной. Во-первых, статус-страницы поставщиков нужно мониторить так же внимательно, как собственные метрики приложения. Во-вторых, интеграции с LLM уже пора проектировать не как «один API и немного промптов», а как отказоустойчивый слой с очередями, кэшированием, ретраями, таймаутами, деградационными режимами и, где это оправдано, резервированием по нескольким провайдерам. В-третьих, бизнесу полезно заранее решить, что считается приемлемой деградацией: например, временный переход с «умного» режима на более простой, задержка неключевых задач или ручная обработка части операций. Такой сбой AI-сервисов неприятен не только сам по себе, но и как стресс-тест зрелости процессов вокруг генеративного ИИ.
Пожалуй, главный вопрос теперь не в том, почему четыре сервиса споткнулись в один день, а в том, как быстро рынок перестанет воспринимать подобные эпизоды как экзотику. Чем глубже AI-сервисы встраиваются в разработку, поддержку и операционку, тем меньше отрасль может позволить себе роскошь верить в «почти всегда работает». Следующий этап конкуренции между платформами, похоже, будет идти не только по качеству моделей, но и по тому, кто лучше переживает плохой день без чужого аврала у клиентов.