인시던트 사후 검토

사후 검토란 무엇입니까?

사후 검토는 인시던트에 대한 서면 기록으로, 다음에 대한 설명이 포함됩니다.

• 인시던트의 영향
• 인시던트를 해결하거나 영향을 완화하기 위해 취한 조치
• 인시던트의 근본 원인
• 인시던트가 반복되는 것을 막기 위해 취한 후속 조치

Atlassian에서는 Jira 이슈 를 통해 모든 사후 검토를 추적하여 완료 및 승인되었는지 확인합니다. 요구사항이 덜 복잡한 경우 각 사후 검토에 대해 Confluence 페이지와 같은 더 단순한 요구를 사용할 수도 있습니다.

왜 사후 검토를 수행해야 하나요?

사후 검토는 인시던트 발생에 기여한 모든 근본 원인을 파악하고, 나중에 참조하고 패턴을 찾을 수 있도록 인시던트를 문서화하고, 인시던트 반복 가능성 또는 반복 발생 시 영향을 줄이기 위해 효과적인 예방 조치를 시행하는 것을 목표로 합니다.

사후 검토를 통해 인시던트 반복을 효과적으로 줄일 수 있으려면, 팀이 근본 원인을 찾고 해결하도록 하는 검토 프로세스가 필요합니다. 정확한 방법은 팀 문화에 따라 다릅니다. Atlassian에서는 다음과 같이 인시던트 대응 팀에 효과가 있는 여러 방법을 조합하여 적용하고 있습니다.

• 오프라인 회의는 적절한 분석을 촉진하고 수정이 필요한 부분에 팀의 역량을 집중할 수 있게 해 줍니다.
• 배포팀 및 운영팀 관리자의 사후 검토 승인을 통해 팀이 사후 검토를 더욱 철저히 수행하도록 유도합니다.
• 지정된 '우선순위 조치'에는 4주 또는 8주(서비스에 따름)의 합의된 서비스 수준 목표 (SLO)가 있으며, 각 조치가 완료되었음을 확인하는 알림과 보고서가 제공됩니다.

이 프로세스를 처리하고 해당 프로세스가 효과를 발휘하도록 하려면 조직의 모든 수준에서 최선을 다해야 합니다. Atlassian의 엔지니어링 이사와 관리자는 해당 영역에서 승인자와 해결 조치의 SLO를 정해 두었습니다. 이 시스템에서는 이러한 결정 사항을 인코딩하고 적용하기만 합니다.

언제 사후 검토를 수행해야 하나요?

사후 검토는 심각도 1, 2의 인시던트에 대해 수행되며, 이외 인시던트에 대해서는 선택적으로 수행됩니다.

이슈를 해결하는 동안, 또는 그 직후에 사후 검토 소유자가 새로운 사후 검토 이슈를 생성합니다.

누가 사후 검토를 완료하나요?

오류가 발생한 서비스의 배포팀(인시던트 이슈와 관련하여 '결함 있는 서비스'를 소유한 팀)에서 사후 검토의 완료를 책임집니다. 이 팀에서 사후 검토 소유자를 선택하고 사후 검토 이슈를 할당합니다.

• 사후 검토 소유자는 사후 검토를 게시하기 전까지 계속해서 초안 작성과 승인을 통해 사후 검토 작업을 수행하면서 사후 검토의 완료를 책임집니다.
• 한 명 이상의 사후 검토 승인자가 사후 검토를 살펴보고 승인한 후에 백로그에서 후속 조치에 대한 우선순위를 지정해야 합니다.

Confluence 페이지에는 필수 및 선택 서비스 사후 검토 승인자가 서비스 그룹별로 나열되어 있습니다. 이 서비스 그룹은 일반적으로 Atlassian 제품(예: Bitbucket Cloud)에 해당합니다.

사후 검토 조치는 어떻게 추적하나요?

사후 검토를 통해 도출된 모든 조치에는 다음 작업이 수행됩니다.

• 인시던트를 소유한 팀의 백로그에서 Jira 이슈를 제출합니다. Jira에서 모든 사후 검토 조치를 추적해야 합니다.
• 사후 검토 이슈에서 이러한 조치를 '우선순위 조치'(근본 원인 수정) 또는 '개선 조치'( 근본 원인과 관계없는 개선)로 연결합니다.

