Кратко

  • RFC 9940 различает Value, Event, Fault, Problem, Symptom, Cause, Alert и Alarm; поясняющие схемы связи между ними не становятся автоматическим полномочием на исправление.
  • Авария может показывать нежелательное состояние ресурса, а оператор может закрыть работу, однако причина, результат для услуги и разрешение на следующее изменение требуют самостоятельных записей.

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

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

Characteristic — наблюдаемое или измеряемое свойство Resource; Value — его измерение. Change означает изменение значения во времени, а Event — изменение в различимый момент. Condition интерпретирует одно или несколько значений, State — это Condition ресурса в определённый момент. Следовательно, между числом и состоянием уже есть слой толкования: частота выборки, временное окно, порог и перспектива.

Relevance зависит от политики, перспективы, намерения и других данных. Значимый Event или Change образует Occurrence. Fault — нежелательная Occurrence, которая может указывать на текущее или будущие нежелательное State. Problem — нежелательное State, которому может требоваться исправление, но которое не обязано иметь одну Cause. Symptom указывает на Problem. Cause может быть подсказана или определена по нескольким faults, problems и symptoms. Alert указывает на Fault, а Alarm обозначает нежелательное состояние Resource, требующее корректирующего внимания.

Различие сохраняется, даже если трафик снова выглядит нормальным. Пример потери света в RFC 9940 допускает возвращение услуг при невыясненном недавнем Fault. Исправление микроперегиба волокна может устранить непосредственную Cause, но оставить открытым вопрос предотвращения повторения. Восстановившийся трафик — существенное свидетельство текущего State, но не общее основание закрыть историю и причинный анализ.

RFC 8632 проводит ту же границу в модели аварий. Ресурсы-кандидаты на root cause — это подсказки для клиента, а не окончательное установление вины. Модель также отличает is-cleared, состояние Alarm, от closed, состояния оператора. Первое может означать, что наблюдаемое условие исчезло; второе — что оператор считает корректирующую работу успешной. Ни одно поле само по себе не доказывает охват измерения, причину или эффект для всех зависимых услуг.

Телеметрия не содержит намерение услуги сама по себе. RFC 9940 помещает телеметрию, мониторинг, аналитику и наблюдаемость в последовательность и отделяет телеметрические данные от определения услуги. RFC 9315 описывает intent как декларативные цели и результаты, которые сеть не узнаёт автоматически. RFC 9417 отдельно определяет metric, symptom, health score и случай, когда metric собрать нельзя. Оценка может расставить приоритеты расследования, но не вправе сама отозвать маршрут, выставить счёт, закрыть инцидент или обещать результат клиенту.

Daniel Kade использует различение слоёв реальности из docs/heng-lu-note.md как редакционную оптику, а не как требование IETF. Исходное значение, порог и политика, классификация, причинная гипотеза, разрешённое решение, выполненное изменение и наблюдение после него должны сохраняться отдельно. Тогда скорость оповещения не будет выдаваться за всю цепочку доказательств.

Источники