![\"Лента](\"/assets/editorial/2024/maintenance-retro-2024-change-timeline.svg\")
В конце квартала список сопровождения выглядит знакомо: одна и та же ручная проверка, старый риск совместимости и задача на удаление, которую откладывают. Симптомы повторяются, но решение каждый раз начинается с нуля. Цена ошибки — не только лишний час инженера. Команда может удалить ещё используемый маршрут, принять риск без владельца или назвать договорённость исправлением.
\nТезис этой статьи простой: годовое сопровождение нужно вести как последовательность проверяемых решений. Для каждой проблемы сначала фиксируют симптом и границу, затем решают: продолжить узкий эксперимент, остановить рост области работ или перепроверить устаревшее свидетельство. Это не обещает результата в production. Такой порядок не даёт черновому решению получить права на изменение живой системы.
\nЗапись «в системе накопился технический долг» ничего не проверяет. Запись «при диагностике одного типа отказа инженер каждый раз ищет один и тот же параметр в трёх местах» уже задаёт наблюдение. У него есть действие, граница и возможный следующий шаг.
\nРетроспектива сопровождения не заменяет postmortem. Postmortem описывает подтверждённое событие, воздействие, причины и follow-up. Если инцидента не было, нельзя добавлять в текст ущерб, время восстановления или результат исправления. Для годового обзора достаточно назвать повторяемый симптом, неизвестное и решение, которое можно проверить отдельно.
\nПолезная карточка сопровождения содержит четыре точки. T0 — наблюдение. T1 — ограниченная гипотеза или эксперимент. T2 — повторная проверка свидетельства. T3 — решение продолжить, изменить формулировку или остановиться. Такая шкала не изображает календарь реальной команды. Она показывает порядок знаний.
Граница решения отвечает на вопрос «что именно мы сейчас можем утверждать». Например, можно утверждать, что диагностический шаг повторяется в учебной карточке. Нельзя утверждать, что он уже уменьшил нагрузку на поддержку. Можно увидеть отсутствие роли-владельца. Нельзя считать риск принятым. Можно сохранить вопрос о восстановлении. Нельзя объявлять cleanup безопасным до проверки зависимостей.
\n| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Один диагностический шаг снова объясняют вручную | У runbook нет явной границы остановки | Другой инженер находит symptom, check и stop condition по одной записи | Продолжить один узкий runbook-эксперимент |
| Риск совместимости описан, но owner не назван | Наблюдение приняли за решение | Проверить роль, которая может принять residual risk | Остановить расширение scope |
| Cleanup выглядит безопасным по старой карточке | Неизвестны consumers и путь восстановления | Перепроверить dependency graph, data conditions и restore boundary | Не переходить к удалению |
| В отчёте появился измеренный эффект без источника | Учебный вывод смешали с production-фактом | Найти trace, метрику, журнал или убрать утверждение | Оставить только подтверждённое наблюдение |
Представьте учебную карточку: на трёх проверках инженер повторно спрашивает, где заканчивается диагностический путь. Это не доказывает частоту проблемы в реальной системе. Но факт повторения в карточке оправдывает небольшой эксперимент: добавить один boundary, один способ проверки и один stop condition.
\nЭксперимент готов, если другой читатель проходит фиксированный failing path и получает тот же порядок действий без доступа к авторским пояснениям. Если задача разрастается до redesign поддержки или начинает обещать экономию времени, её нужно остановить и оформить как отдельное решение. Runbook не должен незаметно стать программой перестройки.
\nВторая карточка описывает границу контракта, но не содержит роли, которая принимает остаточный риск. В такой ситуации фраза «продолжаем миграцию» подменяет решение намерением. Отсутствие известных consumers тоже не равно доказанному отсутствию consumers.
\nПравильный следующий шаг — остановить рост области работ и задать один вопрос: кто может принять или отклонить утверждение о совместимости именно этой границы? Пока роль не названа и не имеет полномочий, карточка не должна переходить в rollout, removal или обещание обратной совместимости.
\nТретья карточка выглядит спокойной: есть предложение удалить старый объект и короткое описание риска. Но неизвестны зависимости, совместимость данных и успешность восстановления. Слово «cleanup» скрывает изменение состояния. Его нельзя считать обратимым только потому, что действие кажется маленьким.
\nRecheck должен назвать boundary, факт остановки и путь возврата. Для маршрута это может быть прежняя конфигурация и проверка ответа клиента. Для данных — совместимая схема и проверка чтения. Для зависимости — список потребителей и подтверждённый владелец. Если эти условия неизвестны, draft не превращается в rollback plan.
\nНиже — намеренно маленькая модель. Она не читает репозиторий, не вызывает сеть, не выполняет deployment и не откатывает изменения. Её задача — показать, что решение остановиться меняет только статус черновика.
\nconst card = {\n symptom: 'cleanup proposed',\n known: ['restore question exists'],\n unknown: ['consumers', 'data compatibility', 'rollback check'],\n};\n\nfunction plan(card) {\n const needsRecheck = card.unknown.length > 0;\n return { decision: needsRecheck ? 'recheck' : 'continue', realChange: false };\n}\n\nconst draft = plan(card);\nconsole.log(draft.decision); // recheck\nconsole.log(draft.realChange); // falseПример учебный. Он не определяет риск автоматически и не доказывает, что список неизвестных полон. В реальном проекте поля нужно связать с разрешёнными источниками, владельцем решения и конкретным тестом. Если код начинает сам удалять, менять или откатывать состояние, он вышел за границу этой модели.
\nФакт можно показать другому человеку: записью события, конфигурацией, тестовым входом, ссылкой на код или повторяемым действием. Решение добавляет владельца и условие следующего шага. Гипотеза связывает факт с возможной причиной. Нельзя заменить один тип другим.
\nФакт: один шаг диагностики повторяется в учебной карточке.\nГипотеза: runbook не показывает boundary.\nПроверка: другой читатель проходит тот же failing path.\nРешение: продолжить один эксперимент, не менять production.Если подтверждающего источника нет, пишите «неизвестно». Это полезнее, чем округлённая оценка. Неизвестное задаёт следующий вопрос. Выдуманная точность создаёт ложное разрешение на действие.
\nЭта схема не измеряет надёжность и не ранжирует весь backlog. Она не заменяет incident response, change control, threat model, интеграционные тесты и право владельца на изменение системы. Один runbook-эксперимент не доказывает снижение toil. Один найденный owner не доказывает совместимость. Один restore question не доказывает успешный rollback.
\nУчебные карточки, T0–T3 и код выше вымышлены. В статье нет production-метрик, истории конкретной команды, данных клиентов, deployment или результата исправления. Переносить вывод можно только после замены учебного входа фактическими источниками и проверки условий среды.
\nКарточка готова к следующему решению, если читатель видит один наблюдаемый симптом, одну границу, цену ошибки, известное и неизвестное, роль владельца, отрицательный путь и один следующий эксперимент. Для cleanup дополнительно указаны зависимости, условия данных и проверка восстановления. Для риска без owner итогом должен быть stop, а не скрытое продолжение.
\nГод сопровождения не закрывается красивым списком исправлений. Он закрывается набором границ, которые можно повторно проверить. Если новая проверка не может изменить решение, она не проверяет механизм.
\n