Как связывать риск, стоимость и повторяемость без фальшивой точности

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

Нужна не идеальная формула, а явная priority boundary. Она отвечает на более скромный вопрос: какой maintenance item нужно вынести в review сейчас, какой оставить в план следующего квартала, а какой только перепроверить. Для этого сначала отделяем evidence от оценки, а стоимость — от выдуманной денежной экономии. Потом используем score как фильтр разговора, не как доказательство будущего.

Здесь evidence — данные, которые можно показать reviewer; score — учебный балл приоритета; priority boundary — правило, по которому карточка попадает в ближайшую проверку, план или повторную проверку. Leading и lagging signal означают соответственно ранний признак и уже отмеченное повторение. Эти слова не заменяют причинный анализ и не делают формулу прогнозом.

Четыре типа evidence нельзя складывать в один счётчик

Evidence отвечает не только на вопрос «есть ли факт». Важно, когда он полезен и что он ограничивает. Leading signal показывает, что review может остановиться до повторения: отсутствует owner, proposal не называет check, scope уже растёт. Lagging signal показывает уже случившееся повторение: тот же вопрос вернулся на следующий review point. Оба полезны, но lagging не доказывает причину, а leading не доказывает, что проблема неизбежна.

Такое разделение соответствует практической интонации NIST SP 800-30: risk assessment даёт лицам, принимающим решения, информацию о course of action, а не заменяет решение. В maintenance review artefact должен сохранять контекст и uncertainty. Если неизвестное исчезает при переносе строки в таблицу, следующая формула уже работает с ложными исходными данными.

Повторяемость и цена: только наблюдаемый класс

Повторяемость — это не «кажется, мы часто об этом говорим». Нужен заранее выбранный repeat boundary: тот же diagnostic step, та же compatibility question или тот же recheck gate. Если boundary меняется между неделями, нельзя складывать события. Поэтому статья предлагает только labels: repeated interrupt, delayed review, extra recheck. Они показывают вид издержки, но не приписывают системе часы, бюджет или экономию.

Такое ограничение не обедняет решение. Для первого review достаточно увидеть, что one manual explanation возвращается и мешает одинаковому check. Чтобы вычислять деньги, нужны scope, период, метод, права на данные и проверяемый источник. Пока их нет, денежная колонка создаёт ложное сравнение: точное число у одной задачи побеждает честное неизвестное у другой.

Synthetic heatmap: порядок, а не прогноз

В учебной модели impact и repeatability дают клетку heatmap. Затем добавляется небольшая поправка на uncertainty и вычитается strength evidence. Формула impact * repeatability + uncertainty * 2 - evidenceStrength выбрана не потому, что открывает математическую истину. Она намеренно короткая, чтобы reviewer мог спорить не с «алгоритмом», а с каждым входом и с границей, где score меняет действие.

Компактный воспроизводимый прогон

Скрипт ниже не читает real metric. Он запускает одну fixed in-memory card и показывает, как различаются heatmap cell и priority boundary. Это воспроизводимо именно потому, что все literals versioned: другой reader получит тот же report, но не должен переносить число в свой production dashboard.

import {
  createFixedSyntheticMaintenanceInput,
  inspectSyntheticMaintenance,
} from './upgrade-2024-12.mjs';

const report = inspectSyntheticMaintenance(
  createFixedSyntheticMaintenanceInput('ownerless-compatibility-risk'),
);

console.log(report.risk.heatmapCell);      // 3x2
console.log(report.risk.priorityScore);    // 11
console.log(report.risk.priorityBoundary); // review-now
console.log(report.evidence.unknown);      // fixed limitation text

Второй fixed case получает высокий score не потому, что synthetic contract уже сломан. Он получает его потому, что impact, uncertainty и слабое evidence в заранее заданной карточке пересекают выбранную boundary. Это повод сформулировать owner question. Если добавить к report реальный traffic, incident или money field, fixture отклонит object: модель не умеет его читать и не должна превращать такой field в решение.

Неопределённость — отдельная ось решения

Частая ошибка — думать, что uncertainty всегда понижает приоритет. Иногда она действительно требует остановиться: нельзя выносить remove proposal на основании неизвестного dependency graph. Иногда она требует раньше провести review: нет owner, а compatibility boundary уже затронута. Поэтому в модели uncertainty не маскируется «средним баллом». Она явно прибавляет осторожность, а final decision всё равно ограничен одним experiment и human review.

Это похоже на preventive maintenance в описании NIST SP 800-40: идентифицировать, приоритизировать, внедрить и проверить — разные шаги. В нашем узком material модель доходит только до первого и второго: фиксирует item и order review. Она ничего не внедряет и не проверяет живую систему. Даже хорошая heatmap не может заменить approval, tests, change window или rollback plan.

