인시던트 사후 검토 템플릿

인시던트 요약

인시던트 요약을 몇 문장으로 작성합니다. 발생한 일, 원인, 심각도, 영향이 지속된 기간이 포함되어야 합니다.

예:

{날짜} {인시던트 시간 범위(예: 15:45부터 16:35까지)}에 사용자 {숫자}명이 {이벤트 증상}을(를) 경험했습니다.

이 이벤트는 {이벤트를 발생시킨 변경이 이루어진 시점}에 {변경}에 의해 트리거되었습니다.

{변경}에는 {시스템을 업데이트하기 위한 코드 변경과 같은 변경 설명 또는 변경 이유}이(가) 포함되어 있습니다.

이 코드의 버그로 인해 {문제 설명}이(가) 발생했습니다.

이 이벤트는 {모니터링 시스템}에서 감지되었습니다. 팀에서는 {취한 해결 조치}을(를) 통해 이벤트에 조치를 취했습니다.

이 {심각도 수준} 인시던트는 {X%}의 사용자에게 영향을 미쳤습니다.

이 인시던트와 관련하여 {예: 제출된 지원 티켓 수, 소셜 미디어 언급, 계정 관리자에게 걸린 전화}과(와) 같은 추가적인 영향이 있었습니다.

사전 요소

인시던트를 유발한 이벤트의 순서를 설명합니다(예: 아직 감지되지 않은 버그가 발생한 이전 변경).

예:

{YY/MM/DD} {16:00}에 ({고객에게 영향을 주기 전까지의 시간(예: 문제의 인시던트가 발생하기 10일 전)}) {인시던트로 이어진 변경}을(를) 위해 {제품 또는 서비스}에 변경이 도입되었습니다.

이 변경으로 인해 {변경의 영향 설명}이(가) 발생했습니다.

결함

구현된 변경 사항이 어떤 면에서 예상대로 작동하지 않았는지 설명하세요. 가능한 경우 오류를 보여주는 관련 데이터를 시각화한 스크린샷을 첨부하세요.

예:

{XX%}의 요청에 대해 응답 {개수}개가 오류로 전송되었습니다. 이것은 {기간} 동안 계속되었습니다.

영향

인시던트 발생 중에 내부 및 외부 사용자에게 어떤 영향을 미쳤는지 설명합니다. 제기된 지원 사례의 수를 포함합니다.

예:

{YY/MM/DD} {XX:XX UTC에서 XX:XX UTC} 사이에 {XX시간 XX분} 동안 {인시던트 요약} 사용자가 이 인시던트를 경험했습니다.

이 인시던트는 {XX}명의 고객({시스템 또는 서비스} 사용자의 X%)에게 영향을 미쳤으며 고객은 {증상 설명}을(를) 겪었습니다.

{지원 티켓 XX개와 소셜 미디어 게시물 XX개}가 제출되었습니다.

감지

팀은 언제 사건을 감지했습니까? 그런 일이 벌어지고 있다는 것을 어떻게 알았습니까? 탐지 시간을 어떻게 개선할 수 있었습니까? 어떻게 그 시간을 절반으로 줄일 수 있었을지 생각해 보세요.

예:

이 인시던트는 {알림 유형}이(가) 트리거되고 {팀/사용자}이(가) 호출되었을 때 감지되었습니다.

{첫 번째 사용자}이(가) 디스크에 쓰는 서비스를 소유하지 않아 응답이 {XX분/시간} 지연되었기 때문에 그 다음으로 {보조 담당자}이(가) 호출되었습니다.

{개선 설명}은(는) {예상되는 개선 사항}을(를) 위해 {개선의 팀 소유자}이(가) 마련할 것입니다.

대응

인시던트에 누가 대응했습니까? 언제 대응했고, 무엇을 했습니까? 응답의 지연이나 장애물을 기입하세요.

예:

{XX:XX UTC}에 호출을 받은 후 {대기 중 엔지니어}이(가) {XX:XX UTC}에 {인시던트 정보가 캡처된 시스템}에서 온라인에 접속했습니다.

이 엔지니어는 {영향 받는 시스템}에 대한 배경 지식이 없었기 때문에 {XX:XX UTC}에 방에 들어온 {에스컬레이션 대기 중 엔지니어}에게 {XX:XX UTC}에 두 번째 알림이 전송되었습니다.

복구

서비스가 어떻게 복원되었고 인시던트가 끝난 것으로 간주되었는지 설명하세요. 서비스가 복원된 방법을 자세히 설명하고 복원을 위해 필요했던 단계를 알고 있어야 합니다.

시나리오에 따라 다음과 같은 질문을 고려하세요. 완화 시간을 어떻게 단축할 수 있습니까? 어떻게 그 시간을 절반으로 줄일 수 있었습니까?

예:

Atlassian은 시스템 복구에 3가지 측면의 접근 방식을 사용했습니다.

{문제를 완화시킨 조치, 조치를 취한 이유 및 결과 설명}

예: BuildEng EC3 ASG 크기를 늘려 워크로드를 지원하는 데 사용하는 노드 수를 늘리고, 노드를 초과 신청하는 예약 가능성을 줄임

• Escalator 오토스케일러를 비활성화하여 클러스터의 범위가 급격하게 축소되는 것을 방지함
• Build Engineering 스케줄러를 이전 버전으로 되돌림

타임라인

인시던트 일정을 자세히 설명합니다. 시간대 표준화를 위해 UTC를 사용하는 것이 좋습니다.

주목할 만한 복선 이벤트, 활동 시작, 첫 번째로 알려진 영향 및 에스컬레이션을 포함하세요. 모든 결정 또는 변경 사항, 인시던트가 종료된 시점 및 영향 후 참고 사항을 기록하세요.

