Close

빠른 속도의 팀을 위한 인시던트 관리

인시던트 사후 검토 프로세스의 중요성

인시던트는 발생하기 마련입니다.

시스템의 규모와 복잡성이 증가할수록 실패는 불가피합니다.

인시던트는 학습의 기회이기도 합니다.

시스템의 취약성을 발견하고 반복적인 인시던트를 완화하며 해결 시간을 단축할 기회입니다. 이 기회를 통해 팀을 하나로 모으고 다음 번에 더 개선할 방법을 계획할 수 있습니다.

인시던트 중에 발생한 일을 분석하고 배운 교훈을 기록하는 데 가장 좋은 방법은 인시던트 사후 검토입니다.

인시던트 사후 검토에서는 다같이 모여 인시던트의 세부 사항, 즉 인시던트가 발생한 이유, 영향, 완화하고 해결하기 위해 취한 조치 및 다시 발생하지 않도록 해야 할 일에 대해 논의합니다.

버전 관리, 기능 플래그 및 지속적 제공과 같은 도구 덕분에 많은 인시던트는 빠르게 해결 가능합니다. 프로덕션으로 푸시된 변경의 버그로 인해 발생하는 경우가 많으며, 변경을 롤백하면 앱이 다시 작동할 수 있습니다. 이 도구는 모든 사용자에게 유용하며 서비스가 빠르게 다시 작동되도록 합니다. 하지만 무엇이 왜 실패했는지 파악할 수 없는 경우가 많습니다. 이때 사후 검토를 활용하면 됩니다.

인시던트 사후 검토는 인시던트로부터 배우고 문제를 통해 발전하기 위한 프레임워크입니다. 또한 고객, 동료, 최종 사용자(기본적으로 인시던트의 영향을 받는 사용자)와의 신뢰를 쌓으며 팀이 향후 인시던트 및 그 영향을 최소화하기 위해 노력하고 있다는 것을 알립니다.

A chance to uncover vulnerabilities in your system. An opportunity to mitigate repeat incidents and decrease time to resolution. A time to bring your teams together and plan for how they can be even better next time. 

The best way to work through what happened during an incident and capture any lessons learned is by conducting an incident postmortem, also known as a post-incident review. 

An incident postmortem brings people together to discuss the details of an incident: why it happened, its impact, what actions were taken to mitigate it and resolve it, and what should be done to prevent it from happening again.

Thanks to tools like version control, feature flags, and continuous delivery, a lot of incidents can be quickly “undone.” Many incidents are caused by some bug in a change pushed to production, and rolling back that change can get the app up and running again. This is really beneficial for everyone, it gets the service quickly working again. But it often doesn’t help you understand what failed and why. This is where postmortems come in.

An incident postmortem is a framework for learning from incidents and turning problems into progress. It also builds trust with customers, colleagues, and end users (basically the folks affected by the incident) and lets them know your team is working to minimize future incidents and impact.

사후 검토 주기 그림

사후 검토는 상시 가동 서비스의 수명 주기에서 중요한 단계입니다. 사후 검토의 결과는 계획 프로세스에 바로 반영해야 합니다. 이렇게 하면 사후 검토 과정에서 식별한 중요한 수정 작업이 향후 작업에서 적절히 이루어지고 다른 향후 작업 및 우선 순위와 균형을 이룰 수 있습니다.

인시던트 사후 검토의 이점

특히 인시던트의 원인을 확실히 알고 있으며 문제를 해결했다고 확신하는 경우 공식적인 인시던트 사후 검토 회의 및 작성을 건너뛰고 싶을 수 있습니다.

여러분이 내용을 자세히 알더라도 일부 팀원은 인시던트의 원인을 아직 이해하지 못했을 수 있으며, 명확하게 이해하면 팀 및 고객에게 제공하는 서비스를 개선할 수 있습니다.

