Skip to main content
모든 개선은 아무리 자신 있게 제안된 것이라도 프로덕션에 닿기 전에 승인을 거칩니다. 게이트는 Flow마다 정할 수 있습니다.

승인 큐

Reliable → Approvals가 워크스페이스 전체의 대기 중인 승인을 모아 보여줍니다.
  • 승인 대상 개선 후보, diff, 시뮬레이션 결과.
  • 요청자 제출한 사람이나 프로세스.
  • 승인 가능자이 Flow에서 자격이 있는 리뷰어.
  • 대기 시간 얼마나 기다렸는지.
기다린 시간, Flow, 변경 크기로 정렬합니다.

승인 뷰

항목마다 이렇게 보여줍니다.
  • 요약 변경을 설명하는 한 줄.
  • Diff Flow 설정에서 무엇이 바뀌는지 줄 단위로.
  • 시뮬레이션 데이터셋에 견준 before/after. 통과율, 회귀, 비용 델타.
  • 근거이 개선을 촉발한 근본 원인 노트.
  • 이력 비슷한 지난 개선과 그 결과.
  • 롤백 계획 이걸 롤백하면 무슨 일이 벌어지는지.
승인하거나, 이유와 함께 거부하거나, 변경을 요청합니다.

게이트 설정

Flow마다 고릅니다.
  • Auto-approve 사람 게이트 없음. 시뮬레이션 결과가 탄탄한 저위험 레버(룰, 사소한 프롬프트 다듬기)에만 권합니다.
  • 단일 승인 자격 있는 리뷰어 한 명.
  • Multi-sign 서로 다른 리뷰어 둘 이상.
  • 역할 제한 Owner나 Manager만 승인 가능.
Flow settings → Approvals에서 정합니다.

승인 라우팅

바깥 시스템과 엮어 쓰는 흐름이라면 이렇게 합니다.
  • Slack 승인 승인이 Approve/Reject 버튼이 달린 Slack 카드로 뜹니다. 서명된 액션입니다.
  • 이메일 승인 일회용 링크.
  • 웹훅 승인 여러분의 리뷰 시스템으로 POST 하고, 판정을 다시 POST 받습니다.
Flow settings → Approval webhook에서 라우팅을 정합니다.

승인 SLA

Flow마다 SLA를 겁니다. N 시간이 지나면 승인이 자동으로 위로 올라가거나(리뷰어를 더 부름) 자동으로 실패합니다(거부로 표시). 흔한 방식은 이렇습니다.
  • 인원이 넉넉한 팀은 근무 시간에 1시간 SLA.
  • 덜 급한 Flow는 24시간 SLA.
  • 오래된 건 7일 뒤 자동 거부(새 시뮬레이션 결과를 붙여 다시 내게 함).

배포 단계

승인되면 배포 방법이 셋입니다.
  • Draft에 적용 diff가 Draft에 얹히고, 준비되면 여러분(또는 자동화)이 배포합니다.
  • 즉시 배포 승인되자마자 변경이 프로덕션으로 갑니다. 수동 배포 단계를 건너뜁니다.
  • Canary 롤아웃 변경을 먼저 프로덕션 트래픽의 일부에만 보냅니다(아래 참고).
개선마다(또는 Flow 기본값으로) 정합니다.

Canary 롤아웃

위험이 큰 개선에는 이렇게 합니다.
  1. 배포하되 새 버전에 트래픽의 N% 만 보냅니다.
  2. Canary 트래픽에서 24~72시간 동안 신호를 지켜봅니다.
  3. 깨끗하면 100% 로 넓힙니다. 신호가 걸리면 자동으로 롤백합니다.
퍼센트는 1% → 5% → 25% → 100% 로 올리는 게 흔합니다. 한 사용자가 늘 같은 버전에 닿도록 스코프 키(사용자, 테넌트)로 라우팅합니다. 왔다 갔다 하는 걸 막아 줍니다.

롤백

배포된 개선은 한 번 눌러 롤백합니다(롤백 참고). 롤백은 한 번에 전부 되돌리는 방식이라, 일부만 남는 일이 없습니다. 승인자가 롤백을 미리 허가해 둘 수도 있습니다(지정한 신호가 걸리면 자동 롤백). 잘못돼도 사람이 손댈 필요가 없죠.

감사

모든 승인, 거부, 변경 요청, 배포가 행위자, 시각, IP, 코멘트와 함께 기록됩니다. 컴플라이언스 리뷰용으로 내보낼 수 있습니다.