예:

모든 시간은 UTC 기준입니다.

11:48 - Control Plane K8S 1.9 업그레이드 완료

12:46 - V1.9으로 업그레이드 완료(클러스터 오토스케일러 및 BuildEng 스케줄러 인스턴스 포함)

14:20 - Build Engineering에서 KITT Disturbed에 문제 보고

14:27 - KITT Disturbed에서 특정 EC2 인스턴스(ip-203-153-8-204)의 오류 조사 시작

14:42 - KITT Disturbed에서 노드 통제

14:49 - BuildEng에서 문제가 여러 노드에 영향을 미치는 것을 보고, 문제의 86개 인스턴스로 오류가 더 시스템상의 문제인 것으로 보임

15:00 - KITT Disturbed에서 표준 스케줄러로 전환하도록 권장

15:34 - BuildEng에서 200개 포드에 오류가 있다고 보고

16:00 - BuildEng에서 OutOfCpu 보고서를 통해 오류가 있는 모든 빌드를 제거

16:13 - BuildEng에서 새로운 빌드에서 오류가 지속적으로 반복되며, 일시적인 오류가 아님을 보고.

16:30 - KITT에서 오류를 인시던트로 인식하고 인시던트로 실행

16:36 - KITT에서 문제의 영향을 완화하기 위해, Escalator 오토스케일러가 컴퓨팅 노드를 제거할 수 없도록 오토스케일러를 비활성화

16:40 - KITT에서 ASG가 안정적이고, 클러스터 로드가 정상이며, 고객에게 미치는 영향이 해결되었음을 확인

템플릿:

XX:XX UTC - 인시던트 활동, 취한 조치

XX:XX UTC - 인시던트 활동, 취한 조치

XX:XX UTC - 인시던트 활동, 취한 조치

근본 원인 식별: 5가지 원인

5가지 원인은 근본 원인 파악 기법입니다. 사용할 수 있는 방법은 다음과 같습니다.

• 영향에 대한 설명부터 시작하여 왜 발생했는지 질문하세요.
• 인시던트가 미친 영향에 주목하세요.
• 왜 발생했는지, 결과적으로 왜 그런 영향을 미쳤는지 질문하세요.
• 근본 원인을 찾을 때까지 계속 "왜"라는 질문을 합니다.

사후 검토 설명서에 "원인"을 기재하세요.

예:

1. 데이터베이스가 잠겨 애플리케이션이 중단되었습니다
2. 데이터베이스에 대한 쓰기가 너무 많아서 데이터베이스가 잠겼습니다
3. 서비스에 변경을 적용했지만 쓰기 증가를 예상하지 못했기 때문입니다
4. 부하 테스트 변경에 대한 개발 프로세스가 수립되어 있지 않기 때문입니다
5. 이 수준의 규모에 도달하기 전까지는 부하 테스트가 필요하다고 생각하지 않았기 때문입니다.

근본 원인

인시던트의 최종 근본 원인, 즉 이 종류의 인시던트가 다시 발생하지 않도록 변경이 필요한 것으로 식별된 사항에 유의하세요.

예:

<버그 원인 또는 버그가 발생한 서비스> 연결 풀 처리의 버그로 인해 잘못된 조건에서 연결에 문제가 생긴 동시에 연결 상태를 확인할 수 없는 문제가 발생했습니다.

백로그 점검

엔지니어링 백로그를 검토하여 이 인시던트를 예방할 수 있었거나 최소한 영향을 줄일 수 있는 계획되지 않은 작업이 있었는지 알아보세요.

백로그에 대한 명확한 평가를 통해 우선 순위 및 위험에 대한 과거의 의사 결정을 밝힐 수 있습니다.

예:

백로그에는 이 서비스를 개선할 수 있었던 특정 항목이 없습니다. 흐름 유형의 개선 사항에 대한 참고 사항이 있으며 이것은 워크플로가 있는 지속적인 작업이었습니다.

통합 테스트 개선을 위해 제출된 티켓이 있지만 지금까지는 성공적이지 않았습니다.

반복

이제 근본 원인을 알았으니 동일한 근본 원인을 가질 수 있는 다른 인시던트를 되돌아보고 확인할 수 있습니까? 그렇다면 해당 인시던트에서 어떤 완화가 시도되었는지 기록하고 이 사건이 다시 발생한 이유를 질문하세요.

예:

동일한 근본 원인으로 인해 인시던트 HOT-13432, HOT-14932, HOT-19452가 발생했습니다.

교훈

인시던트 대응에서 잘 진행된 사항, 개선할 수 있었던 사항 및 개선의 기회가 있는 부분에 대해 논의합니다.

예:

• 작업의 속도 제한기가 올바르게 관리되고 있었는지 검증하기 위한 단위 테스트 필요
• 정상 작업과 다른 대량 작업의 작업량을 검토해야 함
• 대량 작업을 천천히 시작하고 모니터링해야 하며, 서비스 지표가 정상으로 표시되면 늘림

수정 조치

향후 이 종류의 인시던트를 방지하기 위한 시정 조치를 설명하세요. 담당자, 작업을 완료해야 하는 시기, 작업이 추적되는 위치를 기록해 둡니다.

예:

1. 오류 발생을 제한하기 위해 임시로 수동 자동 확장 속도 제한을 적용함
2. 단위 테스트 및 작업 속도 제한을 재도입함
3. 확장 효과를 관리하기 위해 클러스터에서 부하 분산 정도 정보를 수집하는 보조 메커니즘 도입함