Кратко

  • В редакции 16 модель инцидентов специально оставили независимой от уверенности; редакция 17 сохраняет структурированную Probable Root Cause без оценки, личности и версии производителя вывода либо записи о калибровке.
  • Соседние проекты NMOP об аномалиях несут уверенность, уровень обеспокоенности и происхождение аннотации. Риск возникает, когда этот верхний конверт доказательств исчезает, а выбранная причина продолжает жить.
  • Типизированная причина — ограниченная гипотеза, а не полномочие на исправление. Надёжная цепочка должна связывать версию анализа, редакцию инцидента, порог решения, разрешённое действие и наблюдаемый результат.

Что увидит аудитор через полгода

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

Через полгода остаётся запись: критический инцидент, нужный узел и порт, связанные события, interface-hardware-failure как вероятная первопричина. Формально всё аккуратно. Исчезли только разрыв между кандидатами, окно наблюдения, версия аналитики и сведения о недостающих данных.

Такое исчезновение следует из явной границы модели. В редакции 15 draft-ietf-nmop-network-incident-yang говорилось, что связанная работа по выявлению аномалий оценивает результат по уверенности и обеспокоенности. Редакция 16 убрала эту фразу и записала в истории изменений: модель инцидентов остаётся независимой от уверенности. Редакция 17 от 24 сентября 2026 года сохраняет решение.

Граница разумна: общий объект не обязан навязывать всем методам одну шкалу. Но она делает внешний след доказательств частью эксплуатационной ответственности.

Что действительно содержит общее ядро

Инцидент разрешено создать до того, как станет известен его источник. Список источников может быть пустым и заполниться после диагностики. probable-causes называет сеть и узел, при необходимости ресурс, а также cause-name и поясняющие детали. probable-events ссылается на связанные события. Домен, приоритет и категория обязательны.

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

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

Определение Probable Root Cause в проекте строгое: полное устранение этой неисправности прекращает инцидент и предотвращает повторение; сопутствующее условие не считается первопричиной. Однако объект не записывает стандартизированный эксперимент устранения, интервал отсутствия повторений, контрфактическую проверку или конкурирующие объяснения. Определение задаёт смысл, но заполненное поле само по себе не доказывает, что критерий выполнен.

Уверенность не исчезла из NMOP

Она находится в другой семье данных. draft-ietf-nmop-network-anomaly-lifecycle-07 задаёт уверенность от 0 до 100 для аномалии или стратегии обнаружения и отдельную шкалу обеспокоенности от 0 до 100 для внимания оператора. Модель хранит версию и стадию аномалии, идентификатор и имя аннотатора, его человеческий или алгоритмический тип и версию. Detection, Validation и Refinement образуют цикл.

draft-ietf-nmop-network-anomaly-semantics-06 переносит различия в сериализованный словарь: confidenceScore, concernScore, strategy, annotatorType и annotatorVersion. Уверенность в примерах может быть null. То есть сохранённый конверт способен честно сообщить об отсутствии оценки, а не только изображать определённость.

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

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

Уверенность, обеспокоенность и приоритет нельзя смешивать

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

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

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

Полномочие на действие не подтверждает диагноз

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

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

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

Заявленная реализация — ограниченное доказательство

В разделе о статусе реализации проект называет Huawei iMaster NCE, где модель используется вместе с intent management и инструментами ИИ, RESTCONF, управлением жизненным циклом, уведомлениями и запросами списка инцидентов. Это значимое свидетельство работающего кода.

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

Корректный вывод узок: заявленная реализация существует; сохранение конверта доказательств требует отдельной проверки.

Предыдущая статья исследовала другую границу

BTW уже опубликовал A Cleared Incident Does Not Prove Which Command Cleared It. Там рассматривался асинхронный промежуток в редакции 14 между запросом incident-resolve и последующим уведомлением cleared: какая команда действительно вызвала смену состояния?

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

Источники