Инциденты и новый контур обратной связи

Третья часть серии про действие. Сначала о том, как меняются разбор инцидентов и пост-мортемы, когда в расследование включаются агенты, затем — о порядке сборки контура обратной связи, которым серия закрывается.

Инциденты и обратная связь в прод

Два сюжета в этом разделе идут навстречу друг другу. Первый — как меняется разбор инцидента, когда участников стало больше, а времени меньше. Второй — как вернуть знание из прода обратно в агента, который пишет код. Оба упираются в одну границу: где именно должен стоять человек.

Кейс «два ночи»: не хватает не данных, а общей картины

Мерлин (incident.io, вендор — продаёт весь стек: on-call, response, AI SRE, status pages) в докладе «I Broke Production at 2 AM» описывает знакомую сцену. Телефон звонит в два ночи. Алерты горят везде. На звонке ещё трое, у каждого своя теория, полной картины нет ни у кого — и решения принимаются с долей нужной информации. Каждая минута дорога. Масштаб: 700 000 инцидентов у клиентов накопительно, около 1500 клиентов, 180 человек в компании.

Продуктовый ответ конкретный: агент начинает расследование до того, как человек зашёл в Slack-канал. К моменту, когда дежурный открыл ноутбук, контекст уже собран. Это разумно: дефицит во времени на сведение данных. Рядом ставится «рождественская ёлка» Новаковича (Dash0, вендор): при серьёзной аварии мигает всё, и когда красное всё, ты по-прежнему не знаешь, откуда идёт. Агент полезен тем, что успевает пройти больше веток за то же время.

И его же формулировка следующего шага: переход от одиночной работы к совместной. В разборе аварии рядом с людьми параллельно работают один-три агента, каждый копает своё, человек добавляет контекст. Ведущий подкаста сводит это в формулу «context + evals»: делегирование требует снабдить исполнителя знанием и иметь способ проверить работу. Evals заведомо неполны — как и у людей, — но выборочная проверка обязательна.

Отдельно Новакович пересказывает публичное заявление CIO The Telegraph о том, что клиент переписал плейбук incident resolution: раньше шли по списку шагов, теперь первым действием спрашивают агента. Это пересказ вендором чужого поста в LinkedIn — проверяй по первоисточнику, прежде чем ссылаться.

Пост-мортем: два правила, которые не меняются, и одно, которое меняется

Не меняется первое: разбор остаётся blameless. Мерлин повторяет это дважды, в том числе как открывающий тезис доклада. Смотрят на процессы и отсутствие guardrails, которые позволили ситуации возникнуть. Агенты этого не смягчают — при выросшем потоке изменений вопрос «кто виноват» ещё бессмысленнее. Не меняется второе: ценность корпуса появляется только со временем, на накопленных разборах, — Мерлин оговаривает это прямо.

Меняется третье — форма пост-мортема. В документ встраиваются объекты: сервисы, команды, клиенты, pull requests, Slack-переписки, другие инциденты, таймлайн. Накопленный корпус «богатых» пост-мортемов читают и люди, и AI — для распознавания повторяющихся паттернов: если похожее уже было, это кандидат в первопричины нового инцидента.

Технический приём, который стоит украсть: у каждого узла редактора есть «HTML schema awareness» — описание на естественном языке, что это за узел и как его создавать, и оно передаётся модели. Правило шире одного продукта: чтобы агент писал в твою структуру, структура должна себя объяснять. Сроки проекта: старт в августе, демо в сентябре, early access в ноябре, GA в декабре, старый редактор выключен в январе.

Runtime intelligence: прод как вход для агента

Мэй Уолтер (сооснователь Hud, вендор — это и есть их продукт) в докладе «From Blind Spots to Merged PRs» описывает слой между продом и кодовым агентом. По каждой функции собирается: как часто выполняется, сколько занимает, падает ли. При сбое проактивно снимается глубокий форензический контекст.

Ключ в порядке действий: сначала сузить область до функции, и только потом доставать глубину. Это прямое следствие проблемы, разобранной во второй части серии: модель разбирает один трейс и не разбирает миллион.

Второй, по её словам самый недооценённый эффект prod-to-code mapping — инверсия вопроса. К привычному «почему это медленно» добавляется «я собираюсь тронуть эту функцию — на что это повлияет, задену ли я платежи или авторизацию». «I'm going to touch this. What does that impact? And should I care about it?» Оценка риска происходит до внесения изменения.

