Настройка и проверка автоматического сбора показателей

Гайд для ИИ-инженера. Работа начинается на первой неделе PoC параллельно онбордингу, при выбранных показателях и доступных источниках. Повторяется при изменении процесса, источников, правил оценки и по замечаниям к сводкам.

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

Исполнители и результат

Сбор показателей — одна из функций агента внедрения, которого ИИ-инженер создаёт на первой неделе PoC параллельно онбордингу. Он также помогает вести журналы, собирать подтверждения выполнения чек-листов и готовить материалы к встречам. Замечания РП клиента по итогам проверки оценок поступают ИИ-инженеру: тот исправляет данные или правила агента, проверяет изменения на примерах и сохраняет версию и историю исправлений.

Обычно первоначальную настройку выполняет специалист сопровождения вместе со специалистом клиента. Передачу настройки и поддержки фиксируют в журнале передачи обязанностей, без отдельного обязательного графика. При старте Пилота ответственность автоматически не меняется; поддержка сохраняется по потребности.

Навык содержит алгоритм сборки, источники, связи, вычисления, проверки и версию. Показатели и цели остаются в перечне показателей; сводки, ограничения и решения — в журнале этапа. Распределение ответственности описано в гайде РП.

От процесса и плана к событиям

ИИ-инженер вместе с командой читает статусную модель задач и Git-процесс, затем маршрут агента с выбранными способами запуска и точками HITL. Полное описание производственной деятельности не требуется: достаточно правил выбранного потока. Для каждой метрики сопоставление переходов с событиями и подтверждениями ведётся в плане мониторинга, а техническое извлечение — в навыке сборщика. Для показателя устанавливают:

1. Какие события, оценки и сведения о расходе нужны по определению метрики.
2. Каким этапам и переходам процесса они соответствуют и кто отвечает за действие.
3. В каких доступных системах есть подтверждения, как связать их с задачей, требованием, MR/ревизией, запросом, запуском агента и тестовым прогоном.
4. Как различать время события и его получения, исключать повторы и сохранять источники, версии и неполноту.

Это соответствие реализуется в навыке сбора: реальные API, поля, запросы, правила извлечения и проверки. Агент при каждом запуске использует указанные версии обоих процессов, маршрута агента, плана мониторинга и навыка. Он извлекает нужные для метрик события из доступных систем; не подменяет источники пересказом предыдущей сводки и не собирает произвольный набор событий по усмотрению модели.

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

Какие источники использовать

Что настроить в навыке

1. Доступ и соответствие источников. На основе процессов задач/Git, маршрута агента и плана мониторинга указать реальные каналы, проекты, репозитории, таблицы/представления журналов агентов и тестовых сред и разрешённые операции чтения. Найти, где хранятся факты каждого выбранного показателя. Если источника нет, создать задачу на его появление и явно показать ограничение.
2. Идентификацию. Связать ID продуктовой задачи, сообщение передачи, версию требований, запуски агентов, MR, коммиты, артефакты, тесты и наблюдаемые действия людей. Один запуск агента не равен одной продуктовой задаче. Устранить дубли повторной доставки; общий MR и общие затраты нескольких задач распределять по заранее заданному правилу без двойного счёта.
3. Извлечение событий. Для этапов сохранять ответственного исполнителя и роль, передачу работы, паузы и возобновления. Структурированные факты брать из API/логов. По текстам определять кандидатов в передачу, содержательный ответ, завершённый раунд ревью и замечание. Сохранять исходное сообщение и основание классификации. Неоднозначные случаи направлять инженеру на уточнение; не достраивать удобные события. При противоречии источников сохранять конфликт и решение, а не выбирать меньшую длительность.
4. Время и порядок. Хранить время самого события и время его получения; нормализовать часовые пояса. Сформировать интервалы с учётом ревизий, повторных циклов и параллельных работ. Периодически перечитывать изменённые записи с удалением дублей; сохранять связи и историю. Рабочие календари и тарифные интервалы задаются раздельно.
5. Вычисления. Рассчитывать суммы и длительности детерминированным кодом или запросами по извлечённым фактам. Текстовая модель выделяет действия и признаки сложности; часы оцениваются по зафиксированным правилам навыка с сохранением оснований и диапазона. Итоговые суммы и медианы рассчитываются по сохранённым оценкам, а не угадываются моделью. Реализовать правила окна оценки когорты, исходов, полноты, объёма, экономии и выбранных этапов.
6. Доказательства и версии. Для сводки сохранять набор использованных фактов, ссылки на первоисточники, время среза и версию навыка/правил. Для спорного значения должна быть возможность раскрыть его расчёт. Исправление поздно загруженных старых фактов версионируется; события после отсечки не улучшают старый итог.
7. Сбор и публикацию. Настроить ежедневный запуск и пересборку, хранение извлечённых событий, покрытие дат, список аномалий и обновление сводок. Автоматически выполняются извлечение, вычисления и оценка участия людей, без ручного ввода потраченных часов. Если Eᵢ оценивает команда, агент получает результат её принятого процесса и историю изменений. Дневные обновления не заменяют недельный отчёт и согласование РП.

