결제 장애 첫 1시간과 근무 교대 인수인계

결제 장애 대응에서 가장 위험한 순간은 때로 복구 이후에 찾아옵니다. 당직자가 결제 성공을 확인하고 팀이 한숨 돌리는 사이, 결과를 알 수 없는 거래 목록은 메신저 대화 속으로 사라집니다. 그 결과 기술적 가용성은 자금에 대한 통제보다 먼저 돌아옵니다. 첫 1시간 계획은 담당자에게 명확히 넘길 때까지 두 작업 흐름을 모두 유지해야 합니다.

첫 10분: 지휘 체계를 정하고 범위를 파악하라

내부 기준에 따라 장애를 선언하고, 단일 조율 채널을 만들고, 지휘자를 지정하십시오. 기술 복구, 재무 대사, 사용자 공지를 각각 누가 맡을지도 따로 정합니다. 작은 팀에서는 한 사람이 여러 역할을 겸할 수 있지만, 책임은 명시되어야 합니다. Google SRE의 접근법은 조율, 기술 조치, 커뮤니케이션을 분리합니다. 여러 전문가가 동시에 움직이기 시작할 때 유용한 기준이 됩니다.

처음 확인된 증상의 시각, 영향을 받은 결제수단, 계정, 통화, 결제 단계를 기록하십시오. 최근 변경 사항, 자체 오류, PG사나 결제대행사에서 얻을 수 있는 정보를 확인합니다. 한 경로의 문제만 입증되었다면 플랫폼 전체가 다운되었다고 공지하지 마십시오. 동시에 편리한 테스트 요청 하나가 통과했다는 이유만으로 범위를 좁혀서도 안 됩니다.

확인된 영향과 다음 업데이트 시각을 담은 첫 공지를 바로 준비하십시오. 원인이 완전히 밝혀질 때까지 미루지 마십시오. 고객 공지에 대한 승인 절차는 미리 정해 두어, 기술 담당자가 공개적인 약속을 우연히 결정하는 일이 없도록 해야 합니다.

10–20분: 피해 확산을 멈춰라

새로 들어오는 요청과 이미 전송되었지만 결과를 모르는 거래를 분리하십시오. 필요하면 사전에 합의된 계획에 따라 영향받은 흐름을 제한합니다. 대량 재승인, 환불, 지급을 실행하지 마십시오. 모든 금융 조치는 확인된 상태와 정해진 권한에 근거해야 합니다. 예비 경로는 적합한 거래에만, 그리고 이미 허용된 경우에만 사용하십시오.

재시작 전에 대기열과 실행 중인 작업이 어떻게 될지 확인하십시오. 불필요한 개인정보 없이 거래 식별자와 기술적 증거를 보존합니다. 무단 접근의 징후가 있으면 즉시 보안 책임자를 참여시키고 해당 절차를 적용하십시오. 일반적인 가용성 대응 계획만으로는 부족할 수 있습니다.

20–40분: 결과 미확정 거래 목록으로 작업하라

가상의 장애에서 12건의 거래가 PG사로 전송되었지만 최종 결과가 아직 확인되지 않았다고 합시다. 건마다 내부 번호, PG사 참조 번호, 금액과 통화, 마지막으로 신뢰할 수 있는 상태, 다음 단계, 담당자를 기록하십시오. 사용 가능한 API, 서명된 웹훅 알림, 정산 리포트를 해당 결제수단의 규칙에 따라 확인합니다. 고객이 보낸 스크린샷은 조사에 도움이 되지만, 자동으로 재지급을 실행하는 근거가 되어서는 안 됩니다.

한 사람은 처리 복구를 맡고, 다른 사람은 이 12건의 대사를 진행합니다. 고객이 더 이상 문의하지 않는다는 이유로 목록에서 기록을 지우지 마십시오. 예외 건은 문의가 오래되었다고 닫히는 것이 아니라, 결과가 확인되고 다음 조치가 완료되었을 때 닫힙니다.

PagerDuty는 장애 타임라인을 기록하는 사람의 역할을 따로 둡니다. 결제팀에서는 이 기록을 의사결정 중심으로 남기는 것이 유용합니다. 누가 흐름을 멈췄는지, 무엇을 바꿨는지, 어떤 데이터를 근거로 했는지, 어떤 결과를 얻었는지입니다. 여러 차례 개입한 뒤에는 바로 이 순서가 효과 있던 조치와 우연의 일치를 구분하게 해 줍니다.

대상에 따라 다른 내용을 전달하라

