История о том, как инженеры OpenAI охотились за загадочными падениями в ChatGPT-инфраструктуре, — это не просто технический детектив. Это хорошая иллюстрация принципа, который работает далеко за пределами программирования: когда вы застряли, проблема часто не в том, что вы плохо смотрите на одну точку, а в том, что смотрите не туда. Давайте разберём, что произошло, и зачем об этом знать тем, кто строит системы на основе AI.
Что за инфраструктура стоит за ChatGPT
Когда вы задаёте вопрос ChatGPT, модель не просто «думает» — она в реальном времени обращается к внешним данным. Часть этой работы выполняет сервис Rockset: система поиска и аналитики, которую OpenAI приобрела в 2024 году. Rockset написан на C++ — языке, который даёт максимальный контроль над памятью и производительностью, но при этом не прощает ошибок.
Несколько месяцев назад инженеры заметили, что Rockset периодически падает. Причём падает странно: программа завершала обычную функцию и возвращалась по «мусорному» адресу. Иногда адрес возврата был NULL. Иногда указатель стека оказывался сдвинут на 8 байт — без каких-либо очевидных причин. Ни одна из классических гипотез не работала.
Такие падения — не норма. Это примерно как если бы курьер, доставив посылку, вместо выхода через дверь уходил сквозь стену. Что-то фундаментальное шло не так.
Врач или эпидемиолог: два способа искать причину
Поначалу команда действовала как врач: брала один «больной» core dump (снимок состояния программы в момент падения), внимательно его изучала, выдвигала гипотезу, проверяла. Потом брала следующий. Классический подход.
Проблема в том, что такой метод хорошо работает, когда у вас одна болезнь с понятными симптомами. Здесь же симптомы были похожи, но причины — разные. Смешивая данные из двух независимых багов, команда получала противоречивые улики и не могла построить единую картину.
Переломный момент наступил, когда инженеры переключились в режим эпидемиолога: перестали изучать отдельные случаи и начали смотреть на всю популяцию падений сразу. Они написали скрипт (с помощью ChatGPT, что иронично), который автоматически скачивал и анализировал все core dumps за год — сотни файлов. Скрипт маркировал каждое падение: возврат в NULL, смещённый стек или что-то иное.
Как только данные стали чистыми, паттерны проявились немедленно.
Два бага вместо одного: что показала «эпидемиология»
Популяция разделилась на две чёткие группы:
- Падения «возврат в NULL» — распределены по многим регионам и кластерам, нет чёткой даты начала, частота постепенно росла.
- Падения «смещённый стек» — только один регион, чёткая дата начала, никогда не происходили на нодах, которые работали давно.
Второй паттерн выглядел как поведение одного физического сервера с аппаратной неисправностью. Процессор просто неправильно считал — тихо, без явных ошибок. Как только инженеры идентифицировали проблемный хост и вывели его из ротации, этот тип падений исчез.
С первым типом всё оказалось интереснее. Когда «аппаратные» случаи убрали из выборки, оставшиеся падения стали читаться иначе. Раньше команда исключила версию с исключениями (exceptions в C++), потому что «видела падения там, где исключений не было». Но те «контрпримеры» — все до одного — были из аппаратного кластера. Когда их убрали, картина перевернулась: оставшиеся падения происходили именно во время раскрутки стека исключений.
18-летний баг в GNU libunwind
Дальнейшее расследование привело к GNU libunwind — библиотеке с открытым исходным кодом, которую используют тысячи программ для работы с исключениями в C++. Оказалось, что в ней жила гонка состояний (race condition) — ошибка, при которой два потока одновременно обращаются к общим данным и результат зависит от того, кто успел первым.
Эта ошибка существовала 18 лет. Не потому что все были халтурщиками — просто такие баги проявляются только в специфических условиях: при определённой нагрузке, определённом железе, определённом способе использования сигналов. У Rockset эти условия совпали.
Тут важна одна деталь: автоматизация рутинных задач с помощью AI-агентов ускоряет работу, но не отменяет необходимость понимать, на чём эта автоматизация стоит. Rockset — одна из опор ChatGPT, и баг в низкоуровневой библиотеке долго маскировался за более «шумными» симптомами.
Что это значит для тех, кто строит системы на AI
Смотрите, в чём тут дело для практика. Необязательно быть C++-разработчиком, чтобы вынести из этой истории что-то полезное.
Первое: одна аномалия может прятать несколько причин. Если ваши данные «не складываются» ни в одну гипотезу — возможно, вы смотрите на смесь двух разных проблем. Это работает и в маркетинге: низкая конверсия воронки может объясняться одновременно слабым оффером и плохим трафиком. Лечить их как одно — значит не вылечить ни то ни другое.
Второе: качество данных важнее их количества. Команда не смогла прорваться через сотни текстовых логов. Один структурированный датасет из автоматически обработанных core dumps дал то, чего не дали недели ручного разбора. Вопрос «как мы собираем данные о проблеме?» иногда важнее вопроса «какова проблема?».
Третье: старые компоненты несут старые риски. Библиотека с 18-летним багом — не исключение. Это нормальная ситуация для экосистемы опенсорса. Если вы используете готовые инструменты (а в AI-стеке вы их точно используете), понимание их ограничений — часть вашей ответственности. Хорошая иллюстрация этого принципа есть в разборе ловушки деквалификации при работе с AI: когда инструмент делает что-то за вас, вы рискуете перестать понимать, что именно и как.
Четвёртое: переключение масштаба — не признак слабости. Несколько дней команда шла вглубь одного случая. Потом отступила и посмотрела на всю картину. Именно этот шаг оказался решающим. Умение вовремя выйти из «микро» в «макро» — навык, который сложно переоценить.
Как изменился подход после находки
Команда OpenAI сделала несколько практичных вещей, чтобы снизить риск повторения:
- Улучшила обработчик сигналов — теперь он логирует состояние регистров процессора, и повторное появление аппаратной проблемы будет видно сразу из логов, без core dump.
- Изменила логику переиспользования виртуальных машин — так плохой хост будет легче обнаружить.
- Обновила внутренние инструкции и модели понимания проблемы в команде — чтобы «сломанное железо» с самого начала входило в список гипотез.
Это хороший пример того, что реальный результат от AI-инструментов строится не на одном умном решении, а на системе, которая работает при повторении проблемы. Не «мы починили», а «мы сделали так, чтобы следующий раз был проще».
Главный урок: метод важнее интуиции
Интуиция говорила инженерам: это один баг, ищи одну причину. Данные говорили другое — но данные нужно было правильно собрать, чтобы они заговорили.
В работе с AI-системами — будь то ChatGPT в вашем рабочем процессе или собственный инструмент — это напоминание о том, что доверять нужно структурированным наблюдениям, а не первому объяснению, которое «почти подходит».
Тут есть нюанс: это не значит «не доверяй интуиции». Это значит: проверяй её на данных, прежде чем строить на ней стратегию.
Если вам интересно, как похожие принципы работают в маркетинге и системах продаж через контент — заходите в мой Telegram-канал. Там разбираю конкретные ситуации: где рвётся цепочка, как это диагностировать и что чинить в первую очередь.
По мотивам материала OpenAI News «Core dump epidemiology: fixing an 18-year-old bug».
Частые вопросы
Что такое race condition и почему его так сложно найти?
Как OpenAI использует ChatGPT для отладки собственного кода?
Что такое core dump и зачем он нужен при отладке?
Как аппаратный сбой может маскироваться под программную ошибку?
100 нейросетей
для экспертов
Подборка, которой реально пользуются — пришлю на почту. Без спама, отписка в один клик.
любых задач
и эффективности
и карьеры
Комментарии
Будьте первым — поделитесь мыслями или задайте вопрос.
Чтобы оставить комментарий — войдите
Это пара кликов. Чтобы избежать спама — только зарегистрированные пользователи. Никакой рассылки, только если вы сами захотите.