Ежедневный сбор и пересборка

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

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

Например: «Собери сведения для мониторинга за прошлый день». Для пропуска или повторной сборки: «Собери сведения для мониторинга за 25–27 октября 2026 года» или «Пересобери сведения за 26 октября 2026 года». Если часовой пояс уже задан планом, он применяется без нового вопроса. Полные сутки задаются интервалом от 00:00 включительно до 00:00 следующего дня, не включённого в период.

При каждом запуске агент:

1. Определяет период, версии процессов, маршрута агента, плана и навыка; проверяет доступ к требуемым источникам.
2. Извлекает события периода и обновления связанных записей. Поздно появившееся подтверждение учитывается по времени самого события. Также перечитывает изменившиеся записи и необходимые связанные события открытых задач по правилам навыка, чтобы переход через полночь не обрезал начатый этап.
3. Сопоставляет события между системами, сохраняет подтверждения и устойчивые ID. Повторно полученное событие обновляет прежнюю запись, а не увеличивает счётчики. Изменение или удаление исходного факта сохраняется с историей и пересчётом его вклада.
4. Пересчитывает затронутые дни и когорты по сохранённым событиям и оценкам. Повторный сбор заменяет расчёт за тот же период новой версией, а не прибавляет ту же работу ещё раз. Исходная когорта задачи сохраняется; поздний исход не улучшает её результат задним числом.
5. Публикует обновлённую сводку и запись запуска: период и время сбора, версии документов/навыка, доступные источники, покрытие дат, ограничения и результат. При частичном сбое показывает, что получено и что осталось; период не помечается полностью собранным при недоступном необходимом источнике.

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

Ежедневные результаты можно представлять как журнал решения задач и журнал улучшений. Они формируются из первичных записей и ссылок; не создают второй ручной учёт. Недельная сводка использует те же источники.

Проверка на PoC и регулярный контроль

На PoC ИИ-инженер сопровождения настраивает пробную сборку на известных задачах. Сверяет с источниками нормальный путь, повторный запуск, несколько MR, ревью с возвратом, тест с дефектом и последующим успехом, передачу человеку, отмену, отсутствие предварительной оценки или свидетельств участия человека и события у границы недели. Проверяет также оба способа оценки и их согласование с РП, формирование итоговой Eᵢ после приёмки, неизменное значение, корректировку с объяснением причины, изменение объёма и сохранение версий сводки. Для проверки окна оценки когорты достаточно контрольных исторических или учебных данных; ждать три недели ради проверки формулы не нужно. Дополнительно проверяются соответствие событий процессу и плану, суточная граница, пропущенный день, сбор за несколько дат, повторная сборка без дублей, позднее поступление события и частичная недоступность источника. Результат и качество пояснений фиксируются в FLOW-06 журнала PoC.

Минимальные проверки сводки: нет потерь и дублей запусков; N = S + H + C + P для закрытого окна оценки когорты; полные объёмы сходятся по исходам; начало не позже конца; события относятся к нужным ревизиям; неизвестное не превращено в ноль; повторный сбор тех же фактов даёт тот же результат. У каждой строки этапа ровно одна роль; интервалы другой роли не включены, передачи и паузы подтверждены, нераспределённое время показано как неполнота данных. Итоговые медианы сверяются по исходным значениям, а не по средним агрегатов.

Поддержка и исправления

На Пилоте агент автоматически обновляет данные, оценки участия людей и список аномалий; идеальные часы получает выбранным способом с уточнением после приёмки. ИИ-инженер сопровождения исправляет систематические ошибки навыка по результатам разбора РП, ИИ-инженер клиента помогает проверить источники и новые случаи.

При исправлении сохраняются основание, версия навыка и затронутые сводки; изменения проверяются на примерах проекта. Правила выделения человеческих действий, признаки сложности, коэффициенты и диапазоны часов настраиваются и проверяются двумя инженерами. На исторических человеческих задачах проверяют систематическое завышение или занижение оценок. Например, завышение оценки ревью из-за генерируемых файлов требует исправить отбор содержательного diff и выпустить новую версию расчёта. Проверка правдоподобия РП не превращает оценённые часы в измеренные.