문서달리다자동 재개

예상치 못한 중단 및 자동 재개

작업 흐름이 중간에 중단되면 어떻게 해야 합니까? 복구 및 멱등성을 갖추고 중단점에서 다운로드를 재개하고 반복되는 부작용을 방지합니다.

"실행이 한 번에 완료되지 않으면 어떻게 해야 합니까?"는 프로덕션 수준 워크플로가 대답해야 하는 질문입니다. Braidrun는 두 가지 처리 솔루션을 제공합니다.

기본값: 안전 브레이크 — 실행을 INTERRUPTED로 표시하고 명확하게 보일 때까지 기다린 후 중간의 특정 단계에서 수동으로 "재시도"하십시오.
선택사항: 자동으로 계속 실행 — "이 워크플로는 계속될 수 있으며 어떤 단계는 멱등적"인지 명시적으로 선언하면 플랫폼은 중단 지점에서 자동으로 계속됩니다.

방해하다은 무슨 뜻인가요?

두 가지 카테고리:

플랫폼 측 - 서비스가 다시 시작되고, 인스턴스가 교체되고, 호스트가 실패합니다. 우리는 이러한 것들을 피하려고 노력하지만 항상 100%는 아닙니다.
귀하 측에서는 실행을 적극적으로 "취소"합니다(INTERRUPTED가 아닌 CANCELLED에서 중지).

이전 범주만 "자동 계속" 프로세스에 들어가고 CANCELLED의 실행은 자동으로 실행되지 않습니다.

기본 동작: 안전 브레이크

플랫폼 측 인터럽트가 발생하면 플랫폼은 다음을 수행합니다.

실행 상태를 INTERRUPTED로 표시합니다.
Keep the results, products, and logs of all completed steps;
현장 알림을 받습니다(이메일/Slack도 알림에 따라 구성됩니다).
실행 세부정보 페이지로 이동하면 "실패한 단계에서 다시 시도"할 수 있습니다. 플랫폼은 이전 단계의 결과를 재사용합니다.

이 기본값은 모든 워크플로에 사용할 수 있으며 구성이 필요하지 않습니다. 적합 대상:

워크플로에 외부 부작용(이메일 보내기/금액 공제/데이터베이스 수정)이 포함되어 있습니다.
생산이 아직 "다시 시작하고 계속 실행해도 안전한지" 확실하지 않은 경우

선택사항: 자동으로 계속 실행

워크플로가 순수 데이터 파이프라인(읽기 전용 API + 보고서 생성)인 경우 자동 계속을 설정할 수 있습니다. 중단이 발생한 후 수동으로 클릭할 필요 없이 플랫폼이 중단 지점에서 자동으로 계속 실행됩니다.

2계층 옵트인 활성화

자동 연속을 적용하려면 YAML에서 두 레이어를 모두 선언해야 합니다.

작업 흐름 수준: 성명서 recovery.autoResumeOnRestart: true
단계 수준: 안전한 재실행을 위한 단계별 지침 idempotent: true

완전한 예

yaml

name: daily-asa-digest
version: "1.0.0"

recovery:
  autoResumeOnRestart: true
  policy: RESUME_FROM_LAST_INCOMPLETE
  maxAutoResumeAttempts: 3

steps:
  - id: fetch_asa_data
    type: sub_workflow
    module: dingyue-module-asa-fetch
    idempotent: true           # 只读拉取，可重跑

  - id: build_excel
    type: sub_workflow
    module: dingyue-module-excel-report
    idempotent: true           # 生成文件到产物目录，可重跑

  - id: notify_team
    type: sub_workflow
    module: dingyue-module-slack-deliver
    # 不写 idempotent —— 默认 false，发消息不可重跑

세 가지 복구.정책

policy	의미	장면에 적합
`ABORT`	자동으로 복원하지 않는 것은 기본 동작으로 돌아가는 것과 같습니다.	테스트 단계
`RESUME_FROM_LAST_INCOMPLETE`	기본값. COMPLETED가 아닌 첫 번째 단계부터 다시 실행하세요.	데이터 파이프라인, 읽기 전용 API 집계, 순수 계산
`RESUME_FROM_START`	전체 워크플로를 처음부터 다시 실행	가동 중단 중에 데이터 소스가 변경될 수 있고 새로 고쳐야 하는 시나리오

idempotent 표시 방법

단계가 멱등성인지 여부를 결정하는 최적의 표준은 다음과 같습니다.

