Close

더 나은 인시던트 관리를 위한 길은 여기에서 시작됩니다

인시던트 관리 홈

인시던트 사후 검토

Atlassian에서는 비난을 배제한 사후 검토를 적용하여 심각도 수준이 2 이상인 모든 인시던트에서 근본 원인을 파악하고 인시던트를 해결하고 있습니다. 아래에는 Atlassian에서 사후 검토를 운영하는 방식에 대해 설명하는 내부 문서가 간단히 요약되어 있습니다.

인시던트 관리 핸드북

핸드북 인쇄 버전 또는 PDF 받기

무료로 제공되는 Atlassian 인시던트 관리 핸드북의 인쇄 버전은 한정되어 있습니다. 또는 PDF 버전을 다운로드하세요.


사후 검토란 무엇입니까?

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

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

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. 팀에 '잘한 일/더 잘할 수 있었던 일/다행스러웠던 일'이 무엇인지 질문

추천 캘린더 예약 템플릿:

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

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

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

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


사후 검토 이슈 필드

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

필드

설명

인시던트 요약

몇 개의 문장으로 인시던트를 요약합니다. 심각도, 원인, 영향이 지속된 기간이 포함되어야 합니다.

<날짜> <인시던트 시간 범위(예: 14:30부터 15:00까지)><숫자>명의 고객이 <이벤트 증상>을(를) 경험했습니다. 이벤트는 <인시던트의 원인이 된 배포 또는 변경 시간>에 수행된 배포로 인해 트리거되었습니다. 해당 배포에는 <변경 이유에 대한 설명>(으)로 인한 코드 변경이 포함되어 있었습니다. 이 배포의 버그로 인해 <문제에 대한 설명>이(가) 발생했습니다.

이 이벤트는 <시스템>에서 감지되었습니다. 우리는 <취한 해결 조치>을(를) 통해 이벤트의 영향을 완화했습니다.

<심각도 수준> 인시던트는 X%의 고객에게 영향을 미쳤습니다.

이 인시던트와 관련하여 <지원 티켓 및/또는 소셜 미디어 게시물 개수>이(가) 제기되었습니다.

사전 요소

이 인시던트가 발생한 상황에 대해 설명합니다. 예를 들어 잠재 버그를 생성한 이전 변경사항 등입니다.

<날짜><시간>(<고객이 영향을 받기 전까지의 시간>)에 <제품 또는 서비스>을(를) <인시던트를 발생시킨 변경 사항에 대한 설명>과(와) 같이 변경했습니다. 해당 변경으로 인해 <변경 사항의 영향에 대한 설명>이(가) 발생했습니다.

결함

예상과 다르게 수행된 작업에 대해 설명합니다. 결함을 보여주는 관련 그래프 또는 데이터의 스크린샷을 첨부합니다.

<기간> 중에 X%의 요청에 대해 <숫자>개의 응답이 잘못 전송되었습니다.

영향

인시던트 발생 시 내부 고객과 외부 고객에게 표시된 내용에 대해 설명합니다. 제출된 지원 사례의 수를 기재해야 합니다.

<날짜>, <시간 범위><경과 시간> 동안 <인시던트 요약>이(가) 발생했습니다.

이로 인해<숫자> 명의 고객(전체 <시스템 또는 서비스>의 고객 중 X%)이 <고객이 경한한 증상에 대한 설명>을(를) 경험했습니다.

<지원 티켓 및 소셜 미디어 게시물 수>이(가) 제출되었습니다.

감지

Atlassian에서 언제, 어떻게 인시던트를 감지했는가?

어떻게 하면 감지 시간을 개선할 수 있는가? 사고 훈련으로, 어떻게 하면 시간을 반으로 줄일 수 있는가?

<알림 유형> 이(가) 트리거되고 <호출을 받은 팀 또는 개인>이(가) 호출되었을 때 인시던트가 감지되었습니다. 해당 팀 또는 개인에게 디스크에 서비스를 기록할 권한이 없었기 때문에 <2차 대응 담당자 또는 팀>을(를) 호출했으며, 이로 인해 대응이 <시간 길이> 지연되었습니다.

<개선을 소유한 팀>에서 <개선 영향>을(를) 구현하기 위해 <개선에 대한 설명>을(를) 준비할 예정입니다.

대응

누가 언제, 어떤 방법으로 대응했는가? 대응이 지연되거나 불가능했던 요인이 있었는가?

