Capordia원인을 제시하기 전에 영향 설명하기
관찰 가능한 문장으로 제시하세요. 일부 작업이 더 이상 출력을 생성하지 않거나, 허가된 접근이 거부되거나, 내보낸 결과를 다시 읽을 수 없게 된 경우입니다. 영향을 받은 범위와 여전히 작동하는 부분을 명시하세요. "서버가 다운됐다"는 하나의 출력 경로만 실패해도 너무 광범위한 결론이 되기 쉽습니다. 수락된 결과, 불완전한 결과, 실행되지 않은 작업을 상호 배타적인 범주로 집계하세요.
조정 책임자와 개입 권한을 가진 사람을 지정하세요. Google SRE의 사고 관리 가이드는 조정과 운영 및 커뮤니케이션을 구분합니다. 소규모 팀에서는 한 사람이 여러 역할을 맡을 수 있지만, 누가 결정하는지는 모두가 알아야 합니다. 다음 내부 상황 공유 시점을 정하세요. 이 조직은 공급자의 어떠한 응답 시간 보장도 만들지 않습니다.
사실을 구분하는 연혁 보존하기
마지막으로 정상임을 확인한 상황, 첫 증상, 그리고 그 사이에 발생한 변경 사항을 기록하세요. 표준 시간대와 각 시각의 출처(로그, 직접 관찰, 확인이 필요한 기억)를 명시하세요. 스크린샷에 복사된 날짜는 애플리케이션 로그와 기준이 다를 수 있습니다. 경계가 없으면 정확한 분을 지어내기보다 불확실한 구간을 보존하세요.
각 조치마다 수행자, 범위, 목표, 결과를 기록하세요. 어떤 프로세스가 대상이었는지와 증상이 바뀌었는지 모른다면 "재시작 완료"는 불완전합니다. 관찰, 가설, 결정을 분리해 두세요. 이 분리는 실제로 무엇이 도움이 되었는지 재구성하고, 여러 사람이 동시에 양립할 수 없는 해결책을 시도하는 것을 방지해 줄 것입니다.
가상 예시: GPU 고장이 입증된 것이 아니라 부분 내보내기
가상 셀 «해안 지도»에서는 스무 개의 문서를 납품해야 합니다. 열네 개의 출력이 열려 승인되었고, 네 개의 작업이 쓰기 거부를 보고했으며 두 개는 아직 시작하지 않았습니다. 따라서 여섯 개의 결과는 아직 납품할 수 없지만, 스무 개의 결과가 손실되었다고 발표하는 것은 잘못입니다. 이 예시에는 실제 사고나 Capordia 서버가 전혀 설명되어 있지 않습니다.
아래 연대기는 출력 경로에 대한 표적 검토를 요청하게 합니다. 아직 원인을 입증하지는 않습니다. 시간상 가까운 변경은 증상과 관련이 있을 수 있지만 그것을 설명하지는 않습니다. 팀은 승인된 열네 개의 출력을 유지하고 문제가 되는 새로운 제출만 중단합니다. 시각은 가상이며 동일한 시간대에 속하며, 이는 읽을 때의 모호함을 피하기 위해 선택되었습니다.
| 시각 | 기록된 사실 | 허용되는 해석 |
|---|---|---|
| 9시 40분 | 마지막으로 성공적으로 열린 출력 | 알려진 정상 작동 기준점 |
| 9시 42분 | 출력 대상 변경됨 | 검토해야 할 변경 |
| 9시 43분 | 첫 번째 쓰기 거부 기록됨 | 증상이 관찰된 시작점 |
| 9시 48분 | 문제가 되는 새로운 제출 중단됨 | 영향 제한 조치 |
| 10시 05분 | 작은 가상 파일로도 동일한 거부 발생 | 더 작은 재현, 원인은 확인 필요 |
결함을 지우지 않고 재현을 축소하기
증상과 동일한 관련 경로를 유지하는 가장 작은 입력을 찾으세요. 예를 들어 파일 유형, 대상, 기술적 신원 또는 설정입니다. 가능하면 실제 업무 내용을 합성 데이터로 대체하세요. 대체로 오류가 사라진다면 그 한계를 문서화하세요. 더 이상 의심되는 부분을 거치지 않는 단순화된 명령을 충실한 재현이라고 제시하지 마세요.
검증 가능한 가설을 세워 진행하세요. Google SRE의 문제 해결 장에서는 원인을 가려내는 테스트를 권장하며, 계측이나 시험이 시스템에 영향을 줄 수 있음을 상기시킵니다. 따라서 실패한 결과도 성공만큼 꼼꼼히 기록하세요. 출력을 게시하거나 저장소를 악화시키는 처리를 반복적으로 재실행하지 마세요. 담당자가 먼저 허용된 시험 범위를 정합니다.
읽기 쉽고 민감 정보를 제거한 증거 준비하기
전달 자료에는 유용한 버전, 최소 절차, 시각, 정확한 오류 메시지, 증상 전후의 로그 발췌가 포함됩니다. 대조를 쉽게 하는 경우 작업 식별자와 관련 폴더 참조를 추가하세요. 상황을 이해하는 데 아무도 필요로 하지 않는다면 나머지 로그는 제외하세요. 원본은 팀의 허용된 범위 내에 보관하세요.
OWASP는 로그에 비밀번호, 액세스 토큰 또는 키를 노출해서는 안 된다고 상기시킵니다. 프로젝트를 드러낼 수 있는 경로, 파일 이름, 인수도 다시 검토하세요. 진단에 필요한 구조는 유지하면서 PROJET_A와 같이 일관된 대체어를 사용하세요. 민감 정보를 제거한 증거는 무엇을 제거했는지 명시해야 하며, 결정적인 오류 메시지를 바꾸거나 중요한 조건을 사라지게 해서는 안 됩니다.
조치할 수 있는 에스컬레이션 요청 작성하기
요청은 영향과 구체적인 질문으로 시작하세요. 예를 들어 액세스 거부 검토, 할당 속성 확인 또는 재현 가능한 차이를 찾도록 지원 요청입니다. 연대기와 민감 정보를 제거한 재현을 첨부하세요. 이미 시도한 조치, 아무 변화도 없었던 조치, 피해야 할 작업을 명시하세요. 수신자는 주석 없는 캡처 폴더를 뒤지지 않고도 무엇이 기대되는지 알 수 있어야 합니다.
예시에서 요청은 다음과 같을 수 있습니다. «새로 사용된 출력 경로가 처리 신원으로는 쓰기를 거부합니다. 해당 경로에 적용되는 권한을 검토해 주세요. 열네 개의 출력은 여전히 유효하며, 네 개의 작업이 쓰기 거부를 보고했고 이 거부는 가상 입력으로 재현되었습니다.» 이 글은 GPU나 운영자를 비난하지 않습니다. 알려진 내용을 제시하고 검토가 이루어질 때까지 원인을 열어 둡니다.
종료하기 전에 응답 확인하기
더 이상 재현되지 않는 오류만으로는 충분하지 않은 경우가 있습니다. 동일한 신원, 동일한 결정적 조건, 다시 확인한 목적지를 사용해 전체 결과를 검증하세요. 그런 다음 영향을 받은 항목을 점검하세요. 이미 승인된 출력은 보존되었는지, 부분 출력은 격리되었는지, 남은 작업은 올바르게 식별되었는지 확인해야 합니다. 결과 책임자는 기술적 명령의 성공과 구분하여 유효한 재개를 확인해야 합니다.
마이그레이션은 작업을 옮기기 전에 이루어지는 조직적인 변경이며, 인시던트는 예기치 않은 이탈에서 시작됩니다. 인시던트 해결로 인해 데이터를 옮기거나 중단된 처리를 다시 시작해야 한다면, 그 작업에는 기존 마이그레이션 케이스를 사용하십시오. 인시던트 타임라인은 이 결정의 이유를 보존할 뿐, 전환 방식이나 배치 대장을 다시 쓰지 않습니다.
원인이 밝혀지지 않더라도 활용 가능한 결론을 유지하세요
최종 영향, 검증 결과, 입증된 원인 또는 아직 알려지지 않은 원인, 그리고 결정된 조치로 마무리하십시오. 우회 조치는 근본적인 문제를 해결하지 않고 결과만 복원할 수 있으므로 이를 명확히 밝히고 후속 담당자를 명시하십시오. 증거의 부재가 "사고 없음"이 되어서는 안 되며, 과거 사례와의 유사성이 확실한 원인이 되어서도 안 됩니다.
최종 검토는 다른 사람이 무엇이 관찰되었고, 무엇이 시도되었으며, 무엇이 아직 확인되어야 하는지를 구분할 수 있게 해야 합니다. 이는 절차, 점검 또는 오류 메시지를 개선하는 데 쓰이는 것이지, 불확실성 없는 이야기를 만들어내기 위한 것이 아닙니다. 캡처의 개수나 로그의 양, 긴급도 수준이 아무리 높아도 이러한 전달의 품질을 대신할 수는 없습니다.
결정을 위한 질문
장애 원인을 파악할 때까지 기다렸다가 신고해야 하나요?
아니요. 검증 가능한 영향과 알려진 범위를 보고한 뒤 가설을 명확히 구분하세요. 타임라인과 목표로 한 재현은 원인이 입증되기 전에도 도움이 되는 경우가 많습니다. 영향을 제한하기 위해 이미 취한 조치도 함께 밝히세요.
시간을 아끼려고 모든 로그를 보내도 되나요?
먼저 유용한 부분을 추려서 다시 검토하세요. 전체 로그에는 진단에 도움이 되지 않는 비밀 정보와 프로젝트 데이터가 포함될 수 있습니다. 원본은 허용된 공간에 보관하고, 전달한 버전에서 어떤 내용을 대체했는지 설명하세요.
언제 사안을 종결된 것으로 간주하나요?
기대한 결과를 확인하고 책임자가 명시적으로 결정한 후입니다. 확인된 수리와 임시 우회를 구분하세요. 원인을 알 수 없는 경우에도 한계, 수행한 확인, 남아 있는 조치를 명시한다면 종결할 수 있습니다.