런북 예시: 실패한 쓰기를 재시도하기 전 검토

런북 예시는 발생한 일을 기록하고 저장 대상을 확인하며, 쓰기를 재실행해도 되는지 결정할 담당자를 정하는 복구 절차를 보여줍니다. 응답이 없으면 저장 결과를 다시 읽어 확인할 때까지 부수 효과를 불확실한 상태로 취급하세요. 이 런북 예시는 “관찰되지 않음”, “이미 존재함”, “중복됨”을 구분하여 전송 실패가 자동으로 두 번째 쓰기로 이어지지 않도록 합니다.

작성: Ai Flowi · 게시일

사고 범위와 중단 조건 명시하기

이 절차는 알려진 워크시트에 문의 기록을 쓰는 워크플로우 하나를 다룹니다. 실패한 응답이나 응답 누락에서 시작하고, 재실행 결정에 저장 대상의 근거를 연결하거나 남은 불확실성을 대응 담당자에게 맡기는 것으로 끝납니다. 이 복구 기록은 사람의 검토를 지원하며 롤백, 자동 재시도, 정확히 한 번 전달을 구현하지 않습니다.

근거를 수집하는 동안 기존 발신 시스템의 제어 기능으로 영향을 받은 테스트 범위의 새 전달을 중단하세요. 이미 대기 중이거나 처리 중인 요청이 있는지 확인하세요. 다른 쓰기 작업이 같은 기록을 여전히 바꿀 수 있다면 그 불확실성을 기록하고 재실행 승인을 보류하세요. 이 절차는 영향을 받은 저장 대상과 제출한 이벤트 참조 정보를 식별할 수 있다는 전제에 따릅니다.

사고 기록 복사하기

역할 참조 정보와 민감 정보를 가린 근거 위치를 사용하세요. 인증 정보, 제공업체 오류 전문, 제출된 개인정보는 공유용 복구 메모와 분리하여 팀의 접근 제한 사고 관리 시스템에 보관하세요. 알 수 없는 필드는 명시적으로 채우세요. 비어 있는 응답 필드를 요청 거부로 해석하면 안 됩니다.

Incident reference:
Workflow and affected destination:
Detection time and timezone:
Responsible responder:
Last confirmed accepted event:
Sender pause confirmed / in-flight deliveries unresolved:
Affected event references and request versions:
Observed response status / response unavailable:
Read-back time, range and completeness:
Observed rows per event reference:
Approved field comparison: match / mismatch / unknown:
Side-effect classification: absent / present / duplicated / unresolved:
Stop condition encountered:
Reviewer and decision: hold / no replay / approved single replay:
Decision reason and request version:
Replay attempt reference, if authorized:
Post-decision read-back:
Closure evidence or unresolved assignment:

“마지막으로 수락이 확인된 이벤트”는 유용한 조사 기준점이지만 그 이후 이벤트가 실패했다는 증거는 아닙니다. 타임스탬프 순서는 기록 연결에 도움이 될 수 있어도 이벤트 대조를 대신할 수 없습니다. 이전 페이로드의 기존 행을 현재 페이로드의 성공적인 실행으로 착각하지 않도록 참조 정보와 요청 버전을 함께 보관하세요.

저장 대상을 변경하기 전에 근거 수집하기

  1. 발신 시스템의 시도 참조 정보, 제출된 이벤트 참조 정보, 확인 가능한 응답 상태를 기록하세요. “응답을 받지 못함”과 명시적 거부의 차이를 유지하세요.
  2. 영향을 받은 흐름이 사용한 스프레드시트와 워크시트를 정확히 확인하세요. 다른 탭을 성공적으로 읽어도 이번 쓰기의 근거가 되지 않습니다.
  3. 이벤트 참조 정보와 승인된 비교 필드를 포함하여 관련 범위 전체를 읽으세요. 스냅샷을 만든 시각과 페이지네이션, 잘림, 접근 제한으로 행이 숨겨질 가능성을 기록하세요.
  4. 각 참조 정보에 일치하는 행 수를 세세요. 각 일치 행을 제출된 버전 및 필드와 비교하세요. 개수만으로 오래되었거나 덮어쓴 데이터를 식별할 수는 없습니다.
  5. 지정된 검토자에게 결과를 분류하고 허용된 다음 조치를 기록하도록 요청하세요. 불확실한 사례는 보류하세요.

재실행 전에 첫 시도가 나중에 완료될 수 없다는 근거를 요구하세요. 요청이 아직 처리 중이거나 표시가 지연된다면 잠시 행이 없다는 사실만으로는 충분하지 않습니다. 해당 조건을 확인할 수 없다면 전달을 미해결로 유지하고 팀의 기존 절차에 따라 상위 담당자에게 넘기세요.

가상 전달 세 건 대조하기

다음 기록은 결정을 설명하기 위해서만 만든 가상 자료이며, 운영 로그나 테스트 결과가 아닙니다. 이 가상 상황의 워크시트 스냅샷은 발신 시스템을 일시 중지하고 검토자가 처리 중인 시도가 더 이상 없음을 확인한 후 생성합니다.

