Durable Task: когда процессу нужна память о каждом шаге

Microsoft опубликовала в блоге .NET разбор Durable Task in the Real World.

Авторы описывают пять практических сценариев, где durable execution оправдан, и случаи, где он только добавляет сложности.

Отдельный раздел посвящён AI-агентам.

Из разбора я вывел правило: долговечное исполнение окупается, когда бизнес-процесс живёт дольше одного запроса и потерянный шаг стоит денег. В остальных случаях хватит очереди и идемпотентного обработчика.

Durable Task - open-source фреймворк Microsoft, на нём построены Azure Durable Functions.

Разработчик описывает процесс обычным кодом на C#: вызвать сервис, дождаться ответа, вызвать следующий.

Фреймворк записывает результат каждого завершённого шага в историю. Допустим, процесс упал на четвёртом шаге.

После рестарта оркестратор перечитывает историю (этот механизм называется replay), подставляет сохранённые результаты первых трёх шагов и продолжает с четвёртого.

Ожидание может длиться днями: таймер или внешнее событие хранятся в базе, поток при этом не занят. За это приходится платить.

Код оркестратора должен быть детерминированным: внутри нельзя вызывать `DateTime.Now`, генерировать `Guid` или напрямую ходить в HTTP.

Внешние вызовы разработчик выносит в activities, а время и случайные значения берёт через API фреймворка. Команда, которая не знает этих правил, получит баги, которые воспроизводятся только при replay.

Возьмём заказ, который проходит пять систем: сайт, 1С, склад, службу доставки и ЭДО. Предположим, доступность каждой системы 99%.

Тогда заказ проходит цепочку без сбоя с вероятностью 0,99⁵, то есть около 95%.

При 2 000 заказов в день примерно 100 зависнут где-то посередине.

Обычно компании закрывают эту дыру таблицей статусов, cron-скриптом повторов и менеджером, который по утрам вручную ищет потерянные заказы.

Получается самописный durable execution без гарантий и тестов, а устройство его знает один разработчик.

### Процессы, которые ждут человека Примеры: согласование договора, подключение поставщика, подпись документа в ЭДО.

Процесс отправляет документ, ждёт три дня, по таймауту эскалирует руководителю и после подписи идёт дальше.

На очереди такой процесс превращается в машину состояний, размазанную по пяти таблицам. В оркестраторе он занимает несколько десятков строк последовательного кода. ### Саги с компенсацией

Склад зарезервировал товар, оплата не прошла, резерв нужно снять.

Оркестратор хранит список выполненных шагов и запускает компенсации в обратном порядке.

Без этого на складе копятся фантомные резервы: товар физически лежит на полке, а продать его нельзя. ###

Массовая обработка с параллелизмом Допустим, нужно обогатить через LLM 50 000 карточек товаров в Pimcore или Akeneo.

Оркестратор режет их на пачки, запускает параллельно (fan-out) и собирает результат (fan-in).

Если на 30 000-й карточке упадёт модель или кончится квота, обработка продолжится с места сбоя.

Без оркестратора токены, оплаченные за первые 30 000 карточек, пришлось бы тратить второй раз. ### AI-агенты

Агент работает циклом: модель выбирает инструмент, получает результат и решает, что делать дальше.

Иногда агент останавливается и ждёт подтверждения человека.

Каждая итерация стоит токенов и может иметь побочный эффект.

Пусть агент упал на двенадцатом вызове из пятнадцати.

Перезапуск с нуля оплатит одиннадцать вызовов повторно.

Кроме того, клиент может получить письмо дважды, а в 1С появится второй документ. Durable execution сохраняет результат каждого вызова модели и инструмента, и после восстановления агент продолжает с последнего шага.

Короткие идемпотентные запросы, которые укладываются в секунды, закрываются политикой retry. Для потока «сообщение из Apache Kafka → запись в базу»

оркестратор тоже не нужен: Kafka хранит offset, и второй источник истины только усложнит отладку.

Если обмен с 1С уже идёт через ESB с гарантированной доставкой, например Datareon, MuleSoft или Talend, дублировать эти гарантии оркестратором бессмысленно.

Есть и операционный риск, который команды часто упускают на старте, - версионирование. Представьте, что 400 экземпляров процесса ждут подписи, а вы меняете код оркестратора.

При replay старая история не совпадёт с новым кодом, и процессы упадут.

Стратегию версий нужно продумать до первого релиза.