{
  "index": 109,
  "slug": "editorial-2024-12-field-maintenance-retro",
  "title": "Год сопровождения: как принять решение по повторяющейся проблеме",
  "excerpt": "Практическая схема для повторяющихся проблем сопровождения: отделить факт от гипотезы, проверить границу риска и выбрать между ограниченным экспериментом, остановкой и перепроверкой.",
  "contentHtml": "<p>Повторяющаяся ошибка сопровождения редко требует немедленной переделки всей системы. Сначала нужно выяснить, что именно наблюдается, какой риск уже подтверждён и какое действие запрещено до следующей проверки. Иначе команда легко примет старую запись за доказательство, удалит ещё используемый маршрут или назовёт договорённость исправлением.</p>\n<p>Разберём рабочую схему для годового обзора: одна карточка — один симптом, одна граница и одно следующее решение. На выходе может быть ограниченный эксперимент, остановка работ или перепроверка старого свидетельства. Сценарии и код ниже учебные: они показывают способ рассуждения, но не описывают production-события, метрики или результат конкретной команды.</p>\n<h2>Начните с наблюдаемого симптома</h2>\n<p>Фраза «в проекте накопился технический долг» не даёт воспроизводимой проверки. Её лучше заменить записью, которую другой инженер может увидеть и повторить: «при разборе отказа параметр ищут в трёх местах», «после изменения конфигурации нет проверки размера входного файла», «описание совместимости не называет владельца остаточного риска».</p>\n<p>У симптома должны быть четыре поля: действие, вход, наблюдаемый результат и граница. Например: инженер открывает один и тот же runbook, использует тестовую запись с идентификатором <code>case-17</code>, не находит условия остановки и не меняет систему. Последняя часть важна: отсутствие изменения — тоже факт, если его можно подтвердить журналом или diff.</p>\n<p>Не смешивайте ретроспективу сопровождения с postmortem (разбором инцидента). Google SRE описывает postmortem как запись события, воздействия, принятых мер, причин и последующих действий. Если подтверждённого инцидента не было, в карточке нельзя придумывать простой, время восстановления или эффект исправления. Для повторяемого пробела достаточно назвать источник наблюдения и следующий безопасный тест.</p>\n<h2>Четыре точки решения: T0–T3</h2>\n<p>Карточка становится полезной, когда показывает не только мысль автора, но и переход от знания к действию. Используйте четыре точки: <code>T0</code> — наблюдение; <code>T1</code> — узкая гипотеза и эксперимент; <code>T2</code> — повторная проверка источника и границы; <code>T3</code> — решение продолжить, остановить или изменить формулировку.</p>\n<figure><img src=\"/assets/editorial/2024/maintenance-retro-2024-change-timeline.svg\" alt=\"Схема T0–T3: зафиксировать симптом, составить один ограниченный эксперимент, перепроверить источник и границу, затем выбрать stop, continue или revise\" loading=\"lazy\"><figcaption>Последовательность отделяет проверку знания от изменения системы. Она не изображает календарь реального проекта и не означает выполненный rollback.</figcaption></figure>\n<p>На <code>T0</code> не добавляйте объяснение, которого нет в источнике. На <code>T1</code> не расширяйте эксперимент до миграции или redesign. На <code>T2</code> повторите тот же вход и проверьте, что источник действительно относится к текущей версии и потребителям. На <code>T3</code> зафиксируйте отрицательный путь: какое условие блокирует rollout, удаление или обещание результата.</p>\n<table><caption>Как перевести наблюдение в проверяемое решение</caption><thead><tr><th scope=\"col\">Наблюдение</th><th scope=\"col\">Что нужно проверить</th><th scope=\"col\">Безопасный следующий шаг</th><th scope=\"col\">Что пока запрещено утверждать</th></tr></thead><tbody><tr><td>Один диагностический шаг снова объясняют вручную</td><td>Другой инженер находит вход, проверку и условие остановки в одной карточке</td><td>Продолжить один эксперимент по runbook</td><td>Что toil уже уменьшился или ошибка исчезла в production</td></tr><tr><td>Риск совместимости описан, но владелец не назван</td><td>Какая роль может принять или отклонить остаточный риск</td><td>Остановить расширение области работ</td><td>Что миграция разрешена или потребители отсутствуют</td></tr><tr><td>Предлагается удалить старый объект</td><td>Потребителей, условия данных и проверку восстановления</td><td>Перепроверить зависимость и путь возврата</td><td>Что cleanup обратим только из-за малого diff</td></tr><tr><td>Появилось число без трассы, журнала или метрики</td><td>Источник числа и способ повторного измерения</td><td>Оставить только подтверждённое наблюдение</td><td>Что число описывает эффект исправления</td></tr></tbody></table>\n<h2>Когда продолжать: узкий эксперимент</h2>\n<p>Продолжение оправдано, когда симптом повторяется, граница понятна, а проверка не меняет живое состояние. Например, в трёх учебных прогонах читатель не понимает, где заканчивается диагностический путь. Это не доказывает частоту проблемы у пользователей, но достаточно для маленького эксперимента: добавить в runbook один вход, один диагностический шаг и одно условие остановки.</p>\n<p>Критерий эксперимента должен быть бинарным и наблюдаемым. Другой читатель либо проходит фиксированный failing path без устного пояснения, либо нет. Не подменяйте критерий обещанием «сэкономить время»: экономию можно заявлять только после согласованного измерения с определёнными входом, периодом и базовой линией.</p>\n<p>Ограничение scope защищает от незаметного роста задачи. Если для исправления карточки понадобились новая схема данных, новый контракт или массовая миграция, эксперимент закончился. Новая работа получает отдельную оценку риска, владельца и план проверки. Она не наследует разрешение от маленького runbook-изменения.</p>\n<h2>Когда остановиться: риск без владельца</h2>\n<p>Запись «продолжаем миграцию, совместимость проверим позже» не является решением. В ней отсутствуют полномочия и блокирующее условие. Наличие зелёного теста на одном потребителе также не доказывает, что известны все потребители или что остаточный риск принят.</p>\n<p>Остановите расширение работ, если неизвестно, кто может принять риск, какие клиенты зависят от границы и что произойдёт при отказе. Зафиксируйте конкретный вопрос: «какая роль подтверждает совместимость маршрута <code>/legacy</code> с клиентами версии <code>v2</code>?». Пока ответа и источника нет, не следует менять контракт, удалять обратную совместимость или объявлять rollout безопасным.</p>\n<p>Такой stop не означает, что система сломана. Он означает, что имеющихся данных недостаточно для выбранного действия. Это различие помогает не превращать неопределённость в срочную задачу без владельца.</p>\n<h2>Когда перепроверить: cleanup не равен rollback</h2>\n<p>Удаление конфигурации, поля или старой зависимости меняет состояние, даже если diff занимает одну строку. Перед ним нужны как минимум три независимые проверки: список потребителей, совместимость данных и проверяемый путь восстановления. Если восстановление описано словами «вернуть назад», это ещё не rollback plan.</p>\n<p>Для маршрута проверка может включать поиск обращений, тест старого клиента и возврат прежней конфигурации в изолированной среде. Для данных — совместимую схему, контроль чтения и восстановление копии на тестовом наборе. Для зависимости — граф импорта, сборку и подтверждение владельца потребителя. Набор проверок зависит от архитектуры; универсального безопасного числа нет.</p>\n<p>Практический порог простой: если новый факт способен изменить решение «удалять или оставить», его нужно получить до удаления. Google SRE рекомендует для неаварийных изменений поэтапный rollout, наблюдение и откат при неожиданном поведении. Это ориентир процесса, а не разрешение копировать чужие проценты трафика или порядок релиза.</p>\n<h2>Воспроизводимая модель без изменения системы</h2>\n<p>Ниже — полностью локальный пример на Node.js. Он принимает карточку, проверяет наличие неизвестных полей и печатает решение. Сохраните код в файл <code>maintenance-check.mjs</code>, затем выполните команды. Скрипт не читает репозиторий, не вызывает сеть и не удаляет данные.</p>\n<pre><code>const card = {\n  symptom: 'cleanup proposed',\n  known: ['restore question exists'],\n  unknown: ['consumers', 'data compatibility', 'rollback check'],\n};\n\nfunction decide(item) {\n  if (!item.symptom) return { decision: 'stop', reason: 'no observable symptom' };\n  if (item.unknown.length &gt; 0) {\n    return { decision: 'recheck', reason: item.unknown.join(', ') };\n  }\n  return { decision: 'continue', reason: 'bounded experiment only' };\n}\n\nconsole.log(decide(card));</code></pre>\n<pre><code>node --version\nnode maintenance-check.mjs\n# { decision: 'recheck', reason: 'consumers, data compatibility, rollback check' }</code></pre>\n<p>Ожидаемый вывод зависит от версии Node.js и формата консоли, но решение и список причин должны совпасть. Добавьте неизвестное поле, например <code>owner</code>, и убедитесь, что решение не изменилось на <code>continue</code>. Удалите все элементы из <code>unknown</code> только после того, как для каждого есть источник и повторяемая проверка. Модель намеренно не оценивает полноту риска: это обязанность владельца системы и её процесса изменений.</p>\n<h2>Как проверять источники и границы утверждения</h2>\n<p>Для каждой строки карточки заведите пару «утверждение — источник». Источником может быть журнал, тестовый вход, версия конфигурации, diff, трасса или официальная документация. Ссылка на общий раздел проекта без указания версии и операции не подтверждает конкретный вывод.</p>\n<p>Удобная проверка в Git-репозитории выглядит так:</p>\n<pre><code>git grep -n -- '/legacy' -- ':!vendor'\ngit log -S'/legacy' --all --oneline -- path/to/config\ngit diff --check</code></pre>\n<p>В этих командах <code>/legacy</code>, <code>path/to/config</code> и исключение <code>vendor</code> — placeholders: замените их на строку и путь своего проекта. Первая команда ищет текущие обращения, вторая помогает найти историю строки, третья проверяет пробельные ошибки в diff. Ни одна из них не доказывает отсутствие динамических потребителей, внешних клиентов или данных в хранилище. Для них нужны отдельные источники.</p>\n<p>Официальная документация задаёт рамку, но не заменяет локальное доказательство. NIST описывает оценку риска как часть процесса управления риском, который помогает выбрать действие по выявленному риску. Это не превращает абстрактную оценку в разрешение на изменение конкретного сервиса. Точно так же рекомендации Google SRE по rollout применимы как принцип наблюдаемого и постепенного изменения, но параметры должны соответствовать вашей нагрузке, правам и плану восстановления.</p>\n<h2>Порядок годовой проверки одной карточки</h2>\n<ol><li><strong>Сузьте scope.</strong> Оставьте один симптом, один объект и одну границу. Не соединяйте cleanup, изменение контракта и миграцию в одну запись.</li><li><strong>Зафиксируйте T0.</strong> Запишите вход, наблюдаемый результат, время или версию источника и то, что не менялось.</li><li><strong>Разделите известное и неизвестное.</strong> Для каждого неизвестного сформулируйте вопрос, источник и критерий достаточности.</li><li><strong>Назовите цену ошибки.</strong> Опишите конкретное последствие: отказ клиента, потеря совместимости, повторная ручная работа или невозможность восстановления.</li><li><strong>Составьте T1.</strong> Выберите минимальную проверку, которая различает две гипотезы и не меняет production-состояние.</li><li><strong>Проведите T2.</strong> Повторите тот же вход, проверьте версию и независимость источника. Если условия изменились, откройте новую карточку.</li><li><strong>Примите T3.</strong> Continue оставляет ограниченный эксперимент, stop блокирует действие без владельца или доказательства, recheck возвращает карточку на проверку границы.</li><li><strong>Запишите отрицательный путь.</strong> Укажите, какое наблюдение остановит rollout или удаление, кто увидит сигнал и какое действие допустимо после него.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Схема полезна для повторяющихся задач сопровождения, runbook и небольших изменений конфигурации. Она не заменяет аварийное реагирование, управление изменениями, threat model, интеграционные тесты, резервное копирование, требования безопасности или полномочия владельца сервиса.</p>\n<p>Точки T0–T3 и код — учебная модель. В них нет production-метрик, данных клиентов, реального deployment или доказанного результата. Один найденный владелец не доказывает совместимость. Один успешный тест не доказывает отсутствие потребителей. Один вопрос о восстановлении не доказывает успешный rollback. Для критичных систем добавьте требования из своей политики, регуляторные ограничения и независимое ревью.</p>\n<p>Официальные источники ниже описывают общие практики и федеральный контекст NIST, а не конкретную архитектуру вашего проекта. Перед применением проверьте версию инструмента, модель доступа, допустимое окно изменения и способ безопасно вернуть состояние.</p>\n<h2>Критерий готовности</h2>\n<p>Карточка готова к следующему решению, когда другой инженер видит один симптом, источник, границу, известное и неизвестное, цену ошибки, роль владельца, проверяемый эксперимент и отрицательный путь. Для удаления дополнительно указаны потребители, условия данных и тест восстановления. Для риска без владельца итогом остаётся stop, а не скрытое продолжение.</p>\n<p>Год сопровождения закрывается не количеством закрытых задач, а повторяемостью решений. Если новый факт не может изменить выбранный исход, проверка не затрагивает механизм. Если исход меняется после проверки, это полезный результат: он показывает, где прежняя уверенность была шире доказательства.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://sre.google/sre-book/postmortem-culture/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Postmortem Culture</a> — состав postmortem, критерии значимого события и preventive actions; источник не подтверждает учебный сценарий выше.</li><li><a href=\"https://sre.google/sre-book/service-best-practices/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Production Services Best Practices</a> — проверка входных данных, поэтапный rollout, наблюдение и rollback при неожиданном поведении; проценты и условия должны быть локальными.</li><li><a href=\"https://sre.google/sre-book/release-engineering/\" target=\"_blank\" rel=\"noopener noreferrer\">Google SRE Book: Release Engineering</a> — воспроизводимость сборки, audit trail тестов и связь конфигурации с версией артефакта; Google-специфичные инструменты не являются обязательными.</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: Guide for Conducting Risk Assessments</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: Guide to Enterprise Patch Management Planning</a> — идентификация, приоритизация, установка и проверка обновлений как preventive maintenance; руководство посвящено patch management, а не любому cleanup.</li></ul>"
}