Atlassian은 Jira REST API를 사용하여 각 심각도에 속하는 인시던트 중 사후 검토의 우선순위 조치를 통해 근본 원인이 수정되지 않은 인시던트의 수를 추적하는 커스텀 보고 프로세스 구축했으며, 각 부서의 엔지니어링 관리자가 이 목록을 정기적으로 검토합니다.

사후 검토 프로세스

사후 검토 프로세스 실행은 사후 검토 이슈 생성, 사후 검토 회의 실행, 조치 파악, 승인 및 결과 전달(원하는 경우)로 이루어져 있습니다.

사후 검토 소유자는 다음 작업을 수행해야 합니다.

1. 사후 검토를 생성하고 인시던트에 연결합니다.
2. 사후 검토 이슈를 편집하고 필드 설명을 읽고 필드를 작성합니다.
3. 인시던트의 근본 원인을 파악하기 위해 "5가지 원인" 기법을 사용하여 진정한 근본 원인을 찾을 때까지 연쇄적인 인과 관계를 신중하게 조사합니다.
4. 사후 검토 회의 일정을 계획합니다. 회의 초대 템플릿을 사용하여 배포팀, 인시던트로 인한 영향을 받는 팀 및 이해관계자를 초대합니다.
5. 팀과 회의를 갖고 아래의 회의 일정을 계속 진행합니다.
6. 담당 개발 관리자에게 후속 상황을 전달하여 이러한 인시던트 클래스를 방지할 수 있는 특정 조치에 관한 약속을 구합니다.
7. 인시던트를 소유한 팀의 백로그에서 각 조치에 대한 Jira 이슈를 제기합니다. 사후 검토 이슈에서 이러한 조치를 '우선순위 조치'(근본 원인 수정) 또는 '개선 조치'(근본 원인과 관계없는 개선)로 연결합니다.
8. Confluence에서 적절한 승인자를 찾아보고 사후 검토의 "승인자" 필드에 추가합니다.
9. "승인 요청" 전환을 선택하여 지정된 승인자에게 승인을 요청합니다. 이슈에 승인자 안내가 포함된 댓글이 자동으로 추가됩니다.
10. 사후 검토가 승인될 때까지 필요에 따라 후속 작업을 수행합니다.
11. 사후 검토가 승인되면 Confluence에 자동으로 초안 상태의 사후 검토 블로그가 생성되며, 소유자가 이를 편집하고 게시할 수 있습니다. 사후 검토 블로그에 게시하여 어렵게 얻은 교훈을 공유함으로써 인시던트의 가치를 더욱 높일 수 있습니다.

사후 검토 프로세스를 완료하면, 개발 팀에서 팀의 SLO에 따른 정상적인 백로그 과정의 일부로 조치에 우선순위를 지정합니다.

사후 검토 회의

Atlassian의 경험에 따르면 팀이 모두 모여 알게된 내용을 논의할 때 근본 원인을 더욱 깊이 있게 분석할 수 있습니다. 분산되어 있는 팀에서는 동영상 회의를 할 수도 있고 인시던트가 여러 그룹과 관련이 있는 경우에는 그룹으로도 실시할 수 있습니다.

Atlassian이 제안하는 안건:

1. 사후 검토 시 비난을 배제할 것과 그 이유에 대해 팀에 알림
2. 이벤트 일정 확인
3. 근본 원인 확인
4. '향후 이러한 클래스의 인시던트를 방지하기 위해 어떤 일을 할 수 있는지?'와 같이 '열린 생각'을 통해 여러 조치를 도출
5. 팀에 '잘한 일/더 잘할 수 있었던 일/다행스러웠던 일'이 무엇인지 질문

추천 캘린더 예약 템플릿:

비난을 배제하는 <인시던트 링크>( <인시던트 요약>) 사후 검토에 참여해 주시기 바랍니다.

사후 검토는 인시던트 발생에 기여한 모든 근본 원인을 파악하고, 나중에 참조하고 패턴을 찾을 수 있도록 인시던트를 문서화하고, 인시던트 반복 가능성 또는 반복 발생 시 영향을 줄이기 위해 효과적인 예방 조치를 시행하는 것을 목표로 합니다.

이 회의에서 근본 원인을 찾고 이 인시던트의 영향을 완화하는 조치를 결정하려고 합니다.

