빠른 속도의 팀을 위한 인시던트 관리
공개 및 비공개 인시던트 사후 검토 비교
공개적인 인시던트 발생 후 설명을 공유할 적절한 시기 파악
거의 모든 IT 인시던트가 발생한 조직의 네 가지 벽 안에만 고립되어 있을 때가 있었습니다. 그러나 오늘날 웹 서비스와 클라우드 인프라에서는 그런 경우가 거의 없습니다. 기술 인시던트는 진정한 “일대다” 형식의 문제이며 팀이 인시던트에 대응하고 학습하며 커뮤니케이션 방식에 큰 변화를 가져왔습니다.
인시던트 사후 검토(흔히 “인시던트 후 검토” 또는 “PIR”이라고도 함)에 대해 생각해 보세요.
인시던트 사후 검토에서는 다같이 모여 인시던트의 세부 사항, 즉 인시던트가 발생한 이유, 영향, 완화하고 해결하기 위해 취한 조치 및 다시 발생하지 않도록 해야 할 일에 대해 논의합니다.
인시던트 사후 검토는 두 가지 아티팩트로 나눌 수 있습니다. 하나는 인시던트에 대해 논의하는 회의, 나머지 하나는 그 회의의 출력으로서 만들어지는 해당 사후 검토 보고서입니다.
두 가지 활동, 즉 회의와 보고서는 관계자가 “사후 검토”라고 할 때 같은 의미로 사용되는 경우가 많습니다. 사후 검토라는 용어를 사용하는 사용자는 둘 중 하나, 또는 둘 다에 대해 말하고 있는 것일 수 있습니다.
파트너, 고객 및 최종 사용자 역시 어떤 일이 있었는지, 그리고 경험 개선을 위해 어떤 조치가 이루어졌는지 알고 싶어 할 수 있습니다. 경우에 따라 공개 웹사이트에서 인시던트 사후 검토를 제공하기가 적절하지 않을 수도 있지만, 말을 표현하는 데 마케팅 또는 홍보 팀의 도움을 받아 유익하고 서비스에 대한 신뢰를 쌓는 방식으로 정보를 제공할 수 있습니다.
인시던트 사후 검토를 해야 하는 경우
Atlassian에서는 항상 심각도 1 및 2(“주요”) 인시던트에 대해 내부적인 사후 검토를 수행합니다. 경미한 인시던트의 경우 사후 검토는 선택 사항입니다. Atlassian에서는 유용할 만한 모든 상황에서 사후 검토 프로세스를 이용할 것을 권장합니다.
누가 사후 검토를 완료하나요?
일반적으로 인시던트를 유발한 서비스를 제공하는 팀은 관련 사후 검토를 완료할 책임이 있습니다. 이들은 사후 검토 완료에 대한 책임을 질 담당자를 지명하고 이슈를 할당합니다. 이들은 "사후 검토 소유자"라고 하며, 사후 검토를 게시하기 전까지 초안 작성과 승인을 통해 사후 검토 작업을 수행합니다. 인프라 및 플랫폼 수준의 인시던트는 회사의 단면에 영향을 미치는 경우가 많기 때문에 사후 검토가 더 복잡하고 노력이 많이 들어갑니다. 그렇기 때문에 Atlassian은 때때로 전담 프로그램 관리자를 자체 인프라 또는 플랫폼 수준의 사후 검토에 할당합니다. 이 직원은 그룹 간 작업에 더 적합하고 필요한 수준의 노력을 기울일 수 있기 때문입니다.
내부적인 사후 검토 보고서 공유
사후 검토가 승인되면 배운 내용을 회사 전체와 공유하여 그 가치를 배가시킬 수 있습니다. 이것을 위해 Atlassian은 사후 검토 티켓이 승인되면 Confluence에서 초안 블로그 게시물을 만드는 자동화 작업을 갖추고 있습니다.
공개 인시던트 사후 검토 보고서 만들기
흔하지는 않지만, 인시던트 발생 후 사후 검토의 공개 버전을 게시하는 것이 좋을 때도 있습니다.
공개 버전을 게시하는 것은 많은 사용자에게 영향을 미치는 중단을 겪는 대규모 소비자 서비스에서 특히 일반적입니다. 이 팀은 내부적인 보고서의 전체 내용이 아니라 축소된 버전을 게시하는 경우가 많습니다. 개인 정보나 민감한 정보는 모두 지워야 합니다.
공개 인시던트 사후 검토 보고서 공유
공개 사후 검토를 어떤 채널에 게시하는 것이 적합한지 파악하기란 까다로울 수 있습니다. 어떤 팀에서는 회사 블로그 또는 웹사이트에 바로 게시할 수 있지만, 어떤 팀은 사후 검토를 게시하기에 알맞은 별도의 엔지니어링 블로그를 가지고 있기도 합니다.
Atlassian의 제품인 Statuspage에서, 사용자는 인시던트가 해결된 후 상태 페이지에 바로 공개 사후 검토를 게시할 수 있습니다.