내부 업데이트 예시: "10:25 UTC. 경로 A의 승인 확인이 지연 중. 신규 전송은 일시 중지. 결과 미확정 거래 12건 확인 중. 기술 책임자는 대기열을 점검하고, 재무 담당자는 기록을 대사하는 중. 다음 업데이트는 10:40 UTC." 숫자와 시각은 예시이며, 실제 공지에는 검증된 데이터만 사용하십시오.

고객 공지 예시: "일부 결제의 승인 확인이 지연되고 있습니다. 주문이 처리 중으로 표시되면 결제를 다시 시도하지 마십시오. 영향을 받은 거래를 확인하고 있습니다. 다음 안내는 10:40 UTC에 게시하겠습니다." 이 문구는 처리 상태를 실제로 볼 수 있고, 안내한 행동이 해당 결제수단에서 안전한 경우에만 적합합니다. 대사가 끝나지 않았다면 이중 결제가 없다고 약속하지 마십시오.

Atlassian은 주 채널을 통한 정기 업데이트를 권장합니다. 명확한 업데이트 주기를 정하고, 새로운 원인이 밝혀지지 않았더라도 지키십시오. 확인된 영향과 가설을 구분하고, 고객의 결제 정보, 내부 기밀, 파트너에 대한 확인되지 않은 비난은 공개하지 마십시오.

40–60분: 복구를 검증하고 남은 작업을 인계하라

• 허용된 신규 거래가 예상 단계를 정상적으로 통과한다.
• 대기열이 실제로 줄어들고 있으며, 오래된 항목에 담당자가 없는 상태로 남아 있지 않다.
• 결과 미확정 거래가 정리되었거나 구체적인 담당자에게 배정되었다.
• 중복 처리, 누락, 원장 불일치를 확인했다.
• 고객 지원팀이 현재 상태와 약속한 다음 업데이트 시각을 알고 있다.

결제 수납의 복구와 재무 대사의 완료는 서로 다른 시점에 이루어질 수 있습니다. 이를 분명히 알리십시오. 장애가 계속된다면 다음 근무조에 결정 사항, 남은 리스크, 연락처를 인계합니다. 안정화 후에는 원인 분석과 구체적인 개선 조치를 정하고, 아직 종결되지 않은 고객 건마다 담당자를 유지하십시오.

종료 시점은 하나가 아니라 둘이다

기술 복구에는 검증 가능한 조건을 정하십시오. 허용된 신규 거래가 통과하고, 지연이 정한 범위 안에 있으며, 대기열이 줄어드는 것입니다. 재무 종료에는 다른 증거가 필요합니다. 영향받은 시도를 모두 찾았고, 중복과 누락을 정리했으며, 조정에 합의했고, 고객 건마다 결론이 났다는 것입니다. 이 표시는 서로 다른 날에 나타날 수 있습니다. 녹색 상태 하나를 위해 팀이 남은 작업을 숨기게 만들지 마십시오.

장애 중에는 오류 수만이 아니라 금전적 노출도 계산하십시오. 가상의 미확정 거래 12건이 각 10유로인 경우와 각 10,000유로인 경우는 필요한 관심의 수준이 다릅니다. 금액은 통화와 채무 유형별로 묶고, 환산 규칙 없이 보기 좋은 숫자 하나로 합산하지 마십시오. 이미 상품이 출고되었거나 지급이 약속된 거래는 따로 표시하십시오.

이해도를 확인하는 근무 교대 인수인계

인수받는 당직자에게 임의로 고른 미결 건 두 개의 다음 단계를 설명해 보게 하십시오. 이전 근무조의 구두 추측이 필요하다면 카드가 불완전한 것입니다. 건마다 마지막으로 확인된 상태, 출처, 허용되는 조치, 에스컬레이션 조건이 있어야 합니다. "PG사 응답 대기 중"이라는 메모로는 부족합니다. 정확히 무엇을 기다리며, 언제 다시 확인하는가?

안정화 후에는 실제로 발견된 피해를 기준으로 개선 과제를 고르십시오. 특정 유형의 이벤트가 유실되었다면 "모니터링 개선"이라는 과제는 너무 넓습니다. 놓친 신호, 탐지 규칙, 그리고 문제가 더 이상 눈에 띄지 않고 지나가지 않는다는 것을 보여 줄 검증을 구체적으로 적는 편이 낫습니다. 사후 분석은 다음 당직자가 더 신뢰할 수 있는 시스템과 더 짧은 해결 경로를 얻을 때 가치가 있습니다.