Что сломалось в мониторинге

Кода стало больше, чем внимания

Эта серия — о том, почему привычный мониторинг ломается, когда код пишут агенты, и что приходит на смену. Материал построен на докладах конференции AI Native DevCon 2026.

Джастин Кормак в докладе «When Tests Lie» (AI Native DevCon) рассказывает про своё хранилище, совместимое с S3: 350 000 строк Rust, написанных почти целиком AI, — и он не читал этот код. Rust он, по собственному признанию, знает наполовину. За одну неделю рефакторинга диф составил 120 000 добавленных и 75 000 удалённых строк. Один файл дорос до 43 000 строк, прежде чем его пришлось разбирать вручную. Для сравнения, по его же оценке: типовые реализации объектного хранилища пишут от двух лет до десятилетия.

Держи эту картинку в голове весь остальной текст. Это предельный случай уже наступившей нормы: код есть, автора у него нет.

Оливье Помель, CEO Datadog, в разговоре «Datadog CEO on AI Security, Trust and the Future of Observability» описывает тот же сдвиг с другой стороны. За 40–50 лет продуктивность выросла на порядки, AI добавляет ещё ×100–×1000 — это его риторические оценки без замеров, и Помель здесь заинтересованная сторона: ровно этот сдвиг увеличивает рынок его компании. Но побочный эффект он формулирует точно: разработчик всё хуже понимает, что делает его приложение. Центр работы уезжает с «набрать код» на «работает ли оно, не стоит ли дороже, чем должно, делает ли то, что нужно бизнесу».

Мерлин из incident.io в докладе «I Broke Production at 2 AM» добавляет арифметику. Даже если петли обратной связи снижают change failure rate, при росте числа изменений в пять–десять раз (оценка спикера, без измерения) абсолютное число поломок растёт. Мониторинг проектировался под другой темп потока изменений.

И дальше — тезис, ради которого стоит читать всё остальное. Помель: у обычного приложения после деплоя есть довольно точное представление, делает ли оно то, что должно. У AI-приложения такого представления нет в принципе. «For an AI application, you don't [know], and you need to measure in production». Это переворачивает роль наблюдаемости: из подстраховки, которую вспоминают, когда что-то пошло не так, она становится единственным каналом, по которому ты вообще узнаёшь, что построил.

Про заявленный тезис

Название доклада Мирко Новаковича (CEO Dash0, ex-founder Instana) звучит как приговор: «Why Most Observability Platforms Won't Survive the AI Agent Era». Прежде чем принимать его за вывод, посмотри, кто его произносит и что за ним стоит.

Аргумент «за» — его собственный, и он честно называет это экзистенциальным вопросом для своей компании. Если пользователь работает с наблюдаемостью изнутри Cursor, Claude Code или стороннего AI SRE-агента, ценность создаётся там, а платформа остаётся хранилищем. «At the end people will pay for the value, not for the data». Хранилище — это гонка на дно по цене.

Аргумент «против» звучит от Помеля, и он тоже вендор — крупнейший лидер категории. Его контраргумент: компания, которая уже собирает всю телеметрию, может выбирать, в каких классах инцидентов автоматизировать действие, а где промолчать. Беспилотник не может сказать «я делаю только левые повороты», а платформа наблюдаемости — может, и потому стартует с высокой precision при низком recall.

Оба вендоры. Оба описывают собственные роадмапы. Ни один в этих разговорах не привёл цифры, которая бы решала спор. Поэтому ниже, в разделе «Что сломалось в мониторинге», тезис о невыживании разбирается как спор, с обеими сторонами.

Что дальше

Раздел 1 — что именно сломалось в мониторинге: объём, отсутствие автора, недетерминизм, и почему при крупной аварии алерты бесполезны.

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

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

И одна методическая рамка на всю серию. Почти все, кто содержательно говорит о наблюдаемости в агентную эру, её продают: Datadog, Dash0, Traceloop с проектом OpenLLMetry, Hud, incident.io, Tessl. Слушать их стоит: у них лучшие данные в отрасли, и они первыми упираются в реальные ограничения. Но каждый раз отделяй наблюдение от продуктовой ставки. Такие места помечены прямо в тексте, а там, где спикеры друг другу противоречат, показаны обе позиции без попытки свести их к одной.

Что сломалось в мониторинге

