Распределённые бизнес-операции¶
Требования применяются к бизнес-операции, обязательные эффекты которой
фиксируются в двух или более независимо отказывающих системах без общей
атомарной транзакции. Они не предписывают orchestration, choreography или
конкретный workflow engine. Уровни обязательности определены в корневом
README.md.
В этом документе distributed workflow — сохраняемая модель выполнения такой
операции. Требования применяются совместно с BE-STATE-007.
INT-WF-001. Идентичность и источник истины workflow¶
Уровень: MUST
Применяется к: каждому экземпляру distributed workflow
Workflow должен иметь стабильный идентификатор операции и один определённый источник истины о текущем состоянии. Повторное получение той же операции после timeout, redelivery или restart должно находить существующий workflow либо возвращать определённый конфликт, а не неявно создавать независимый набор эффектов.
Идентификатор workflow должен отличаться по смыслу от trace_id, span_id и
идентификатора попытки выполнения.
Обоснование¶
Стабильная идентичность связывает повторы и восстановление с одной бизнес-операцией без обещания exactly-once выполнения.
Проверка¶
- повтор инициирующего запроса и сообщения с тем же идентификатором;
- restart между созданием workflow и первым эффектом;
- проверка различия идентификаторов операции и попытки.
Исключения¶
Не допускаются для операции с обязательным внешним эффектом.
INT-WF-002. Закрытая модель состояний и переходов¶
Уровень: MUST
Применяется к: модели distributed workflow
Проект должен определить закрытый перечень состояний, разрешённые переходы, условия входа и выхода, а также успешные, компенсированные и неуспешные терминальные состояния. Для каждого нетерминального состояния должны быть определены следующий допустимый шаг и способ восстановления после restart.
Переход состояния и соответствующая локальная запись эффекта должны
фиксироваться одной транзакцией либо восстанавливаться по BE-STATE-007.
Произвольная запись состояния в обход разрешённого перехода запрещена.
Обоснование¶
Неявное состояние не позволяет отличить выполняемую, зависшую, частично завершённую и окончательно неуспешную операцию.
Проверка¶
- state-machine test каждого разрешённого и запрещённого перехода;
- fault-injection до и после фиксации перехода;
- restart из каждого нетерминального состояния.
Исключения¶
Не допускаются.
INT-WF-003. Контракт шага¶
Уровень: MUST
Применяется к: каждому шагу distributed workflow с внешним эффектом или ожиданием
Для шага должны быть определены входные данные, стабильная identity эффекта, timeout, классификация retryable и terminal ошибок, предел повторов и способ установить фактический результат после timeout или потери подтверждения.
Повтор шага должен быть идемпотентным у provider либо защищаться проверяемым механизмом предотвращения повторного эффекта. Отсутствие ответа не должно трактоваться как доказанный отказ необратимого эффекта.
Обоснование¶
Граница сети допускает завершившийся эффект без полученного подтверждения; слепой повтор создаёт дубликат, а отказ от восстановления оставляет workflow навсегда неопределённым.
Проверка¶
- timeout до и после фиксации эффекта provider;
- повтор шага с той же identity;
- тест каждого retryable и terminal класса;
- исчерпание повторов и восстановление фактического результата.
Исключения¶
Шаг без внешнего эффекта MAY не иметь identity эффекта, если его повтор не изменяет наблюдаемый результат.
INT-WF-004. Компенсация и необратимый эффект¶
Уровень: MUST
Применяется к: каждому подтверждённому эффекту, после которого workflow может завершиться безуспешно
Эффект должен быть классифицирован как компенсируемый или необратимый. Для компенсируемого эффекта должны быть определены порядок, предусловия, идемпотентность и результат отказа компенсации. Для необратимого эффекта должны быть определены допустимые последующие терминальные состояния и способ операторского восстановления.
Компенсация не должна представляться как транзакционный rollback: внешний результат должен различать отсутствие эффекта, успешную компенсацию и незавершённую компенсацию.
Обоснование¶
Компенсация сама является распределённой операцией и может завершиться частично или повториться.
Проверка¶
- отказ до, во время и после каждого компенсирующего действия;
- двукратный запуск компенсации;
- проверка результата необратимого и незавершённо компенсированного эффекта.
Исключения¶
Эффект, после которого не существует безуспешного пути workflow, находится вне области требования.
INT-WF-005. Конкурентное выполнение¶
Уровень: MUST
Применяется к: двум workflow, способным изменить один логический бизнес-объект или исчерпаемый ресурс
Проект должен определить concurrency key и применить сериализацию, optimistic concurrency, reservation либо иной проверяемый механизм. Конфликт должен возвращать определённый результат и не должен неявно превращаться в last-write-wins.
Параллельные шаги одного workflow должны иметь явно определённое условие объединения результатов; порядок завершения не должен менять терминальную семантику.
Обоснование¶
Корректные по отдельности workflow могут взаимно нарушить инвариант или компенсировать эффект другого экземпляра.
Проверка¶
- конкурентный запуск для одного concurrency key;
- перестановка порядка завершения параллельных шагов;
- тест stale version, reservation expiry и повторной попытки.
Исключения¶
Last-write-wins MAY использоваться только для поля, контракт которого явно объявляет эту семантику и подтверждает её конкурентным тестом.
INT-WF-006. Автоматическое восстановление и наблюдаемость¶
Уровень: MUST
Применяется к: нетерминальному distributed workflow
После restart или восстановления зависимости workflow должен автоматически продолжить выполнение, начать допустимую компенсацию либо перейти в определённое состояние, требующее вмешательства. Время нахождения в каждом нетерминальном состоянии должно быть ограничено deadline или наблюдаемым порогом эскалации.
Метрики и диагностические события должны позволять определить состояние, возраст, число попыток, последний стабильный код причины и следующий разрешённый recovery action без записи payload, секретов или персональных данных сверх утверждённого контракта.
Обоснование¶
Сохраняемое состояние без механизма возобновления превращает штатный restart в ручной поиск частично выполненных операций.
Проверка¶
- restart из каждого нетерминального состояния;
- восстановление после длительной недоступности зависимости;
- тест порога эскалации и обязательных сигналов;
- проверка защиты данных в telemetry.
Исключения¶
Не допускаются для обязательного эффекта.
INT-WF-007. Управляемое вмешательство¶
Уровень: MUST
Применяется к: ручному изменению выполнения distributed workflow
Операторское действие должно быть аутентифицировано, авторизовано,
идемпотентно и записано как аудит-событие по OBS-AUD-002–OBS-AUD-006.
Запись должна использовать object.type: distributed_workflow, помещать
идентификатор workflow в object.id и содержать actor.type, actor.id,
action и result по OBS-AUD-003. Действие должно использовать разрешённый
переход модели workflow и повторно проверять его предусловия.
Прямая правка persisted state, пропуск обязательного эффекта или сообщение успеха без подтверждённого результата запрещены.
Обоснование¶
Неограниченная ручная правка скрывает фактический результат и может повторить или пропустить обязательный эффект.
Проверка¶
- отказ действия без требуемых полномочий;
- повтор одного операторского действия;
- проверка audit event и предусловий перехода;
- негативный тест прямого изменения состояния.
Исключения¶
Экстренное вмешательство выполняется по OPS-INC-003, но не освобождается от
последующей фиксации аудит-события и сверки фактических эффектов.