Архитектурно петля у них из трёх намеренно открытых слоёв: язык запросов к данным (у них ClickHouse), скиллы с методологией расследования, автоматизации поверх (autofix, удаление мёртвого кода). Агенту нужен доступ на каждом уровне — «инструментов недостаточно, потому что агенту может понадобиться то, что я не могу выразить словами». Оговорка Уолтер: рабочий процесс — это код. Его не отгружают и не забывают, его постоянно правят. Если правки трудны, люди перестают их делать.

Про скиллы у неё же аргумент, полезный за пределами их продукта: методология («как подходить к HTTP 500», «как к утечке памяти», «как к деградации производительности») зашивается заранее, чтобы агент не тратил токены и chain-of-thought на переоткрытие известного. Побочный эффект — это выводит знание Дэйва из головы Дэйва.

Требования к среде выполнения агентных рабочих процессов они формулировали осознанно: работа в облаке; нейтральность по compute, harness и модели («никто не знает, какая лучшая — бывают сезоны»); безопасность правок и вызовов инструментов из готового решения; триггеры по вебхукам и по расписанию; лёгкость правок. Выбрали GitHub Agentic Workflows: GitHub Actions у людей уже есть, и путь наименьшего сопротивления здесь важнее гипотетически лучшего варианта в вакууме. Запуск еженедельный, отчёт в Slack.

Со сцены: 100 мс в норме, 45 секунд в выбросах

• Кто и где: Мэй Уолтер, сооснователь Hud, доклад «From Blind Spots to Merged PRs», AI Native DevCon. Вендор — runtime intelligence и есть их продукт.
• Что показали: отбор находок идёт по трём осям — hot paths (часто вызываемые эндпоинты), бизнес-влияние (платежи, аутентификация) и риск. Ищут максимальный эффект при минимальном риске, без миграций. Формат вывода человекочитаемый, буквально: «этот эндпоинт обычно 100 мс, но иногда 45 секунд — потому что используется Mongo distinct; замена на search даст 30–40%». Дальше человек выбирает — посмотреть глубже, завести тикет или открыть PR; обе ветки размечены, чтобы это можно было измерять.
• Цифры: P90 около 100 мс против выбросов около 45 с; ожидаемый выигрыш 30–40%; N+1 запрос, проживший в кодовой базе шесть лет (самой базе 15 лет).
• Что это меняет: центральная идея доклада: починить находку обычно можно, проблема в приоритизации. «Час или три недели?» — чтобы узнать цену, приходится заплатить исследованием. Её метафора: как нести товар на кассу, чтобы узнать, сколько он стоит. Если исследование делает агент еженедельно и выдаёт оценённые по ROI возможности, performance-спринт, который откладывали месяцами, начинает происходить регулярно. Оговорка её же: бэклог от этого не опустеет, цель — лучшие решения.

Что у Hud не сработало

Честная часть доклада — три задокументированных провала.

Провал первый: автоматические PR. Логичный следующий шаг — «открывать PR на все находки высокого импакта и низкого риска» — провалился. Никто их не смотрит. Уолтер сравнивает это с опытом «700 issues в Datadog и Sentry»: список, на который смотрят и решают не начинать. Её вывод стоит запомнить: убеждать надо человека, который решает, стоит ли это внимания. Дословно: «instead of convincing the agent that it's worth the tokens — he will always think that they are».

Провал второй: plausible but unverified. Первые предложения агента звучали верно, но было неизвестно, там ли бутылочное горлышко: при 20 секундах ответа непонятно, где именно потрачено время, — а предложение уже выглядит убедительно.

Провал третий: lazy fix. Есть исключение — давайте его поймаем. Оптимизация «по локальному синтаксису» даёт локальный ответ, когда нужен более широкий взгляд. Лечится описанием того, что такое хорошее исправление, — «как staff engineer объясняет новичку».

Из этих трёх Уолтер выводит порог, который применим гораздо шире её доклада:

«If something works 90% of the time, it's not an automation, it's streamlining humans».

