Практическое руководство по реестру агентов и инвентаризации¶

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

Эта страница собирает такой минимум в одном месте.

1. Что должно существовать всегда¶

Даже у небольшой агентной программы должны существовать два слоя:

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

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

2. Кто должен владеть этим слоем¶

Реестр редко работает, если ответственность размыта.

Минимально полезное распределение обычно такое:

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

Одна и та же команда может совмещать эти роли. Но сами роли должны быть видны явно.

3. Как должна выглядеть запись агента¶

Минимальную запись полезно проверять по одному шаблону:

agent_id
команда-владелец;
деловая цель;
состояние жизненного цикла;
уровень риска;
идентичность среды исполнения;
разрешенные возможности;
пакет политик;
режим подтверждения;
покрытие наблюдаемости;
связь с пакетом артефактов;
связь с выводом из эксплуатации.

Без этого реестр быстро превращается в список имен без эксплуатационного смысла.

Канонические сценарии реестра

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

4. Когда агент должен попадать в инвентарь¶

Хорошее строгое правило выглядит так:

если сущность может вызывать инструменты;
если она читает организационный контекст;
если она действует от имени сотрудника или сервиса;
если она участвует в промышленном рабочем процессе;

она должна попадать хотя бы в инвентарь.

Отдельные исключения лучше оформлять явно, а не держать как молчаливое допущение.

5. Когда агент должен попадать в реестр¶

В реестр обычно должны попадать сущности, которые:

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

Именно реестр нужен для управления, подтверждений и надежного реагирования на инциденты.

6. Как часто проверять реестр¶

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

Минимальная периодичность обычно такая:

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

Если реестр не обновляется в этих точках, дрейф почти неизбежен.

7. Какие признаки дрейфа важнее всего¶

Не весь дрейф одинаково опасен. В первую очередь стоит ловить:

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

Это и есть минимальный список для непрерывной проверки.

8. Когда запись надо переводить в ограниченное, устаревшее или выведенное состояние¶

Полезно не тянуть с изменением состояния жизненного цикла:

restricted, если есть временное сужение набора возможностей или режима подтверждения;
deprecated, если замена уже выбрана и новые волны выпуска должны идти мимо;
retired, если принципал отозван, выпуск остановлен и историческое состояние переведено в режим хранения.

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

9. Что проверять при реагировании на инцидент¶

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

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

Если реестр не отвечает на эти вопросы быстро, он слабо помогает эксплуатации.

10. Минимальная еженедельная проверка¶

Короткую проверку можно строить вокруг нескольких вопросов:

Есть ли новые агентоподобные сущности вне инвентаря?
Есть ли бесхозные записи?
Есть ли агенты промышленного контура без покрытия в телеметрии?
Есть ли устаревшие записи с живыми принципалами?
Есть ли несоответствия между реестром, пакетом политик и состоянием выпуска?

Такую проверку лучше делать короткой, но регулярной.

11. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

У каждого действующего агента есть владелец?
Инвентарь и реестр разделены?
Состояние жизненного цикла обновляется при поэтапном выпуске и выводе из эксплуатации?
Реестр связан с пакетом политик и режимом подтверждения?
Реестр проверяется против живой телеметрии?
Устаревшие агенты теряют принципалы и доступ к инструментам?
Инциденты обновляют гигиену реестра?