인시던트 사후 검토 템플릿

효과적인 인시던트 사후 검토 프로세스의 핵심은 명확한 문서화입니다. 많은 팀은 각 사후 검토 중에 포괄적인 템플릿을 사용하여 일관적인 세부 정보를 수집합니다. 

아래는 인시던트 핸드북에 간략하게 설명된 사후 검토를 바탕으로 한 인시던트 사후 검토 템플릿의 예입니다. 잘라내고 붙여 넣어서 자체적인 사후 검토를 문서화할 수 있습니다.

인시던트 요약

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

예:

{DATE}에 {time range of incident, e.g. 15:45 and 16:35}시 사이에 {NUMBER}명의 사용자가 {EVENT SYMPTOMS}을(를) 겪었습니다. 

이벤트는 {TIME OF CHANGE THAT CAUSED THE EVENT}에 {CHANGE}에 따라 트리거됐습니다. 

{CHANGE}에는 {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}이(가) 포함되어 있습니다. 

이 코드의 버그로 인해 {DESCRIPTION OF THE PROBLEM}이(가) 발생했습니다. 

이 이벤트는 {MONITORING SYSTEM}에서 감지되었습니다. 팀에서는 {RESOLUTION ACTIONS TAKEN}을(를) 통해 이벤트에 조치했습니다.

이 {SEVERITY LEVEL} 인시던트는 {X%}명의 사용자에게 영향을 미쳤습니다.

{e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS}을(를) 통해 이 인시던트와 관련하여 추가 영향이 확인되었습니다. 

사전 요소

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

예:

{MM/DD/YY}, {16:00}에({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}) {PRODUCT OR SERVICE}에 {THE CHANGES THAT LED TO THE INCIDENT}을(를) 위해 변경 사항이 도입되었습니다. 

이 변경으로 인해 {DESCRIPTION OF THE IMPACT OF THE CHANGE}이(가) 발생했습니다.

결함

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

예:

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

영향

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

예:

{XXhrs XX minutes} {XX:XX UTC and XX:XX UTC} {MM/DD/YY}, {SUMMARY OF INCIDENT} 에서 사이의 에 대해 사용자가 이 인시던트를 경험했습니다.

이 인시던트는 {XX}명의 고객({SYSTEM OR SERVICE} 사용자의 X%)에게 영향을 미쳤으며 고객은 {DESCRIPTION OF SYMPTOMS}을(를) 겪었습니다.

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}이(가) 제출되었습니다.

감지

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

예:

이 인시던트는 {ALERT TYPE}이(가) 트리거되고 {TEAM/PERSON}이(가) 호출되었을 때 감지되었습니다.

{FIRST PERSON}이(가) 디스크에 서비스를 기록할 권한이 없었기 때문에 응답이 {XX MINUTES/HOURS} 지연되어 그 다음으로 {SECONDARY PERSON}이(가) 호출되었습니다.

{EXPECTED IMPROVEMENT}할 수 있도록 {TEAM OWNER OF THE IMPROVEMENT}이(가) {DESCRIBE THE IMPROVEMENT}을(를) 설정하게 됩니다. 

대응

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

예:

{XX:XX UTC}에 호출을 받은 후 {SYSTEM WHERE INCIDENT INFO IS CAPTURED}에서 {XX:XX UTC}에 {ON-CALL ENGINEER}이(가) 온라인 상태가 되었습니다. 

이 엔지니어는 {AFFECTED SYSTEM}에 대한 배경 지식이 없었기 때문에 {XX:XX UTC}에 방에 들어온 {ESCALATIONS ON-CALL ENGINEER}에게 {XX:XX UTC}에 두 번째 알림이 전송되었습니다.

복구

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

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

예:

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

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

예: 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. 확장 효과를 관리하기 위해 클러스터에서 부하 분산 정도 정보를 수집하는 보조 메커니즘 도입함