회의에 담당 개발 관리자가 참여하지 못하면 우선순위 결정을 위한 좋은 상황이 아닌 것입니다. 따라서 회의에서 나온 특정 조치를 이행하지 않는 것이 좋습니다. 사람들이 이행에 부담을 느끼게 되며, 정보도 완전하기 않기 때문입니다. 대신, 회의 후에 담당 관리자에게 후속 상황을 알려 정해진 우선순위 조치를 수정하겠다는 약속을 구하는 것이 좋습니다.

사후 검토 이슈 필드

사후 검토 이슈에는 사후 검토 회의를 열기 전에 인시던트의 모든 중요 세부 사항을 수집할 수 있도록 매우 광범위한 필드가 포함되어 있습니다. 아래에는 이러한 필드를 채우는 방법에 대한 몇 가지 예가 나와 있습니다.

직전 원인과 근본 원인

사후 검토를 작성하거나 읽을 때 직전 원인과 근본 원인을 서로 구분해야 합니다.

• 직전 원인 은 이 인시던트의 직접적인 원인입니다.
• 근본 원인 은 변경을 수행한 일련의 이벤트에서 이 전체 클래스의 인시던트를 방지할 수 있는 가장 적합한 지점에서 찾은 원인입니다.

사후 검토에서는 근본 원인을 찾고 그러한 원인의 영향을 완화하는 최선의 방법을 결정하는 것을 목표로 합니다. 일련의 이벤트에서 인시던트를 방지할 수 있었던 최적 지점을 찾는 것이야말로 사후 검토에서 가장 중요한 작업입니다. 5가지 원인 기법을 사용하여 "체인을 거슬러 올라가면서" 근본 원인을 찾습니다.

아래에는 직전 원인과 근본 원인의 몇 가지 예가 나와 있습니다.

근본 원인의 카테고리 및 조치

Atlassian에서는 근본 원인을 그룹화하고 각 근본 원인에 대한 적절한 조치를 논의하기 위해 다음 범주를 사용합니다.

종속 서비스가 있는 근본 원인

종속 서비스 실패로 인해 서비스에서 인시던트가 발생한 시점, 결함이 있는 위치, Atlassian 내부 또는 타사 종속 서비스에 따른 근본 원인, 종속 서비스의 성능에 대한 합리적 기대치가 이에 해당합니다.

내부 종속 서비스인 경우 '종속 서비스의 서비스 수준 목표(SLO)가 무엇인가?'라고 질문합니다.

• 종속 서비스가 SLO를 위반했는가?
  • 결함의 원인이 종속 서비스에 있으며, 신뢰성을 높여야 합니다.
• 종속 서비스가 SLO에 따라 작동했지만 서비스가 실패했는가?
  • 서비스의 복원력을 높여야 합니다.
• 종속 서비스에 SLO가 없는가?
  • SLO를 마련해야 합니다.

타사 종속 서비스인 경우 '타사 종속 서비스의 가용성, 대기 시간 등에 대한 합리적인 기대치는 무엇인가?'라고 질문합니다.

• 타사 종속 서비스가 도움이 되지 않는 방식으로 기대치를 초과하는가?
  • 기대치가 잘못 설정되었습니다.
    • 다시 발생하지 않을 것이 확실한가? 예를 들어, RCA를 검토하고 이에 동의합니다. 이 경우 조치는 해당 RCA가 됩니다.
    • 또는 기대치를 조정해야 하는가? 이 경우 조치는 회복력을 높이고 기대치를 조정하는 것입니다.
    • 조정된 기대치를 받아들일 수 없는가? 이 경우 다른 공급업체를 찾는 등의 방법으로 요구사항과 해결책 간의 불일치를 해결해야 합니다.
• 타사 종속 서비스가 기대치만큼 작동했지만 서비스가 실패했는가?
  • 이 경우 서비스의 복원력을 높여야 합니다.
• 기대치가 실제로 존재하는가?
  • 타사 종속 서비스 소유자는 이 기대치를 설정하고 팀과 공유하여, 팀원들이 종속 서비스에 구축해야 할 복원력 수준을 알 수 있게 해야 합니다.

*타사와 합의한 SLA가 있는데 왜 "기대치"가 필요할까요? 사실 타사와의 계약상 SLA는 결함과 완화 조치를 판별하는 데 있어 유용성이 매우 낮습니다. 예를 들어, AWS는 EC2에서 SLA를 거의 알려주지 않고 있습니다. 따라서 Atlassian이 타사 서비스를 사용하는 경우 신뢰성, 가용성, 성능 또는 합리적으로 타사가 제공할 것으로 기대하는 다른 주요 메트릭의 수준에 대해 결정해야 합니다.

