# Блок 10. Сопровождение и метрики

- Курс: [Переход на разработку с ИИ](https://ykononov.ru/ai-cto/), блок 10 из 15
- Автор: Юрий Кононов, CTO (https://ykononov.ru/)
- Страница: https://ykononov.ru/ai-cto/soprovozhdenie-monitoring/
- Обновлено: 2026-10-12. Данные на 2026 год
- Время чтения: 15 мин
- Лицензия: CC BY-NC 4.0: можно использовать и распространять с указанием автора и ссылкой на страницу, коммерческое использование запрещено

> В сопровождении ИИ лучше всего работает как аналитик, который за минуты собирает картину инцидента, а не как оператор, нажимающий кнопки на проде.

Сопровождением называют всё, что начинается после выкатки: инциденты, мониторинг, журналы, трассировка. Здесь ИИ меняет работу так же сильно, как в разработке, но об этом говорят реже, потому что эффект труднее показать на демонстрации. Для корпорации с большой нагрузкой это может оказаться одним из самых ценных направлений.

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

## Инциденты и аварии

ИИ полезен на 3 этапах инцидента. Во время аварии он быстро собирает контекст: что менялось в последние часы, какие сервисы затронуты, какие похожие инциденты были раньше. Это сокращает время до понимания причины, то есть самую дорогую часть аварии. После аварии он пишет разбор инцидента (постмортем) по хронологии из журналов и чата, а люди такую работу обычно откладывают. Между инцидентами он ищет закономерности в истории: какие компоненты падают чаще, какие изменения предшествуют авариям.

Чего делать нельзя: давать агенту право самостоятельно чинить прод во время аварии. Цена ошибки максимальна, а понимание ситуации у модели неполное. Агент предлагает решение, а принимает его человек.

**Пример: разбор инцидента за 10 минут.** Ночью в банке Даниила вырос процент ошибок сервера (код ответа 5xx) в сервисе переводов. Всё время в примере – московское. Дежурный инженер открывает чат с агентом, у которого есть доступ только на чтение к журналам, трассам, системе деплоя и трекеру инцидентов, и даёт одну команду: «Ошибки 5xx в transfers-service с 02:40, собери контекст». Агент за пару минут возвращает сводку:

```
Окно: 02:40–02:55, ошибок 5xx 4,2% (норма 0,1%), затронуты /transfers/create и /transfers/confirm.
Изменения за 6 часов: деплой transfers-service v2.41.0 в 02:35 (пул-реквест #2231, суточный лимит переводов).
Трассы с ошибкой: 97% падают на шаге LimitChecker → daily_limits (таймаут 2 000 мс).
Журналы: «lock wait timeout» на таблице daily_limits, 318 записей, первая в 02:41.
Похожие инциденты: INC-4471 (март), блокировки на той же таблице после добавления индекса.
Гипотеза: новый счётчик в daily_limits пишет в ту же строку, что и лимит по сумме, → конкуренция за блокировку.
Варианты: 1) откат v2.41.0; 2) отключить проверку счётчика флагом LIMIT_COUNT_ENABLED=false.
```

Дальше решает человек: дежурный выбирает флаг, потому что откат затронет ещё 2 исправления из того же релиза. Агент не нажимает ничего сам. Утром он же собирает постмортем по хронологии из чата дежурных и журналов, а человек дописывает единственное, чего нет в данных: почему ревью пропустило конкуренцию за блокировку.

Что нужно подготовить заранее, чтобы такой разбор был возможен: доступ агента к журналам и трассам только на чтение; история деплоев с привязкой к пул-реквестам; архив инцидентов в текстовом виде, а не в головах; и правило из политики ([блок 05](/ai-cto/bezopasnost-politika-ii/)) о том, что любое действие на проде требует подтверждения человека.

## Мониторинг

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

**Пример: что мониторить и как убрать шум.** Для сервиса с HTTP-интерфейсом стандартный минимум – 4 «золотых сигнала» из книги Google о практиках эксплуатации (Site Reliability Engineering): задержка, трафик, ошибки, насыщение ресурсов. Запрос к модели «предложи метрики и пороги для сервиса переводов, 300 запросов в секунду, p95 сейчас 180 мс» даёт разумный черновик. p95 – 95-й процентиль: 95% запросов выполняются быстрее этого значения.

| Метрика | Порог оповещения | Почему именно такой |
| --- | --- | --- |
| p95 задержки /transfers/create | > 400 мс 5 минут подряд | в 2 раза выше текущего, одиночные всплески не считаются |
| Доля ошибок 5xx | > 1% за 5 минут | норма 0,1%, рост в 10 раз – реальная проблема |
| Насыщение пула соединений с базой | > 80% | дальше начинаются таймауты |
| Глубина очереди на подтверждение | > 50 000 сообщений | при 300 запросах в секунду это почти 3 минуты отставания |

Пороги модель предлагает, а утверждает владелец сервиса: только он знает, что p95 в 400 мс для банковского перевода приемлемо, а для проверки баланса на главном экране приложения – нет.

Снижение шума работает так. У Марии дежурные получали около 120 оповещений в сутки, и 80% из них были одной причиной, расходящейся по 10 сервисам. Модель получает поток оповещений за сутки и группирует их по времени, общему корню в графе зависимостей и тексту; на выходе – 8–12 групп с предполагаемой первопричиной каждой. После месяца такой группировки правила оповещений переписали: часть объединили, часть сделали зависимыми от «корневых». Результат, который можно измерить: число оповещений на дежурного в сутки и доля оповещений, по которым дежурный ничего не сделал (её стоит довести ниже 20%).

## Журналирование

Журналы (логи) содержат записи о том, что происходит в системе. У ИИ здесь 2 применения. В первом ИИ хорошо генерирует правильное журналирование в коде: структурированный формат, нужные поля, разумные уровни. Если ваш стандарт записан в файлах контекста, сгенерированный код будет логировать единообразно, чего от людей годами добиваются безуспешно. Второе применение связано с анализом: найти в тысячах строк то, что относится к проблеме, объяснить непонятную ошибку, восстановить последовательность событий.

Ограничение по безопасности: журналы часто содержат персональные данные и секреты, поэтому их отправка во внешнюю модель нарушает правила из [блока 05](/ai-cto/bezopasnost-politika-ii/). Подходят 2 варианта: модель в контуре или маскирование до отправки.

**Пример: стандарт журналирования в файле контекста и что он даёт.** Чтобы модель писала журналы единообразно, стандарт должен быть записан коротко и с образцом. У Даниила в файле контекста это выглядит так:

```
# Журналирование
- Формат: JSON (текстовый формат структурированных данных), одна запись – одна строка, через общий логгер core/log.
- Обязательные поля: ts, level, service, trace_id, span_id, event, duration_ms (если есть).
- Уровни: ERROR – требуется действие человека; WARN – деградация без потери функции;
  INFO – бизнес-события (перевод создан, лимит достигнут); DEBUG – выключен на проде.
- Запрещено писать: номер карты, номер счёта целиком, ФИО, паспорт, сумму перевода.
  Разрешено: account_id (внутренний), masked_card «****1234».
- Образец (время в UTC): {"ts":"2026-10-06T23:41:03Z","level":"INFO","service":"transfers",
  "trace_id":"8f3a…","event":"limit.count_exceeded","account_id":"a-77812","count":31,"limit":30}
```

Что это даёт на практике. Во-первых, все сервисы, где код писали с этим файлом контекста, пишут одинаково, и запрос вида «все события limit.count_exceeded за ночь по одному account_id» работает без парсинга текста. Во-вторых, анализ журналов моделью становится безопасным: в записях нет данных, которые нельзя отправлять, и это можно проверить автоматически тестом на образцовых событиях. В-третьих, при разборе инцидента агент ищет не по строкам, а по полям, и за минуту отвечает на вопросы вроде «какие account_id получили отказ по лимиту между 02:40 и 02:55 по Москве и были ли у них до этого ошибки».

Если журналы старые и неструктурированные, маскирование перед отправкой делается отдельным шагом: регулярные выражения и словари для номеров карт, счетов, телефонов, паспортов, с проверкой на тестовом наборе из нескольких тысяч реальных строк. Этот набор и отчёт о нём – то, что Даниил понесёт в ИБ.

## Трассировка

Трассировкой называют отслеживание пути одного запроса через все сервисы, которые его обрабатывали. В распределённой системе это главный инструмент, который показывает, где именно потерялось время или произошёл сбой. ИИ помогает внедрить трассировку (это трудоёмкая типовая работа по всему коду) и интерпретировать её результаты: по сложной трассе объяснить, где узкое место и почему оно возникло.

**Пример: трасса одного перевода и что в ней видит модель.** Трассировка строится на открытом стандарте OpenTelemetry: каждый сервис добавляет к запросу идентификатор трассы и записывает свой отрезок (span) с временем начала и конца. Для одного перевода у Даниила трасса выглядит примерно так:

```
transfers.create                                  1 840 мс  ← p95 норма 180 мс
├─ auth.verify_token                                 12 мс
├─ limits.check_amount                               18 мс
├─ limits.check_count                             1 760 мс  ← новый шаг
│   └─ db.daily_limits SELECT … FOR UPDATE        1 752 мс  (ожидание блокировки)
├─ antifraud.score                                   31 мс
└─ ledger.post                                       19 мс
```

Человек увидит то же самое, но потратит на это время, а в 5 утра – ещё и внимание. Модель получает трассу вместе с десятком «нормальных» трасс того же запроса и за секунды отвечает: 95% времени ушло на один новый отрезок, он ждёт блокировку в базе, остальные отрезки в норме, причина – конкуренция за строку. Это и есть «интерпретировать результаты трассировки»: не найти длинный отрезок, а объяснить его.

Внедрение трассировки – как раз та типовая работа по всему коду, где агент даёт предсказуемую отдачу: добавить инструментирование в сотню обработчиков по одному образцу, прокинуть trace_id через очереди и фоновые задачи, где он обычно теряется. Задача формулируется спецификацией с критерием приёмки «у 99% запросов на проде трасса сквозная, без разрывов между сервисами», а проверяется отчётом из системы трассировки, а не словами «вроде везде добавили».

## Метрики

Здесь важно различать 2 вида метрик, а этот блок посвящён первому. Метрики системы (задержки, ошибки, нагрузка, доступность) описывают, как работает ваш продукт. Метрики внедрения (скорость поставки, стабильность, стоимость) описывают, как работает ваш процесс разработки, о них рассказывает следующий блок.

По метрикам системы ИИ полезен тем же, чем и по мониторингу: помогает выбрать, что измерять, настроить сбор и объяснить изменения. Одно предупреждение: ИИ ускоряет создание панелей и отчётов, поэтому возникает соблазн измерять всё. Панель с 40 графиками не читает никто, лучше иметь 5 метрик, которые смотрят каждый день.

**Пример: панель из 5 метрик системы.** У Марии после чистки на главной панели сервиса остались: доступность за 30 дней (цель 99,9%), p95 задержки ключевого запроса, доля ошибок, число инцидентов уровня «критичный» за месяц, время восстановления после инцидента (медиана). Всё остальное живёт на вторичных панелях, которые открывают при разборе. Правило простое: если метрику не смотрели 2 недели, она переезжает с главной панели на вторичную; если по оповещению 3 раза подряд ничего не сделали, порог пересматривают или оповещение удаляют.

**Корпорация:** журналы содержат персональные данные, поэтому анализ моделью возможен только в контуре или после маскирования, согласованного с ИБ. Доступ агента к наблюдаемости – только на чтение и только через учётную запись с журналом действий.

**Небольшая компания:** облачная система наблюдаемости плюс внешняя модель с маскированием – рабочая схема с первого дня; главный выигрыш здесь – разбор инцидентов, когда дежурный один и ему некого спросить. Панель из 5 метрик важнее трассировки: сначала понять, что ломается, потом – где.

## Аудит действий системы и ИИ

Аудитом в сопровождении называют запись того, кто и что делал с системой: человек или агент, когда, с какими правами и чем это закончилось. Журналы отвечают на вопрос «что произошло в системе», аудит – на вопрос «кто это сделал и на каком основании».

С появлением ИИ в эксплуатации у аудита 2 задачи. Первая – записывать действия самого агента. У агента из примера с инцидентом доступ только на чтение, но и чтение нужно фиксировать: какие журналы и трассы он запросил, по чьей команде, что вернул. Если агент предлагает действие на проде, в записи должны остаться само предложение и человек, который его принял или отклонил. Вторая задача – анализ: ИИ помогает читать аудиторские записи так же, как журналы, и находить в них необычное – доступ в нерабочее время, массовую выгрузку, действие вне роли.

Что записывать для агента в эксплуатации: учётную запись и человека, который дал команду; время; какие данные агент запросил и из какой системы; какие команды выполнил; что предложил и кто это подтвердил. Требования к хранению запросов и ответов модели те же, что в [блоке 05](/ai-cto/bezopasnost-politika-ii/).

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

**Корпорация:** аудит действий агента – условие допуска к наблюдаемости, а срок хранения записей задаёт регулятор. Через год эти записи понадобятся аудитору ([блок 12](/ai-cto/slozhnosti-vnedreniya-ii/)).

**Небольшая компания:** достаточно отдельной учётной записи для агента и журнала её действий в облачной системе наблюдаемости. Главное – не давать агенту работать под учётной записью инженера: тогда действия человека и агента не различить.

## Источники

- [DORA, описание метрик](https://dora.dev/guides/dora-metrics/)
- [Google, Site Reliability Engineering, глава Monitoring Distributed Systems («4 золотых сигнала»)](https://sre.google/sre-book/monitoring-distributed-systems/)
- [OpenTelemetry, документация по трассировке](https://opentelemetry.io/docs/concepts/signals/traces/)

## Что говорят коллеги

Даниил: Банк · 200 инженеров · первый год. Мария: Продуктовая компания · второй год.

Даниил и Мария о том, где в сопровождении ИИ окупается быстрее всего.

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

**Мария:** У нас самый заметный эффект дало снижение шума в оповещениях: дежурные снова начали их читать. А с панелями мы попались ровно в ловушку из блока. ИИ делает их так легко, что за квартал их стало в разы больше, но никто не смотрел ни одну. Пришлось вернуться к нескольким метрикам, которые смотрят каждый день. Модель в контуре мы не ждали: начали с маскирования.

- **Мария:** Даниил, маскирование до отправки вполне рабочий вариант. Чтобы начать с журналами, ждать модель в контуре не нужно.
- **Даниил:** Маскирование в банке тоже надо доказать ИБ. Если проскочит хотя бы одно поле, вместо пилота у нас будет инцидент.
- **Мария:** Тогда начни с журналов тестовых сред. Там правила те же, а цена ошибки заметно ниже, чем на проде.

## Итог блока

Главное из блока: в сопровождении ИИ ускоряет самую дорогую часть аварии (понимание причины), но чинит прод человек, а журналы уходят в модель только в контуре или после маскирования. По метрикам системы несколько графиков, которые смотрят каждый день, лучше 40, которые не читает никто. Дальше, в [блоке 11](/ai-cto/metriki-dora-baseline/), речь пойдёт о втором виде метрик: как измерять эффект самого внедрения.