Операции и Управление → Автоматизированные воркфлоу

Автоматизированные воркфлоу

1) Зачем это нужно

Автоматизированные воркфлоу уменьшают ручные операции, ускоряют «время от идеи до денег» и снижают риск ошибок. В iGaming/финтехе это критично для депозитов/выводов, KYC/AML, управления бонусами/джекпотами, обновления контента, инцидент-реакции и бэк-офисных задач.

• Устойчивые, прозрачно наблюдаемые процессы от триггера до результата.
• Минимум ручных шагов, предсказуемые SLO процесса.
• Контроль ошибок: ретраи, компенсирующие действия, четкие эскалации.
• Масштабирование по событиям и нагрузке без «штормов» и дубликатов.

2) Базовая терминология

Воркфлоу (WF): цепочка шагов (tasks) для достижения бизнес-результата.
Оркестрация: центральный координатор управляет шагами и их порядком.
Хореография: шаги реагируют на события, нет «центрального мозга».
Компенсация: обратные действия при частичной неудаче (саги).
HITL (Human-in-the-loop): контролируемые «ручные» решения внутри WF.
SLO процесса: целевое время завершения/успеха конкретного WF (например, «95% депозитов ≤ 3 сек»).

3) Где применять (примеры)

Платежные флоу: депозиты, антифрод, постинг в бухучет, уведомления.
KYC/AML: сбор документов, проверки провайдерами, эскалация в комплаенс.
Управление контентом/лимитами: публикация игр, квоты, гео-правила.
Бонусы/джекпоты: начисления, удержания, расчет условий, выплаты.
Инциденты: авто-диагностика, сокращенные чек-листы, коммуникации.
Данные/ETL: выгрузки отчетов, reconciliation, архивация.

4) Оркестрация vs Хореография

Оркестрация подходит, когда: сложная логика ветвлений, строгие SLO, явные дедлайны/таймауты, визуальная «карта процесса» нужна бизнесу.
Хореография — когда: высокая событийность, слабая связность, много независимых потребителей одного события.

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

5) Архитектурные принципы

Идемпотентность: каждый шаг должен безопасно повторяться (idempotency-key, дедуп по message-ID).
Явные таймауты и ретраи: backoff + джиттер, лимиты попыток, ретраи только для безопасных ошибок.
Компенсации (саги): откаты по цепочке при частичной неудаче.
Изоляция шагов: bulkhead (отдельные пулы/лимиты на внешние даунстримы).
Контракты: OpenAPI/AsyncAPI для всех внешних вызовов, CDC-тесты.
Версионирование WF: изменение схемы входных/выходных данных без «массовых» падений старых инстансов.

6) Модель событий и триггеров

• событие домена (`deposit.requested`),
• расписание (cron),
• ручной запуск (оператор/саппорт),
• сигнал из алерта (инцидент-авто-воркфлоу).
• Контекст: корреляционный `trace_id`, `workflow_instance_id`, пользователь/регион, версия фичефлагов.
• Дешевые фильтры на входе: ранняя валидация и отсечение дублей.

7) Дизайн шагов (tasks)

Каждый шаг описывается: вход, выход, SLO, таймаут, попытки, условия ретраев, компенсация, права/секреты.

task: call_psp input: { user_id, amount, currency, idempotency_key }
timeout: 200ms retries:
max: 2 on: [5xx, connect_error]
backoff: exponential jitter: true compensation: reverse_authorization secrets: [PSP_TOKEN]
sla: p99 <= 300ms

8) Компенсации и саги

Локальная транзакция + событие: «сохранить intent → опубликовать событие».
Компенсация: отмена авторизации, возврат бонуса, пересчет баланса, закрытие тикета.
Идемпотентность компенсаций: повторная отмена не должна ломать инварианты.

9) Безопасность и секреты

KMS/Secrets Manager: хранение токенов, ротация, доступ по ролям.
Наименьшие привилегии: WF-движку выдаются ровно нужные скоупы.
Подпись вебхуков/колбеков: HMAC/JWS, проверка таймстемпа.
Политики данных: маскирование PII в логах/трассировках, шифрование.

10) Наблюдаемость и SLO

Метрики процесса: `workflow_started/completed`, `success_rate`, `aborted`, `mean/p95/p99 duration`, «висящие» инстансы, «dead letter».
Метрики шагов: `task_latency`, `error_rate`, `retry_count`, `open_circuit`, `cost_per_1k_calls`.
Трассировки: спан на каждый шаг, теги `workflow.name`, `step`, `attempt`.
SLO: например, «95% депозитов ≤ 3 сек, 99% ≤ 5 сек; abort ≤ 0.3%/сутки».
Дашборды: тепловая карта шагов, «узкие места», карты зависимостей.

11) Человек-в-контуре (HITL)

Критерии: спорные кейсы (risk/AML), ручное подтверждение крупных выплат.
Дедлайны: таймаут ожидания решения, напоминания/эскалации.
Аудит: кто/когда/что решил, обоснование, связка с тикетом.

12) Управление изменениями и релизы

Версии воркфлоу: `v1` и `v2` параллельно; миграция инстансов невозможна — завершайте старые естественным путем, новый трафик — на `v2`.
Канареечный трафик: 1% → 10% → 100%, сравнение метрик `success/p95/abort`.
Фичефлаги: быстрый откат на предыдущую реализацию шага/ветки.
CDC/контракты: гейт в CI, чтобы изменения шагов не ломали потребителей/провайдеров.

13) Тестирование

