인시던트 사후 검토 프로세스: 추적, 문서화 및 개선

주요 시사점

• 인시던트 사후 검토는 팀이 어떤 일이 왜 일어났는지 및 반복되는 문제를 방지하기 위해 무엇을 변경해야 하는지 이해하는 데 도움이 됩니다.

• Jira Service Management, Confluence 및 Jira를 함께 사용하면 대응, 문서화 및 후속 조치를 위한 연결된 워크플로가 만들어집니다.

• 일관된 사후 검토 템플릿을 사용하면 시간이 지나면서 인시던트 검토를 더 쉽게 문서화하고 비교하고 그로부터 배울 수 있습니다.

• 시정 조치를 소유자 및 마감 날짜가 있는 Jira 업무 항목으로 전환하면 팀이 배운 점을 실질적인 개선 사항으로 바꾸는 데 도움이 됩니다. 

프로덕션에서 문제가 발생하면 해결은 시작에 불과합니다. 똑같이 중요한 것은 왜 그런 일이 발생했는지 이해하고 같은 방식으로 다시 발생하지 않도록 하는 것입니다. 

인시던트 사후 검토는 인시던트를 처음부터 끝까지 체계적으로 검토하는 과정으로, 무엇이 문제였는지, 팀이 어떻게 대응했는지, 앞으로 무엇을 변경해야 하는지를 다룹니다.

인시던트 대응 계획 템플릿이 프로세스를 안내하면 팀에서 모든 인시던트를 일관되게 문서화할 수 있어 중요한 사항을 놓치지 않고 모든 검토가 실질적인 개선으로 이어지게 됩니다.

작동 방식: 인시던트 실행 및 사후 검토 캡처

효과적인 인시던트 관리 는 단순히 문제를 해결하는 것이 아니라 모든 인시던트가 더 나은 프로세스, 더 효과적인 도구 및 다음번을 위한 더 효과적인 준비로 이어지는 시스템을 구축하는 것입니다. Jira Service Management, Confluence 및 Jira를 함께 사용하면 알림이 발생하는 순간부터 사후 검토를 거쳐 후속 업무까지 전체 인시던트 대응 수명 주기를 다루는 연결된 워크플로를 팀에 제공합니다. 

이 접근 방식은 인시던트 전반에 걸쳐 일관된 문서화를 유지하고 명확한 책임 사슬을 구축합니다. 인시던트 세부 정보가 Slack 메시지, 이메일 및 누군가의 기억에 흩어져 있는 대신, 모든 것이 검토하고 참조하고 조치할 수 있는 하나의 연결된 생태계에 저장됩니다. 또한 이 일관성은 인시던트 대응 계획 템플릿이 팀에서 시간이 날 때 작성하는 것이 아니라 프로세스의 중심에 머물러 있다는 것을 의미합니다. 

각 단계별로 프로세스가 어떻게 진행되는지 살펴보겠습니다.

Jira Service Management에서 인시던트 실행

Jira Service Management는 인시던트 대응이 시작되는 곳입니다. 이슈가 접수되는 즉시 JSM에 로그하고 심각도 수준을 설정한 다음, 적절한 응답자를 할당합니다. 

인시던트 중 팀은 JSM을 사용하여 다음을 수행할 수 있습니다.

• 실시간으로 작업, 의사 결정 및 에스컬레이션을 추적

• 누가 참여했고 무엇이 변경되었는지에 대한 명확한 기록을 유지

• 사후 검토를 지원할 세부 정보를 캡처

• 대응자를 방해하지 않고 리더십에 정보를 제공

JSM이 Confluence 및 Jira와 통합되므로 인시던트 중 수집된 데이터가 사후 검토 문서화 및 후속 업무로 직접 흘러갈 수 있습니다. JSM을 더 광범위한 ITSM 소프트웨어 설정의 일부로 사용하는 팀의 경우, 인시던트 데이터도 더 큰 서비스 관리 그림에 반영됩니다.

JSM은 또한 팀이 다음을 수행할 수 있도록 지원하여 대응 전반에 걸쳐 강력한 인시던트 커뮤니케이션을 지원합니다.

• 고객, 지원 팀 및 이해 관계자에게 최신 정보를 제공

• 진행 중인 인시던트 중 혼란을 줄임

• 상태 및 영향에 대한 가시성을 제공

• 심각도가 높은 이벤트 또는 위기 관리 시나리오에서 더 명확하게 소통

