Что в логах, что в жизни, самое важное — это связи. ИИ это не исправляет. Он делает только хуже.
После двадцати лет devops большинство программистов по-прежнему воспринимают observability (наблюдаемость) как пожарную сигнализацию — то, к чему обращаются, когда уже всё горит.
А не как контур обратной связи, с помощью которого проверяют каждое изменение после выката. Не как важнейший, незаменимый источник правды о качестве продукта и пользовательском опыте.
Проблема здесь не в первую очередь в культуре и даже не в инструментах. Это проблема данных. Доминирующая модель сбора телеметрии хранит каждый тип сигнала в отдельной «опоре», и тем самым безвозвратно разрывает ткань связей между ними.
Данные вашей наблюдаемости разрушаются уже в момент записи
Модель трёх опор отлично работает для инфраструктуры(примеч.1), но для задач программной инженерии она катастрофична и для агентной валидации не подходит.
Но почему? Причина не в чём-то одном, а в целом маховике взаимно усиливающих факторов. Но самый важный фактор вот в чём:
✨Силу данным придаёт контекст✨
Чем больше контекста вы собираете, тем мощнее становятся ваши данные
По мере расширения набора данных его ценность растёт не линейно, а экспоненциально. А если говорить совсем точно, то по мере добавления контекста она растёт комбинаторно.
Я сделала небольшое приложение на Netlify, где можно указать, сколько атрибутов вы сохраняете на один лог или трейс, и посмотреть, насколько мощным становится ваш набор данных.
4 поля? 6 попарных комбинаций, 15 возможных сочетаний.
8 полей? 28 попарных комбинаций, 255 возможных сочетаний.
50 полей? 1,2 тысячи попарных комбинаций, 1,1 квадриллиона (2^250) возможных сочетаний, как показано на скриншоте ниже.
Когда вы добавляете ещё один атрибут в структурированные события логов, это не просто даёт вам «ещё одну сущность для запроса». Это создаёт новые комбинации со всеми остальными полями, которые уже существуют.
Обратите внимание: эта математика учитывает только ключи атрибутов. Если добавить к этому ещё и значения, точность ваших инструментов станет ещё выше — особенно при работе с данными с высокой кардинальностью.
Ценность данным придают связи
Фраза «данные становятся ценными благодаря контексту» — это, по сути, другой способ сказать, что связи между атрибутами являются самой важной частью любого набора данных.
Это должно быть интуитивно понятно каждому, кто работает с данными. Насколько ценна строка «Mike Smith» или «21 years old»? Без контекста — никакой ценности.
Разнося телеметрию по изолированным хранилищам по типам сигналов, модель трёх опор в итоге уничтожает самую ценную часть ваших данных — их связность.
Похоже, AI-SRE-агентам не нравятся данные из модели трёх опор
Вчера я опубликовала пост в LinkedIn и получила множество интересных комментариев. Один из них был от Кайла Форстера, основателя стартапа в области AI-SRE под названием RunWhen. Он дал ссылку на свою статью «Читают ли люди логи?».
В своей статье он отметил, что менее 30% их AI-SRE-инструментов приходилось на «традиционные данные наблюдаемости», то есть метрики, логи и трейсы. Вместо этого они использовали инструментирование, создаваемое другими ИИ-инструментами, чтобы оборачивать вызовы и запросы. Его вывод:
Оказалось, что качественное рассуждение ИИ требует гораздо меньше данных наблюдаемости, чем мы предполагали, если у него есть альтернативные источники.
Мой вывод немного другой. В конце концов, агенту всё равно требовались инструментирование и телеметрия, чтобы оценить происходящее. Разве это не та же самая наблюдаемость?
Но, как рассказывает Кайл, агенты начали искать более богатый сигнал, чем тот, который давала модель трёх опор. Они вернулись к источнику, чтобы получить «сырую», ещё не агрегированную телеметрию — со всеми сохранёнными связями. Настолько это оказалось для них важно.
Любопытно.
Шалтая-Болтая обратно не собрать
Я всё чаще слышу: «это решает ИИ», «теперь, когда у нас есть MCP, ИИ может бесшовно делать объединения данных между тремя опорами», «эта проблема уже решена».
Хм. Объединения данных между разрозненными хранилищами, конечно, лучше, чем ничего. Но они не восстанавливают связность. Они не возвращают вас в то самое «математически правильное» состояние, где каждый новый атрибут делает все остальные экспоненциально более ценными. На скоростях агентных систем такая реконструкция превращается в бутылочное горлышко и источник сбоев.
Вся индустрия сейчас коллективно пытается понять, каким будет будущее агентной разработки. Самые сложные и интересные задачи, на мой взгляд, связаны с валидацией. Как проверять изменения, если их скорость выросла в 10, 100, 1000 раз?
У меня нет всех ответов, но я точно знаю одно: агентам понадобится наблюдаемость в продакшене с высокой скоростью, гибкостью, огромным количеством контекста и некоторой онтологической опорой, основанной на семантических соглашениях.
Если коротко: агентам понадобятся высокоточные инструменты. А точность обеспечивается контекстом (и кардинальностью).
Продакшен — это очень шумное место
Продакшен — это шумная, хаотичная среда, особенно на больших масштабах. Если вы пытаетесь обнаруживать аномалии без априорного понимания того, что искать, то аномалия должна быть достаточно крупной, чтобы её заметить. (Иначе вы будете «находить» сотни аномалий постоянно.)
Но если у вас есть хотя бы какое-то понимание намерений, а также точные инструменты, такие аномалии можно отслеживать и валидировать даже тогда, когда они предельно малы. Например, когда это всего лишь тонкий поток запросов(примеч.2) на фоне десятков миллионов запросов в секунду.
Представим, что вы работаете в глобальной платёжной системе. Вы выкатываете изменение кода для партнёрских платежей, которые обрабатывают «всего лишь» десятки тысяч запросов в секунду — это лишь малая часть от общего потока в десятки миллионов запросов в секунду, но при этом крайне важная.
Это рискованное изменение, сколько бы тестов вы ни провели на стенде. Чтобы безопасно проверить его в продакшене, вы решаете сначала выкатить новый билд на небольшую группу тестовых пользователей из числа сотрудников. А заодно — почему бы и нет — добавляете ещё один фича-флаг, позволяющий любому пользователю добровольно подключиться к новой функциональности, и включаете его для своей учётной записи.
Проходит несколько дней. Вы пару раз расплачиваетесь своей картой. Всё работает (слава богу).
В понедельник утром вы открываете данные наблюдаемости и выбираете все запросы, содержащие новый build_id или хэш коммита, а также все задействованные фича-флаги. Делаете разбивку по эндпоинтам, после чего начинаете анализировать задержки, ошибки и распределение кодов ответов, сравнивая их с базовой линией.
Хм — что-то выглядит не совсем правильно. Ваши тестовые запросы не падают по таймауту, но выполняются дольше, чем в базовом наборе. Не все, но часть из них.
Дальнейшее исследование позволяет выделить затронутые запросы в группу с определённым хэшем запроса. Упс… как туда незаметно проскочил n+1 запрос (n+1 query)?
Вы быстро вносите фикс, выкатываете новый build_id и расширяете раскатку: теперь изменение уходит на 1% пользователей в выбранном регионе.
При этом аномальные запросы могли составлять всего несколько десятков в день, распределённых на протяжении многих часов, в системе, которая за это время обрабатывала буквально миллиарды запросов.
Точные инструменты позволяют такие вещи находить. Неточные — делают их невидимыми.
Как вы собираетесь заставить агентов валидировать каждое изменение, если последствия этих изменений невозможно обнаружить?[примеч.3]
Можно спросить: а как мы справлялись до сих пор? Ответ — за счёт человеческой интуиции, которая заполняет пробелы. Для агентов это не сработает. Наша экспертиза должна быть зашита в систему, иначе её просто не существует.
Агентам для валидации в продакшене нужны скорость, гибкость, контекст и точность
Раньше столь предельно точные поэтапные раскатки в основном были прерогативой компаний уровня Google и Facebook. Прогрессивная доставка исторически требовала значительного объёма инструментов и инженерных ресурсов.
Агентные рабочие процессы сделают такие автоматизированные методы валидации гораздо проще и доступнее. Но одновременно с этим агенты, разрабатывающие строго по спецификации, будут требовать существенно более высокого уровня точности и автоматической валидации в продакшене.
Для получения качественных результатов от ИИ важна не только ширина данных. Оптимизация данных для рассуждений, атрибуции или обнаружения аномалий включает гораздо больше факторов. Но в основе всего лежит одно — захват и сохранение связей.
В этой ситуации, как и во многих других, ИИ одновременно является и проблемой, и решением[примеч. 4]. К этому придётся привыкнуть.
Если наблюдаемость у вас — это разрозненные метрики, логи и трейсы, вы уже теряете контекст и, вместе с ним, точность решений. На курсе «Observability: мониторинг, логирование, трассировка» разбирают, как собирать и связывать сигналы так, чтобы данные сохраняли ценность и позволяли находить реальные причины, а не симптомы.
Чтобы узнать, подойдет ли вам программа курса, пройдите вступительный тест. До 30 апреля за прохождение теста действует скидка 15% на курс.
Примечания:
1 — Инфраструктурные команды используют модель трёх опор по одной очень веской причине: им приходится эксплуатировать большое количество кода, который они не писали и не могут изменить. Им приходится забирать все метрики и логи, которые генерируют компоненты, и где-то их хранить.
2 — Да, здесь есть некоторые нюансы, которые я опускаю, те самые, что начинаются на «s» и рифмуются со словом “ampling”. Однако подход «богатые данные + выборка» обычно решает баланс между стоимостью и удобством за счёт отбрасывания наименее ценных данных. В модели трёх опор баланс стоимости и удобства достигается, как правило, за счёт отбрасывания САМЫХ ценных данных — кардинальности и контекста.
3 — Пример «иголки в стоге сена» — это наглядная иллюстрация ценности богатого контекста и точных инструментов, но есть и другие. Например: разве не было бы полезно, если бы ваша агентная команда могла проверять любые изменения, связанные с ключами кэша или схемой данных, скажем, раз в день в течение следующих 6–12 месяцев? Такие изменения, как известно, часто проявляются с большим запаздыванием, когда все уже забывают, что они вообще происходили.
4 — Одна фраза, которую я в последнее время часто использую: «ИИ, как и алкоголь, одновременно является и причиной, и решением всех жизненных проблем».
Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные уроки:
14 апреля, 20:00. «Grafana Stack — закрываем все современные потребности Observability». Записаться
16 апреля, 20:00. «Архитектура ИИ-сервисов для High-Load и Low-Latency инференса». Записаться
20 апреля, 20:00. «Качество данных (data quality) на практике: от технических метрик до внедрения в команде». Записаться