구조화된 공동 작업 프로세스에 참여하도록 팀원을 하나로 모으면 모두가 각자 배운 내용을 공유하고 팀 내에서 신뢰와 복원력을 쌓을 수 있습니다. 또한 인시던트와 팀에서 이것을 해결한 방법을 문서화하면 향후 인시던트를 어떻게 처리할지 알려줄 수 있습니다.

또한 인시던트 사후 검토에는 고객 또는 나머지 조직에 대한 요점을 게시할 수도 있습니다. 그렇게 하면 인시던트가 발생했을 때 밀접하게 관여하지 않았을 수 있는 사용자에게 자신감을 심어주는 데 중요한 역할을 할 수 있습니다. 조직의 다른 팀, 특히 리더십 팀은 나중에 팀에 대한 비판이 이루어지지 않도록 문제의 세부 사항 및 문제 해결을 위해 취한 조치를 확인해야 할 수 있습니다.

파트너, 고객 및 최종 사용자 역시 어떤 일이 있었는지, 그리고 경험 개선을 위해 어떤 조치가 이루어졌는지 알고 싶어 할 수 있습니다. 경우에 따라 공개 웹사이트에서 인시던트 사후 검토를 제공하기가 적절하지 않을 수도 있지만, 말을 표현하는 데 마케팅 또는 홍보 팀의 도움을 받아 유익하고 서비스에 대한 신뢰를 쌓는 방식으로 정보를 제공할 수 있습니다.

인시던트 사후 검토 모범 사례

인시던트 사후 검토에 접근하는 방법은 취한 조치의 체크리스트만큼 중요합니다. 인시던트가 발생하면 긴장이 심해질 수 있습니다. 어려운 문제를 해결하는 데 참여하고 준비되도록 만드는 데 핵심 요소는 심리적 안정감을 주는 것입니다.

비난을 배제한 문화 구축

Etsy의 전 CTO John Allspaw는 “남을 탓하지 않는 사후 검토”에 대한 중요한 글을 썼습니다. 인시던트 조사에 대한 이 접근 방식을 통해 인시던트 관련자는 처벌이나 보복을 두려워하지 않고 자신의 모든 행동, 영향 및 알고 있던 내용과 시기를 설명할 수 있습니다.

이 접근 방식은 팀이 공개적으로 정보를 공유하고 인시던트의 근본적인 원인을 파악하는 데 중요합니다. 비난받을까 봐 두려워하는 경우 정보를 숨기거나 책임을 전가하려고 할 수 있습니다. 이런 일이 생기면 서로에 대한 신뢰가 무너지며 조직은 팀과 시스템의 복원력을 쌓을 기회를 잃게 됩니다. Atlassian 및 Google을 포함한 많은 팀에서는 이 함정에 빠지는 것을 피하기 위해 남을 탓하지 않는 사후 검토 방법을 채택했습니다.

비난하지 말고 비판을 건설적으로 유지

사후 검토 회의를 하고 후속 조사 결과를 작성할 때, 인시던트에 대한 책임이 있는 개인을 특정하는 언어는 피하세요. 그 대신 행동, 결과 및 영향에 집중하세요.

대화를 안전하고 객관적으로 유지하는 것은 중요하지만, 문제를 해결하려면 인시던트의 근본 원인을 파악해야 합니다. 회의에서는 “5가지 원인”이라는 기술을 사용할 수 있습니다. 먼저, 모두 문제가 무엇인지에 동의하는지 확인합니다. 그런 다음 왜 이런 일이 발생했는지 물어본 다음 그 답변에 대해 “왜”라는 질문을 합니다. 이 과정을 다섯 번 이상 반복하여 문제의 원인이 되는 모든 심층적인 요인을 발견했는지 확인합니다. 회의에서 불편한 진실을 피하거나 대충 합의에 도달하려고 하면 안 됩니다. “5가지 원인” 접근 방식은 플레이북 플레이를 통해 자세히 알아볼 수 있습니다.