При 90% надёжности говорить об автоматизации рано: это ускорение человека. Переход от «ведёт человек» к «ведёт рабочий процесс» требует принципиально более высокой уверенности, потому что каждое ложное предложение стоит прерывания потока инженера и убивает доверие ко всему процессу. Цифра 90% — риторический порог без замера за ним. Но стоит она ровно там же, где эмпирика Помеля из первой части серии: два ложных срабатывания подряд — и систему выключают навсегда. Два вендора, независимо друг от друга, описывают один и тот же обрыв доверия.

Отсюда же стратегия внедрения, которую Помель (Datadog, вендор) формулирует прямо: начинать с узкого подмножества задач, где уверенность максимальна, — высокая precision ценой низкого recall. Препятствие он называет честно: LLM не умеют понимать, чего они не знают, и всегда охотно отвечают, поэтому основная работа состоит в том, чтобы понять, когда ты прав. Его оговорка про сложность: разбор инцидента занимает команды квалифицированных людей и недели — в отличие от вождения, которое осваивает любой шестнадцатилетний.

Замыкание петли: детект, фикс и доставка

Помель рассказывает траекторию Datadog так: первые десять лет — принципиально никаких обратных действий, только приём данных. Несколько лет назад начали строить автоматизацию рабочих процессов, и именно это теперь позволяет замкнуть петлю: детект, генерация кода исправления и доставка. Самое простое поле — 500-е ошибки после релиза: диагноз очевиден, код исправления генерируется легко, вся сложность в проведении и валидации изменения. Его аргумент за автоматизацию действия: «For AI to show its value, you need to automate action. If you have to keep pestering the humans to do things, you're not going to be successful». Это CEO, обосновывающий продуктовую траекторию своей компании.

Технически под это подложена собственная модель — Toto, foundation model для временных рядов. Причины две: общие LLM плохи в числах и особенно во временных рядах, и модель должна быть маленькой, чтобы запускаться in-process на огромном числе рядов.

Обучали на собственных данных, где есть сигнал качества — видно, какие ряды используются для алертов и как часто на них смотрят. Первая, «наивно» построенная версия оказалась лучшей в своём классе, в том числе на задачах вне observability, — это заявление вендора без ссылки на бенчмарк, в открытый доступ модель не выкладывали. Цель — сдвиг от обнаружения к опережению: «этот монитор сработает через час, потому что растёт очередь запросов к базе», причём правило не закодировано, модель выучила связь.

Полезный контринтуитивный результат оттуда же: модели, обученные под конкретного крупного клиента, пока работают хуже широких. Данные у клиентов разнообразные, но компоненты общие (MySQL, Postgres) и имена метрик семантически похожи. И продуктовое ограничение: ценность должна быть видна в первый день.

Две вещи, которые ломают петлю снаружи

Prompt injection через логи и трейсы — это не теория. Помель говорит, что инъекции уже наблюдались (раньше это был XSS через лог). С LLM поверхность размывается: control plane и data plane слиты, всё, что пришло, фактически исполняется моделью. Автофикс требует генерации и исполнения кода — двойной риск. Вывод: жёсткий sandbox и defensive coding для всех входящих данных, и сквозных end-to-end моделей в этой области не будет — нужны проверки на каждом шаге. «It's good habit to imagine that anything that processes external data might end up executing untrusted code». Его аналогия: «open S3 bucket» новой эпохи — это промпт в чате.

Ответственность. Ограничение автономии может оказаться юридическим по своей природе: какую ответственность берёт вендор за действие, которое раньше было решением пользователя. Помель называет это ситуацией «стажёр уронил прод-базу» — территория, по его мнению, не новая (авто-обновления уже приводили к громким авариям), но рамки требуют уточнения.

Обратная связь не в диф, а в систему

Последний кусок — правило Йегги и Нокса (Tessl, вендор). Прежде чем оставить комментарий агенту, инженер обязан хотя бы раз отмотать назад и изменить скилл, тест или архитектуру так, чтобы ошибка не возникла, и перезапустить. Если и на втором прогоне агент не справился без подсказок, тогда уже можно комментировать.

Это то же движение, что у Кормака после инцидентов («какие тесты поймали бы это?») и у Уолтер со скиллами: обратная связь идёт в систему, из которой потом выходят все следующие диффы. Оговорка Tessl: фабрика деградирует со временем, на её гигиену закладывают отдельные роли и токены. Их цели — no human-written code и no interactive coding sessions; «no human code review» назван долгосрочной целью, ещё не достигнутой.

Коротко

