Automation failure recovery

1. Автоматизация ломает громче ручной работы

Когда человек ошибается вручную, ошибка обычно локальна: один кривой commit, одна забытая команда, один неверный README. А вот когда ошибается автоматизация, она ошибается быстро, уверенно и иногда сразу для всех: она масштабирует не только хорошие решения, но и плохие.

Представьте обычный день в Commerce OS. Команда добавила проверку PR: deterministic checks в CI, advisory AI-review поверх diff и hook, который после правок документации напоминает прогнать команды из README. А потом начинается жизнь. AI-reviewer помечает безопасный запрос к базе как «возможную критическую уязвимость». Hook блокирует обычный markdown-файл из-за широкого matcher. Release script подцепляет не тот диапазон коммитов. Маршрут реакции не продуман — и команда действует по древнему распределённому алгоритму: кто первый запаниковал, тот и архитектор.

Здесь и появляется понятие failure path — маршрут реакции на сбой: что делаем при сбое, какие логи читаем, когда допустим повторный запуск, когда откат, как временно выключить проблемный слой, не снеся полпроекта, и кто имеет право это решить.

Эту мысль полезно запомнить в короткой формуле:

Если автоматизация не умеет безопасно ломаться, она ещё не готова к работе.

Звучит немного обидно для скрипта, который вы писали до двух ночи, зато очень честно. Автоматизация без failure path похожа на робота-пылесос с бензопилой: видно, что старается помочь, но расслабляться рядом трудно.

Ниже — простая схема, которую полезно держать в голове всякий раз, когда очередной «умный» слой внезапно покраснел:

flowchart TD
    A[Сбой автоматизации] --> B[Читаем логи]
    B --> C{Классифицируем сбой}
    C -->|временный или flaky| D[Один осмысленный rerun]
    C -->|регрессия или неверный артефакт| E[Rollback]
    C -->|сломана сама автоматизация| F[Disable path]
    D --> G[Проверяем результат]
    E --> G
    F --> H[Короткий postmortem и правка артефакта]

Заметьте, в схеме нет шага «нажать rerun пять раз и надеяться на светлое будущее». Это потому, что надежда — плохой инструмент диагностики.

2. Failure path: проектируем до внедрения

Очень заманчиво думать так: «Сначала включим, а сломается — тогда и разберёмся». На практике это почти всегда означает: разбираться вы будете, когда горит PR, релиз подвис, а кто-то в чате написал великое инженерное заклинание «у меня тоже красное». Дешевле описать путь сбоя заранее.

В нашем контексте лучший дом для него — QUALITY_GATES.md. Рядом с правилами для PR, docs и release candidate держите recovery-карту: у каждого слоя видны owner, logs и способ безопасно остановиться.

Вот как может выглядеть небольшой, но уже взрослый фрагмент для Commerce OS:

## Сбой и восстановление

### Детерминированные CI-проверки
- Владелец: @backend-team
- Логи: CI job `deterministic-checks`
- Rerun: только для flaky/timeout/network
- Rollback: revert проблемного commit или PR
- Disable path: временно выключать нельзя, только чинить

### AI-ревью
- Владелец: @platform-team
- Логи: CI job `ai-review`
- Rerun: только после подтверждённого сетевого сбоя
- Rollback: не требуется, check advisory
- Disable path: переменная `AI_REVIEW_ENABLED=false`

Это operational-часть того же файла. Здесь важна не красота markdown, а инженерный смысл. Нет владельца — в стрессе автоматизация становится «общей ответственностью», то есть ничьей. Нет пути к логам — причину ищут по памяти, по чату и по звёздам. Не прописан rerun — каждый делает его по настроению. Нет disable path — люди «временно» комментируют куски workflow, и эти временные решения живут дольше некоторых стартапов.

Особенно полезно заранее различать два класса автоматизации. Первый блокирует движение change дальше: build, tests, lint, type-check, secret scan. Второй — advisory слой, например AI-assisted review. У advisory тоже есть failure path, но другой: не rollback, а корректная деградация — отключить проблемный advisory-check, зафиксировать причину, сузить правила, вернуть в исправленном виде.

Если хотите совсем короткое практическое правило, оно такое: каждая автоматизация в pipeline должна отвечать на вопрос «а как мы её остановим, если она сломается сама?». Нет ответа — она пока не production-friendly даже для внутренней команды.

3. Классификация сбоя, потом лечение

Одна из самых дорогих ошибок — лечить сбой до того, как вы вообще поняли, что сломалось. Тогда flaky-тест лечат откатом рабочего кода, ошибку в hook — повторным прогоном CI, ложноположительное AI-замечание — выключением всего review-слоя. Одинаково шумно, одинаково бесполезно.

Полезнее сначала пройти маленький triage: определить, к какому классу относится сбой — не по интуиции, а по наблюдаемым симптомам. Для того, кто пока неуверенно чувствует себя в программировании, это даже хорошая новость: «понимать всю архитектуру» сразу не нужно — достаточно научиться задавать правильный диагностический вопрос.

Вот компактная таблица для первых решений:

Обратите внимание на важную деталь. Симптом — это не причина. «Красный CI» — внешний признак; причина сидит в коде, в среде, в скрипте проверки, в устаревшей зависимости или в ложноположительном AI-review. Именно поэтому сначала классификация.

Claude Code здесь может быть полезен, но только в режиме triage, а не «почини всё немедленно». Хороший запрос выглядит примерно так:

Проанализируй лог CI как инженер по triage.
Верни:
1. тип сбоя;
2. вероятную причину;
3. evidence: команда, файл или строка;
4. что уместно: rerun, rollback или disable;
5. минимальный следующий шаг.
Код не меняй.

