장애 후 첫 화면이 다시 열린다고 모든 기능의 처리가 끝난 것은 아닐 수 있습니다. 로그인은 가능해졌지만 이전 요청 내역이 늦게 반영되는 상황이라면 이용자가 할 수 있는 일과 기다려야 할 일을 나누어 설명해야 합니다. 복구 완료라는 한 문장보다 확인된 기능, 정상화 시각, 남은 제한을 함께 알리는 편이 정확합니다.
공지에 넣는 복구 범위는 실제 시험 결과와 맞춰 정합니다. 화면 접속만 확인한 상태에서 신청부터 확인 메시지 수신까지 모두 정상이라고 넓혀 쓰지 않습니다. 일부 기능은 정상화됐고 다른 기능은 확인 중이라면 그 차이를 표시하세요. 아직 원인이 확정되지 않은 오류에 대해서는 추측한 이유를 사실처럼 적지 않고 확인된 영향부터 안내합니다.
장애 중 제출한 요청의 처리 여부를 확인할 경로도 중요합니다. 이용자가 결과를 모르고 같은 신청이나 결제를 다시 시도하면 중복 문제가 생길 수 있습니다. 내역을 확인하는 방법과 아직 확인되지 않는 경우의 문의 창구를 알려 주세요. 재처리가 필요한 대상이 있다면 누구에게 해당하는지 구체적으로 적고 모든 사용자에게 동일한 행동을 요구하지 않습니다.
복구 뒤에는 공지에서 정상이라고 한 흐름을 다시 따라가 보고 같은 오류 신고가 이어지는지 살펴봅니다. 문제가 남아 있다면 완료 문구를 유지한 채 댓글로만 정정하지 말고 본문 상태를 갱신합니다. 최초 발생, 일부 복구, 추가 조치의 시각을 구분해 남기면 독자가 오래된 내용을 현재 상황으로 읽는 일을 줄일 수 있습니다. 확인된 범위를 넘어선 안심 문구는 넣지 않습니다.
복구 공지를 작성하는 담당자는 검증한 기능과 검증 결과를 연결한 목록을 받아야 합니다. 가상의 장애에서 로그인과 신규 신청은 정상인데 기존 내역 조회가 지연된다면 세 기능의 상태를 나누어 표시합니다. 이용자는 신규 요청을 시작할지, 기존 요청을 기다릴지 서로 다른 결정을 내리므로 전체 서비스라는 큰 범위로 묶지 않는 것이 좋습니다.
정상화 시각도 조치 완료 시각과 구별합니다. 서버 설정을 바꾼 때와 이용 흐름을 끝까지 확인한 때가 다르면 어느 시각을 공지에 쓰는지 정합니다. 이전 신청의 누락 여부를 아직 조사 중이라면 새 신청이 정상이라는 결과만으로 과거 내역도 모두 안전하다고 말하지 않습니다. 추가 확인이 끝나면 남아 있던 제한 항목을 갱신하고 그동안 제시한 임시 우회 방법이 계속 필요한지도 정리합니다.