# Изменения алертов ИИ-агентами, которые снижают видимость

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

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

Это важно, даже когда агент формирует технически корректные запросы к API. Системы мониторинга открывают разные ресурсы, но права часто остаются широкими. Один агент может обращаться к нескольким системам с одними учетными данными API. Шлюз или процесс вокруг этих данных должен понимать результат запрошенной операции, показывать опасную часть проверяющему и контролировать результат после выполнения. Общий вопрос «Разрешить обновление мониторинга?» ничего из этого не делает.

## Смоделируйте весь путь от сигнала до человека

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

Документация Prometheus четко разделяет эти задачи. Правила алертинга Prometheus вычисляют выражения и отправляют активные алерты дальше, а Alertmanager группирует, подавляет, отключает и доставляет уведомления. Такое разделение полезно для архитектуры, но оно же показывает опасную расплывчатость права «может редактировать алерты». Изменение порога PromQL и создание отключения в Alertmanager затрагивают разные этапы и оставляют разные свидетельства.

При инвентаризации действий агентов используйте пять классов результатов:

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

Не классифицируйте операцию только по HTTP-методу. `PUT`, который меняет `isPaused` с `false` на `true`, может быть опаснее `DELETE`, удаляющего истекшее отключение. `POST`, создающий сопоставление для всех производственных сервисов, может подавить больше уведомлений, чем удаление одного тестового правила. Результат зависит от исходного состояния, предлагаемого состояния и места ресурса в цепочке.

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

## Для изменения порога нужна смысловая разница

Изменение порога должно показывать, как меняется обнаружение, а не перечень измененных полей JSON. Повышение порога загрузки процессора с 85 до 95 процентов заметно сразу. Расширение окна запроса с пяти до тридцати минут, признание отсутствующих данных нормальным состоянием, добавление узкого фильтра меток или увеличение периода ожидания может дать тот же практический результат, хотя в сырой разнице выглядит безобидно.

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

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

```json
{
  "action": "alert.threshold.update",
  "resource": "payments-api/high-error-rate",
  "environment": "production",
  "before": {"threshold": 2, "window": "5m", "pending": "2m"},
  "after": {"threshold": 8, "window": "15m", "pending": "10m"},
  "effect": {
    "visibility": "decrease",
    "reasons": ["threshold raised", "window widened", "pending duration increased"]
  },
  "precondition": {"revision": "184", "config_sha256": "9a8e..."},
  "requested_by": {"agent_session": "run-7f31", "task": "reduce duplicate pages"}
}
```

Название задачи агента дает контекст, но ничего не доказывает. Фраза «сократить повторные уведомления» не обосновывает восьмипроцентный порог ошибок. Требуйте причину, связанную с наблюдаемым условием, например развертывание, изменившее известную базовую линию, и прикладывайте точное состояние монитора, которое изучал агент. Не разрешайте агенту самостоятельно объявлять изменение малорисковым.

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

Некоторые правки дают смешанный результат. Запрос может добавить один регион и исключить другой или снизить порог с одновременным увеличением периода ожидания. Не усредняйте результаты до «нейтрального» значения. Если заметная часть теряет покрытие, классифицируйте предложение как снижение видимости и покажите эту часть. Проверяющий может согласовать ограниченный компромисс, но не должен самостоятельно искать его в длинном выражении.

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

## Отключение должно иметь границы и оставаться наблюдаемым

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

Термины продуктов могут скрывать разное поведение. Документация Datadog говорит, что downtime отключает алерты и уведомления, но не мешает переходам состояния монитора. Google Cloud Monitoring описывает более сильное действие snooze: активная пауза не дает создавать уведомления и инциденты, а для политик на основе метрик или SQL еще и закрывает связанные инциденты. Если агент называет обе операции «отключением», проверяющий не увидит важного различия.

Отключения Prometheus Alertmanager используют сопоставления и временной интервал. Официальная документация указывает, что входящий алерт должен соответствовать всем сопоставлениям активного отключения, чтобы уведомления прекратились. Поэтому главный риск связан с расширением сопоставления. `service="checkout"` задает узкую область. `service=~".*"` или отсутствие сопоставления среды может охватить всю инфраструктуру. Карточка проверки должна применить сопоставление к текущим меткам, показать число результатов и несколько названий, а не повторять регулярное выражение.

Для каждого подавления, созданного агентом, требуйте следующие свойства:

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

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

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

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

## До удаления нужны доказательства возможности восстановления

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

AWS описывает `cloudwatch:DeleteAlarms` как отдельное право, и такое разделение нужно сохранить в учетных данных агента. API CloudWatch `DeleteAlarms` принимает несколько имен и может удалить правильные имена, даже если одно из переданных имен ошибочно. AWS рекомендует затем вызвать `DescribeAlarms` и подтвердить удаление. Поэтому общее сообщение об успехе небезопасно: шлюз должен записать запрошенный набор и проверить итоговый набор по каждому элементу.

API подготовки алертов Grafana также использует разные конечные точки для обновления и удаления правил, а еще позволяет удалять целые группы. Для удаления одного правила и группы нельзя показывать одинаковый текст согласования. Покажите число правил в группе, их папки, среды и активное состояние. Если после согласования инвентаризация изменилась, запретите удаление группы.

