Що робити, коли процес зламався посередині

Проблема простіша, ніж звучить

Уявімо звичайний процес в інтернет-магазині:

1. створити замовлення;
2. забронювати товар на складі;
3. списати або зарезервувати оплату;
4. надіслати підтвердження клієнту.

Тепер третій крок завис. Замовлення вже є. Товар, можливо, вже заброньований. Про оплату не зрозуміло: банк міг прийняти запит, а міг ні. Клієнт ще не отримав нормального підтвердження.

Ось про що ця стаття: як заздалегідь описати дії після такого збою, щоб команда не розбирала кожен випадок вручну.

Головна ідея: для кожного кроку потрібен план прибирання

Коли процес складається з кількох кроків, простого try/catch часто мало. Код бачить помилку, але не завжди знає, що вже сталося у зовнішній системі.

Тому для кожного кроку варто записати три речі:

• що цей крок змінює;
• як перевірити, чи зміна справді відбулась;
• що робити, якщо наступний крок упав.

Це і є практичний план відкату. Не обовʼязково починати з терміна saga. Для команди важливіше просте питання: “як ми повертаємо процес у зрозумілий стан?”

Приклад: що записати для процесу замовлення

Для кроку “забронювати товар” план може бути таким:

• зміна: склад зменшив доступну кількість товару;
• перевірка: подивитися резерв за order_id або reservation_id;
• дія після збою: зняти резерв, якщо оплата не підтвердилась;
• важлива умова: не знімати резерв двічі.

Для кроку “оплата” план інший:

• зміна: банк міг створити платіж або резерв коштів;
• перевірка: запитати статус платежу за зовнішнім payment_id;
• дія після збою: скасувати резерв або створити задачу на ручну перевірку;
• важлива умова: якщо статус невідомий, не робити автоматичне скасування навмання.

Так процес стає не “магією в коді”, а таблицею зрозумілих рішень.

Найнебезпечніший випадок: невідомий стан

Найгірше не тоді, коли крок точно впав. Найгірше, коли він завис.

Наприклад, сервіс платежів не відповів. У вас є три варіанти:

• платіж точно не створився;
• платіж точно створився;
• невідомо.

Для перших двох випадків автоматизація може діяти сама. Для третього потрібен окремий стан, наприклад SUSPECT або “потрібна перевірка”. Це означає: процес зупиняється, наступні кроки не запускаються, команда бачить конкретну задачу для перевірки.

Це не слабкість автоматизації. Це нормальний запобіжник від ще більшої помилки.

Чому порядок відкату йде з кінця

Якщо процес пройшов кілька кроків, прибирати наслідки часто треба у зворотному порядку.

Спочатку скасовуємо те, що сталося останнім. Потім попередній крок. Це схоже на вихід із кімнати: якщо ви спочатку відкрили шафу, потім дістали коробку, а потім розсипали інструменти, прибирати логічно з останньої дії.

Для технічного процесу це виглядає так:

1. якщо підтвердження клієнту ще не пішло — нічого не відкочуємо;
2. якщо оплата зависла — перевіряємо статус;
3. якщо оплати немає — знімаємо резерв товару;
4. якщо замовлення більше не має сенсу — переводимо його в “скасовано” або “потребує перевірки”.

Головне: не запускати один великий скрипт “прибрати все”. Він швидко стає небезпечним.

Де тут складні терміни

Тепер терміни стають простими.

Saga — це підхід, де довгий процес розбитий на кроки, і для кожного кроку є дія на випадок подальшого збою.

Компенсація (у джерелах часто compensation) — це не завжди ідеальне скасування. Іноді неможливо повернути все як було. Тоді компенсація означає “перевести систему в прийнятний стан”. Наприклад:

• не видаляти замовлення, а позначити його як “потребує перевірки”;
• не повторювати платіж, а перевірити статус у банку;
• не змінювати склад напряму, а зняти конкретний резерв.

Тобто це не академічна тема. Це спосіб зменшити ручний хаос після часткових збоїв.

Що зробити в команді за один спринт

Не треба одразу перебудовувати всю систему. Почніть із одного болючого процесу.

1. Випишіть кроки в реальному порядку.
2. Біля кожного кроку запишіть, що він змінює у зовнішніх системах.
3. Додайте перевірку: як дізнатися, що дія справді виконалась.
4. Додайте дію після збою: відкотити, зупинити або віддати людині.
5. У тестовому середовищі спеціально зламайте середній крок і перевірте, що система не створює дублікати.

Після цього тема перестає звучати абстрактно. Вона стає про дуже практичну річ: якщо процес упаде посередині, команда вже знає, що робити.

Антипатерни

• Один загальний скрипт прибирання для всіх ситуацій.
• Повтор платежу без перевірки, чи перший запит не пройшов.
• Відкат без журналу виконаних кроків.
• Автоматичне скасування у невідомому стані.
• Відсутність окремого статусу “потрібна перевірка”.

Джерела

• https://blog.cloudflare.com/rollbacks-for-workflows/