В maintenance backlog появляется строка «риск 8,7», но никто не может показать исходные данные. В соседней карточке зафиксирован один и тот же симптом после нескольких проверок, но числового score нет. Команда выбирает первую задачу: число выглядит точнее. Цена ошибки — повторяемый дефект остаётся без проверки, а спорная оценка получает вид готового решения. Позже приходится восстанавливать границу риска, владельца и основание приоритета.
Тезис: сопровождение нужно приоритизировать по проверяемой границе, а не по красивой арифметике. Сначала отделите evidence от оценки, repeatability от впечатления, а uncertainty от нулевого риска. Затем используйте score только как фильтр очереди. Он может выбрать следующую проверку, но не доказывает вероятность сбоя, денежную экономию или необходимость изменения.
Evidence — факт, который можно предъявить другому инженеру: запись проверки, contract, тест, runbook или повторная карточка. Signal — признак, помогающий выбрать следующий вопрос. Priority boundary — правило, которое переводит карточку в одно из состояний: проверить сейчас, подготовить к следующему review или наблюдать. Эти понятия нельзя заменять одним числом.
Для каждого item нужны четыре поля. Первое — symptom: что наблюдаем и где. Второе — boundary: какой потребитель, интерфейс или операция затронуты. Третье — evidence: что уже известно и чего нет. Четвёртое — action: какую одну проверку можно выполнить без расширения scope. Если action требует сначала узнать владельца, собрать неизвестный граф зависимостей и изменить код, карточка описывает не задачу, а гипотезу.
Повторяемость тоже имеет границу. Можно считать повтором только тот же diagnostic step, тот же вопрос совместимости или тот же recheck gate. Фразы «мы часто к этому возвращаемся» недостаточно. Если boundary меняется от review к review, события нельзя складывать в один показатель.
| Тип | Что зафиксировано | Чего это не доказывает | Следующий вопрос |
|---|---|---|---|
| Known artifact | Есть конкретный тест, contract, runbook или запись проверки | Что artifact покрывает всех потребителей и все пути | Какую именно границу он покрывает? |
| Leading signal | До изменения виден ранний признак роста риска или scope | Что отказ уже произошёл или обязательно произойдёт | Какой stop condition сработает раньше? |
| Lagging signal | Один и тот же вопрос вернулся после review | Что известна первопричина или будущая частота | Что прошлое действие не изменило? |
| Unknown | Данных недостаточно или метод проверки недоступен | Что риск равен нулю и число можно угадать | Какой разрешённый метод изменит статус? |
Known artifact сужает область незнания, но не закрывает её автоматически. Leading signal позволяет остановить расширение scope до изменения системы. Lagging signal показывает повторение, но не объясняет причину. Unknown — не пустая клетка. Это явное условие, при котором нельзя усиливать вывод.
Такой подход согласуется с практикой оценки риска: оценка помогает выбрать курс действий, но не заменяет решение владельца. Если неизвестное исчезает при переносе строки в таблицу, формула начинает работать с ложным входом. Сначала сохраните текст неизвестного. Потом решайте, нужен ли отдельный способ его проверить.
У maintenance item бывает наблюдаемый класс издержки: повторное ручное объяснение, задержка review, дополнительная проверка, возврат к той же границе. Такой label честнее, чем «экономия 14 часов», если команда не зафиксировала период, выборку, метод подсчёта и право использовать эти данные.
Денежная оценка требует отдельного контракта. Нужны scope, период, источник, правило attribution и человек, который принимает допущения. Без них точное число создаёт асимметрию: карточка с выдуманной суммой выигрывает у карточки с честным unknown. Для порядка review достаточно сказать, какой повторяемый шаг мешает работе и как его можно проверить.
Ниже — учебный пример. Он работает только с заранее заданными метками impact, repeatability, uncertainty и evidenceStrength. Он не читает production-метрики, не использует историю инцидентов и не предсказывает результат. Формула нужна для прозрачного разговора о входах:
function teachingPriority(card) {\n const score = card.impact * card.repeatability\n + card.uncertainty * 2\n - card.evidenceStrength;\n\n const boundary = score >= 10\n ? 'review-now'\n : score >= 6\n ? 'plan-next-review'\n : 'watch-and-recheck';\n\n return { score, boundary };\n}\n\n// Учебный объект в памяти. Не production-метрика.\nconst example = teachingPriority({\n impact: 3,\n repeatability: 2,\n uncertainty: 2,\n evidenceStrength: 1,\n});\n// { score: 9, boundary: 'plan-next-review' }Число 9 в этом фрагменте ничего не говорит о вероятности сбоя. Оно только показывает, как выбранные teaching labels переводят карточку в учебную полосу. Если reviewer не согласен с uncertainty или evidenceStrength, спорить нужно с входом и его границей, а не с десятичными знаками.
В реальном проекте такой score можно применять только после явного согласования шкал и источников. Если у карточки появился traffic, incident count или денежная оценка, это не повод молча добавить поле в объект. Нужно пересмотреть модель и правила доступа к данным. Иначе учебная функция начинает изображать систему, которой она не видела.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Карточка с высоким score не имеет факта | Оценку приняли за evidence | Попросить ссылку на тест, контракт, incident или повторную запись | Понизить вывод до unknown и назначить отдельную проверку |
| Один симптом возвращается на каждом review | Повторяемая граница не названа | Сравнить diagnostic step, consumer и recheck gate | Сформулировать одну bounded проверку, не начинать rewrite |
| Unknown исчез после расчёта | Пропуск данных заменили нулём | Сверить исходную карточку и обязательные поля модели | Остановить score и сохранить причину неизвестности |
| Leading signal требует немедленного deploy | Ранний признак перепутали с доказанным отказом | Проверить symptom, affected boundary и stop condition | Ограничить следующий шаг review или тестом |
| Lagging signal лечат автоматизацией | Повторение приняли за первопричину | Открыть прошлую карточку и проверить, что изменилось | Сначала уточнить owner, evidence и действие, затем выбирать автоматизацию |
| Денежная сумма определяет очередь | Нет периода, метода или attribution | Проверить источник, выборку, допущения и полномочия | Вернуть cost к наблюдаемому классу до отдельной оценки |
Проверка должна уметь остановиться. Если карточка не содержит boundary, owner role или evidence, результатом не должен быть score с нулевыми значениями. Ноль означает измеренное отсутствие, а unknown означает отсутствие знания. Эти состояния нельзя смешивать.
Остановите draft, если scope вырос с одной проверки до переписывания подсистемы, если action не имеет stop condition или если неизвестный consumer влияет на решение. Не объявляйте item закрытым после одной удачной проверки. Успешный путь показывает, что выбранный вход обработан. Отрицательный путь показывает, что опасный вход не превратился в разрешение на изменение.
Для lagging signal отдельно сравните прошлое и текущее действие. Если symptom вернулся, спросите, изменился ли contract, owner, evidence или stop condition. Если ничего не изменилось, повторная формулировка задачи не является прогрессом. Если изменилось только название, карточку нужно вернуть в review.
Heatmap и формула не заменяют risk assessment, change approval, тесты, rollback и наблюдение системы. Они не знают реальный traffic, SLO, support queue, стоимость простоя или число пользователей. Учебный код не подключается к данным и не подтверждает, что выбранные коэффициенты подходят вашему проекту.
Preventive maintenance не всегда нужно автоматизировать. Ручной review может быть обязательным из-за безопасности, прав доступа или редкой операции. Повторяемость сама по себе не доказывает, что автоматизация окупится. Она только помогает найти шаг, который стоит разобрать.
Нельзя выдавать score за вероятность incident. Нельзя считать отсутствие evidence доказательством отсутствия риска. Нельзя включать реальный incident или денежную оценку в учебную модель без нового контракта, метода и ответственного владельца. При такой неопределённости правильное действие — остановить расширение scope.
Карточка готова к следующему review, если другой инженер может восстановить symptom, boundary, тип сигнала, evidence, неизвестное, один action и stop condition. Для каждого значения понятно, откуда оно взялось. Для каждого перехода между полосами понятна причина. Повторная проверка на том же входе даёт тот же статус.
Если используется score, рядом лежат шкала, формула и явная оговорка о её учебном или локальном статусе. Отрицательная проверка переводит карточку в hold или unknown, а не в нулевой риск. Готовность означает не «задача решена», а «следующий шаг ограничен, проверяем и не маскирует неизвестное».