장애 대응 연락망과 역할을 미리 정하는 이유

누가 받는지와 누가 결정하는지를 구분합니다

서비스에 문제가 생겼을 때 처음 연락받은 사람이 모든 조치를 결정할 수 있는 것은 아닙니다. 문의를 접수하는 사람, 기술적으로 조사하는 사람, 서비스를 중단하거나 복구를 승인하는 사람, 고객에게 알리는 사람을 구분해야 합니다. 작은 팀에서는 한 사람이 여러 역할을 맡더라도 역할 자체는 적어 두는 편이 좋습니다.

외부 서비스 문제가 원인인 경우에는 해당 업체에 문의할 계정과 담당 경로도 필요합니다. 누구나 같은 문의를 중복해서 보내거나, 서로 다른 결정을 실행하지 않도록 상황을 정리하는 책임자를 정합니다.

연락망에는 이름과 연락처 외에 맡은 역할, 대체 담당자, 접근 가능한 시스템을 포함합니다. 담당자가 바뀌면 갱신할 책임도 있어야 문서가 실제로 쓸 수 있는 상태로 남습니다.

영향과 긴급도를 같은 기준으로 설명합니다

“긴급합니다”라는 표현만으로는 어떤 대응이 필요한지 판단하기 어렵습니다. 전체 사용자가 접근할 수 없는지, 특정 기능만 실패하는지, 일부 데이터가 잘못 보이는지처럼 영향 범위를 설명해야 합니다. 처음에는 원인을 단정하기보다 관찰한 사실을 기록합니다.

접수 양식에는 발생 시각, 영향을 받는 기능, 재현 여부, 사용한 버전, 확인한 우회 방법을 넣을 수 있습니다. 개인정보나 비밀정보는 공개 대화에 붙이지 않고 필요한 경로로 다룹니다.

긴급도에 따른 연락 경로와 지원 시간은 실제 합의한 범위에 맞춰 정합니다. 접수 확인까지의 목표 시간, 조사 시작, 복구 예상은 서로 다른 값입니다. 아직 모르는 복구 시간을 확정된 약속처럼 전달하지 않도록 표현도 구분합니다.

조치와 고객 안내가 같은 사실을 보게 합니다

조사 중에는 확인한 사실, 가설, 실행한 조치를 구분해 시간순으로 남깁니다. 설정을 바꾸거나 배포를 되돌렸다면 누가 무엇을 언제 했는지 적어야 이후 결과를 해석할 수 있습니다. 동시에 여러 변경을 진행하면 어떤 조치가 영향을 주었는지 찾기 어려워질 수 있습니다.

고객 안내에는 현재 영향, 사용자가 할 수 있는 일, 다음 안내 시점을 담습니다. 원인이 확정되지 않았다면 조사 중이라는 사실을 그대로 전달합니다. 기술 용어를 나열하기보다 사용자의 업무에 어떤 제약이 있는지 설명하는 편이 도움이 됩니다.

복구 여부는 오류 수치뿐 아니라 실제 사용자 흐름으로 확인합니다. 접속이 돌아왔더라도 실패한 작업이나 지연된 처리가 남아 있을 수 있으므로 후속 확인 범위를 정해 두세요.

평소에 연락과 복구 절차를 점검합니다

연락망이 있어도 대체 담당자가 접근 권한이 없거나 외부 서비스 계정을 찾을 수 없으면 조치가 늦어집니다. 정기적으로 연락 경로와 계정 접근을 확인하고, 대표 상황을 가정해 누구에게 어떤 정보를 전달할지 연습해 보세요.

복구 연습은 실제 고객 데이터에 영향을 주지 않는 환경과 범위에서 진행합니다. 준비한 절차를 다른 담당자가 따라 할 수 있는지, 누락된 승인이나 도구가 없는지 확인합니다. 문서의 단계가 성공한 환경과 날짜도 기록합니다.

장애가 끝난 뒤에는 원인과 영향을 정리하고 재발 방지 작업에 담당자와 완료 기준을 붙입니다. 연락망 개선, 경보 보완, 테스트 추가처럼 실행할 수 있는 항목으로 남겨야 다음 대응에 반영됩니다.