• Дефицит при инциденте — во времени на сведение картины. Ответ incident.io (вендор): агент начинает расследование до прихода дежурного; 700 000 инцидентов накопительно, около 1500 клиентов.
• Пост-мортем становится структурированными данными: сервисы, команды, PR, Slack, таймлайн как объекты. Чтобы агент писал в структуру, структура должна себя объяснять. Blameless-принцип агентами не смягчается.
• Runtime intelligence сужает область до функции, потом достаёт глубину (Уолтер, Hud — вендор). Инверсия вопроса — «что сломается, если я трону эту функцию» — недооценена сильнее всего.
• Автоматические PR провалились у Hud. Убеждать приходится человека: агент всегда считает, что токены того стоят. Кроме того, два антипаттерна — plausible but unverified и lazy fix.
• При 90% надёжности говорить об автоматизации рано: это ускорение человека. Эта планка совпадает с эмпирикой Datadog про два ложных срабатывания подряд: доверие обваливается.
• Петля замыкается только через действие, и там же вылезают prompt injection через логи и трейсы и вопрос ответственности — обе проблемы Помель считает нерешёнными.

Новый контур обратной связи

Если свести весь материал к одному предложению, получится так: раньше наблюдаемость отвечала на вопрос «что сломалось», теперь она отвечает на вопрос «что мы вообще построили» — и это разные контуры, с разными требованиями к точности.

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

Порядок сборки

0. Фундамент — телеметрия, которую поймёт агент

• 0.1 OTel-нативно, без конвертации в проприетарный формат. Модели понимают трейсы по спецификации, которую видели в обучающих данных (Новакович, Dash0 — вендор). Кастомные имена метрик — налог, который ты платишь каждым запросом.
• 0.2 Теги. В OTel обязателен ровно один — service.name. Имена пода и хоста проставлять принудительно (k8s-оператор и авто-инжект инструментации).
• 0.3 Collector: отправка в несколько систем сразу, персональные данные вычищаются до отправки. В спанах агента лежат промпты и ответы, поэтому телеметрия теперь относится к персональным данным (Помель, Datadog — вендор).

1. Агентный прогон — что писать (Газит, Traceloop — вендор)

• 1.1 Logs — промпты, completions, вызовы функций (содержимое целиком).
• 1.2 Metrics — token usage, latency, error rate.
• 1.3 Traces — весь многошаговый прогон и каждый шаг отдельно.
• 1.4 RAG — retrieval отдельно: запросы, индексы, векторы, scores.
• 1.5 system_fingerprint — чтобы отличать дрейф провайдера от собственной регрессии.

2. Доказательство — то, что заменяет покрытие (Кормак, не вендор)

• 2.1 Внешний оракул: живая система или зафиксированная вне репозитория модель поведения. Оракул, написанный тем же агентом, — тавтология.
• 2.2 Mutation testing поверх покрытия; отчёт читает агент, действовать напрямую не даём — много ложных срабатываний (Нокс, Tessl — вендор).
• 2.3 Типы там, где они убивают класс багов целиком.
• 2.4 AI security review по всему состоянию кода, а не только по PR.
• 2.5 Оценка агента — только на закрытом и свежем. Публичное демо измеряет память модели (кейс Dash0 на OTel-демо).

3. Prod-to-code — обратная связь (Уолтер, Hud — вендор)

• 3.1 Маппинг на уровне функций: частота, длительность, падения.
• 3.2 Сначала сузить область функцией, потом доставать глубину. Модель разбирает один трейс и не разбирает миллион.
• 3.3 Triage как tool через MCP. Вариант «дадим модели больше контекста» проблему объёма не решает.
• 3.4 Скиллы с методологией (HTTP 500, утечка памяти, деградация), чтобы не платить токенами за переоткрытие известного.

4. Действие — замыкание петли

• 4.1 Стартовать с узкого класса, где уверенность максимальна: высокая precision ценой низкого recall (Помель — вендор).
• 4.2 Начинать с 500-х после релиза: диагноз очевиден, сложность — в проведении и валидации изменения.
• 4.3 Sandbox и defensive coding для всех входящих данных. Логи и трейсы — вектор prompt injection, это уже наблюдалось.
• 4.4 Обратная связь идёт в систему: сначала почини скилл, тест или архитектуру и перезапусти, и только со второго раза комментируй диф (Йегги и Нокс, Tessl — вендор).

