장애가 발생하면 사람들은 자신에게 영향이 있는지, 무엇을 해야 하는지, 언제 다음 소식을 받을 수 있는지 알고 싶어 합니다. 장애 커뮤니케이션 발표 자료는 팀이 이 질문에 일관되게 답하도록 돕습니다. 고객이나 경영진이 엔지니어의 장애 대응 채팅을 직접 해석하게 해서는 안 됩니다.
가상의 첨부파일 업로드 서비스가 보낸 첫 고객 안내를 보겠습니다. 아래의 시각, 관측 내용, 메시지는 모두 설명을 위해 만든 것이며 Presenti의 실제 장애가 아닙니다.
10:15 UTC — 첨부파일 업로드 오류 조사 중
EU 리전에 호스팅된 일부 작업 공간에서 새 첨부파일 업로드 오류가 발생해 조사하고 있습니다. 오류는 10:05 UTC에 처음 관측했으며 전체 영향 범위를 확인하고 있습니다. 다음 안내는 10:30 UTC까지 게시하겠습니다.
이 메시지는 원인이나 복구 시각을 지어내지 않고, 영향을 받은 작업과 확인된 범위, 다음 안내 시각을 말합니다. 브리핑도 같은 확인된 사실을 바탕으로 구성하세요. 메모를 승인받은 뒤에는 Presenti로 텍스트를 편집 가능한 프레젠테이션으로 바꿔 이해관계자 브리핑에 사용할 수 있습니다. Presenti가 장애를 모니터링하거나 복구를 검증하거나 상태 페이지에 공지를 올려 주는 것은 아닙니다.
여러 메시지의 기준이 되는 사실 기록을 하나로 유지하세요
슬라이드를 만들기 전에 공지 작성자 모두가 참고할 짧은 장애 기록을 준비하세요. 관측에는 시각과 출처가 필요하고, 가설은 가설이라고 표시해야 합니다. 근거가 생기기 전까지 모르는 것은 모르는 상태로 남겨 두세요.
가상 장애의 10:18 UTC 기록은 다음과 같을 수 있습니다.
| 상태 | 내용 | 근거 또는 다음 조치 |
|---|---|---|
| 확인됨 | EU 리전의 일부 작업 공간에서 새 첨부파일 업로드 오류가 발생함 | 게이트웨이 오류 기록과 영향받은 작업 공간의 업로드 실패 테스트. 첫 관측은 10:05 UTC |
| 확인됨, 범위 제한 | 지금까지 수행한 점검에서는 기존 파일 다운로드가 성공함 | 기록된 테스트 결과. 모든 고객의 모든 다운로드에 영향이 없다는 증거는 아님 |
| 미확인 | 정확한 장애 시작 시각과 전체 영향 작업 공간 수 | 운영팀이 이전 기록과 실패 요청의 범위를 조사 중 |
| 가설 | 라우팅 변경이 관련됐을 수 있음 | 서비스팀이 변경 기록과 실패를 비교 중. 시점이 겹친다고 인과관계가 확정되는 것은 아님 |
| 미확인 | 시간 초과된 업로드가 모두 첨부파일 저장 전에 실패했는지 여부 | 요청 결과를 대조해야 함. 고객에게 데이터 손실이 없었다거나 아무것도 저장되지 않았다고 말하지 않음 |
정확한 시작 시각과 처음 관측한 시각은 구분하세요. 이 사례에서는 “10:05에 오류를 처음 관측했습니다”라고 말할 수 있습니다. “장애는 10:05에 시작됐습니다”라고 할 수는 없습니다. 그래야 나중에 더 이른 실패 로그가 발견돼도 확정적으로 한 말을 되돌리는 일을 피할 수 있습니다.
프레젠테이션은 이 기록의 특정 시점 사본이지, 또 다른 기준 기록이 아닙니다. 내부 브리핑에 “10:18 UTC 기준”을 표시하세요. 한 시간 뒤 전달받은 사람도 자료가 얼마나 오래됐는지 알 수 있어야 합니다.
대상별로 사용할 수 있는 정보를 전달하세요
Google의 장애 대응 안내는 지휘, 운영, 커뮤니케이션 책임을 구분합니다. 고객, 지원팀, 엔지니어, 경영진에게 필요한 정보도 다르다고 설명합니다. 이 차이에 맞춰 강조점을 바꾸되 사실을 바꾸지는 마세요.
| 대상 | 주요 질문 | 안내에 담을 내용 |
|---|---|---|
| 고객 | 내 작업을 할 수 있나? 무엇을 해야 하나? | 영향 기능과 범위, 확인된 조치 또는 우회 방법, 현재 상태, 다음 안내 시각 |
| 고객지원팀 | 일관되게 답하고 유용한 제보를 어떻게 전달하나? | 승인된 공지, 식별할 증상, 약속하면 안 되는 내용, 요청할 진단 정보 |
| 대응 담당자 | 무엇을 알고 있고 무엇을 시험하며 누가 맡고 있나? | 근거, 가설, 진행 조치, 담당자, 의존 관계, 남은 기술적 결정 |
| 경영진 | 영향은 무엇이며 내가 결정할 일이 있나? | 확인된 고객 영향, 아직 모르는 규모, 대응 책임, 자원·커뮤니케이션 결정, 다음 브리핑 시각 |
고객 공지에는 대개 라우팅에 대한 가설이 필요하지 않지만 대응팀에는 필요합니다. 경영진에게는 작업 공간 수를 아직 조사 중이라고 알려야 합니다. 대략 추측한 수를 넣으면 누군가 슬라이드를 전달하는 순간 공식 숫자로 굳어질 수 있습니다.
동일한 가상 상황의 10:18 내부 경영진 브리핑은 이렇게 쓸 수 있습니다.
EU 리전에 호스팅된 일부 작업 공간에서 새 첨부파일 업로드가 실패하고 있습니다. 영향받은 작업 공간 수와 정확한 시작 시각은 확인되지 않았습니다. 서비스팀이 조사 중이며 장애 지휘자가 대응 결정을 맡고 커뮤니케이션 담당자가 고객·지원팀 안내를 조율합니다. 외부에 안내하도록 승인된 복구 예상 시각은 없습니다. 다음 고객 안내는 10:30 UTC까지입니다. 현재 추가로 요청하는 경영진 결정은 없습니다.
지원팀에는 별도 지침을 덧붙이세요. 정상적인 지원 채널로 작업 공간 식별자, 대략적인 UTC 시각, 화면에 표시된 오류 메시지를 요청합니다. 공개 상태 페이지에 사적인 파일이나 인증 정보를 올려 달라고 하면 안 됩니다. 확인된 우회 방법이 없다면 확인되지 않은 조치를 안내하지 말고 없다고 밝히세요.
장애 진행과 안내 진행을 별도 사건으로 표시하세요
운영 조치와 이를 알리는 메시지는 서로 다른 기록입니다. 10:42에 완화 조치를 적용했다고 고객에게 10:42에 알렸거나 복구를 이미 검증했다는 뜻은 아닙니다. 두 종류의 사건을 모두 브리핑 타임라인에 넣으세요.
| 시각 | 유형 | 기록 내용 |
|---|---|---|
| 10:05 | 관측 | 업로드 오류를 처음 관측. 정확한 시작 시각은 미확인 |
| 10:12 | 대응 | 장애를 선언하고 지휘자와 커뮤니케이션 담당자를 지정 |
| 10:15 | 공개 안내 | 조사 중임을 알리고 10:30까지 다음 안내 약속 |
| 10:30 | 공개 안내 | 복구 미확인, 조사 지속. 다음 안내는 10:50까지 |
| 10:42 | 대응 | 완화 조치 적용. 효과는 아직 확인해야 함 |
| 10:50 | 공개 안내 | 최근 점검에서 개선 확인, 모니터링 중. 다음 안내는 11:15까지 |
| 11:15 | 공개 안내 | 합의한 복구 점검을 마친 뒤 업로드 가용성 복구를 선언. 미해결 고객 문제는 지원 경로 유지 |
이 간격은 예시이지 보편적인 장애 정책이 아닙니다. 대응팀이 실제로 지킬 수 있는 주기를 정하고 상황에 따라 더 짧게 안내하세요. 약속한 시각 전에 의미 있는 변화가 생기면 먼저 알립니다.
다음 안내를 약속하는 것은 복구를 약속하는 것과 다릅니다. 근거와 승인이 없다면 “10:50까지 복구” 대신 “다음 안내는 10:50 UTC까지”라고 쓰세요. 조사에서 새 결론이 나오지 않아도 안내할 책임은 남습니다.
상황이 바뀌어도 사실에 맞는 상태 메시지를 쓰세요
첫 안내는 문제를 공개 기록에 남깁니다. 다음 메시지들은 잠정적인 근거를 확정 사실로 바꾸지 않으면서 같은 가상 장애의 진행을 전하는 예시입니다.
10:30: 조사가 계속되는 경우
10:30 UTC — 조사 계속 중
EU 리전에 호스팅된 일부 작업 공간의 첨부파일 업로드 오류를 계속 조사하고 있습니다. 확정된 복구 시각이나 확인된 우회 방법은 아직 없습니다. 다음 안내는 10:50 UTC까지 게시하겠습니다.
해결 소식이 없어도 유용한 안내입니다. 장애가 계속되고 있음을 확인해 주고, 앞서 약속한 안내 시각을 말없이 넘기지 않게 합니다. “엔지니어들이 밤낮없이 노력하고 있습니다” 같은 문장을 채우거나 검증되지 않은 원인을 반복하지 마세요.
10:50: 개선 상태를 확인하는 경우
10:50 UTC — 복구 상태 모니터링 중
완화 조치를 적용했으며 최근 점검에서 해당 리전의 첨부파일 업로드가 다시 성공하는 것을 확인했습니다. 서비스 복구를 선언하기 전에 업로드 결과를 모니터링하고 있습니다. 여전히 업로드 오류가 발생하면 작업 공간 식별자와 대략적인 발생 시각을 지원팀에 알려 주세요. 11:15 UTC까지 이 페이지에 다음 안내를 게시하겠습니다.
“점검에서 개선을 확인했다”는 “모두 정상화됐다”보다 범위가 좁습니다. 그 경계를 유지하세요. 그래프가 정상으로 돌아왔다고 이전 시도의 결과가 모두 해결되거나 모든 고객 경로가 복구됐다는 뜻은 아닙니다.
11:15: 무엇이 복구됐는지 설명하는 경우
11:15 UTC — 첨부파일 업로드 가용성 복구
해당 리전에서 첨부파일 업로드가 정상 작동하고 있습니다. 복구 관측 기간 동안 업로드 결과가 서비스의 정상 범위를 유지했고, 합의한 업로드 점검도 통과했습니다. 앞선 업로드에 오류가 표시됐거나 결과가 불분명하다면 다시 시도하기 전에 첨부파일 목록을 확인해 주세요. 문제가 계속되면 지원팀으로 문의해 주세요.
이 마지막 메시지는 가상의 팀이 해당 점검을 마치고 고객 지침도 서비스에 맞는지 확인했다는 전제입니다. 그런 근거가 생기기 전에 실제 장애 공지로 복사하면 안 됩니다. 원인을 확정하거나 모든 영향 고객 수를 밝히거나 데이터 손실에 대해 포괄적으로 단정하는 메시지도 아닙니다.
직접 작성할 때는 기능, 범위, 관측된 증상, 근거가 있는 상태, 고객 행동, 다음 안내 시각을 실제 상황에 맞게 바꾸세요. 의미를 만드는 것은 이 정보들입니다. 서비스 이름만 바꾸고 근거 없는 복구 문구를 남겨 두는 것은 안전한 활용이 아닙니다.
승인 책임과 다음 안내를 브리핑에 표시하세요
커뮤니케이션 담당자에게는 완성된 문장만 필요한 것이 아닙니다. 누가 기술적 사실을 확인하고, 누가 공개 메시지를 승인하며, 누가 승인된 채널에 게시하는지 브리핑에 밝혀야 합니다. 실제 장애 대응 역할을 사용하세요. 슬라이드 작성자가 복구 선언을 승인할 권한까지 있다고 가정하지 마세요.
가상의 서비스에는 5장짜리 브리핑이면 충분할 수 있습니다.
- 현재 상태: 영향받은 기능과 리전, 기준 시각, 현재 장애 책임자
- 영향과 불확실성: 확인된 사실, 아직 모르는 내용, 주요 주장 각각의 출처
- 대응: 검증 전 가설을 원인처럼 말하지 않으면서 진행 조치와 필요한 결정을 설명
- 커뮤니케이션: 승인된 고객 공지, 지원팀 메모, 게시 담당자, 다음 안내 시각
- 복구 근거: 조사 중에서 모니터링 또는 복구 상태로 전환할 때 필요한 점검과 확인된 실제 결과
작성 중인 문구와 이미 보낸 문구를 눈에 띄게 구분하세요. 버전, 승인 시각, 게시 시각, 게시 위치를 기록합니다. 영향 범위를 “EU 리전”에서 더 좁은 작업 공간 집합으로 수정했다면, 모순되는 슬라이드가 돌아다니지 않도록 공동 사실 기록과 이후 메시지를 함께 고치세요.
Google의 장애 관리 안내는 최신 장애 기록과 명확한 인수인계를 강조합니다. 이 발표 자료에서는 특히 대응 담당자가 바뀔 때 책임자와 기준 시각이 계속 보이도록 하는 것이 중요합니다.
서비스 복구와 사후 설명을 구분하세요
복구 단계에서는 다시 작동하는 기능과 고객에게 남은 조치를 알려 주세요. 완전한 원인 분석이 나올 때까지 복구 안내를 미룰 필요는 없습니다. 반대로 시스템 지표 하나가 나아졌다고 “해결됨”이라는 표시 뒤에 계속되는 고객 영향을 숨겨서도 안 됩니다.
장애 후에는 장애 회고 발표 자료로 기여 요인과 장기 개선 사항을 조사할 수 있습니다. 이는 별도의 산출물입니다. 이야기를 완결된 것처럼 보이게 하려고 진행 중인 브리핑에 가상의 근본 원인을 넣지 마세요.
해결 전에 커뮤니케이션 담당자가 바뀐다면 실제로 쓸 수 있는 기록을 남기세요. 다음은 조사 안내와 모니터링 안내 사이인 10:35 UTC의 가상 인수인계입니다.
커뮤니케이션 인수인계 — 10:35 UTC
현재 공개 상태: EU 리전의 일부 작업 공간에서 첨부파일 업로드 오류 조사 중. 마지막 메시지: 버전 2, 10:30 UTC 게시. 다음 공개 안내: 복구가 확인되지 않아도 변화 없음 안내를 포함해 10:50 UTC까지. 인계받는 커뮤니케이션 담당자가 책임을 수락함. 장애 지휘자가 운영 상태를 확인하고 커뮤니케이션 담당자가 승인된 문구를 게시함. 복구 시각, 정확한 시작 시각, 영향 작업 공간 수는 미확인. 공동 장애 기록에 최신 근거와 지원팀 메시지가 있음.
이제 인계받은 담당자는 채팅 이력을 다시 조합하거나 어느 슬라이드가 최신인지 추측하지 않고도 다음 안내를 정확히 보낼 수 있습니다.