Сломалось допущение, на котором держался мониторинг: изменений мало, у каждого изменения есть автор, одинаковый вход даёт одинаковый выход. Агентная разработка убирает все три.

Объём: поток изменений вырос быстрее, чем контур контроля

Мерлин (incident.io, доклад «I Broke Production at 2 AM») формулирует это как арифметику. AI резко поднял темп изменений. Допустим, петли обратной связи работают и change failure rate падает — но если число изменений выросло в пять или десять раз (оценка спикера, без измерения), абсолютное число поломок всё равно растёт. incident.io продаёт платформу incident response, интерес прямой. Но сама арифметика от интереса не зависит.

Масштаб на конкретике даёт Кормак («When Tests Lie»): 350 000 строк Rust, неделя рефакторинга — 120 000 добавленных и 75 000 удалённых строк, 5000 тестов, проходящих за две минуты. Ревью такого потока глазами невозможно: глаз столько не пропускает.

Есть и архитектурный предел. Симон Мартинелли в докладе «Lessons from Spec-driven Development» описывает клиента-страховую: около 500 микросервисов и около 500 микрофронтендов. По его опыту это делает агентную работу почти невозможной — агенту нужен весь релевантный контекст в одном месте. Его рекомендация — self-contained systems: вертикали, в которых интерфейс, логика и база данных собраны в одном репозитории. Возврат к монолиту с тысячами таблиц он при этом не предлагает. Оговорка: это его консалтинговый опыт на бизнес-приложениях, опыта продуктовой разработки за ним нет. Но вывод для наблюдаемости прямой: топология системы теперь влияет на то, можно ли её вообще расследовать агентом.

Автор: код есть, спросить некого

Мэй Уолтер (сооснователь Hud, вендор runtime intelligence) в докладе «From Blind Spots to Merged PRs» описывает петлю, которая перестала фильтровать: один агент делает PR, второй говорит «выглядит отлично», тесты зелёные — и код всё равно находит творческие способы упасть в проде. Оба конца контроля стали автоматическими. Её формулировка: «Coding agents have no idea how [the code] actually behaves [in production]».

Помимо организационной, тут есть и техническая причина. Продовый контекст выражен в сервисах и эндпоинтах — в её примере эндпоинт отвечает 5 секунд, P99 — 6 секунд, P100 — 17 секунд. Кодовый агент рассуждает функциями, файлами и методами классов. Связь между тем и другим он может угадать, но не знает. Отсюда её решение — prod-to-code mapping на уровне функций (разбор — в третьей части серии). Её же оговорка: часть проблем действительно ловится статическим анализом, и mapping нужен там, где надо перейти от «расследование ведёт человек» к «расследование ведёт рабочий процесс».

Помель (Datadog, заинтересованная сторона) описывает ту же дыру со стороны навыка: чем выше продуктивность, тем меньше разработчик понимает свою систему. И делает продуктовый вывод — если ты код не писал, наблюдать нужно исход: делают ли пользователи то, что нужно, получают ли ценность. Причину ищешь потом и там, где она есть — в коде, в спеке, в инфраструктуре. Отсюда его прогноз о слиянии observability с product analytics. Прогноз совпадает с роадмапом Datadog, где product analytics уже стоит поверх RUM, — читай его как позицию вендора.

Недетерминизм: одинаковый вход, разный выход

Андрей Райков (principal engineer, Delivery Hero — не вендор, внутренний кейс) в докладе «AI Driven Load Test Analysis» перечисляет ровно то, что ломает мониторинговую логику «сравнили с порогом»:

• результаты различаются между прогонами при одинаковом промпте;
• различаются между моделями;
• деградируют со временем — через одну-две недели вывод «менялся драматически», и это при том, что каждый раз создаётся новый тред, без длинного диалога.

Его правило: «Every time you modify your prompt you should expect unexpected». И отдельно — детерминированная версия той же задачи («тупое сравнение чисел») работала пять лет: «It's very dumb but it works».

Помель добавляет главное. У обычного приложения после деплоя есть довольно точное представление, делает ли оно то, что должно. У AI-приложения такого представления нет в принципе — измерять можно только в проде. Его иллюстрация: было 1% неудовлетворительных диалогов, стало 5% — почему?

Следствие, которое дорого стоит эксплуатации: телеметрия сменила класс данных. Раньше в трейсы и логи не попадали рецепты врача и номера соцстрахования. Вход и выход модели — попадают. Меняются требования к хранению, доступу и защите. При этом без просмотра этих данных наблюдаемость LLM-приложения не построить вообще. Это противоречие Помель не разрешает — он его констатирует.

