진행 중 보고

보고를 받는 사람은 기술적 사실을 알고 싶은 것이 아닙니다. 판단을 해야 합니다. 고객에게 안내할지, 다른 팀에 지원을 요청할지, 대체 수단을 가동할지, 임원에게 보고할지를 정해야 합니다.

그래서 보고에 필요한 것은 스택트레이스가 아니라 영향 범위와 예상 시간, 그리고 지금 무엇을 하고 있는지입니다.

기술 상세는 종료 후 원인 규명 보고서에 씁니다. 진행 중에는 판단에 필요한 것만 보냅니다.

Part 1에서 첫 보고 형식을 봤습니다. 이후 보고도 같은 뼈대를 유지합니다. 형식이 같으면 받는 사람이 변화만 빠르게 읽을 수 있습니다.

장애 대응의 대부분은 모르는 상태에서 진행됩니다. 이때의 소통 방식이 신뢰를 가릅니다.

"원인 파악 중입니다"만 반복하면 상대는 아무 진전이 없다고 느낍니다. 실제로는 여러 가능성을 배제하며 나아가고 있는데도 그렇습니다.

주기를 정해 알리지 않으면 상대가 계속 물어봅니다. 그 응대에 시간을 뺏기고, 정작 대응이 늦어집니다.

다음 보고 시각을 먼저 말해 두면 그 사이에는 재촉이 줄어듭니다. 상대도 언제 정보를 받을지 알아야 자기 일정을 잡을 수 있습니다.

• 초기에는 15분에서 30분 간격이 적당합니다. 상황이 안정되면 1시간으로 늘립니다.
• 약속한 시각에는 진전이 없어도 보고합니다. "진전 없음, 계속 확인 중"도 정보입니다. 침묵이 가장 나쁩니다.
• 중요한 사실을 확인하면 주기와 무관하게 즉시 알립니다. 특히 영향 범위가 커졌을 때입니다.
• 복구되면 즉시 알립니다. 이때 원인이 규명되지 않았다면 그 사실도 함께 씁니다.

고객사 시스템을 담당하면 보고 대상이 내부 상사만이 아닙니다. 그리고 고객사 담당자도 자기 조직에 보고해야 합니다.

이 구조를 이해하면 보고 방식이 달라집니다. 그 담당자가 그대로 인용할 수 있는 문장을 주는 것이 실질적인 도움입니다. 기술 용어로만 쓰면 담당자가 번역하다 내용이 왜곡됩니다.

복구는 됐는데 원인은 모르는 상태로 종료하는 일이 실제로 있습니다. 재기동으로 풀렸거나, 증상이 저절로 사라졌거나, 증거가 남지 않았을 때입니다.

이때 원인을 그럴듯하게 지어내서 쓰는 것이 가장 나쁜 선택입니다. 재발하면 그 보고서 때문에 엉뚱한 대응을 하게 됩니다.

정직하게 쓰되, 다음에는 잡을 수 있도록 무엇을 준비했는지를 함께 씁니다. 이러면 미규명 보고도 의미 있는 문서가 됩니다.