모든 사후 검토를 확인하고 프로세스에 반영

검토하지 않은 인시던트 사후 검토 보고서는 작성되지 않은 것이나 마찬가지입니다. 인시던트 사후 검토 보고서의 초안을 작성한 후에는 보고서를 검토하여 해결되지 않은 문제를 처리하고, 향후 고려할 아이디어를 기록하고, 보고서를 마무리하는 것이 중요합니다. 이 검토가 이루어질 때까지는 인시던트가 실제로 해결되지 않았다고도 할 수 있습니다.

그렇게 하는 방법은, 인시던트 사후 검토 보고서를 검토하기 위해 엔지니어링(및 고객 지원 또는 계정 관리자 등 관련 있는 사용자) 팀과 한 달에 한 번 이상 정기적인 회의를 잡는 것입니다. 최근 보고서 또는 이전 보고서를 검토하고 현재에도 관련 있는 교훈을 공유할 수 있습니다.

효과적인 인시던트 사후 검토 계획

효과적인 사후 검토, 그리고 지속적으로 개선되는 문화를 구축하기 위해서는 모두가 참여할 수 있는 간단하고 반복 가능한 프로세스를 구현해야 합니다. 문화와 팀에 따라 방법이 다릅니다. Atlassian에서는 저희에게 적합한 방법을 개발했으며 인시던트 핸드북에서 자세한 내용을 읽어볼 수 있습니다.

시작하기 위한 몇 가지 팁은 다음과 같습니다.

팁 1: 임계값 설정

조직의 인시던트는 명확하고 측정 가능한 심각도 수준이어야 합니다. 이 심각도 수준을 사용하여 사후 검토 프로세스를 트리거할 수 있습니다. 예를 들어 심각도 1 이상의 인시던트는 사후 검토 프로세스를 트리거하는 반면, 덜 심각한 인시던트의 경우 사후 검토가 선택 사항이 될 수 있습니다. 팀 리더나 경영진에게 임계값을 충족하지 않는 인시던트에 대해 사후 검토 조사를 요청할 기회를 제공하는 것이 좋습니다.

팁 2: 미루지 않기

인시던트가 발생한 후에 휴식을 취하는 것도 중요하지만 인시던트 사후 검토 작성을 미루지 않는 것도 중요합니다. 시간이 너무 오래 지나면 중요한 세부 정보를 잊어버릴 수 있습니다. 인시던트 해결 후 24~48시간 이내에 인시던트 후 검토 회의를 열고 초안을 작성하여 영업일 기준 5일 이내로 작성하는 것이 가장 좋습니다.

팁 3: 역할 및 소유자 할당

인시던트 후 검토 회의에서는 인시던트 사후 검토에 기록할 세부 정보를 논의하게 됩니다. 이상적으로 사후 검토 초안은 인시던트에 대해 잘 알고 있으며 원인과 완화 방법을 이해하는 데 요구되는 수준의 기술 및 조직적 지식을 갖춘 담당자에게 위임하는 것이 좋습니다.

팁 4: 템플릿에서 작업

템플릿을 사용하면 주요 세부 정보가 생략되는 것을 방지할 수 있습니다. 사후 검토 과정 전반에서 일관성을 유지하기에 좋은 방법입니다.

팁 5: 타임라인 포함

타임라인은 인시던트 문서화에 큰 도움이 되며, 일어난 일의 규모를 평가할 때 대부분 가장 먼저 타임라인을 확인합니다. 최대한 명확하고 구체적으로 작성하세요. 예를 들어 “11시쯤”이 아니라 “태평양 표준시 오전 11시 14분”으로 작성해야 합니다. 타임스탬프를 구체적으로 지정하면 연쇄적인 이벤트를 충실도 높게 매핑할 수 있으므로 개선할 영역을 파악하는 데 유용합니다. 예를 들어 영향이 시작된 시점과 고객에게 알림을 받은 시점 사이의 간격이 너무 길다는 점을 알아낼 수 있습니다.

