Поиск результатов, которые никто не читает: аудит потребителей автоматизированных систем

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

Принцип аудита: у каждого шага есть отправитель и получатель

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

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

Что обычно выявляет честный аудит

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

• Проверки, которые так и не срабатывают. Было обнаружено 95 проверок, способных показать красный статус, но к которым никогда не обращались. Каждая из них была правильно реализована и протестирована, и каждая казалась необходимой в момент написания, однако ни одна из них не была включена ни в один из путей обработки.
• Правила без способа применения. Из 25 недавно введённых правил 19, то есть 76%, не имели упоминаний ни в каких кодовых путях, чек-листах или рутинах. Проблемой было не нарушение правил — на них вообще ничего не указывало. Один из процедур отладки оставался в стандартном руководстве команды в течение 42 дней, так и не будучи применённым ни разу. Никто его не забыл — просто запись о нём была ошибочно воспринята как его реальное применение.

Реестр задач, полный бездействующих элементов. По текущим данным насчитывалось 417 открытых задач: у 146 из них не было никакой активности, а для 104 не было определено, что считается завершением работы. Самый старый элемент, оставшийся без изменений, имел возраст 37 дней.

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

Последний пример кратко иллюстрирует урок: размещение чего-либо в правильном месте — это не то же самое, что его доставка.

Почему сбои всегда происходят в «швах»

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

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

Ещё два примера показывают последствия такого молчания:

• Система уведомлений хранила сообщения для оператора и обещала доставку при следующей успешной отправке. На одном из узлов она заканчивала работу ещё до выполнения первой строки логики, и это происходило каждый раз. 552 сообщения оставались в ожидании в течение 16 дней. Источник данных функционировал нормально, маршрут был правильным, но до потребителя сообщения так и не доходили.
• Публичная панель управления отображала 17 публикаций, взятых с копии данных, хотя журнал записей, который, по заявлениям, отражал эти данные, вообще не существовал нигде в системе. Панель верно отображала только то, что имела в своем распоряжении. Никто не спрашивал, откуда на самом деле берутся данные.

Оба этих проблемы можно было бы выявить путем проверки на стороне получателя: получил ли оператор какие-либо данные, существует ли источник данных на панели управления.

Три способа, как может пойти не так при аудите использования

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

1. Измеряйте использование, а не вызов

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

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

2. Выводите информацию о возрасте данных и соблюдайте временные рамки

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

3. Исключайте элементы, ценность которых заключается в доступности

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

Более глубокая ловушка: показатели, которые могут только подтверждать

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

Решение: указать потребителя при создании продукта

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

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

• добавить обязательное поле «consumer» в шаблоны для новых задач, правил и запланированных операций
• отклонять определения статуса «завершено», описывающие только действия создателя («дашборд обновлен») без указания получателя («дашборд виден ответственному рецензенту»)
• для всего, что передается через какой-либо механизм обмена, такой как общий доступ, очередь или ретранслятор, добавить проверку с стороны получателя, а не только с отправительской

Как только такое поле появится, аудит больше не потребует сложных расследований. Достаточно просто выполнить запрос к объектам с пустым значением в поле «consumer»; этот список и будет результатом, и его можно было бы прочитать в любой момент.

Основные выводы

• Результаты без указания получателя по умолчанию остаются невидимыми, поскольку ничего не ломается, если их никто не читает.
• Сбои возникают на этапах передачи, поэтому необходимо проверять доставку с стороны получателя.

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

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

При создании элемента записывать «кто им пользуется и откуда мы это знаем»; тогда аудит стоит почти ничего.