AI API закрывается: аудит миграции до даты отключения

AI API закрывается: как провести аудит миграции до даты отключения

При объявлении deprecation недостаточно заменить имя модели или Base URL. Даже если новый endpoint принимает похожий JSON, поведение может отличаться в streaming, tool calls, структуре ошибок, лимитах и формате usage. Миграция завершена только тогда, когда команда зафиксировала дату отключения из первичного источника, нашла все зависимости, сравнила наблюдаемое поведение и подготовила обратимое переключение.

На 25 августа 2026 года OpenAI публикует shutdown date и рекомендуемую замену на официальной странице Deprecations. Для generally available моделей заявлен минимальный срок уведомления шесть месяцев, для специализированных вариантов — три месяца, а preview-модели могут получить существенно более короткий срок. Это общая политика, но календарь проекта нужно строить по конкретной строке deprecation, а не по ожиданию.

1. Зафиксируйте исходное событие

Создайте запись миграции до изменения кода:

deprecation_source: https://developers.openai.com/api/docs/deprecations
checked_at: 2026-08-25
old_endpoint: /v1/chat/completions
old_model: OLD_MODEL_ID
replacement_endpoint: /v1/chat/completions
replacement_model: NEW_MODEL_ID
shutdown_date: YYYY-MM-DD
owner: team-name

shutdown_date заполняйте только значением из уведомления поставщика. Если дата отсутствует, не придумывайте её: пометьте unknown, назначьте владельца повторной проверки и не называйте миграцию срочной из-за вымышленного дедлайна.

2. Соберите реестр зависимостей

Ищите не только строку модели. Реестр должен включать:

Поиск по репозиторию — только первый слой. Проверьте CI variables, serverless jobs, n8n/Dify workflows, секрет-хранилище и фоновые задачи. Секреты не копируйте в аудит; сохраняйте имя переменной и владельца.

3. Подготовьте контрольные запросы

Возьмите реальные пользовательские задачи, удалив персональные данные. Минимальный набор включает:

1. обычный текстовый ответ с проверяемым фактом;
2. structured output или JSON с обязательными полями;
3. один tool call с валидными аргументами;
4. сценарий, где tool вызывать не нужно;
5. streaming-ответ с корректным завершением;
6. негативный запрос для проверки 4xx;
7. временную серверную ошибку или test double для проверки retry.

Сравнивайте не буквальное совпадение текста, а контракт. Для JSON проверяйте schema; для tool call — имя, аргументы и решение приложения после выполнения; для текста — наличие обязательных фактов и отсутствие запрещённых. Стоимость и latency измеряйте отдельно и только на собственном прогоне: одна замена модели не гарантирует прежние значения.

4. Проверьте streaming и ошибки отдельно

Streaming может сломаться после первого token, даже если non-streaming запрос уже проходит. Зафиксируйте:

• тип события и формат data;
• признак завершения;
• где и когда приходит usage;
• поведение при обрыве до первого token и после части ответа;
• можно ли безопасно повторить запрос без двойного внешнего действия.

Для ошибок сохраните HTTP status, machine-readable code и границу retry. Не повторяйте автоматически 401, 403 или schema validation error. Для 429 и временных 5xx соблюдайте Retry-After, если он есть, ограничивайте число попыток и добавляйте idempotency на своей стороне для запросов с внешними эффектами.

5. Запустите старый и новый путь на одном наборе

Сделайте двойной прогон в тестовой среде. Старый путь остаётся baseline, новый получает те же очищенные fixtures. В отчёте для каждого кейса сохраните:

case_id | old_result | new_result | contract_pass | difference | decision

Различие формулировки не обязательно ошибка. Изменение tool arguments, пропуск обязательного поля, другая граница завершения stream или новая ошибка — контрактное отличие, которое требует исправления клиента или осознанного принятия.

Если вы проверяете OpenAI-compatible транспорт через BetterToken, используйте текущий полный путь https://www.bettertoken.ai/v1/chat/completions, Bearer Key пользователя и Model ID из Model Plaza или Setup. Это проверяет совместимость формата запроса, но не доказывает эквивалентность двух моделей. Создайте тестовый Key, выполните контрольный запрос по официальной инструкции Chat Completions и зафиксируйте HTTP status и проверяемое поле ответа.

6. Cutover: переключайте обратимо

Перед production переключением должны существовать:

• feature flag или версионированный provider config;
• владелец решения и окно наблюдения;
• метрики ошибок, contract-test failures и бизнес-инвариантов;
• точное условие rollback;
• сохранённая старая конфигурация без раскрытия секретов.

Порядок:

1. Разверните код, который понимает оба контракта.
2. Включите новый путь для внутреннего трафика или малой контролируемой доли.
3. Сверьте ошибки и результаты контрольных задач.
4. Увеличивайте долю только при выполнении критериев.
5. Откатите feature flag при нарушении заранее записанного инварианта.
6. Удаляйте старый путь лишь после завершения окна наблюдения и до shutdown date.

Rollback не означает, что старый API будет доступен после даты отключения. Поэтому последняя безопасная дата переключения должна оставлять время на исправление, повторный прогон и повторный cutover.

Что приложить к решению о готовности

Аудит завершён, когда есть пять артефактов:

• ссылка и дата проверки официального deprecation;
• полный реестр зависимостей с владельцами;
• версия контрольного набора и результаты двух путей;
• подписанное решение по каждому существенному отличию;
• runbook cutover/rollback с измеримыми условиями.

Если отсутствует хотя бы один из них, статус должен быть migration_in_progress, даже если happy-path запрос уже вернул 200.

Источники

• OpenAI API Deprecations, проверено 25.08.2026: https://developers.openai.com/api/docs/deprecations
• BetterToken OpenAI Chat Completions API, проверено 25.08.2026: https://docs.bettertoken.ai/api-reference/chat-completions