До удаления производственного монитора агентом требуйте восстанавливаемый экспорт и проверку зависимостей. Экспорт должен содержать полное правило, ссылки на уведомления, метки и сведения о происхождении, нужные для восстановления. Храните его вне пути, куда может писать агент, и прикладывайте дайджест к записи согласования. Снимок экрана не заменяет резервную копию, а составленное агентом резюме не восстановит сложный запрос.

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

Разделите удаление на две части:

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

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

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

## Риск зависит от потери видимости

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

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

Начальная матрица может выглядеть так:

- Повышение видимости, например снижение порога или добавление получателя: авторизация сессии и аудит.
- Нейтральные метаданные, например редактирование описания без изменения смысла: авторизация сессии и аудит.
- Узкое временное снижение, например отключение одного непроизводственного алерта на 30 минут: явная проверка одним нажатием.
- Снижение в производстве, например повышение порога или исключение производственного региона: строгая проверка со смысловой разницей.
- Широкое или повторяющееся снижение, например глобальное сопоставление или еженедельное отключение: строгая проверка и именованный владелец.

«Строгая проверка» требует большего, чем еще одно окно подтверждения. Привяжите согласование к дайджесту действия, текущей ревизии ресурса, вычисленной области, длительности и аутентифицированной сессии агента. Для высшего уровня требуйте подтверждение присутствия человека через Touch ID или второго проверяющего, одобренного организацией. Не разрешайте агенту делить широкий запрос на мелкие вызовы, каждый из которых проходит ниже порога. Объединяйте связанные предложения в коротком окне проверки и считайте их суммарную область.

Если классификатор не знает поля, меняющего смысл, по умолчанию запрещайте операцию. Когда шлюз не может определить, делает ли `noDataState: OK` конкретное правило менее заметным, он не должен считать его безопасным по названию поля. Добавьте адаптер, понимающий смысл продукта, или потребуйте прямую работу человека. «Неизвестно» служит результатом классификации, а не категорией низкого риска.

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

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

## Согласование должно объяснять последствия

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

Полезное согласование повышения порога сообщает: «Алерт высокой доли ошибок платежей сработает при превышении 8 процентов в течение 10 минут; сейчас он срабатывает при превышении 2 процентов в течение 2 минут». Затем оно называет производственную среду, затронутые регионы, текущее активное состояние, причину и откат. Отключение указывает, какие алерты перестанут отправлять уведомления, продолжатся ли вычисление и создание инцидентов, а также точное время окончания. Удаление сообщает о постоянном исчезновении правила и называет сохраненный экспорт.

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

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

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

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

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

## Разделите предложение и выполнение

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

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

Границу можно выразить таким компактным фрагментом политики:

```yaml
actions:
  alert.threshold.update:
    classify: semantic_diff
    require_review_when: visibility == "decrease"
    bind: [resource_revision, proposal_digest, agent_session]
  alert.mute.create:
    require: [scope, starts_at, ends_at, owner, reason]
    deny_when: ends_at == null
    aggregate_by: [agent_session, environment]
  alert.rule.delete:
    require_review: always
    require: [restorable_export, dependency_check, rollback_owner]
    bind: [resource_revision, proposal_digest, agent_session]
```

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

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

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

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

## Проверка должна подтвердить возвращение видимости

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

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

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

Для удаления подтвердите отсутствие каждого элемента и сохраните экспортированную конфигурацию. Рекомендация CloudWatch вызвать `DescribeAlarms` после `DeleteAlarms` дает хороший минимум, но отсутствие не доказывает существование замены. Если предложение называет замену, получите ее, подтвердите включенное состояние и сравните область с удаленным правилом.

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

```json
{
  "proposal_id": "chg-2025",
  "execution": "accepted",
  "checks": [
    {"name": "approved revision applied", "status": "pass"},
    {"name": "rule enabled", "status": "pass"},
    {"name": "notification route resolves", "status": "pass"},
    {"name": "production regions covered", "status": "fail", "missing": ["eu-west"]}
  ],
  "final_status": "failed_closed",
  "remediation": "rollback_requested"
}
```

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

Проверка также обнаруживает изменение смысла API поставщика. Grafana документирует поле `isPaused` для правил; обновление продукта или ошибка адаптера может потерять его при чтении и записи. Нормализованное постусловие обнаружит неожиданную паузу даже после успешного ответа конечной точки. Храните тесты адаптера с зафиксированными запросами и ответами и запрещайте операцию, когда неизвестные поля влияют на вычисление, подавление, маршрутизацию или удаление.

## Журнал аудита должен пережить агента

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

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

Документация Audit Trail от Datadog содержит отдельные запросы для создания, изменения, удаления и разрешения мониторов, а также показывает разницу конфигураций. Эти свидетельства поставщика полезны, но их нужно связать с записью шлюза. Поставщик показывает сервисную учетную запись, которая изменила монитор, а шлюз объясняет, какой процесс агента использовал ее и какой человек согласовал точный результат.

Sallyport подходит для этой границы, когда MCP-совместимый агент обращается к API мониторинга по HTTP: его хранилище не отдает агенту учетные данные API, флаг на ключе может требовать согласование при каждом использовании, а журналы Sessions и Activity строятся из зашифрованной хеш-цепочки со слепой записью. Этот механизм не классифицирует смысл мониторинга за вас; вызывающий инструмент по-прежнему должен разделять изменения порога, отключения и удаления и показывать нужные доказательства.

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

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