Шаги 0–1 стоит делать в любом случае. Шаг 2 — там, где агент пишет значимую долю кода. Шаг 3 окупается на кодовых базах со стажем (у Hud N+1 запрос прожил шесть лет в пятнадцатилетней базе). Шаг 4 — последний, и его стоит держать узким дольше, чем хочется.

Что мерить

Что	Зачем	Откуда цифра
Token usage на прогон и на класс задач	Токены — единица работы фабрики, качество становится ручкой расхода	Йегги; Газит (метрики)
Смена system_fingerprint при том же имени модели	Отделить дрейф провайдера от своей регрессии	Газит, Traceloop — вендор
Доля валидных находок автоматики	Ниже порога — автоматику выключают навсегда	Кормак: около трёх четвертей у security review; Помель: два ложных срабатывания подряд
Дельта до и после исправления (P90 против выбросов)	Проверить, что чинили бутылочное горлышко, а не то, что рядом	Уолтер: 100 мс против 45 с, ожидание 30–40%
Судьба каждой находки: посмотрели, тикет или PR	Единственный способ узнать, что автоматику вообще читают	Уолтер: обе ветки размечены
Что тесты поймали при мутации	Покрытие не доказывает ничего, мутация — доказывает	Нокс, Tessl — вендор
Свежесть корпуса пост-мортемов	Ценность появляется только на накопленном	Мерлин, incident.io — вендор

Чего в материале нет и придумывать не надо: измеренной экономии времени от агентной наблюдаемости, честного бенчмарка precision AI SRE-агентов, подтверждённой цифры «90% вендоров конвертируют OTel». Всё это оценки спикеров.

Где ставить человека

Три места, и каждое выводится из конкретных провалов.

Первое — генерация гипотез. Кормак прямо разделил: человек читает документацию и спрашивает «а это правда?», находя края. Агент этого не умел. Зато агент отлично проверяет подсказанные гипотезы и типовые края — 0, 1, 10001. Гипотезы твои, объём проверок — его.

Второе — решение «стоит ли это внимания». Провал автоматических PR у Hud: агент всегда считает, что токены того стоят, поэтому убеждать надо человека. Список из 700 issues — это список, на который смотрят и решают не начинать.

Третье — приёмка автоматического действия, пока precision не доказана на твоих данных. Планка Уолтер (при 90% надёжности говорить об автоматизации рано — это ускорение человека) и эмпирика Помеля (два ложных срабатывания подряд — и систему выключают навсегда) описывают один и тот же обрыв: доверие обваливается. И то, и другое — риторические пороги вендоров, но сходятся они независимо.

Что человеку не обязательно делать — читать весь код. У Кормака 350 000 строк Rust, которые он не читал, и при этом две воспроизводимые 500-е ошибки, найденные в самом S3. Внимание тратится на границы: оракул, спека, приёмка.

Спор, который остался нерешённым

Тезис «большинство платформ наблюдаемости не переживёт агентную эру» так и не получил в этих докладах измеримого подтверждения. Новакович (Dash0) описывает риск своей же компании: ценность создаётся внутри агента, платформа остаётся хранилищем, а это гонка на дно по цене. Помель (Datadog) отвечает, что лидер рынка может выбирать классы задач и стартовать с высокой precision. Оба вендоры, оба описывают роадмапы.

Показательнее их обоих — трезвость Помеля в конце: категория AIOps существовала десять лет назад, и «AI» там был регулярками; Datadog первые десять лет намеренно не писал AI на сайте; технология «ещё не совсем там». И его личная строчка: «I haven't reached break-even yet. I'm still spending more time learning about it than it saves me». Это говорит CEO компании, которой выгодно утверждать обратное.

Финальная мысль

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

Из материала складывается другая схема. У AI-приложения нет момента «оно работает» до прода (Помель). Тесты стали инструментом разведки, и доказательством корректности они больше не служат (Кормак). Кодовый агент не знает, как его код ведёт себя в реальности (Уолтер). Предмет наблюдения сместился с изменения на систему, которая изменения производит (Йегги: «not a given PR, but a system that produces PRs»).

Значит контур замкнулся: наблюдаемость стоит в начале цикла разработки. Прод — источник, из которого агент получает контекст перед тем, как написать следующую строчку. Всё остальное в серии — о том, как сделать этот вход достаточно узким, чтобы через него не прошло то, чему ты не поверил бы от человека.