이번 장에서는 포스트모텀의 수행 시기를 결정하기 위한 조건, 포스트모텀 작성 이유에 대해 알아보도록 하자.
1. 구글의 포스트모텀 철학
포스트모텀을 작성하는 가장 큰 이유는 장애에 대한 내용을 문서화하고, 장애가 발생하게 된 원인에 대해 이해하며, 무엇보다 장애를 해결하기 위해 취한 조치들이 향후 장애의 재발을 막는 데도 유용하게 사용될 수 있도록 하기 위함이다.
포스트모텀은 불이익을 주기 위한 것이 아니다. 회사 전체가 실패로부터 새로운 것을 배울 수 있는 기회인 것이다. 팀마다 조금씩 다르겠지만 보통 포스트모텀은 다음과 같은 상황이 발생했을 때 수행한다.
- 사용자가 다운타임을 경험했거나 신뢰성이 목표치 이하로 떨어진 경우
- 종류에 관계 없이 데이터 손실이 발생한 경우
- 장애의 해결 시간이 목표치보다 오래 걸린 경우
- ...
장애가 발생하기 전에 포스트모텀을 수행하는 조건을 미리 선정하여 언제 포스트모텀이 필요한지 모두가 이해하게끔 하는 것이 중요하다. 이렇게 선정된 조건들 외에도 의사 결정자가 포스틑모텀을 요청할 수 있다.
2. 협업과 지식의 공유
포스트모텀 절차에는 모든 단계마다의 협업과 지식 공유가 담겨있다.
- 실시간 협업: 데이터와 아이디어를 실시간으로 신속하게 수집할 수 있다. 포스트모텀 문서 생성 초기에 매우 유용하다.
- 열린 댓글/주석 시스템: 집단 지성을 쉽게 활용하며 그 적용 범위를 넓힐 수 있다.
- 이메일 알림: 문서를 함께 편집 중인 사람들에게 메일 알림을 보내거나 혹은 다른 사람들의 추가 의견을 기대할 때 그 사람을 문서 편집자로 초대할 수 있다.
포스트모텀 문서의 작성은 형식적인 리뷰 및 발행 절차도 포함하고 있다. 실질적으로 팀은 포스트모텀의 첫 번째 초안을 내부적으로 공유하여 선임 엔지니어들이 초안을 검토하고 그 완성도를 높이도록 하는 방법을 취하는 것이 낫다. 리뷰 과정에서는 다음과 같은 항목이 포함될 수 있다.
- 나중을 대비해 장애에 대한 핵심 데이터를 수집하고 있는가?
- 장애의 영향이 완벽하게 처리되었는가?
- 장애의 근본 원인이 충분히 사려 깊게 분석되었는가?
- 후속 조치 계획이 적절하며 버그 수정 작업들의 우선순위가 적절하게 조정되었는가?
- 관련 의사 결정자들에게 이 결과를 공유했는가?
3. 결론
포스트모텀 문화가 잘 정착되어 있으면 장애는 점점 줄어들고 더 나은 사용자 경험을 제공할 수 있을 것이라 생각한다. 현재 내가 속한 팀에는 포스트모텀 문화가 잘 정착되어 있는 것 같지만 부족한 부분도 분명히 있는 것 같다. 특히 명시적으로 리뷰하는 단계가 따로 없기 때문에 포스트모텀 문서 자체의 완성도는 떨어질 수 있을 것 같다는 생각이 든다. 이 부분은 앞으로 개선하도록 해야겠다.
'CS > SRE' 카테고리의 다른 글
Ch17. 신뢰성을 위한 테스트 (0) | 2023.08.30 |
---|---|
Ch16. 시스템 중단 추적하기 (0) | 2023.08.23 |
Ch14. 장애 관리하기 (0) | 2023.08.23 |
Ch13. 긴급 대응 (0) | 2023.08.16 |
Ch12. 효과적인 장애 조치 (0) | 2023.08.16 |