Такой запрос хорош тем, что ограничивает роль Claude. Он не автослесарь, который без спроса разобрал полмашины, а диагност: классифицирует сигнал и предлагает следующий шаг.

Особенно аккуратно стоит обращаться с ложноположительными AI-замечаниями. Reviewer-subagent увидел проблему там, где её нет, — это не повод выключать весь AI-assisted review. Чаще виноват не подход, а слишком широкий фокус, слабый output contract или плохое описание того, что считается evidence. Другими словами, если человек ошибся на code review, мы же не увольняем всех reviewers разом. С AI так же.

4. Rerun, rollback и disable — три разные реакции

Когда automation падает, у команды обычно возникает сильное желание сделать что-нибудь быстрое — чаще всего этим быстрым становится rerun. Чтобы не превращать pipeline в казино, полезно очень чётко различать три реакции: rerun, rollback и disable.

Rerun — повторный запуск того же check или job без изменения артефакта. Уместен при evidence, что сбой временный: сеть моргнула, внешний сервис ответил timeout, тест известен как flaky, runner странно себя повёл. Rerun — не способ убедить реальность перестать быть реальностью. При стабильной регрессии после конкретного diff он пять раз напишет вам то же самое, только увереннее.

Rollback — возврат к последнему рабочему состоянию. На уровне PR это revert commit или откат ветки; на уровне release — возврат к предыдущему tag или удаление неверного артефакта. Нужен, когда automation уже произвела вредный результат или diff принёс регрессию. Rollback не значит «всё было зря» — часто это самый дешёвый способ быстро восстановить рабочее состояние, а причину чинить потом.

Disable path — временное выключение самой автоматизации, которая мешает. Advisory AI-reviewer сыплет ложными critical findings и парализует review. Hook блокирует нормальные команды из-за широкого matcher. Внутренний tool в PR pipeline трогает чужие файлы. Выключаем механизм понятным, обратимым способом, потом разбираемся глубже.

Хороший disable path — это не «закомментировать пол-YAML и потом забыть», а заранее предусмотренный рубильник: через переменную окружения или условие запуска.

jobs:
  ai_review:
    if: ${{ vars.AI_REVIEW_ENABLED == 'true' }}
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/ai-review.sh   # advisory check

Точный синтаксис зависит от CI-провайдера, но сама идея стабильна: automation должна уметь выключаться цивилизованно. Не с топором, а с переключателем.

Для Commerce OS это особенно важно на advisory-слоях. Работают security-reviewer, performance-reviewer и test-reviewer — тот самый parallel multi-agent review, что ускоряет семантический анализ diff. Security-reviewer посыпал ложными критическими замечаниями на обычные parameterized queries — правильная реакция не снести весь multi-agent review, а изолировать проблемный specialization, временно выключить, уточнить инструкции, вернуть. Точечно, а не как герой фильма-катастрофы, выбивающий рубильник всего здания.

Полезно держать в голове ещё одну простую логику. Rerun: «не был ли это временный сбой?». Rollback: «как быстро вернуться в рабочее состояние?». Disable: «как перестать ломать workflow, пока чиним причину?». Не синонимы и не три названия одной кнопки.

5. Postmortem и автоматизация как система

Если automation сломалась заметно и команда потратила на это больше пяти минут, полезно оставить после себя не только облегчённый выдох, но и маленькую запись о случившемся. Не роман на двадцать страниц, а короткий postmortem note на четыре вопроса: что произошло, как заметили, что сделали, что изменили в системе после инцидента.

### Короткая заметка после сбоя
- Что случилось: AI review пометил безопасный SQL как critical
- Как заметили: PR завис в красном статусе, evidence слабое
- Что сделали: выключили только `security-review`, PR проверили вручную
- Что обновили: `QUALITY_GATES.md` и prompt reviewer-агента

Смысл такой заметки не в бюрократии. Она держит главный вопрос: что мы изменили в самой системе после сбоя? Ответ «ничего, но в следующий раз будем внимательнее» — значит, automation воспитывает людей, а не улучшается сама.

И здесь мы подходим к последнему важному понятию лекции — automation maturity as system, зрелость автоматизации как системы. Взрослая автоматизация — не просто script, который «вроде работает», а набор элементов, поддерживающих друг друга.

Вот почему automation без failure path кажется удобной только до первого реального падения. После этого оказывается, что «у нас есть скрипт» и «у нас есть надёжная автоматизация» — очень разные вещи. Первое ускоряет happy path. Второе умеет переживать плохие дни команды.

Для Commerce OS это можно зафиксировать прямо в QUALITY_GATES.md, но рядом с подробной картой полезна короткая общая policy — тогда в одном месте видно и owner/logs, и логику rerun/rollback/disable:

## Политика восстановления

### Когда допустим rerun
Только flaky, timeout, network issues.

### Когда нужен rollback
Если diff дал регрессию или release-артефакт создан неверно.

### Когда используем disable path
Если сломана сама автоматизация и она мешает workflow.

### После нетривиального сбоя
Обновить `QUALITY_GATES.md`, script, hook или prompt.

На этом месте automation перестаёт быть «набором умных штук» и становится тем, чем должна быть в профессиональной разработке: предсказуемой инженерной системой. А это уже совсем другой уровень доверия. Не «надеюсь, не упадёт», а «если упадёт, мы знаем, где посмотреть, как остановить и как вернуть рабочее состояние».

И чем ближе automation подбирается к publish, deploy и другим рискованным действиям, тем меньше хватает одной надёжности pipeline: приходится заранее отделять допустимые операции от тех, где нужен явный человек и жёсткие права доступа. Именно с этого момента QUALITY_GATES.md работает не как красивый чек-лист, а как настоящая карта управления delivery.