Автоматизація повинна мати failure path
Автоматизація масштабує не лише корисні дії, а й помилки. Для кожного CI-check, hook, AI-reviewer або release-script заздалегідь опишіть, що робити після збою, де шукати докази і хто приймає рішення.
Зрілий workflow має не тільки happy path, а й контрольоване завершення, тимчасове вимкнення та повернення до стабільного стану.
| Поле recovery plan | Приклад змісту |
|---|---|
| Owner | Відповідальний за компонент |
| Logs | Місце job, hook або release-логів |
| Rerun condition | Коли повторний запуск обґрунтований |
| Rollback | Спосіб повернення до останнього робочого стану |
| Disable | Явний перемикач або умова запуску |
| Aftercare | Що оновити після інциденту |
Спочатку докази, потім дія
- Знайдіть job або hook, який завершився помилкою.
- Зафіксуйте команду, файл, рядок і релевантний лог.
- Перевірте diff останніх змін і відмінності середовища.
- Оцініть, чи відтворюється проблема при повторному запуску.
- Класифікуйте failure перед вибором rerun, rollback або disable.
Rerun, rollback і disable — різні реакції
Для advisory-перевірки іноді безпечніше вимкнути лише несправний reviewer, зберігши решту pipeline. Не вимикайте весь quality workflow, якщо проблема локальна.
| Дія | Коли доречна | Чого не робити |
|---|---|---|
| Rerun | Є ознаки тимчасового timeout, flaky або мережевого збою | Не повторювати стабільну регресію без нових доказів |
| Rollback | Зміна пошкодила код, release або delivery-артефакт | Не відкотити навмання без визначеної стабільної точки |
| Disable | Несправний automation component блокує правильний flow | Не коментувати великі ділянки YAML і не забути про тимчасовий стан |
Типові сценарії класифікації
- flaky, timeout або мережевий збій — один обґрунтований rerun;
- стабільне падіння після конкретного diff — аналіз регресії та можливий rollback;
- hook блокує правильну дію — тимчасове disable і виправлення matcher або handler;
- AI-review дає слабко обґрунтоване критичне зауваження — ручна перевірка та звуження prompt;
- неправильний release tag або changelog — зупинка поширення і відновлення коректного артефакту;
- локально green, CI red — порівняння залежностей, env і runner.
Після інциденту оновіть не лише код
Короткий postmortem має зафіксувати, що сталося, як проблему виявили, яку дію виконали та що змінили після цього. Іноді потрібні правки в QUALITY_GATES.md, prompt, hook, matcher, логуванні або recovery path.
Рішення про rollback, disable або продовження ризикованої операції залишається за людиною. Особливо це стосується publish, deploy і privilege-bound actions.
## Incident
- What happened:
- Detection signal:
- Evidence:
- Action taken:
- Follow-up change:
- Owner:Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush