На 31 июля 2026 года строгий аудит проходит 247 из 358 созданных материалов. Остальные 111 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
На 31 июля 2026 года строгий аудит проходит 250 из 358 созданных материалов. Остальные 108 не считаются «почти готовыми»: их нужно заменить, а не косметически удлинить.
Пакет заменяет только три декабрьские overlay-ревизии:
- editorial-2024-12-practice-maintenance-retro
- editorial-2024-12-mechanism-maintenance-retro
- editorial-2024-12-field-maintenance-retro
Все owners, evidence, cases, scores, costs, timelines и outcomes в материале
являются versioned fixed synthetic in-memory literals из
synthetic-maintenance-retro/2024-12-v1. Скрипт не читает filesystem, Git, CI,
network, telemetry, incident archive, clock, team history или production state.
Он не выполняет deployment, deletion, rollback или любой внешний change.
## Досье источников
Все URL ниже проверены обычным HTTPS GET 2026-07-31: HTTP 200, без
аутентификации и TLS bypass. Это источники, существовавшие до декабря 2024.
| Источник, дата или версия | Точная поддерживаемая мысль | Ограничение источника |
| --- | --- | --- |
| [Google SRE Book, Chapter 15: Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/), первое издание 2016 | Postmortem фиксирует воздействие, причины, response и follow-up; триггеры и owner action item должны быть определены, а обучение не равно поиску виноватого. | Не задаёт maintenance backlog score, не подтверждает историю читателя и не санкционирует change. |
| [Google SRE Book, Chapter 5: Eliminating Toil](https://sre.google/sre-book/eliminating-toil/), первое издание 2016 | Повторяемую ручную операционную работу полезно отличать от устойчивой инженерной ценности; источник toil стоит устранять осознанно. | Не говорит, что любая ручная проверка является долгом, и не даёт универсальную оценку времени или денег. |
| [NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments](https://csrc.nist.gov/pubs/sp/800/30/r1/final), final September 2012 | Risk assessment служит информацией для выбора курса действий; контекст и uncertainty нельзя подменять одним числом. | Не утверждает, что формула из этой статьи — вероятность, стандартная шкала или финансовый прогноз. |
| [NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final), final April 2022 | Preventive maintenance различает identification, prioritization, implementation и verification. | Не заменяет локальные ownership rules, approval, tests, change window или проверку конкретной системы. |
Покрытие на статью:
- Practice использует минимум Google postmortem и Google toil; NIST SP 800-30
и SP 800-40 уточняют границу оценки и preventive maintenance.
- Mechanism использует минимум NIST SP 800-30 и SP 800-40; Google toil
объясняет, почему повторяемость не равна любой ручной работе.
- Field использует минимум Google postmortem и NIST SP 800-40; Google toil и
NIST SP 800-30 ограничивают выводы из повторяемости и score.
## Проход 1 — факты и техника
Проверено вручную:
- Во всех трёх текстах первые два абзаца называют ситуацию и цену ошибки.
Нет утверждения о реальном incident, team history, customer, metric, saving
или production outcome.
- Practice отделяет symptom, risk, cost class, owner role, evidence boundary и
one next experiment. Ценой названы только учебные классы: interrupt, delay
- Техническая проверка не нашла imports, fetch, filesystem, child process или
HTTP client в overlay script. Внешние URL находятся только в опубликованном
source list и не являются I/O модели.
После этого прохода уточнена формулировка «явная граница доказательств» и
убраны неясные смешанные фразы, чтобы reader не принимал synthetic artefact за
наблюдение реальной системы.
## Проход 2 — редактура и голос
Прочитаны полные тела статей до списка источников:
| Статья | Объём основного текста | Редакторский вывод |
| --- | ---: | --- |
| Practice | 10 020 знаков | Уплотнена вокруг review-card: symptom → причина → проверка → один experiment. Есть таблицы, code example, figure, ограничения и следующий шаг. |
| Mechanism | 10 259 знаков | Score сначала ограничен evidence types и priority boundary. Из текста убраны обещания точной стоимости и «математического» решения. |
| Field | 11 665 знаков | Три case не превращены в выдуманное ретро. Timeline отделяет draft, recheck и отдельный human-approved change. |
Голос соответствует декабрю 2024: системный практик показывает наблюдаемый
артефакт, цену решения, ownership и путь проверки, но не пишет от лица
универсальной платформенной стратегии 2027 года. Термины раскрываются рядом с
сценарием, а абзацы следуют цепочке symptom → причина → проверка → действие.
## Проход 3 — визуал и выпуск
Проверено вручную:
- SVG открыты и просмотрены после Sharp-render на ширине 375 px:
<descid="desc">Горизонтальная последовательность T0 capture symptom, T1 draft one experiment, T2 recheck boundary, T3 decide stop continue or revise. Это учебный timeline без production change.</desc>
<textx="78"y="430"fill="#172033"font-family="Arial, sans-serif"font-size="16"font-weight="700">Boundary: review order, not forecast.</text>
<textx="78"y="453"fill="#526174"font-family="Arial, sans-serif"font-size="15">uncertainty и strength evidence остаются отдельными полями карточки.</text>
<titleid="title">Maintenance review loop with a human decision boundary</title>
<descid="desc">Пять шагов образуют loop: observe symptom, write card, run one bounded experiment, recheck evidence, human decision continue stop revise. Внешний контур запрещает выполнять production change внутри модели.</desc>
note:'Первичный официальный текст Google. Он описывает postmortem как запись влияния, причин, действий и follow-up, а также требует заранее определять триггеры. Он не предписывает конкретный backlog score, состав команды или частоту годового review.',
},
{
title:'Google SRE Book, Chapter 5: Eliminating Toil, first edition 2016',
note:'Первичный официальный текст Google. Он отличает повторяемую ручную операционную работу от устойчивой инженерной ценности и показывает, почему источник toil полезно устранять, а не только фиксировать. Он не даёт универсальной оценки цены одного maintenance item.',
},
{
title:'NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments, final September 2012',
note:'Официальная финальная публикация NIST. Она задаёт риск-оценку как вход для выбора курса действий и требует учитывать контекст и неопределённость. Она не утверждает, что произведение нескольких баллов является достоверной вероятностью.',
},
{
title:'NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning, final April 2022',
note:'Официальная финальная публикация NIST. Она описывает preventive maintenance как идентификацию, приоритизацию, внедрение и проверку обновлений. Она не заменяет локальные ownership rules, change approval или проверку конкретной системы.',
constFIXTURE_LIMIT='versioned-fixed-synthetic-js-literals-in-memory-only; no filesystem, git, CI, network, production, telemetry, cloud account, incident archive, clock, team history or live change';
excerpt:'Повторяемый симптом, риск, цена, владелец и граница доказательств: короткая карточка maintenance review, которая приводит к одному проверяемому эксперименту, а не к бесконечному списку долгов.',
readingMinutes:13,
},[
p('К концу года backlog часто выглядит убедительно: в нём есть старые задачи, раздражающие ручные шаги и несколько слов про риск. Но через неделю список перестаёт отвечать на главный вопрос: что именно повторяется и почему это опаснее других пунктов. Цена такой записи не в красной метке «technical debt». Команда либо берёт случайную задачу с громким заголовком, либо переносит всё ещё на квартал, потому что у карточек нет проверяемой границы.'),
p('Maintenance review нужен не для красивой ретроспективы. Он нужен, когда один симптом возвращается, а изменение каждый раз обсуждают с нуля. Тогда долг — это не неприятность и не обвинение автора прежнего решения. Это повторяемый риск с владельцем, явной границей доказательств и одним следующим экспериментом. Если этих частей нет, пункт backlog нельзя честно сравнить с другим пунктом.'),
p('Дальше использую несколько рабочих терминов. <code>Maintenance review</code> — короткая проверка списка задач сопровождения; <code>backlog item</code> — одна такая задача; <code>evidence boundary</code> — запись о том, что подтверждено и что остаётся неизвестным; <code>owner role</code> — роль, принимающая следующий вопрос; <code>experiment</code> — ограниченная проверка, а не запуск изменения. Английские названия оставлены только для устойчивых терминов и кода.'),
h2('Симптом сначала, название долга потом'),
p('Начинать с названия вроде «улучшить поддержку» опасно: в нём нет наблюдаемого факта. Гораздо полезнее написать: «на каждом review приходится заново объяснять, где заканчивается диагностический шаг». Это уже симптом. Он не доказывает частоту в реальной системе и не сообщает стоимость в деньгах, зато даёт предмет проверки: есть ли в runbook одна граница, по которой другой инженер может остановиться.'),
p('После симптома указываем причину только на том уровне, который можно защитить. В учебной карточке причиной может быть отсутствующая диагностическая граница. В настоящем review причиной не становится «плохой код», пока нет артефакта: trace, теста, записи проверки или другого согласованного доказательства. Такая осторожность сохраняет время: обсуждение не превращается в поиск виноватого и не обещает точного диагноза раньше проверки.'),
table('Минимальная карточка maintenance item',['Поле','Что в нём должно быть','Чего в нём нет'],[
['Owner','роль, которая принимает следующий вопрос или эскалацию','имени человека без его согласия и полномочий'],
['Evidence boundary','что подтверждено и чего не читали','слова «все пользователи», если scope не проверен'],
['One next experiment','один артефакт и критерий его review','скрытого плана большого рефакторинга'],
]),
h2('Маршрут review: symptom → причина → проверка → действие'),
ol([
'<strong>Зафиксируйте один симптом.</strong> Он должен помещаться в предложение и иметь границу: route, runbook step, contract или review question.',
'<strong>Назовите риск.</strong> Не «система хрупкая», а «изменение может пересечь compatibility boundary без принимающего owner».',
'<strong>Опишите цену классом.</strong> Достаточно «повторный interrupt» или «ещё один review pass». Деньги, часы и проценты пишут только при воспроизводимой методике и разрешённом источнике.',
'<strong>Поставьте owner role.</strong> Владелец не обязан сразу исправить всё; он обязан принять следующий узкий вопрос или явно передать его.',
'<strong>Отделите evidence от unknown.</strong> Список известного не становится полным только потому, что он красиво оформлен.',
'<strong>Сформулируйте один experiment.</strong> Его результатом должен быть новый проверяемый артефакт, а не deploy, удаление или «разобраться».',
]),
figure('/assets/editorial/2024/maintenance-retro-2024-review-loop.svg','Цикл maintenance review: наблюдаемый symptom переходит в ограниченную карточку, затем в один experiment, recheck и решение continue, stop или revise. Внешний контур помечен как human review; схема не выполняет change.','Цикл полезен тем, что останавливает рост scope. Повторяемость делает item видимым, но право на реальное изменение остаётся за отдельным human review.'),
h2('Карточка должна быть контрактом review, а не мини-отчётом'),
p('У карточки есть граница ответственности. Автор карточки фиксирует факт, который действительно видел или получил из разрешённого доказательства. Owner role отвечает за дальнейший вопрос. Reviewer проверяет, что experiment не выдаёт учебную модель за production verdict. Никто из них не получает право назвать feature, consumer или incident существующим только потому, что такой пример хорошо объясняет метод.'),
p('Это особенно важно в годовом обзоре. Память легко склеивает несколько похожих эпизодов в «весь год было тяжело». Для планирования полезнее три отдельные строки с разными границами: повторяемый runbook gap, risk без owner и cleanup без recheck. Они могут иметь похожий приоритет, но требуют разных действий. Общий список теряет это различие.'),
table('Три учебных backlog item и разные следующие шаги',['Synthetic item','Наблюдаемый symptom','Граница риска','Один experiment'],[
['repeated-runbook-gap','объяснение одного diagnostic step повторяется','review не может назвать stop condition','написать одну boundary и проверить её на fixed path'],
['ownerless-compatibility-risk','риск записан, а принимающая роль пуста','contract change может остаться без решения по residual risk','указать role и один acceptance question'],
['recheck-before-removal','cleanup proposal опирается на старые labels','removal обсуждают до recheck compatibility boundary','добавить recheck gate и restore question'],
]),
h2('Компактный воспроизводимый пример'),
p('Ниже не находится настоящий долг и не делает запрос к системе. Он берёт один versioned fixed card из памяти, рассчитывает только учебную priority boundary и создаёт review draft. Это полезно как проверка формы: extra key, sparse array или cyclic object должны остановить draft раньше, чем кто-то прочитает красивый summary как разрешение на действие.'),
p('Этот example намеренно слабее реального процесса. В нём нет files, Git, CI, network, telemetry, incident archive, clock или production state. Значит, результат <code>review-now</code> не говорит «срочно менять систему». Он говорит только, что заданный набор fixed literals проходит выбранную учебную формулу и может быть оформлен в review card.'),
h2('Evidence boundary защищает от ложной полноты'),
p('Граница доказательств — не юридическая приписка в конце. Она влияет на действие. Если card содержит только documentation gap, нельзя из неё вывести число затронутых клиентов. Если известен один contract, нельзя объявить, что других нет. Если owner role назван, это не означает, что человек уже принял риск. Эти различия мешают review превратиться в формат «мы почти уверены».'),
p('Практичный способ — разделить evidence на known, leading, lagging и unknown. Known отвечает, какой артефакт уже есть. Leading signal показывает, что риск растёт до повторения: например, proposal не может назвать check. Lagging signal фиксирует то, что уже вернулось: такой же вопрос снова попал на review. Unknown остаётся отдельным полем; его не переводят в ноль ради удобства таблицы.'),
h2('Один experiment лучше программы исправлений'),
p('Следующий experiment должен менять знание, а не просто создавать активность. Для runbook gap это одна диагностическая граница и короткая репетиция. Для ownership gap — одна роль и вопрос, который она может принять или отклонить. Для cleanup — recheck gate, не сам removal. У каждого варианта есть stop condition: как только draft расширяется до redesign, удаления или обещания данных, которых нет, его останавливают.'),
p('Такой stop не означает провал. Он показывает, что первоначальный item был уже, чем предполагаемое решение. Сохраняем текущую карточку, возвращаемся к последней документированной границе и открываем отдельный review для большего scope. Google описывает postmortem как документирование причин и follow-up, а не как автоматическое выполнение любого action item; это полезная рамка и для maintenance review.'),
h2('Что не стоит класть в годовой список'),
p('Не стоит склеивать в один item повторный вопрос, миграцию и будущую архитектуру. Не стоит писать «сэкономим N» без метода, диапазона и разрешённых данных. Не стоит заменять owner именем, если непонятно его полномочие. И не стоит называть числовой score вероятностью. NIST SP 800-30 описывает оценку риска как помощь в выборе курса действий; учебный score может лишь сделать обсуждение последовательным, но не снимает неопределённость.'),
p('Если item не проходит этот фильтр, его не обязательно удалять. Можно оставить его как hypothesis с явным unknown и назначить меньшее исследование. Но тогда он не конкурирует с хорошо описанной maintenance work на тех же условиях. Честный backlog допускает незнание, а не прячет его за приоритетом.'),
h2('Ограничения и следующий проверяемый шаг'),
p('Все labels, roles, costs, timelines, evidence, scores и outcomes в этой статье — fixed synthetic teaching values внутри одного JS module. Они не описывают реальную команду, систему, incident, customer, деньги или историю года. Источники объясняют подход к preventive maintenance, risk assessment, postmortem и toil, но не доказывают корректность конкретной карточки читателя.'),
p('Следующий шаг: возьмите один пункт своего backlog и перепишите только шесть полей из первой таблицы. Затем попросите reviewer назвать one next experiment и stop condition, не открывая новый scope. Ожидаемый результат: item либо становится коротким проверяемым review card, либо честно возвращается в hypothesis с неизвестной границей.'),
h2('Историческая граница декабря 2024'),
p('Использованы официальные главы первого издания Google SRE Book (2016) и финальные публикации NIST SP 800-30 Rev. 1 от сентября 2012 года и SP 800-40 Rev. 4 от апреля 2022 года. На декабрь 2024 эти материалы уже существовали. Они не дают универсального backlog template и не заменяют локальный change process. Учебная модель намеренно не читает внешний state.'),
excerpt:'Evidence types, leading и lagging signals, uncertainty и priority boundary: как использовать компактную synthetic heatmap для порядка review, не выдавая score за вероятность, цену или готовое решение.',
readingMinutes:14,
},[
p('Maintenance backlog становится недостоверным в тот момент, когда ему приписывают точность, которой в нём нет. Число 8,7 выглядит как ответ на вопрос о приоритете, но не говорит, откуда взялись значения, что осталось неизвестным и кто принимает остаточный риск. Цена ошибки двойная: тихий повторяемый symptom может проиграть эффектному числу, а спорная задача получает вид «рассчитанной», хотя никто не проверял её границу.'),
p('Нужна не идеальная формула, а явная priority boundary. Она отвечает на более скромный вопрос: какой maintenance item нужно вынести в review сейчас, какой оставить в план следующего квартала, а какой только перепроверить. Для этого сначала отделяем evidence от оценки, а стоимость — от выдуманной денежной экономии. Потом используем score как фильтр разговора, не как доказательство будущего.'),
p('Здесь <code>evidence</code> — данные, которые можно показать reviewer; <code>score</code> — учебный балл приоритета; <code>priority boundary</code> — правило, по которому карточка попадает в ближайшую проверку, план или повторную проверку. <code>Leading</code> и <code>lagging signal</code> означают соответственно ранний признак и уже отмеченное повторение. Эти слова не заменяют причинный анализ и не делают формулу прогнозом.'),
h2('Четыре типа evidence нельзя складывать в один счётчик'),
p('Evidence отвечает не только на вопрос «есть ли факт». Важно, когда он полезен и что он ограничивает. Leading signal показывает, что review может остановиться до повторения: отсутствует owner, proposal не называет check, scope уже растёт. Lagging signal показывает уже случившееся повторение: тот же вопрос вернулся на следующий review point. Оба полезны, но lagging не доказывает причину, а leading не доказывает, что проблема неизбежна.'),
table('Evidence types для maintenance review',['Тип','Что можно сказать','Что нельзя заключать','Вопрос reviewer'],[
['Known artifact','есть конкретный runbook, contract, test или зафиксированная карточка','что artifact покрывает всех consumers или все paths','какая именно граница описана?'],
['Leading signal','до изменения виден признак роста риска или scope','что failure уже произошёл','какой stop condition сработает раньше?'],
['Lagging signal','повторение уже отмечено после review point','что известна первопричина или будущая частота','что в предыдущем action не изменило знание?'],
['Unknown','данных недостаточно либо method не authorized','что риск равен нулю или score можно уточнить догадкой','какой отдельный method мог бы изменить статус?'],
]),
p('Такое разделение соответствует практической интонации NIST SP 800-30: risk assessment даёт лицам, принимающим решения, информацию о course of action, а не заменяет решение. В maintenance review artefact должен сохранять контекст и uncertainty. Если неизвестное исчезает при переносе строки в таблицу, следующая формула уже работает с ложными исходными данными.'),
h2('Повторяемость и цена: только наблюдаемый класс'),
p('Повторяемость — это не «кажется, мы часто об этом говорим». Нужен заранее выбранный repeat boundary: тот же diagnostic step, та же compatibility question или тот же recheck gate. Если boundary меняется между неделями, нельзя складывать события. Поэтому статья предлагает только labels: repeated interrupt, delayed review, extra recheck. Они показывают вид издержки, но не приписывают системе часы, бюджет или экономию.'),
p('Такое ограничение не обедняет решение. Для первого review достаточно увидеть, что one manual explanation возвращается и мешает одинаковому check. Чтобы вычислять деньги, нужны scope, период, метод, права на данные и проверяемый источник. Пока их нет, денежная колонка создаёт ложное сравнение: точное число у одной задачи побеждает честное неизвестное у другой.'),
h2('Synthetic heatmap: порядок, а не прогноз'),
figure('/assets/editorial/2024/maintenance-retro-2024-debt-risk-heatmap.svg','Heatmap из девяти клеток: по вертикали impact, по горизонтали repeatability. Три fixed synthetic cases помещены в клетки 3x3, 3x2 и 2x2; рядом показана отдельная поправка uncertainty. Подпись отмечает, что результат — порядок review, а не вероятность или бюджет.','Heatmap разделяет две оси, которые часто смешивают: ущерб границы и повторяемость symptom. Отдельно от клетки указаны uncertainty и strength evidence, чтобы цвет не скрывал пробелы в данных.'),
p('В учебной модели <code>impact</code> и <code>repeatability</code> дают клетку heatmap. Затем добавляется небольшая поправка на uncertainty и вычитается strength evidence. Формула <code>impact * repeatability + uncertainty * 2 - evidenceStrength</code> выбрана не потому, что открывает математическую истину. Она намеренно короткая, чтобы reviewer мог спорить не с «алгоритмом», а с каждым входом и с границей, где score меняет действие.'),
table('Priority boundary в fixed synthetic model',['Score band','Смысл','Разрешённое действие','Запрещённый вывод'],[
['10 и выше','review-now','оформить один bounded experiment и отправить в human review','немедленно делать deploy, rewrite или removal'],
['6–9','plan-next-quarter','оставить видимый plan с recheck condition','объявить риск принятым навсегда'],
['ниже 6','watch-and-recheck','сохранить card и проверить boundary перед расширением scope','удалить item как несущественный'],
]),
h2('Компактный воспроизводимый прогон'),
p('Скрипт ниже не читает real metric. Он запускает одну fixed in-memory card и показывает, как различаются heatmap cell и priority boundary. Это воспроизводимо именно потому, что все literals versioned: другой reader получит тот же report, но не должен переносить число в свой production dashboard.'),
p('Второй fixed case получает высокий score не потому, что synthetic contract уже сломан. Он получает его потому, что impact, uncertainty и слабое evidence в заранее заданной карточке пересекают выбранную boundary. Это повод сформулировать owner question. Если добавить к report реальный traffic, incident или money field, fixture отклонит object: модель не умеет его читать и не должна превращать такой field в решение.'),
h2('Неопределённость — отдельная ось решения'),
p('Частая ошибка — думать, что uncertainty всегда понижает приоритет. Иногда она действительно требует остановиться: нельзя выносить remove proposal на основании неизвестного dependency graph. Иногда она требует раньше провести review: нет owner, а compatibility boundary уже затронута. Поэтому в модели uncertainty не маскируется «средним баллом». Она явно прибавляет осторожность, а final decision всё равно ограничен одним experiment и human review.'),
p('Это похоже на preventive maintenance в описании NIST SP 800-40: идентифицировать, приоритизировать, внедрить и проверить — разные шаги. В нашем узком material модель доходит только до первого и второго: фиксирует item и order review. Она ничего не внедряет и не проверяет живую систему. Даже хорошая heatmap не может заменить approval, tests, change window или rollback plan.'),
h2('Leading и lagging signal ведут в разные действия'),
p('Когда leading signal говорит «proposal не называет check», полезное действие — сократить proposal до одного testable artefact. Когда lagging signal говорит «тот же вопрос вернулся», полезно открыть previous card и проверить, что именно не было изменено: owner, boundary, evidence или stop condition. Ошибка — одинаково лечить оба сигнала общим призывом «автоматизировать». Automation может быть дальнейшим решением, но прежде нужно понять, какой повторяемый ручной шаг она заменяет.'),
p('Google в главе об eliminating toil описывает работу, которая повторяется и не создаёт устойчивой ценности. Это не формула для всех maintenance cases: некоторый manual review нужен по смыслу и не является долгом. Но глава даёт полезный вопрос: уменьшается ли повторяемая нагрузка после experiment, или команда лишь перенесла её из одного канала в другой? Ответ должен опираться на наблюдаемый review artefact, а не на настроение по итогам года.'),
h2('Проверка модели должна быть строже красивого результата'),
p('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.'),
p('Canonical comparison также полезен для обычной редактуры. Порядок ключей не должен менять смысл. Но добавленный <code>actualIncident</code>, переписанный action или missing evidence — это уже другой документ. Такой report нужно рассматривать заново, а не пропускать из-за того, что верхняя строка и score выглядят знакомо.'),
h2('Как проводить review без арифметического театра'),
ol([
'<strong>Покажите raw card.</strong> До score reviewer читает symptom, risk, cost class, owner role и evidence boundary.',
'<strong>Назовите signal type.</strong> Leading, lagging, known и unknown нельзя сворачивать в один флажок.',
'<strong>Проверьте входы формулы.</strong> Каждое число является teaching label; если оно спорно, спорим о label, а не о десятых долях.',
'<strong>Смотрите на boundary.</strong> Переход из watch в plan или review-now меняет только следующий review artefact.',
'<strong>Оставьте stop rule.</strong> Большой scope, ложная полнота или попытка выполнить change останавливают draft.',
]),
h2('Ограничения и следующий проверяемый шаг'),
p('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.'),
p('Следующий шаг: возьмите один реальный item только как предмет внутреннего review и пока не ставьте число. Сначала заполните four evidence types и назовите priority boundary словами. Если после этого всё ещё нужен score, зафиксируйте формулу, owner и stop condition отдельно. Ожидаемый результат: таблица покажет, что именно неизвестно, прежде чем число начнёт управлять очередью.'),
h2('Историческая граница декабря 2024'),
p('Эта статья использует официальные главы первого издания Google SRE Book (2016) и финальные NIST SP 800-30 Rev. 1 (сентябрь 2012) и SP 800-40 Rev. 4 (апрель 2022). Они существовали до декабря 2024 и доступны по официальным страницам. Ни один из них не утверждает, что эта synthetic formula является стандартом, вероятностью или финансовым калькулятором.'),
]);
constfield=revision({
slug:'editorial-2024-12-field-maintenance-retro',
title:'Год сопровождения: что остановить, что продолжить, что перепроверить',
excerpt:'Три fixed synthetic maintenance case: повторяемый runbook gap, риск без owner и cleanup с recheck gate. Как построить timeline, остановить ложный rollback и подготовить следующий квартал без выдуманного ретро.',
readingMinutes:14,
},[
p('Год сопровождения легко превратить в историю с аккуратным финалом: «мы нашли долг, исправили процесс и стали устойчивее». Такая фраза опасна, если под ней нет timeline, evidence boundary и отдельного решения, что именно остановили. Цена ошибки — следующий квартал начинает с ложной уверенности: cleanup уже считают безопасным, ownership считают назначенным, а повторяемый symptom считают закрытым, хотя была только договорённость на встрече.'),
p('Поэтому ниже нет ретроспективы неизвестной команды и нет выдуманных incidents, savings или метрик. Вместо этого три fixed synthetic cases. Они нужны как полевая тренировка decision flow: один case требует продолжить маленький runbook experiment, второй — остановиться на owner boundary, третий — перепроверить cleanup до разговора об удалении. Все даты в timeline — T0–T3, а не история реальной системы.'),
p('В этой статье <code>timeline</code> — последовательность точек T0–T3, а не календарь команды; <code>case</code> — учебная карточка; <code>recheck</code> — повторная проверка границы; <code>stop</code> — прекращение черновика до отдельного решения. <code>Fixed synthetic</code> означает, что примеры записаны в коде и не описывают реальный сервис. Термины нужны только для различения состояний одной проверки.'),
h2('Сначала соберите timeline изменения, а не список впечатлений'),
p('Timeline отвечает на четыре простых вопроса: что было замечено, какое ограниченное изменение знания предложено, где его нужно перепроверить и что происходит, если scope растёт. Без этих точек «в прошлом квартале решили» становится доказательством само по себе. С timeline видно, что decision был только draft, а не выполненный deploy; recheck был условием, а не подтверждённым результатом.'),
figure('/assets/editorial/2024/maintenance-retro-2024-change-timeline.svg','Горизонтальный timeline T0–T3: capture symptom, draft one experiment, recheck evidence boundary, decide stop, continue or revise for the next quarter. Под всеми точками стоит запрет превращать synthetic review в production change.','Timeline показывает порядок знаний, а не хронологию реальных событий. Каждая точка имеет отдельный смысл: наблюдение, draft, recheck и решение.'),
table('Три fixed synthetic case для годового review',['Case','Что зафиксировано','Что не известно','Вердикт следующего шага'],[
['repeated-runbook-gap','повторяемый manual explanation и отсутствующая diagnostic boundary','реальная частота, пользовательский эффект и усилие реализации','continue: один bounded runbook experiment'],
['ownerless-compatibility-risk','risk у contract boundary и пустая принимающая роль','реальные consumers, traffic и право на принятие риска','stop scope growth: сначала owner question'],
['recheck-before-removal','cleanup-shaped proposal и сохранённый restore question','dependency graph, data compatibility и успешность rollback','recheck before human removal review'],
]),
h2('Case 1. Продолжить: repeated runbook gap'),
p('Первый case не говорит, что runbook в реальном сервисе плохой. В fixed card есть только observation: один diagnostic step приходится снова объяснять на трёх synthetic review points. Риск узкий — reviewer может не знать, где прекращать проверку. Цена выражена классом: repeated interrupt и slower review. Этого достаточно, чтобы продолжить one experiment, но недостаточно для решения о переписывании support process.'),
p('Действие также узкое: записать один diagnostic boundary и прогнать его по fixed failing path. Ожидаемый evidence — другой reviewer может назвать symptom, boundary, check и stop condition без обращения к реальной системе. Если note разрастается до redesign или начинает утверждать, что он уменьшит actual support load, срабатывает stop condition. Draft возвращается к текущей карточке, а новый scope оформляется отдельно.'),
h2('Case 2. Остановить: риск есть, owner boundary нет'),
p('Во втором case важен не score, а отсутствие роли, которая принимает residual risk. У карточки есть compatibility boundary и фиксированное описание опасности. Но не существует реального списка consumers и нет права угадать их отсутствие. Если команда на этой точке пишет «продолжаем миграцию», она заменяет решение по риску намерением.'),
p('Правильное действие — остановить расширение scope и задать один question: какая role может accept или reject statement о residual risk для одного contract boundary? Это не перекладывание работы на формального owner. Это способ отделить исследование от решения. Пока role не названа или не может принять вопрос, timeline не должен переходить в removal, rollout или обещание совместимости.'),
h2('Case 3. Перепроверить: cleanup ещё не rollback plan'),
p('Третий case выглядит спокойнее: fixed score попадает в <code>watch-and-recheck</code>, есть action, похожий на cleanup, и сохранена restore question. Именно здесь легко назвать карточку «низким риском» и пропустить recheck. Но синтетическая карта прямо говорит другое: evidence labels старые, а real dependency graph, data compatibility и rollback success неизвестны.'),
p('Поэтому результатом является recheck gate. Он спрашивает: какая boundary будет повторно проверена, какой факт остановит proposal и куда вернуться до реального change? Ответ «у нас есть rollback» не проходит, пока неизвестно, кто восстановит route, какие data/schema conditions сохранятся и как проверить client recovery. В этой статье stop operation только отбрасывает draft; она не откатывает deployment и не читает систему.'),
h2('Компактный учебный прогон stop path'),
p('Следующий пример показывает именно эту разницу. В нём draft создаётся из canonical fixed report, затем безопасно останавливается. Это не test production rollback. Его задача — проверить форму review: change proposal не должен получить скрытое право на deploy, delete или network request.'),
p('Fixture покрывает отрицательные ветки: extra keys, missing report field, forged score, sparse nested array, cyclic report, sparse actions и cyclic draft. Все такие objects должны быть rejected without throw. Это редакторская защита от очень знакомого сбоя: summary выглядит тем же, но внутри уже появился факт или action, которые модель не умеет обосновать.'),
h2('Reassessment loop: не все продолжения одинаковы'),
p('После T2 задача не получает автоматически статус done. Есть три допустимых исхода. Continue означает оставить одну bounded experiment до следующего review. Revise означает изменить card, потому что evidence boundary или owner question стали точнее. Stop означает отбросить draft до отдельного решения, потому что scope вырос или need for external evidence стал очевиден. None of these is a production outcome. Это только порядок работы с knowledge.'),
table('Decision после recheck',['Состояние','Что сохраняем','Что останавливаем','План следующего квартала'],[
['Continue','one experiment, owner question и current boundary','рост scope за пределы card','проверить ожидаемый artefact на следующем review point'],
['Revise','исходный symptom и known evidence','старую формулировку риска или action','переписать card, затем снова пройти human review'],
['Stop','last documented boundary и explicit unknown','draft, который обещает change или полноту данных','открыть отдельное authorized investigation или сохранить compatibility'],
]),
h2('Что взять из года, а что не переносить'),
p('Продолжать стоит только то, что оставляет воспроизводимый artefact: короткий runbook boundary, owner question, recheck gate, stop condition. Останавливать стоит ложную точность: всеобщую формулировку «долг закрыт», округлённый score без inputs, обещание rollback без restore boundary. Перепроверять стоит место, где evidence стареет или scope меняется: contract, config, data migration, dependency или decision owner.'),
p('Здесь полезна рамка preventive maintenance из NIST SP 800-40: идентификация, приоритизация, внедрение и verification не должны склеиваться в один глагол «исправить». Наша timeline признаёт только первые два и preparation for recheck. Реальные внедрение и verification требуют иного контекста: права, тесты, change controls, зависимости и измерения. Нельзя добавлять их задним числом в retrospective paragraph.'),
h2('План следующего квартала должен быть уже прошлогоднего списка'),
p('Хороший next-quarter plan короче исходного maintenance list. В него входят one card per boundary, owner role, next experiment, recheck condition и stop condition. Если в плане есть «улучшить платформу», «устранить риски» или «сделать cleanup», он ещё не готов. План должен позволять на следующем review увидеть разницу: появилась ли boundary, принят ли question, описан ли recheck.'),
table('Шаблон plan на следующий квартал',['Поле','Короткая форма','Критерий готовности'],[
['Card','один symptom и один boundary','reader не додумывает scope из заголовка'],
['Owner role','role для одного decision question','role может принять, отклонить или передать вопрос'],
['Experiment','один review artefact','результат не требует live deployment'],
['Recheck','one observable condition','понятно, когда card вернётся на review'],
['Stop','one fact that blocks scope growth','draft можно отбросить без ложного rollback claim'],
]),
h2('Короткий порядок закрытия года'),
ol([
'<strong>Сузьте scope.</strong> Выберите одну карточку и не объединяйте её с архитектурной программой или миграцией.',
'<strong>Восстановите T0–T3.</strong> На каждой точке оставьте только known artefact и явно назовите unknown.',
'<strong>Сверьте stop rule.</strong> Если draft обещает deployment, deletion или полноту данных, остановите его до следующей встречи.',
'<strong>Выберите один исход.</strong> Continue, revise или stop должны менять только план review, а не состояние живой системы.',
'<strong>Запишите следующий recheck.</strong> Он должен проверять конкретную boundary, owner question или evidence label в следующем квартале.',
]),
h2('Почему maintenance retro не заменяет postmortem'),
p('Google описывает postmortem как запись события, его воздействия, причин, ответа и follow-up. Maintenance retro похож тем, что фиксирует обучение и следующий шаг, но не должен притворяться incident analysis. Если не было подтверждённого incident, нельзя писать последствия. Если нет timeline с evidence, нельзя придумывать recovery. Мы берём структуру ответственности и follow-up, а не чужую историю и цифры.'),
p('То же относится к toil. Повторяемая ручная работа может быть кандидатом на устранение источника, но не всякая ручная проверка является waste. Некоторые ручные проверки нужны именно потому, что boundary зависит от риска и полномочий. Поэтому fixed model предлагает не «автоматизировать всё», а сначала установить, какая часть действия повторяется без создания нового знания.'),
h2('Ограничения и следующий проверяемый шаг'),
p('Три cases, T0–T3, labels, roles, scores, actions, stop rules и expected outcomes существуют только как versioned fixed in-memory objects. Они не используют исходный код, историю команды, deployment, production telemetry, tickets, logs, customer data, incident archive, Git, files, CI или network. Источники не подтверждают, что какая-либо конкретная система имеет такие же риски или что любой rollback сработает.'),
p('Следующий шаг: выберите одну завершённую или остановленную maintenance task и восстановите только четыре точки T0–T3 из памяти и разрешённых artefacts. В каждой точке разделите known от unknown. Если action обещает real change, добавьте stop condition и вынесите его в отдельный authorized plan. Ожидаемый результат: следующий квартал получает не праздничный список, а одну короткую проверяемую границу для каждого выбранного item.'),
h2('Историческая граница декабря 2024'),
p('В материале использованы официальные главы первого издания Google SRE Book (2016), NIST SP 800-30 Rev. 1 от сентября 2012 года и NIST SP 800-40 Rev. 4 от апреля 2022 года. Все источники появились до декабря 2024. Они поддерживают дисциплину learning, risk-informed action и preventive maintenance, но не доказывают synthetic timeline и не дают разрешения на реальное изменение.'),
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
