Все статьи
RELIABILITY & AUTOMATIONFZM2026-09-257 мин чтения

Crash-safe automation: intent, checkpoints и восстановление без blind retry

Самая опасная ошибка в автоматизации возникает не тогда, когда команда завершилась RED, а когда неизвестно, успела ли она изменить внешнее состояние. Решение — durable intent, checkpoints и reconcile-before-retry.

1. Почему unknown state опаснее RED Если операция вернула ошибку до изменения данных, ситуация понятна. Гораздо хуже таймаут после отправки команды: система могла успеть создать ресурс, переключить релиз или записать данные, но клиент не получил подтверждение.

Повтор той же команды вслепую может удвоить эффект.

2. Durable intent перед мутацией Перед внешним действием полезно записать намерение: какую операцию собираемся выполнить, над каким ресурсом, с какой идентичностью кандидата и каким ожидаемым результатом.

Этот intent должен жить дольше процесса, который выполняет операцию. Тогда после обрыва новый исполнитель понимает, что именно было начато.

3. Checkpoint после каждого внешнего эффекта Безопасный автоматизированный workflow не выполняет длинную серию мутаций между двумя точками сохранения. После каждого значимого внешнего эффекта записывается checkpoint: - что было выполнено; - какой ресурс изменился; - какая версия теперь активна; - какие проверки уже пройдены.

Так recovery начинается с последнего доказанного состояния, а не с начала процесса.

4. Reconcile before retry После таймаута нельзя сразу повторять операцию. Сначала нужно прочитать текущее внешнее состояние и сравнить его с intent: 1. Если эффект уже применен — продолжить со следующего шага. 2. Если эффекта нет — безопасно повторить. 3. Если состояние противоречиво — остановиться и восстановить истину.

Этот принцип одинаково полезен для релизов, платежей, очередей, инфраструктуры и длительных AI-assisted workflows.

СТАРТ ПРОЕКТА

Есть задача? Обсудим решение и следующий шаг.

Опишите бизнес-задачу — поможем определить подход, состав проекта и предварительный бюджет.