"동일한 입력을 두 번 실행하면 부작용이 발생하나요?"

외부 메시지 보내기, 비용 청구, 주문 작성 등이 가능하다면 멱등성을 추가하지 마세요.

단계 속성	`idempotent`
읽기 전용 API 쿼리(보고서 가져오기, 앱 나열)	✓ true
순수 계산/데이터 변환	✓ true
제품 디렉토리에 Markdown/Excel 생성	✓ true(기존 제품은 재실행 전 삭제됩니다)
LLM 추론(부작용 없는 도구)	✓ true(토큰은 다시 계산되지만 의미상 안전합니다.)
이메일 보내기 / 텔레그램 / 슬랙 / 페이슈	✗ false
외부 DB 쓰기/광고 입찰 변경/주문/출금	✗ false
웹훅 아웃바운드 통화	✗ false(다른 엔드포인트가 중복 항목을 명시적으로 제거하지 않는 한)
manual_approval	✗ false(계속 실행하면 승인자에게 다시 핑이 울리게 되는데, 이는 좋지 않은 경험입니다.)

기본값은 false입니다. 안전이 최우선입니다.

멱등성이 작성되지 않은 경우 기본값은 false입니다. RESUME_FROM_LAST_INCOMPLETE는 멱등성이 아닌 단계가 발생하면 ABORT로 다운그레이드됩니다. 자동으로 실행되지 않으므로 사용자가 수동으로 수행해야 합니다.

자동연속시 발생하지 않는 여러 상황

복구를 구성하더라도 다음 실행은 자동으로 계속 실행되지 않습니다.

트리거 소스는 Webhook입니다. Webhook 페이로드는 최대 한 번일 수 있으며 플랫폼은 업스트림이 재시도할지 여부를 알 수 없습니다.
트리거 소스는 스케줄러입니다. 스케줄러는 다음 크론 라운드에서 자체적으로 다시 실행됩니다.
현재 manual_approval에서 중지되었습니다. 승인 대기는 원래 차단되었음을 의미합니다.
가동 중단 중에 워크플로 정의 파일이 수정되었습니다. 플랫폼이 해시 불일치를 감지했으며 새 버전이 호환되는지 확실하지 않습니다.

수동 "단계부터 다시 시도"(언제든지 사용 가능)

워크플로우가 복구로 구성되었는지 여부에 관계없이 실행 세부 정보 페이지에는 항상 "실패한 단계에서 다시 시도" 버튼이 제공됩니다.

중단됨/실패한 실행을 엽니다.
실패/중단된 단계 옆에 있는 "이 단계에서 다시 시도"를 클릭하십시오.
이전 COMPLETED 단계의 결과가 재사용됩니다. 이 단계가 다시 실행되기 시작합니다.

단계가 멱등성이 아니더라도 수동으로 재시도할 수 있습니다. 왜냐하면 그때 인간으로서 의식적으로 "재실행할 가치가 있다"고 결정하기 때문입니다.

계속 실행 한도

시스템이 "무한 루프"에서 동일한 실행을 다시 시작하는 것을 방지합니다. 각 실행은 자동으로 최대 3번까지 계속 실행됩니다. 그래도 실패하면 중지하고 처리될 때까지 기다리십시오. Recovery.maxAutoResumeAttempts에서 (1-20)을 재정의할 수 있습니다.

감사

자동 연속이 수행될 때마다 감사 이벤트가 기록됩니다.

execution.auto_resume — 성공적으로 계속 실행됨
execution.auto_resume.skipped — 규칙에 따라 계속해서 달리면 안 됩니다.

관리자는 이 두 가지 event_type을 기준으로 감사 로그를 필터링하고 볼 수 있습니다.

실용적인 제안

순수 데이터 파이프라인(ASA 일일, RSS 요약): 전체 복구 + 멱등성, 자동으로 계속 실행되므로 안심하세요.
외부 부작용(공제, 메시지 전송, 주문 등)이 있는 경우: 자동 재개를 열지 마세요. 인간의 의사결정을 방해합니다.
주요 부작용 단계 앞에 manual_approval을 추가하세요. 승인 자체는 불연속 실행에 대한 "자연적인 차단 지점"입니다.

다음 단계

실행 모니터링 및 로깅 — INTERRUPTED 상태의 실행을 보는 방법
모범 사례 — 멱등성 주석/분할/모듈화에 대한 포괄적인 제안