Leading и lagging signal ведут в разные действия

Когда leading signal говорит «proposal не называет check», полезное действие — сократить proposal до одного testable artefact. Когда lagging signal говорит «тот же вопрос вернулся», полезно открыть previous card и проверить, что именно не было изменено: owner, boundary, evidence или stop condition. Ошибка — одинаково лечить оба сигнала общим призывом «автоматизировать». Automation может быть дальнейшим решением, но прежде нужно понять, какой повторяемый ручной шаг она заменяет.

Google в главе об eliminating toil описывает работу, которая повторяется и не создаёт устойчивой ценности. Это не формула для всех maintenance cases: некоторый manual review нужен по смыслу и не является долгом. Но глава даёт полезный вопрос: уменьшается ли повторяемая нагрузка после experiment, или команда лишь перенесла её из одного канала в другой? Ответ должен опираться на наблюдаемый review artefact, а не на настроение по итогам года.

Проверка модели должна быть строже красивого результата

Fixture проверяет exact input keys, dense arrays, unknown keys, canonical report и canonical draft. Отдельно есть cases для forged score, cyclic JSON и sparse nested array. Причина не в том, что эти дефекты обязательно появятся в review document. Причина в контракте: если учебный report принимает незнакомое поле, он постепенно начинает изображать систему, которой не видел. Строгая форма оставляет человеку право добавить внешний факт только в отдельном authorized process.

Canonical comparison также полезен для обычной редактуры. Порядок ключей не должен менять смысл. Но добавленный actualIncident, переписанный action или missing evidence — это уже другой документ. Такой report нужно рассматривать заново, а не пропускать из-за того, что верхняя строка и score выглядят знакомо.

Как проводить review без арифметического театра

1. Покажите raw card. До score reviewer читает symptom, risk, cost class, owner role и evidence boundary.
2. Назовите signal type. Leading, lagging, known и unknown нельзя сворачивать в один флажок.
3. Проверьте входы формулы. Каждое число является teaching label; если оно спорно, спорим о label, а не о десятых долях.
4. Смотрите на boundary. Переход из watch в plan или review-now меняет только следующий review artefact.
5. Оставьте stop rule. Большой scope, ложная полнота или попытка выполнить change останавливают draft.

Ограничения и следующий проверяемый шаг

Heatmap, score, evidence labels, owner roles и все три учебных case — fixed synthetic objects. В них нет реальных p95, SLO, support queues, users, расходов, production changes или результатов команды. Официальные источники помогают различить preventive maintenance, risk assessment, postmortem follow-up и toil; они не подтверждают выбранные коэффициенты и не обещают, что score предскажет incident.

Следующий шаг: возьмите один реальный item только как предмет внутреннего review и пока не ставьте число. Сначала заполните four evidence types и назовите priority boundary словами. Если после этого всё ещё нужен score, зафиксируйте формулу, owner и stop condition отдельно. Ожидаемый результат: таблица покажет, что именно неизвестно, прежде чем число начнёт управлять очередью.

Историческая граница декабря 2024

Эта статья использует официальные главы первого издания Google SRE Book (2016) и финальные NIST SP 800-30 Rev. 1 (сентябрь 2012) и SP 800-40 Rev. 4 (апрель 2022). Они существовали до декабря 2024 и доступны по официальным страницам. Ни один из них не утверждает, что эта synthetic formula является стандартом, вероятностью или финансовым калькулятором.

Проверяемые источники

• Google SRE Book, Chapter 15: Postmortem Culture: Learning from Failure, first edition 2016 — Первичный официальный текст Google. Он описывает postmortem как запись влияния, причин, действий и follow-up, а также требует заранее определять триггеры. Он не предписывает конкретный backlog score, состав команды или частоту годового review.
• Google SRE Book, Chapter 5: Eliminating Toil, first edition 2016 — Первичный официальный текст Google. Он отличает повторяемую ручную операционную работу от устойчивой инженерной ценности и показывает, почему источник toil полезно устранять, а не только фиксировать. Он не даёт универсальной оценки цены одного maintenance item.
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments, final September 2012 — Официальная финальная публикация NIST. Она задаёт риск-оценку как вход для выбора курса действий и требует учитывать контекст и неопределённость. Она не утверждает, что произведение нескольких баллов является достоверной вероятностью.
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, final April 2022 — Официальная финальная публикация NIST. Она описывает preventive maintenance как идентификацию, приоритизацию, внедрение и проверку обновлений. Она не заменяет локальные ownership rules, change approval или проверку конкретной системы.