Конфигурация по инцидентам

• Правила агента не проектируются заранее, а накапливаются из инцидентов
• Между инцидентом и правилом есть буфер: рабочие заметки, откуда правило продвигают
• У каждого правила есть история; за месяц конфиг вырос на 7 правил, все привязаны к сбою

Задача

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

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

flowchart TD
    M[Дефолты<br/>модели] --> I[Инциденты]
    E[Нестабильность<br/>среды] --> I
    C[Динамика чатов:<br/>люди] --> I
    D[Проектирование<br/>заранее] -. видит частично .-> I

Приём

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

flowchart LR
    I[Инцидент] --> N[Рабочие<br/>заметки]
    N --> A[Разбор паттерна<br/>оператором]
    A --> R[Жёсткое правило<br/>в конфиге]

Стартовать нужно с намеренно минимального конфига: несколько правил, очевидных настолько, что на них можно ставить. Остальное накопится.

Между инцидентом и правилом есть буфер, три файла заметок:

• Поведенческие корректировки. Агент делал X, это вызвало проблему, теперь делает Y.
• Технические отказы. Инструмент или среда сломались; что случилось, как диагностировано, как обойдено.
• Недостающие возможности. Замечено в эксплуатации, полезно, но не сейчас.

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

flowchart TD
    N[Запись<br/>в заметках] --> Q{Показался<br/>дважды?}
    Q -->|нет| W[Остаётся<br/>в буфере]
    Q -->|да| T{Тип правила}
    T --> P[Поведение:<br/>файл персоны]
    T --> O[Процесс: файл<br/>операционных правил]
    T --> X[Технический обход:<br/>файл инструментов]
    T --> S[Расписание:<br/>файл планировщика]

Продвинутое правило маленькое — одна-две строки — и несёт свою историю комментарием:

После каждой отправки проверить, что ушло ровно одно сообщение.
При дубле удалить немедленно.
(после тройной отправки 22.03 при сетевом таймауте)

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

flowchart LR
    R[Правило +<br/>история инцидента] --> A[Аудит через<br/>несколько месяцев]
    A --> Q{Причина<br/>ещё действует?}
    Q -->|да| K[Правило<br/>остаётся]
    Q -->|нет| D[Правило<br/>убрано]

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

Месяц эксплуатации одного агента дал такие продвижения:

Правило про чтение чата выросло в отдельный принцип — контекст перед действием; правило про статусы клиенту стало частью двухуровневой автономности.

Правила нужно и убирать. «Мониторить только будни» убрали в тот же день, когда продвинули «ежедневно, включая выходные». Конфиг с историей позволяет сделать это без страха сломать что-то невидимое.

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

flowchart LR
    I[Инцидент] --> R[Правило<br/>в конфиге]
    R --> W[Проверка<br/>в watchdog]
    W --> F[Самопочинка<br/>или алерт]
    F -. ложное срабатывание .-> W
    classDef key stroke:#FF3600,stroke-width:2px
    class W key

Где ломается

• Продвижение без истории. Правило село в конфиг без записи об инциденте. Через месяцы оператор не может понять, актуально ли оно, и боится тронуть.
• Заметки без продвижения. Инциденты копятся в буфере и не доходят до конфига; агент повторяет ошибки. Продвижение — это работа оператора с известной частотой, у нас — еженедельно.
• Нет оператора. В полностью необслуживаемой системе некому разбирать и продвигать. Там нужен другой механизм или проектирование заранее с честным принятием того, что оно недопокрывает.

Итог

• Минимальный старт, рост по прецеденту, каждое правило привязано к сбою.
• Три файла заметок как буфер; в конфиг попадает то, что повторилось.
• Комментарий с историей у каждого правила делает конфиг аудируемым и удаляемым.
• Один агент за месяц: семь продвижений, конфиг по-прежнему короче сорока строк.
• Инфраструктурный инцидент даёт не только строку в конфиге, но и проверку в watchdog; у проверок свой цикл калибровки по ложным срабатываниям.

© Александр Никулин. Цитирование — с указанием автора и ссылкой · Версия для LLM