15. 포스트모텀 문화: 실패로부터 배우기

실패의 비용은 교육이다 - 데빈 캐러웨이

구글의 포스트모텀 철학

• 장애에 대한 내용을 문서화하고, 장애가 발생하게 된 원인에 대해 이해하며, 무엇보다 장애를 해결하기 위한 취한 조치들이 향후 장애의 재발을 막는 데도 유용하게 사용될 수 있도록 하기 위함
• 포스트모텀은 불이익을 주기 위한 것이 아님
• 회사 전체가 실패로부터 새로운 것을 배울 수 있는 기회
• 보통 포스트모텀은 다음과 같은 상황이 발생했을 때 수행
  • 사용자가 다운타임을 경험했거나 신뢰성이 목표치 이하로 떨어진 경우
  • 종류에 관계 없이 데이터 손실이 발생한 경우
  • 비상 대기 엔지니어의 중재가 발생한 경우
  • 장애의 해결 시간이 목표치보다 오래 걸린 경우
  • 모니터링 장애 시 (장애를 사람이 직접 발견한 경우)
• 서로를 비난하지 않는 포스트모텀은 SRE문화의 신조

협업과 지식의 공유

• 포스트모텀 절차에는 모든 단계마다의 협업과 지식 공유가 담겨있음
• 포스트모텀 템플릿 (부록 D참조), Confluence에도 있음

실시간 협업

열린 댓글/주석 시스템

이메일 알림

리뷰 과정

• 나중을 대비해 장애에 대한 핵심 데이터를 수집하고 있는가?
• 장애의 영향이 완벽하게 처리되었는가?
• 장애의 근본 원인이 충분히 사려 깊게 분석되었는가?
• 후속 조치 계획이 적절하며 버그 수정 작업들의 우선순위가 적절하게 조정되었는가?
• 관련 의사 결정자들에게 이 결과를 공유했는가?

모든 포스트모텀 문서는 반드시 리뷰를 거쳐야 한다.

포스트모텀 문화 도입하기

• 포스트모텀 문화를 소개하는 것은 말처럼 쉬운 일은 아니다
• 선임 관리자가 적극적으로 리뷰 및 협업 절차에 개입하게 함으로써 협력적인 포스트모텀 문화를 정착시키기 위해 노력함
• 특정인을 비방하지 않는 포스트모텀은 스스로 동기를 부여하는 엔지니어의 산출물으로써 태어나는 것이 이상적

이달의 포스트 모텀

구긆츨러스 포스트모텀 그룹

포스트모텀 읽기 클럽

불행의 바퀴 (wheel of misfortune)

• 새로 입사한 SRE들은 종종 불행의 바퀴 연습을 수행한다.
• 이전의 포스트모텀 중 하나를 선정해서 엔지니어들이 그 안에 기록된 대로 역할을 수행해보는 것
• 실제와 같은 경험을 위해 당시 장애 제어를 담당했던 사람이 함께 참여 함

어려움

• 구성원들이 준비 과정 대비 실제 가치에 의문을 제기할 수 있음

해결 전략

• 포스트모텀을 작업의 일부로 편입. 일정한 시범 기간을 거쳐 성공적인 포스트모텀 문서를 작성해보면 그 가치를 입증할 수 있음
• 앞서 언급한 사회적 방법들을 통해 공개적으로, 그리고 개인과 팀의 역량 관리를 통해 효과적으로 작성된 포스트모텀 문서에 보상을 부여하고 축하해 줌
• 선임 리더들의 관심과 참여를 독려한다. 래리 페이지마저도 포스트모텀의 높은 가치를 역설함

결론 및 지속적인 개선

• 매달 구글 전체가 만들어내는 엄청난 양의 포스트모텀 문서를 수집하는 도구 역시 점점 더 유용하게 활용되고 있음
• GPT로 뭔가 할 수 있지 않을까…?