Відновлення після збоїв автоматизації

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`
- Повторний запуск: лише для flaky/timeout/network
- Відкат: revert проблемного commit або PR
- Шлях вимкнення: тимчасово вимикати не можна, лише виправляти

### AI-ревʼю
- Власник: @platform-team
- Логи: CI job `ai-review`
- Повторний запуск: лише після підтвердженого мережевого збою
- Відкат: не потрібен, check advisory
- Шлях вимкнення: змінна `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   # попереджувальна перевірка

Точний синтаксис залежить від 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.