UTC 기준으로 14시 34분에 호출을 받은 후에 KITT 엔지니어가 14시 38분에 인시던트 채팅방에 접속했습니다. 그러나 대기 중인 엔지니어는 Escalator 오토스케일러에 대한 충분한 배경 지식이 없었기 때문에 14시 50분에 추가 알림을 보냈으며, 선임 KITT 엔지니어가 14시 58분에 채팅방에 접속했습니다.

복구

서비스가 복구된 방법과 시점에 대해 설명합니다. 영향을 완화하는 방법을 어떻게 찾았는가?

시나리오에 따라 추가 질문하기: 영향을 완화하기까지 소요되는 시간을 어떻게 개선할 수 있는가? 사고 훈련으로, 시간을 반으로 줄이려면 어떻게 해야 하는가?

다음 세 가지 방법으로 복구되었습니다.

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

  • Escalator 오토스케일러를 비활성화하여 클러스터의 범위가 급격하게 축소되는 것을 방지함

  • Build Engineering 스케줄러를 이전 버전으로 되돌림

일정

시간대가 포함된 타임스탬프를 기록하여 자세한 인시던트 타임라인을 시간순으로 제공합니다.

사전 요소, 영향 시작 시간, 감지 시간, 에스컬레이션, 의사결정, 변경사항, 영향 종료 시간이 모두 포함되어야 합니다.

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

