{
  "index": 111,
  "slug": "editorial-2024-12-practice-maintenance-retro",
  "title": "Maintenance review: как превратить повторяющуюся проблему в проверяемое действие",
  "excerpt": "Повторяющаяся ручная работа и старые задачи не образуют план сами по себе. Разбираем симптом, цену ошибки, границу риска и один эксперимент, который можно проверить до большого изменения.",
  "contentHtml": "<p>В конце квартала список сопровождения обычно растёт быстрее, чем команда успевает его читать. В нём соседствуют «обновить зависимость», «разобраться с алертами», «убрать ручной шаг» и «проверить старый контракт». Через месяц эти записи перестают объяснять, что повторяется. Инженер снова выясняет контекст, а затем переносит задачу, потому что не понимает, какой результат считать достаточным.</p>\n<p>Симптом виден в работе: один и тот же вопрос возвращается на встречу, оператор вручную повторяет одинаковую последовательность, а изменение обсуждают без владельца и границы проверки. Цена ошибки — не абстрактный технический долг. Команда тратит время на повторное объяснение, принимает решение по неполному контексту и может удалить нужную совместимость раньше, чем найдёт потребителя.</p>\n<p>Тезис статьи простой: maintenance review должен превращать жалобу в короткую проверяемую карточку. В ней есть наблюдаемый симптом, риск, видимая цена, принимающая роль, доказательства, неизвестное и один следующий эксперимент. Карточка не разрешает большой рефакторинг. Она помогает решить, что проверить первым и где остановиться.</p>\n<h2>Сначала зафиксируйте симптом</h2>\n<p>Начинайте не с названия технологии и не с решения. Запишите действие, которое можно увидеть ещё раз. «Система хрупкая» слишком широко. «При проверке релиза инженер каждый раз вручную ищет, где заканчивается диагностический шаг» уже задаёт границу. Её можно показать в runbook, маршруте, контракте или записи проверки.</p>\n<p>Затем укажите цену на уровне, который подтверждён наблюдением. Подойдут «повторный interrupt», «ещё один круг review», «задержка проверки» или «риск удаления потребного пути». Не подставляйте часы, деньги и проценты из ощущения. Точное число требует периода, метода подсчёта и разрешённого источника.</p>\n<p>Отделяйте симптом от причины. Повторный ручной шаг может возникнуть из-за отсутствующей инструкции, неясного контракта, неудобного инструмента или неверной границы ответственности. Пока проверка не проведена, причина остаётся гипотезой. Такой порядок не смягчает текст. Он не позволяет спорить о виновнике вместо проверки.</p>\n<h2>Механизм карточки</h2>\n<p>Карточка работает как маленький контракт между тем, кто заметил проблему, и тем, кто принимает следующий вопрос. Она не обязана описывать всю систему. Её задача — сузить вопрос до одного эксперимента и сохранить то, чего мы пока не знаем.</p>\n<table><caption>Поля maintenance review: симптом → причина → проверка → действие</caption><thead><tr><th>Поле</th><th>Что записать</th><th>Проверка</th><th>Чего не утверждать</th></tr></thead><tbody><tr><td>Симптом</td><td>Повторяемое действие и его граница</td><td>Другой инженер может указать тот же шаг или артефакт</td><td>«Так происходит везде» без проверенного охвата</td></tr><tr><td>Причина</td><td>Гипотеза с опорой на конкретный артефакт</td><td>Есть лог, тест, контракт, diff или запись наблюдения</td><td>«Плохой код» без доказательства</td></tr><tr><td>Цена</td><td>Класс усилия или риск пересечения границы</td><td>Понятно, что повторится при бездействии</td><td>Придуманная экономия и точный прогноз потерь</td></tr><tr><td>Владелец</td><td>Роль, принимающая следующий узкий вопрос</td><td>У роли есть полномочие принять или отклонить действие</td><td>Имя человека без согласия и полномочий</td></tr><tr><td>Доказательства</td><td>Известные факты и список неизвестного</td><td>Для каждого факта указан источник или способ проверки</td><td>Полноту, которой проверка не показала</td></tr><tr><td>Действие</td><td>Один эксперимент и критерий остановки</td><td>Результат изменит знание, а не только создаст активность</td><td>Автоматическое разрешение deploy, удаления или rewrite</td></tr></tbody></table>\n<p>Важна именно связка полей. Симптом без цены превращается в раздражитель. Цена без причины превращается в приоритет «на глаз». Причина без проверки создаёт спор. Проверка без действия оставляет запись в том же состоянии. Карточка готова к review, когда следующий шаг ограничен и его результат можно увидеть.</p>\n<h2>Пример: повторный ручной шаг перед релизом</h2>\n<p>Ниже учебный пример. Он не описывает реальный сервис, команду или измеренный результат. Представим, что перед каждым релизом инженер вручную сравнивает список маршрутов с короткой инструкцией. Инструкция не говорит, на каком условии проверку можно закончить. Ошибка в карточке была бы такой: «автоматизировать релиз». Это уже решение, а не описание проблемы.</p>\n<p>Рабочая карточка выглядит уже: симптом — повторное ручное сравнение маршрутов; риск — изменение может пройти без проверки одного compatibility boundary; цена — ещё один review pass и interrupt; владелец — роль, отвечающая за release checklist; известное — в инструкции нет stop condition; неизвестное — какие потребители используют старый маршрут; эксперимент — добавить один явный stop condition и прогнать его на фиксированном учебном наборе маршрутов.</p>\n<pre><code>const reviewItem = {\n  symptom: 'manual route comparison repeats before each review',\n  risk: 'a compatibility boundary may be skipped',\n  costClass: 'repeat-review',\n  ownerRole: 'release-checklist owner',\n  evidence: ['runbook step 4 has no stop condition'],\n  unknown: ['consumers of the legacy route'],\n  nextExperiment: 'add one stop condition and check a fixed route set',\n};\n\nconst canContinue =\n  reviewItem.evidence.length &gt; 0 &amp;&amp;\n  reviewItem.nextExperiment.length &gt; 0 &amp;&amp;\n  reviewItem.unknown.length &gt; 0;\n\nconsole.log(canContinue); // учебный результат: true</code></pre>\n<p>Код показывает только форму данных и условие перехода к review. Он не читает репозиторий, сеть, метрики, логи или состояние сервиса. Значение <code>true</code> означает лишь, что учебная карточка заполнена минимально. Оно не доказывает наличие потребителей, безопасность изменения и экономию времени.</p>\n<h2>Как читать симптом и выбирать действие</h2>\n<table><caption>Диагностическая таблица</caption><thead><tr><th>Симптом</th><th>Вероятная причина</th><th>Проверка</th><th>Действие</th></tr></thead><tbody><tr><td>Один вопрос возвращается на каждом review</td><td>Не задана граница завершения</td><td>Найти шаг инструкции и попросить коллегу назвать stop condition</td><td>Сформулировать одну границу и повторить проверку</td></tr><tr><td>Ручной шаг повторяется и растёт вместе с числом объектов</td><td>Процесс не имеет устойчивого автоматизированного пути</td><td>Разделить обязательную проверку и повторяемую механику</td><td>Проверить малый bounded experiment, не автоматизировать всё сразу</td></tr><tr><td>Удаление старого пути выглядит безопасным</td><td>Не проверены потребители или совместимость</td><td>Проверить контракт, ссылки и restore-вопрос</td><td>Остановить removal и назначить recheck</td></tr><tr><td>Есть риск, но нет принимающей роли</td><td>Карточка описывает проблему, а не ответственность</td><td>Назвать роль с правом принять residual risk</td><td>Сначала задать owner question, потом расширять scope</td></tr><tr><td>В карточке появился точный score</td><td>Неизвестное заменили удобным числом</td><td>Разложить score на входы и источники</td><td>Вернуть класс цены и отдельно записать unknown</td></tr></tbody></table>\n<p>Эта таблица не заменяет диагностику. Она задаёт порядок вопросов. Если симптом не совпадает ни с одной строкой, не подгоняйте его под знакомый шаблон. Добавьте наблюдение, уточните границу и только затем решайте, нужен ли новый тип проверки.</p>\n<h2>Иллюстрация цикла</h2>\n<figure><img src=\"/assets/editorial/2024/maintenance-retro-2024-review-loop.svg\" alt=\"Цикл maintenance review: симптом переходит в карточку, затем в один эксперимент и повторную проверку; решение продолжить, остановить или пересмотреть остаётся за человеком\"><figcaption>Цикл ограничивает scope: наблюдение ведёт к одному эксперименту, а не к автоматическому изменению системы.</figcaption></figure>\n<p>Схема важна из-за последней развилки. Если эксперимент добавляет redesign, удаление или обещание неизвестных данных, карточка останавливается. Это отрицательный путь, а не неудача. Он показывает, что текущая граница слишком мала для предлагаемого действия. Сохраните исходный симптом и откройте отдельный review с новым scope.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Запишите один симптом.</strong> Укажите повторяемый шаг, маршрут, контракт или вопрос. Уберите слова «всё», «всегда» и «система» без границы.</li><li><strong>Назовите риск.</strong> Опишите, какую границу можно пересечь и какое решение станет ошибочным.</li><li><strong>Укажите цену классом.</strong> Запишите повторный interrupt, задержку review, ручное усилие или риск несовместимости. Числа добавляйте только с методом и источником.</li><li><strong>Назначьте роль.</strong> Найдите того, кто может принять следующий вопрос или вернуть его на уточнение.</li><li><strong>Разделите known и unknown.</strong> Для каждого факта укажите артефакт. Не превращайте отсутствие данных в нулевой риск.</li><li><strong>Сформулируйте один эксперимент.</strong> Он должен изменить знание и иметь stop condition. Не называйте экспериментом deploy, удаление или большой рефакторинг.</li><li><strong>Проведите recheck.</strong> Сравните результат с исходным симптомом. Если повторение не исчезло или граница стала шире, пересмотрите карточку.</li></ol>\n<h2>Что считать поддержанием, а что — рутинной нагрузкой</h2>\n<p>Не вся ручная работа является дефектом. Иногда человек обязан принять решение, проверить исключение или подтвердить риск. Google SRE отличает toil от полезной инженерной работы по признакам: работа ручная, повторяемая, предсказуемая, без устойчивой ценности и растёт вместе с системой. Это полезная проверка гипотезы, но не универсальный повод для автоматизации.</p>\n<p>Если шаг требует экспертного решения, автоматизируйте подготовку данных, а не само решение. Если шаг повторяет одну и ту же механику и не меняет вывод, ищите маленький эксперимент. Если ручная проверка существует ради безопасности, её удаление может увеличить риск. В карточке нужно записать, что именно должно остаться человеческим.</p>\n<h2>Ограничения</h2>\n<p>Maintenance review не выдаёт вероятность инцидента и не вычисляет бюджет исправления. Учебная карточка не знает реальный traffic, список потребителей, окно изменений, требования отката и полномочия ролей. Пример с маршрутами фиксирует только форму рассуждения. Его нельзя переносить в рабочую систему без отдельной проверки входов и разрешения на изменение.</p>\n<p>Ограничение scope защищает от двух ошибок. Первая — начать большую переделку по одному повторному вопросу. Вторая — удалить старый путь, потому что в известном наборе ссылок его не нашли. В обоих случаях неизвестное ошибочно приняли за отсутствие зависимости. Отрицательный результат проверки означает «в этом методе и охвате не найдено», а не «этого нет».</p>\n<h2>Критерий готовности</h2>\n<p>Maintenance review готов к следующему решению, если независимый инженер может за несколько минут ответить на пять вопросов: какой симптом повторяется; какую границу он затрагивает; что уже доказано; что остаётся неизвестным; какой один эксперимент и stop condition идут дальше. После эксперимента есть повторная проверка, связанная с тем же симптомом. Если хотя бы один ответ требует устного контекста автора, карточка ещё не готова.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://sre.google/sre-book/eliminating-toil/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE: Eliminating Toil</a> — критерии повторяемой операционной нагрузки и причины ограничивать её рост.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/40/r4/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-40 Rev. 4</a> — официальное руководство по выявлению, приоритизации, внедрению и проверке профилактических обновлений.</li><li><a href=\"https://csrc.nist.gov/pubs/sp/800/30/r1/final\" target=\"_blank\" rel=\"noopener noreferrer\">NIST SP 800-30 Rev. 1</a> — официальный контекст оценки риска и фиксации неопределённости.</li></ul>"
}