99,66%: сбои OpenAI — не повод отказываться от ИИ

За последние несколько дней это уже третий заметный масштабный сбой сервисов OpenAI. 25 июля фиксировались массовые перебои в работе ChatGPT, API и Codex — в США, Европе, Индии, Японии и Австралии. В лентах — знакомое: «на этом невозможно строить бизнес, оно падает три раза в неделю».

Проверим арифметику, прежде чем делать вывод.

📌 На статусной странице самой OpenAI за последние 90 дней: ChatGPT — 99,66%, API — 99,93%, Codex — 99,98%. Если пересчитать 99,66% доступности на месяц, это эквивалентно примерно 2,5 часа недоступности за 30 дней. Сервис работает 29 дней и 21 час из 30.

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

⚠️ Но успокаиваться на этом рано. Реальный риск — не 0,34% простоя, а то, на что именно вы этот простой посадили.

Две ошибки, которые превращают короткий сбой провайдера в остановку бизнеса:

Первое — процесс завязан на потребительское приложение ChatGPT. Потребительская версия ChatGPT не предназначена для критически важных бизнес-процессов и не предполагает договорных гарантий доступности. Строить процесс на приложении в браузере — всё равно что строить логистику на личном курьере вместо договора с оператором.

Второе — ИИ воткнут в синхронный критический путь без запасного варианта. Модель недоступна — встало всё. Это не проблема ИИ, это проблема архитектуры.

💻 Что делать — по убыванию важности:

Разделить процессы на ИИ-критичные (встанет ИИ — встанет бизнес) и ИИ-ассистируемые (ускоряют, но не блокируют). Для второй категории июльские сбои — новостной шум, реагировать не нужно.
Для критичных процессов — как минимум API и корпоративные условия обслуживания вместо потребительского приложения. Промышленную интеграцию и договорные гарантии доступности можно получить именно там.
Поставить абстрактный слой и второго провайдера. Не вызывать одну модель напрямую из критичного пути: router + OpenAI/Anthropic + локальная open-модель (Qwen, DeepSeek, Llama) в резерве. Переключение при сбое — автоматическое.
Проектировать деградацию, а не отказ. Очередь, ретраи, кэш, ручной режим по умолчанию. Пользователь должен видеть «обрабатываем чуть дольше», а не «ошибка 500».

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