11:48 - Control Plane K8S 1.9 업그레이드 완료
12:46 - V1.9 으로 Goliath 업그레이드 완료(클러스터 오토스케일러 및 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에서 300개 포드에 장애가 있다고 보고함
16:00 - BuildEng에서 OutOfCpu 보고서를 통해 장애가 있는 모든 빌드를 제거함
16:13 - BuildEng에서 새로운 빌드에서 장애가 지속적으로 반복되며, 일시적인 장애가 아님을 보고함
16:30 - KITT에서 장애를 인시던트로 인식하고 인시던트로 실행함
16:36 - KITT에서 문제의 영향을 완화하기 위해, Escalator 오토스케일러가 컴퓨팅 노드를 제거할 수 없도록 오토스케일러를 비활성화함
16:40 - KITT에서 ASG가 안정적이고, 클러스터 로드가 정상이며, 고객에게 미치는 영향이 해결되었음을 확인

다섯 번의 '왜?'

근본 원인 식별 기법을 사용합니다.

영향에서 시작하고 왜 인시던트가 발생했는지, 그리고 왜 그런 영향을 미쳤는지 질문합니다. 근본 원인을 찾을 때까지 계속 질문합니다.

여기에서, 또는 이슈에 첨부된 다이어그램에 이러한 이유를 목록으로 문서화합니다.

  1. 데이터베이스가 잠겼기 때문에 서비스가 중지됨

  2. 데이터베이스 쓰기 작업이 너무 많았기 때문에

  3. 서비스가 변경되었으며, 증가를 예상하지 못했기 때문에

  4. 부하 변경사항을 테스트하는 시점에 대한 개발 프로세스를 준비하지 않았기 때문에

  5. 부하 테스트를 한 번도 수행하지 않은 상태에서 새로운 수준의 규모에 도달함

근본 원인

근본 원인은 무엇이었는가? 이는 이러한 클래스의 인시던트가 반복되는 것을 막기 위해 변경해야 하는 사항입니다.

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

백로그 점검

백로그에 이러한 인시던트를 방지하거나, 인시던트의 영향을 크게 줄일 수 있었던 조치가 있는가? 그렇다면 왜 그러한 조치를 수행하지 않았는가?

솔직하게 평가해야만 우선순위와 위험에 대한 과거 의사결정을 밝히는 데 도움이 됩니다.

구체적으로 정해진 사항은 없습니다. 흐름 유형 지정에 대한 개선이 현재 진행 중인 것으로 알려져 있으며, 특정 방식이 마련되어 있습니다(예: 파일 변경/생성 시 흐름 유형 추가). 통합 테스트를 수정하기 위한 티켓이 만들어졌지만, 성공하지 못했습니다.

반복

이 인시던트가 이전에 동일한 원인으로 반복된 적이 있는가? 그렇다면 왜 다시 발생했는가?

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

교훈

어떤 점을 알게 되었는가?

잘한 일, 더 잘할 수 있었던 일, 다행히 개선 기회를 찾을 수 있었던 점에 대해 논의하세요.

  1. 작업의 속도 제한기가 올바르게 관리되고 있었는지 검증하기 위한 단위 테스트 필요

  2. 정상 작업과 다른 대량 작업의 작업량을 검토해야 함

  3. 대량 작업을 천천히 시작하고 모니터링해야 하며, 서비스 지표가 정상으로 표시되면 늘림

수정 조치

이 종류의 인시던트가 다시 발생하지 않게 하려면 무엇을 해야 하는가? 누가, 언제 조치를 취할 예정인가?

이슈에 대해 각 조치를 추적하는 "우선 순위 조치" 이슈 링크를 만듭니다.

  1. 오류 발생을 제한하기 위해 임시로 수동 자동 확장 속도 제한을 적용함

  2. 단위 테스트 및 작업 속도 제한을 재도입함

  3. 확장 효과를 관리하기 위해 클러스터에서 부하 분산 정도 정보를 수집하는 보조 메커니즘 도입함

  4. AWS ES는 자동 확장되지 않으므로 대규모 마이그레이션을 준비해야 함

  5. Stride 검색이 아직 티어 2로 분류되어 있는지 확인함

  6. xpsearch-chat-searcher가 실패할 경우 pf-directory-service에 대한 티켓을 완전 실패 대신 부분 실패로 제출

  7. ElasticSearch 클러스터의 높은 IO 문제를 확인하는 Cloudwatch 알림


직전 원인과 근본 원인

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

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

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

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

시나리오 직전 원인 및 조치 근본 원인 근본 원인의 영향 완화 방법

Stride "Red Dawn" 팀의 서비스에서 서비스를 위한 Datadog 모니터링 및 대기 중 알림이 없었거나 서비스가 적절하게 구성되지 않았습니다.

팀원이 새로운 서비스에 대한 모니터링과 알림을 구성하지 않았습니다.

해당 서비스를 위한 모니터링과 알림을 구성합니다.

모니터링과 알림을 비롯하여 새로운 서비스를 올바르게 실행하기 위한 프로세스가 없습니다.

새로운 서비스를 올바르게 실행하기 위한 프로세스를 만들고 팀에게 해당 프로세스를 준수하도록 교육합니다.

이 브라우저 버전에서 작동하지 않는 Fabric Editor로 업그레이드하여 IE11에서 Stride를 사용할 수 없습니다.

종속 서비스를 업그레이드했습니다.

업그레이드를 취소합니다.

브라우저 간 호환성 테스트를 하지 않았습니다.

지속적인 브라우저 간 호환성 테스트를 자동화합니다.

Micros EU의 로그가 로깅 서비스에 전달되지 않았습니다.

로그를 보내도록 Micros에 지정된 역할이 올바르지 않습니다.

역할을 수정합니다.

특정 환경의 로깅이 언제 작동하지 않는지 알 수 없습니다.

모든 환경의 누락된 로그에 대해 모니터링과 알림을 추가합니다.

이전 AWS 인시던트에 의해 트리거되어 Confluence Vertigo 노드에서 미디어에 대한 연결 풀이 소진되었으며, 고객이 계속 연결되지 못하고 미디어 오류가 발생합니다.

AWS에 결함이 있습니다.

AWS 사후 검토를 실시합니다.

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

버그를 수정하고 향후 비슷한 상황 발생 시 영향을 미치기 전에 감지하기 위해 모니터링을 추가합니다.


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

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

범주

정의

근본 원인에 대해 취해야 할 조치

버그

Atlassian에서 코드에 적용한 변경사항(특정한 유형의 변경)

테스트하고 카나리아 버전을 만든 후 단계적으로 롤아웃하고 감시합니다. 기능 플래그를 사용합니다. 품질 엔지니어에게 알립니다.

변경

코드에 대한 변경 외에 Atlassian에서 적용한 변경사항

변경하는 방법을 개선합니다. 예를 들어, 변경 검토 또는 변경 관리 프로세스 등이 있습니다. '버그' 외의 모든 사항도 여기에 해당합니다.

확장성

리소스 제약을 모르거나 용량 계획을 하지 않아서 확장에 실패함

서비스에 어떤 리소스 제약이 있습니까? 이러한 제약을 모니터링하고 알리고 있습니까? 용량 계획이 없으면 새로 만듭니다. 용량 계획이 있다면 새로운 제약으로 무엇을 고려해야 합니까?

아키텍처

설계가 운영 조건에 부합하지 않음

설계를 검토합니다. 플랫폼을 변경해야 합니까?

종속성

Atlassian이 아닌 제3자 서비스 결함

제3자 결함의 위험을 관리하고 있습니까? 위험을 수용하는 비즈니스 결정을 내렸습니까, 또는 완화 대책을 구축해야 합니까? 아래의 '종속 서비스 관련 근본 원인'을 참조하세요.

알 수 없음

확인 불가(조치: 진단 능력 향상)

로깅, 모니터링, 디버깅 및 비슷한 기능을 추가하여 시스템의 식별 능력을 개선합니다.


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

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

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

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

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

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

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


사후 검토 조치

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

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

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

범주 질문 예제

인시던트 조사

'이 인시던트가 어떤 상황에서 발생했으며 그 원인은 무엇인가?' 근본 원인을 찾는 것이 궁극적인 목표입니다.

로그 분석, 요청 경로를 다이어그램으로 작성, 힙 덤프 검토

이 인시던트의 영향 완화

'이 특정 이벤트를 해결하고 관리하기 위해 취한 즉각적 조치는 무엇인가?'

롤백, 체리 피킹, 푸싱 구성, 영향을 받는 사용자에게 알림

이 인시던트로 인한 손해 복구

'이 인시던트로 인한 즉각적 또는 부차적 손해를 어떻게 해결했는가?'

데이터 복원, 시스템 수정, 트래픽 다시 라우팅 제거

향후 인시던트 감지

'비슷한 오류를 정확히 감지하는 시간을 어떻게 줄일 수 있는가?'

모니터링, 알림, 입력/출력에 대한 타당성 점검

향후 인시던트의 영향 완화

'향후 이와 비슷한 인시던트 발생 시 심각도 및/또는 기간을 줄일 수 있는 방법은 무엇인가?'

'이러한 클래스의 오류가 다음에 다시 발생하는 경우 영향을 받는 사용자 비율을 어떻게 줄일 수 있는가?'

단계적 기능 축소, 중요하지 않은 결과 제외, 장애 시 열림, 대시보드 또는 플레이북 사용과 관련된 현재 방식 보강, 인시던트 프로세스 변경

향후 인시던트 방지

'어떻게 이러한 종류의 오류가 반복되는 것을 막을 수 있는가?'

코드 기반의 안정성 개선, 더욱 철저한 단위 테스트, 입력 유효성 검사 및 오류 조건에 대한 견고한 내성, 변경 제공

또한, Lueder와 Beyer의 조언을 참조하여 사후 검토 조치에 사용되는 표현을 결정했습니다.

사후 검토 조치의 표현:

사후 검토 조치에 올바른 표현을 사용하여 실행이 불가능하거나 미루는 것으로 인해 해당 조치가 무제한 연기되는 것을 막고 인시던트를 쉽게 완료할 수 있습니다. 잘 작성된 사후 조치는 다음과 같은 특징을 갖추고 있습니다.

실행 가능함: 동사로 시작하는 문장으로 각 조치를 표현합니다. 조치를 통해 프로세스가 아닌 유용한 결과를 얻어야 합니다. 예를 들어, '중요한 종속 서비스 목록을 열거하세요'는 좋은 조치인 반면, '종속 서비스를 조사하세요'는 좋은 결과를 만들 수 없습니다.

구체적임: 각 조치의 범위를 최대한 좁게 정의하여 작업에 포함되는 사항과 그렇지 않은 사항을 명확하게 합니다.

제한이 있음: 조치를 무기한 또는 진행 중 상태로 남겨놓는 대신 조치가 종료되는 시점을 알 수 있도록 각 조치를 표현

바람직하지 않은 표현 권장 표현

이 시나리오에 대한 모니터링을 조사하세요.

(작업 지정) 이 서비스에서 1%를 초과하여 오류가 반환된 모든 경우에 대해 알림을 추가하세요.

서비스 중단을 야기한 이슈를 수정하세요.

(구체적임) 사용자 주소 서식 입력의 유효하지 않은 우편번호를 안전하게 처리하세요.

엔지니어가 업데이트 전에 데이터베이스 스키마를 구문 분석할 수 있어야 합니다.

(작업 지정) 스키마 변경에 대해 자동화된 사전 제출 점검을 추가하세요.


사후 검토 승인

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

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

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

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


비난을 배제한 사후 검토

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

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

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

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

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

다음 단계
Template generator