포함해야 할 중요한 시간.

  • 첫 번째 알림 또는 티켓
  • 첫 번째 커뮤니케이션 공지(내부 및/또는 외부)
  • 상태 페이지 업데이트 시간
  • 수정 시도 시간(코드 롤백 등)
  • 문제 해결 시간

팁 6: 세부 정보의 중요성

세부 정보를 생략하는 것은 쓸모 없고 불분명한 사후 검토를 향한 지름길입니다. 인시던트 중에 발생한 일과 이루어진 조치에 대해 최대한 많은 세부 정보를 추가하세요. “공개 커뮤니케이션이 이루어짐” 대신 “공개 상태 페이지와 Twitter 계정에서 인시던트를 알리는 초기 공개 커뮤니케이션이 이루어졌습니다”라고 해야 합니다.

가능한 경우 링크와 이름, 티켓 및 상태 업데이트에 대한 링크, 인시던트 상태 문서 링크 및 모니터링 차트를 포함하세요. 관련 그래픽 또는 대시보드의 스크린샷도 부담 없이 추가하세요. 인시던트의 시작 및 종료 시간을 명확하게 보여주는 모니터링 시스템의 그래프(예: 요청률 감소 후 정상 상태로의 복귀)는 모호하지 않기 때문에 매우 유용합니다. 예를 들어 데이터베이스 연결, 네트워크 연결 상태 또는 해당 기간의 CPU/메모리/입출력/대역폭 소비와 같이 그 시간 동안 백그라운드에서 무슨 일이 있었는지 보여주는 그래프와 결합하면 효과가 더 높아집니다.

팁 7: 인시던트 메트릭 캡처

인시던트 사후 검토에서 메트릭을 캡처할 때는 문제와 그 영향에 하드 데이터를 적용하게 됩니다. 이 데이터 포인트가 있으면 팀이 올바른 방향으로 나아가고 있는지 확인하고 인시던트 개수, 심각도 및 가동 중지 시간을 줄일 수 있습니다. 일관된 메트릭을 측정하면 한 걸음 물러서서 시간 경과에 따른 인시던트 추세를 살펴볼 수 있습니다.

인시던트 사후 검토 추적에서 고려해야 할 몇 가지 메트릭:

  • 증가 또는 감소하는지 추적 가능한 가동 중지 시간(분).
  • 시스템의 상대적 안정성을 확인할 수 있는 인시던트의 심각도.
  • 처음 보고된 시점부터 인시던트를 해결하기까지 걸리는 평균 시간을 측정하는 평균 해결 시간(MTTR).

가장 중요한 팁은 건너뛰는 단계가 없어야 한다는 것입니다. 팀과 시스템을 개선을 개선할 수 있는 인시던트 사후 검토를 수행할 때 핵심은 프로세스를 마련하고 따르는 것입니다.

인시던트 사후 검토 템플릿을 사용하여 프로세스 간소화

팀이 인시던트 사후 검토를 중심으로 문화를 개발할 수 있도록 하려면 정보를 캡처하고, 회의를 예약하고, 재사용 가능한 체크리스트와 템플릿을 사용하여 최종 보고서를 게시하기 쉽게 만들어야 합니다. 반복 가능한 프로세스를 통해 일관성을 제공하고 기대치를 설정할 수 있으며 생산적인 사고 방식을 가지고 프로세스에 임할 수 있습니다.

인시던트 사후 검토 프로세스에 대한 일반적인 체크리스트 항목:

열어야 할 회의:

  • 정보 수집을 위한 회의
  • 보고서 검토
  • 보고서 프레젠테이션

미리 수집해야 하는 정보:

  • 각 회의의 표준 안건
  • 참가자, 이해 관계자, 검토자
  • 템플릿을 통해 인시던트 사후 검토 보고서 작성을 표준화
다음 단계
Template