Claude как SRE: может ли ИИ чинить себя?

В канун Нового года Opus начал возвращать больше HTTP-ошибок 500, и Алекс попросил Claude Code разобраться.

Claude отследил ошибки до бага в предобработке изображений: падали именно те запросы, которые содержали ровно 22 картинки. По словам Алекса, сам он на этом этапе, скорее всего, просто завёл бы тикет для команды API. Но Claude продолжил — и проверил, кто именно отправляет такие запросы.

Он обнаружил 200 аккаунтов, одновременно посылающих похожие запросы, и все они принадлежали пачке из 4 000 аккаунтов, созданных тремя днями ранее с одинаковым шаблоном email-адресов. Это привело Claude к рекомендации подключить команду безопасности (safeguards team), которая подтвердила факт злоупотребления. Claude вышел за рамки технической работы над багом и посмотрел на ситуацию шире — заметив то, что дежурный, сосредоточённый на исправлении, скорее всего, упустил бы.

Для Алекса это стал его личный «Ход 37»: с этого момента он понял, что работа с инцидентами будет выглядеть иначе.

Claude снова его удивил — в ситуации, когда роутер инференса (inference router) вывел из работы исправный кластер и перегрузил серверы, принявшие его трафик. Пока люди в канале обвиняли дата-центр, Claude заметил, что несколько серверов сообщают о количестве токенов в секунду, физически невозможном для их конфигурации — деталь, которую, на мой взгляд, человек мог бы и не догадаться проверить. Claude пришёл к выводу: с системой всё в порядке, но метрики врут.

Он добрался до системы мониторинга: коллекторы метрик только что были перешардированы (resharded), и на протяжении пяти минут два шарда опрашивали одни и те же серверы, искусственно раздувая показатели, на которые опирался роутер. Затем Claude предложил и проверил исправление, пока команда приостановила автоскейлер коллекторов во избежание повторения.

Для Алекса это был ещё один «Ход 37»: Claude вышел за пределы его инфраструктуры и углубился в стек наблюдаемости (observability stack) — область, в которой сам Алекс не является экспертом.

Но Claude умеет и попадаться в классическую ловушку ложного следа (red herring). В последнем описанном Алексом инциденте один кластер возвращал ошибки на 41% запросов на протяжении пяти минут. Claude заметил, что незадолго до этого упал коэффициент попаданий в локальный кеш. Потеря кеша, казалось, объясняла ошибки, а хронология делала эту версию убедительной. Час спустя сессия другого инженера с Claude помогла найти упущенное: запросы, промахнувшиеся мимо локального кеша, всё равно получали данные из общего кеша. Общий коэффициент попаданий почти не просел — проблемой были перегруженные серверы.

Алекс признаёт, что сам мог совершить ту же ошибку, ведь график идеально укладывался в ожидаемое объяснение. Иными словами, Claude попал в ту же ловушку, что и люди. Алекс вспомнил своего первого менеджера в Google, Стива МакГи (Steve McGhee), который постоянно предупреждал: смотреть на графики без конкретного вопроса — значит рисковать найти «проблемы», которых на самом деле нет. Ирония в том, что суперспособность агента — просматривать куда больше графиков, чем человек, — одновременно даёт ему больше шансов наткнуться на вводящие в заблуждение паттерны.

Чтобы оценить способность Claude «чинить себя», Алекс обращается к петле OODA из арсенала ВВС США: наблюдай (observe), ориентируйся (orient), решай (decide), действуй (act). Идея в том, что побеждает тот, кто быстрее осмыслит меняющуюся ситуацию, — и, по мнению Алекса, это так же верно в канале инцидента, как и в кабине пилота.

Наблюдение — то, в чём большие языковые модели (LLM) блещут. Они умеют искать логи, запрашивать метрики и параллельно исследовать несколько направлений быстрее любого человека-дежурного. Зато ориентирование — осмысление найденного — это та самая зона, где возможности становятся неравномерными.

Принятие решений тоже в неплохой форме. Claude может предлагать исправления, сравнивать их компромиссы и сверять с историей прошлых инцидентов. Наконец, действие — это этап, где граница пока не проведена. Для Алекса любое исправление в проде должно требовать одобрения человека, и он хочет понимать каждую команду, которую выполняет. Для большей автономии, считает он, понадобится классификатор производственных действий (production action classifier), который одобряет рутинные операции и направляет рискованные на проверку.

Алекс — талантливый SRE, дошедший до уровня Staff за восемь лет в Google. Сейчас он работает в Anthropic, имея доступ к лучшим моделям компании и практически неограниченному количеству токенов. Если при таких условиях его ответ на вопрос «Может ли Claude починить себя?» всё ещё звучит как «возможно», это, на мой взгляд, задаёт реалистичную планку ожиданий для всей AI SRE-индустрии.

Я работаю в Rootly, где мы создаём инструменты реагирования на инциденты с поддержкой ИИ. И я бы сказал, что большинство команд начинают с позиции хуже, чем у Алекса, — и дело здесь вовсе не в модели: агент настолько хорош, насколько богат контекст, к которому он имеет доступ.

Код и инфраструктура могут быть лишены инструментации, ограничения безопасности могут закрывать доступ к имеющимся данным, а ключевой контекст нередко существует только в головах у людей. Важна и стоимость. Например, я неоднократно слышал от инженеров, что стоимость отправки логов приложений в Datadog многократно превышала их бюджет — и агент для реагирования на инциденты оставался бесполезным из-за отсутствия нужного контекста.

Эти инструменты, безусловно, способны снизить рутинную нагрузку на oncall-инженеров. Но до полностью автономной работы нам ещё далеко, и я ожидаю, что люди останутся в контуре принятия решений ещё долгое время.