사후 검토 조치

Google의 Sue Lueder와 Betsy Beyer는 사후 검토 조치 항목에 대한 우수한 프리젠테이션과 자료를 가지고 있는, Atlassian에서는 이를 사용하여 팀의 사후 검토 작업을 지원합니다.

아래 질문을 검토해보면 PIR이 단기 및 장기 수정사항을 모두 포함하고 있는지 확인하는 데 도움이 됩니다.

'향후 인시던트 영향 완화' 및 '향후 인시던트 방지'에서 근본 원인을 해결할 수 있는 조치를 찾을 수 있는 가능성이 가장 높습니다. 다음 중에서 하나 이상을 수행해야 합니다.

사후 검토 승인

Atlassian에서는 사후 검토가 승인되었는지 확인하기 위해 승인 단계가 포함된 Jira 워크플로우를 사용하고 있습니다. 승인자는 일반적으로 서비스 운영을 담당하는 서비스 소유자 또는 기타 관리자입니다. 사후 검토를 승인하는 것은 다음을 의미합니다.

• 근본 원인을 포함하여 인시던트 발생 후 검토 결과에 대해 동의함
• 연결된 '우선순위 조치'가 근본 원인을 해결하기 위한 허용 가능한 방법인 것에 동의함

승인자는 보통 추가 조치를 요구하거나, 제안된 조치를 통해 해결되지 않는 일련의 인과 관계가 있음을 밝혀냅니다. Atlassian에서는 승인 단계를 통해 사후 검토 프로세스에 많은 가치를 더할 수 있었습니다.

인시던트가 덜 발생하거나 인프라가 덜 복잡한 팀에서는 사후 검토 승인이 필요하지 않을 수도 있습니다.

비난을 배제한 사후 검토

문제가 발생하면 보통 사람들은 비난할 대상을 찾습니다. Atlassian에서는 누구도 비난하지 않는 것이 가장 이익이 된다고 생각하며, 사후 검토를 수행할 때 여러분은 비난하지 않기 위해 의식적으로 노력해야 합니다. 우리는 직원이 선의를 갖고 작업했다고 생각하며 문제가 있을 때 절대 개인을 비난하지 않습니다. 사후 검토에서는 솔직하고 객관적으로 결함이 발생한 상황을 조사해야 하며, 이를 통해 진정한 근본 원인을 찾고 해당 영향을 완화할 수 있어야 합니다. 개인을 비난하는 경우 다음과 같은 위험이 뒤따릅니다.

• 사람들은 동료들의 신임을 잃을 위기에 놓이거나 향후 경력에 문제가 생길 것으로 생각되면 개인적인 우선순위에서 '회사의 최대 관심사'보다 이러한 걱정이 앞서게 됩니다. 그렇기 때문에 이들은 자연스럽게 자신의 최우선 요구를 보호하기 위해 진실을 왜곡하거나 숨깁니다.
• 개인이 인시던트의 직접적인 원인이 되는 일을 했더라도 'x라는 사람이 왜 이 일을 했는가'가 아니라 '시스템에서 왜 그들이 이런 일을 할 수 있게 허용했는지, 또는 왜 그들이 이렇게 하는 것이 맞다고 생각하게 했는지'라고 질문해야 합니다.
• 개인을 비난하는 것은 불쾌한 일일 뿐만 아니라, 그러한 일이 반복될 경우 공포와 불신의 문화를 조성할 수 있습니다.

Atlassian 사후 검토에서는 다음 기법을 사용하여 업무에 참여한 모든 직원을 개별적으로 보호합니다.

• 사후 검토 회의를 열 때 사후 검토에서 비난이 배제된다는 점과 그 이유에 대해 설명
• '대기 중이었던 위젯 엔지니어'와 같이, 이름 대신 역할로 개인을 지칭(반면 사실에 대해서는 모호한 부분이 없이 명확하게 설명)
• 사후 검토 일정, 연쇄적 인과 관계, 완화 조치는 개인이 아닌 시스템, 프로세스, 역할의 맥락에서 표현해야 함

Atlassian의 비난을 배제한 사후 검토 및 '심층 원인 분석'이라는 유용한 개념은 John Allspaw의 중요한 문서에 기반한 것입니다.