인시던트가 해결될 때쯤이면 팀은 이미 상황이 어떻게 전개되었는지에 대한 상세한 기록을 보유하고 있으므로, 사후 검토를 더 쉽게 문서화하고 향후 개선에 더 유용하게 활용할 수 있습니다.

Confluence에서 사후 검토 캡처

인시던트가 해결되면 세부 사항의 기억이 아직 생생할 때, 이상적으로는 24~48시간 이내에 문서화하세요. 기다리는 시간이 길어질수록 컨텍스트가 잊혀지고 사후 검토의 유용성이 떨어집니다. 

전용 인시던트 사후 검토 템플릿을 사용하여 전용 Confluence 페이지를 만들고 각 섹션(타임라인, 근본 원인 분석, 영향 평가 및 배운 점)을 진행합니다. 이 페이지에 포함된 인시던트 대응 템플릿은 팀에서 새로운 인시던트마다 복사하여 작성할 수 있는 완전한 프레임워크를 제공하므로 매번 처음부터 무엇을 문서화할지 고민할 필요가 없습니다.

사후 검토를 Confluence에 보관하면 다음과 같은 실용적인 이점이 있습니다.

• 팀 전체 가시성: 엔지니어링부터 리더십까지 누구나 대기 중 대응자를 쫓아다니면서 말로 요약해 달라고 부탁하지 않고도 발생한 상황을 검토할 수 있습니다.

• 패턴 식별: 모든 인시던트가 동일한 형식으로 문서화되면 분기별로 반복되는 장애 및 시스템 차원의 약점을 훨씬 쉽게 발견할 수 있습니다.

• 책임 없는 문서화: 구조화된 인시던트 대응 템플릿은 개인을 비난하기보다는 시스템 및 프로세스에 대화를 집중시켜 더욱 정직하고 유용한 보고로 이어집니다.

• 신규 채용자의 빠른 적응: 새로운 팀원은 과거 사후 검토를 읽어보며 압박이 높은 상황에서 시스템이 어떻게 작동하는지 및 팀이 이전 인시던트에서 이미 어떤 점을 배웠는지 이해할 수 있습니다.

생산적인 사후 검토를 실행하는 더 자세한 가이드는 Atlassian 인시던트 사후 검토 핸드북을 참조하세요.

후속 조치를 Jira 업무 항목으로 추적

사후 검토의 유용성은 사후 검토가 이끌어내는 작업에 달려 있습니다. 검토 중 식별된 모든 수정 작업 및 반복되는 이슈는 명확한 소유자 및 마감 날짜가 있는 Jira 업무 항목으로 변환되어야 합니다. 

이 단계는 실제로 개선을 이루는 팀과 동일한 문제에 계속 부딪히는 팀을 구분하는 단계입니다. 시정 조치가 Jira에서 추적 가능한 업무 항목으로 관리되면 관리자는 진행률을 모니터링할 수 있고 팀은 합의한 개선 사항을 완료하는 데 서로 책임을 질 수 있습니다. 우선 순위 지정에도 도움이 됩니다. 인시던트 기반 업무가 나머지 백로그와 함께 있으면 조용히 목록 맨 아래로 밀려나도록 놔두는 것보다 다른 우선 순위와 비교하여 검토하기가 더 쉽습니다.

적절한 인시던트 관리 도구는 이 전체 워크플로를 엔드투엔드로 연결합니다. 대응, 문서화 및 후속 조치 시스템이 통합되면 문제를 감지하는 것과 재발을 방지하는 것 사이의 공백이 크게 줄어듭니다.

인시던트 대응 템플릿

다음은 팀에서 새로운 인시던트마다 복사하고 조정할 수 있는 인시던트 대응 계획 템플릿입니다. 초기 요약 및 타임라인부터 근본 원인 분석, 배춘 점 및 시정 조치까지 사후 검토의 모든 단계를 안내합니다. 모든 인시던트에 일관된 구조를 사용하면 놓치는 것이 없고 시간이 지나면서 사후 검토를 쉽게 비교할 수 있습니다.

템플릿의 예시는 시작 지점이며, 엄격한 스크립트가 아닙니다. 조직의 운영 방식에 맞게 표현 및 세부 사항 수준을 조정하세요. 목표는 몇 달 후에 누가 사후 검토를 읽더라도 정확히 무엇이 일어났는지 및 팀이 그에 대해 무엇을 했는지 이해할 수 있도록 충분한 컨텍스트를 문서화하는 것입니다.

인시던트 요약

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

예:

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