Отдельная поломка на входе — качество самой телеметрии. Новакович (Dash0, вендор) напоминает: в OpenTelemetry обязателен ровно один тег, service.name. Раньше проприетарный агент дописывал pod name и host name сам. Теперь контекст приходит от клиента, и если клиент их не проставил, запрос «дай логи этого пода» физически невыполним. Появились компании, занимающиеся только качеством телеметрии. Практические обходные пути — во второй части серии.

Дашборд как протез

Новакович: график придумали ради человека — спайк в 5000 точек глазами в данных не найти, на картинке он заметен. Агент читает исходные данные напрямую. Значит первичный экран сервиса — текстовый статус вида «работает в пределах последних 30 дней, но появились две новые ошибки, выглядят подозрительно». Его формулировка: «An agent doesn't need charts anymore. The charts are just for the user». Оговорка обязательна: Dash0 строит продукт именно на этой ставке, а «5000 точек» — иллюстрация из доклада, без замера за ней.

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

И два наблюдения, которые стоит держать рядом:

• «Рождественская ёлка». При серьёзной аварии всё связано со всем, поэтому мигает всё. Когда красное всё, ты по-прежнему не знаешь, откуда идёт. Именно тут нужен эксперт, знающий «эта база подключена ко всему».
• Знание живёт в головах. Экспертиза «где смотреть» не документирована. Уходят два человека — знание исчезает. Новакович предлагает «enterprise architecture management tool для агентов»: машиночитаемый корпус знаний о системе, включая architectural decisions. И сам признаёт, что не знает, кто должен этот слой держать — «не уверен, что это будем мы».

Спор о невыживании платформ

Тезис Новаковича стоит развернуть в обе стороны, потому что аргументы разной природы.

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

Со сцены: два ложных срабатывания — и систему выключают навсегда

• Кто и где: Оливье Помель, CEO Datadog, разговор «Datadog CEO on AI Security, Trust and the Future of Observability» (подкаст AI Native Dev). Крупнейший вендор категории — заинтересованная сторона.
• Что показали: заказчики говорят «давайте мне false positives, я сам разберусь» — и это, по его словам, ложь. Люди пойдут по ложному следу ради коллеги, но не ради машины. Отсюда планка precision для автоматических выводов должна быть очень высокой. Отдельное наблюдение: в безопасности планка ниже, чем в operations, потому что соотношение риска и выгоды другое — «уронить нагрузку, чтобы предотвратить взлом, приемлемо; уронить её, чтобы предотвратить падение, — нет».
• Цифры: «два false positive подряд» — эмпирика Datadog, без формального замера. Точная причина аварии три-четыре года назад была «научной фантастикой», сейчас, по его оценке, «в пределах досягаемости».
• Что это меняет: доверие к автоматике обваливается. Значит стратегия внедрения начинается со сужения до тех случаев, где ты почти наверняка прав. Помель прямо говорит, что главное препятствие — LLM не умеют понимать, чего они не знают, и всегда охотно отвечают, поэтому основная инженерная работа состоит в том, чтобы понять, когда мы правы.
• Как читать: это одно из самых полезных наблюдений темы, но оно же — объяснение вендора, почему он не выпускает автоматику быстрее конкурентов.

Коротко

• Сломалось допущение, на котором держался мониторинг. Он рассчитан на поток изменений, у которого есть автор и повторяемое поведение. Агентная разработка убирает и то, и другое (Мерлин из incident.io, Уолтер из Hud, Райков из Delivery Hero).
• Тесты и ревью перестали быть фильтром, когда оба конца петли автоматические: «Coding agents have no idea how the code actually behaves» (Уолтер, Hud — вендор).
• У AI-приложения нет момента «оно работает» до прода (Помель, Datadog — вендор). Наблюдаемость превращается из подстраховки в единственный источник знания о системе.
• Телеметрия стала персональными данными, а её качество — узким местом: в OTel обязателен ровно один тег service.name (Помель; Новакович, Dash0 — вендор).
• Тезис «большинство платформ не выживет» не разрешён. За него — уход ценности в агента и потеря семантики OTel; против — возможность лидера рынка выбирать задачи и стартовать с высокой precision. Обе стороны вендоры, измеримых аргументов ни одна не привела.