시도 기록과 전체 범위 재조회 결과 비교
전달발신 시스템 관찰 결과워크시트 관찰 결과검토 결정
enquiry-A, 버전 v1제출 후 응답 확인 불가일치 행 한 개, 승인된 모든 필드 일치재실행하지 않습니다. 응답이 없어도 쓰기 결과가 존재함을 기록합니다.
enquiry-B, 버전 v1응답 확인 불가, 발신 시스템에서 다시 시도함승인된 필드가 같은 일치 행 두 개보류합니다. 중복 검토를 맡기세요. 추가 쓰기로 중복을 해소할 수 없습니다.
enquiry-C, 버전 v1응답 확인 불가, 두 번째 시도 기록 없음영향을 받은 범위 전체에서 일치 행 없음지연 완료 가능성을 배제한 후에만 사람이 승인하는 단일 재실행의 후보가 됩니다.

검토자는 명시된 스냅샷 전제에 따라 enquiry-A를 존재함, enquiry-B를 중복됨, enquiry-C를 없음으로 표시합니다. 추가 쓰기 작업이나 읽지 않은 범위가 확인되면 enquiry-C는 미해결로 바뀝니다. 결정은 근거의 품질에 달려 있습니다. “일치 항목 0개”는 모든 상황에 적용되는 재시도 지시가 아닙니다.

enquiry-B의 두 행 참조 정보와 발신 시스템의 시도 참조 정보 두 개를 모두 보존하세요. 이 절차에서 어느 행도 삭제하지 마세요. 별도의 권한 있는 수정 절차에서 남길 행을 선택하고, 후속 작업도 두 번 일어났는지 조사해야 합니다. 스프레드시트 중복과 외부 작업 중복은 별개의 문제입니다.

읽기 전용 조사 단계 구성하기

상태: 문서화됨. 아래의 독립적인 Read Range 설정은 카탈로그에 문서화되어 있지만 Ai Flowi가 이 복구 절차를 운영 환경에서 테스트한 것은 아닙니다.

구성 예시이며, 기록된 테스트가 아닙니다

Workflow 작업 공간에서 Google 연결 설정에 따라 영향을 받은 시트에 접근할 수 있는 Google 계정을 연결하세요. 해당 제공업체의 요금은 사용자가 부담합니다.

전체 인터페이스는 Read Range 안내를 확인하세요. 가상 이벤트 참조 정보, 버전, 메시지를 포함하도록 range_name=RecoveryDemo!A:C를 설정하고, spreadsheet_id로 해당 스프레드시트를 식별하며, google_account로 허가된 계정을 선택하세요.

반환된 워크시트 스냅샷을 수동 비교용으로 보관하고, 민감 정보를 가린 행 참조 정보를 사고 기록에 첨부하세요. 읽기 작업은 시트를 잠그거나 다른 쓰기를 막지 않으며, 다른 범위의 완전성을 입증하거나 재실행하지도 않습니다. 재조회가 실패하면 중단하세요. 원래 쓰기의 결과는 여전히 알 수 없습니다.

한 번의 재실행 결정하고 검증하기

검토자가 enquiry-C를 승인하면 재실행할 원래 참조 정보, 요청 버전, 가상 필드를 정확히 기록하세요. 페이로드를 몰래 바꾸지 말고, 알려진 구성 또는 접근 문제를 먼저 해결하세요. 두 전달 시도를 구분할 수 있도록 재실행에 별도의 시도 참조 정보를 기록하세요.

승인된 한 번의 시도 후 다시 읽어 개수와 필드를 모두 비교하세요. 올바른 행 한 개는 그 시점에 관찰된 저장 대상 상태를 입증합니다. 결과가 없거나, 불일치하거나, 중복되면 사건은 계속 미해결 상태입니다. 원하는 응답이 나올 때까지 계속 재실행하지 마세요. 이번 쓰기가 다른 시스템의 작업을 시작한다면 종결 전에 해당 시스템의 근거도 확보하세요.

런북에서 기록된 플랫폼 제약을 어떻게 적용하나요?

재실행 결정을 제한하는 후속 오류 및 동시 실행 제약의 기록은 웹훅 오류 안내를 확인하세요.

enquiry-C의 유용한 복구 메모는 다음과 같습니다. “원래 시도의 응답 확인 불가. 영향을 받은 범위 전체 확인. v1 행 없음. 발신 시스템 일시 중지 및 지연 완료 가능성 배제. 검토자가 변경 없는 v1 페이로드의 한 번 재실행을 승인함.” 재실행 후 새 스냅샷을 첨부하고 관찰된 일치 행 수를 기록하세요. 이렇게 작성한 메모는 권한을 한 버전과 한 시도에 연결하여, 이벤트를 반복 전송할 수 있는 재사용 가능한 승인으로 남지 않게 합니다.

메모를 작성하는 동안 원래 응답이 나타나면 근거에 추가하고 분류를 재검토하세요. 사고 이력에서 앞서 존재했던 불확실성을 지우지 마세요. 응답과 워크시트 스냅샷이 상충한다면 같은 저장 대상과 시도를 가리키는지 확인하세요. 다른 실행의 응답은 이 사고를 해결할 수 없습니다. 상충하는 이유가 설명될 때까지 재실행 결정을 보류하세요.

관련 자료: AIOps란 무엇인가: 알림 상관관계와 한계.

근거로 종결하거나 예외 담당자 유지하기

종결에는 날짜가 있는 재조회 결과, 검토한 요청 버전, 선택한 조치, 검토자 참조 정보가 필요합니다. 미해결 기록에는 지정된 대응 담당자와 다음에 요청할 근거가 명확히 있어야 합니다. 저장 대상을 확인할 수 없거나, 요청을 연결할 수 없거나, 지연 완료 가능성이 남아 있다면 이 절차를 사용하지 마세요. 이런 조건에서는 재실행 전에 상위 담당자에게 넘겨야 합니다.