Unit шагов: позитив/негатив + идемпотентность.
Contract tests: против мока/стейджа провайдера.
WF-симуляции: happy-path + timeouts, 4xx/5xx, «медленный провайдер», потеря событий, частичные ошибки.
Game-days: инъекция сбоев (падение PSP/KYC, лаг очередей, закрытый брейкер).
Replay: воспроизведение исторических событий для проверки миграций.

14) Инциденты и авто-реакции

Авто-воркфлоу инцидента: сбор метрик, проверка даунстримов, уведомления, подготовка workaround (переключение провайдера, деградация).
Runbook-шаги: как «распутать» зависшие инстансы, когда разрешен ручной abort/force-complete.

15) Управление затратами

Квоты и «soft-cap»: лимиты на дорогостоящие шаги/провайдеров.
Кэш/дедуп: не делать повторных внешних вызовов без нужды.
Отчеты: `cost_per_1k_workflows`, «стоимость успеха» по типам WF.

16) Мини-шаблон воркфлоу (псевдо-YAML)

workflow: deposit_v1 trigger:
event: deposit.requested filters: [amount > 0, currency in [USD,EUR,TRY]]
sla:
p95_ms: 3000 abort_rate_daily: 0.3%
steps:
- name: reserve_funds timeout_ms: 150 retries: {max: 2, on: [5xx, connect_error], backoff: exponential, jitter: true}
compensation: release_reserve
- name: call_psp timeout_ms: 200 retries: {max: 2, on: [5xx, connect_error]}
circuit_breaker: {error_rate: 0.05, window_s: 10, open_s: 30}
- name: post_ledger type: async topic: ledger.post
- name: notify_user channel: push hitl:
when: amount > 10000 or risk_score > 0.8 timeout_m: 30 escalate_to: "compliance@oncall"
observability:
emit_metrics: true trace: true security:
secrets: [PSP_TOKEN, PUSH_API_KEY]

17) Политики ретраев и таймаутов (рекомендации)

Таймаут шага = 70–80% от его бюджета латентности.
Ретраи ≤ 2–3, только на идемпотентные операции и сетевые сбои.
Джиттер обязателен; запрет ретраев на таймауты узких мест без фоллбека.
Компенсации — как отдельные шаги, тоже идемпотентные.

18) Дашборды (минимум)

WF Overview: запуски/успех/abort, p95/p99 длительности, висы/деды.
Step Drilldown: топ медленных/ошибочных шагов, ретраи, открытые брейкеры.
Provider Panel: исходящие p95/error-rate/квоты/стоимость.
HITL Board: «ожидают решения», сроки, SLA комплаенса.

19) Чек-лист внедрения

• Карта ключевых WF и владельцы (on-call, чат, репо).
• Описание шагов: вход/выход, SLO, таймауты, ретраи, компенсации, секреты.
• Контракты OpenAPI/AsyncAPI + CDC.
• Идемпотентность/дедуп на входе и на шагах.
• Дашборды, трассировки, алерты (SLO процесса и по шагам).
• Канарейка + фичефлаги для релизов WF.
• Runbook: как «лечить» зависшие/частично выполненные WF.
• План деградации: альтернативные провайдеры, выключение «тяжелых» веток.
• Политики секретов/доступов/аудита.
• Game-days/хаос-сценарии раз в спринт.

20) Примеры алертов (идеи)

ALERT WorkflowSLOBreached
IF workflow_p95_duration_ms{name="deposit_v1"} > 3000 FOR 15m
LABELS {severity="critical", team="payments"}

ALERT WorkflowAbortRateHigh
IF rate(workflow_aborted_total{name="deposit_v1"}[30m]) > 0.005
LABELS {severity="warning", team="payments"}

ALERT StepRetryStorm
IF step_retry_count{name="call_psp"} > 2 baseline_1w FOR 10m
LABELS {severity="warning", team="integrations"}

ALERT StuckInstances
IF workflow_in_progress_age_p95_m{name="kyc_v2"} > 60
LABELS {severity="warning", team="risk"}

21) Анти-паттерны

«Большой монолитный WF» со 100+ шагами и жесткой связностью — ломается сложно и шумит.
Ретраи на неидемпотентные операции (двойные списания/начисления).
Таймауты «длиннее жизни» запроса пользователя → висяки и «зомби».
Отсутствие компенсаций → ручные исправления и долгие постмортемы.
Нет версионирования WF → релизы ломают старые инстансы.
Секреты внутри конфигов/переменных без ротации и аудита.

22) KPI качества воркфлоу

Success rate и Abort rate по типам WF.
p95/p99 длительности шагов и процесса.
MTTD/MTTR по инцидентам процессов.
Retry storm count / месяц (целевое → 0).
Стоимость на 1k WF и «стоимость успеха».
Доля автоматизации: % кейсов без HITL.

23) Быстрый старт (дефолты)

Начните с 3–5 критичных WF (депозит, вывод, KYC).
Оркестрируйте долгоживущие саги; локальные реакции — событиями.
Таймаут шага ≤ 80% бюджета; ретраи ≤ 2 с backoff+джиттер.
Компенсации определены письменно и протестированы.
Включите канарейку на 5–10% трафика с дашбордом сравнения.
Каждому WF — владелец, runbook и алерты SLO.

24) FAQ

Q: Что выбрать: оркестратор или события?
A: Если нужна наглядная карта, дедлайны и длинные саги — оркестратор. Если преобладают простые реакции на события и много потребителей — хореография. Часто лучший вариант — гибрид.

Q: Как избежать дубликатов?
A: Idempotency-key на входе WF, дедуп по `message_id` и хранение «seen-events». Шаги — идемпотентные.

Q: Нужен ли человек-в-контуре?
A: Да, для спорных/дорогих кейсов. Но измеряйте и снижайте долю HITL за счет лучшей автоматизации и правил.