안녕하세요. 오늘은 '사이트 신뢰성 엔지니어링' 이란 책을 읽으며 '구글의 포스트모텀'이란 문화를 소개 시켜드리려 합니다.
포스트모텀이란 ?
포스트모텀은 장애 발생 후에 이를 분석하고 개선점을 도출하는 과정으로, 일종의 회고문서와 유사한 개념입니다.
이 과정을 통해 향후 비슷한 문제의 재발을 예방하고 시스템을 강화하는데 도움이 됩니다.
포스트모텀을 진행할 경우, 일반적으로 구글 SRE 팀에서는 다음과 같은 사항을 문서로 기록합니다:
- 장애의 발생 기록(타임라인)과 그 영향: 장애가 발생한 시점부터 해결될 때까지의 시간 경과를 기록하고, 이로 인한 영향을 정확히 파악합니다. 이는 장애가 시스템 전반에 미친 영향을 이해하는 데 중요하죠.
- 장애를 완화하거나 해결하기 위한 수행한 작업: 장애를 해결하기 위해 수행한 모든 조치를 기록합니다. 이는 향후 유사한 문제에 대처할 때 참고 자료로 활용될 수 있습니다. ( 실제로 효과를 톡톡히 보고 있습니다 )
- 장애의 근본 원인과 근본 원인을 찾아가는 과정: 장애의 진짜 원인을 찾는 것이 중요합니다. 이를 통해 단순히 증상만 해결하는 것이 아니라, 시스템의 근본적인 문제를 해결할 수 있습니다.
- 재발 방지를 위한 후속 조치: 유사한 문제가 재발하지 않도록 예방하는 조치를 마련합니다. 이는 시스템의 안정성을 높이고, 사용자 경험을 향상시키는데 중요한 역할을 합니다.
이러한 포스트모텀 문서는 기록하는 것만으로 그치는 것이 아닌, 장애가 발생하게 된 원인에 대해 이해하며, 장애를 해결하기 위해
취한 조치들이 향후 또다른 장애의 재발을 막는데도 유용하게 쓰기 위함입니다.
또한 , 시스템의 취약점을 고칠 수 있는 기회임과 동시에 더 견고하게 만드는 기회라고도 볼 수 있습니다. ( 시스템의 어느 부분을 어떻게 개선할 수 있는지에 대한 결과를 도출하면 더욱 좋겠죠 )
마냥 좋아보이는 문화이긴 하지만 주의할 점으로는, 문서를 작성함과 동시에 누군가의 실수도 드러날 수 있기 마련입니다. 그러나, 이것 은 비난의 목적으로는 작성하지 말아야 합니다.
누군가를 지적하거나 비난하는 분위기는 자칫 장애나 이슈를 숨기려는 문화를 만들 위험이 있으며, 이는 곧 속한 조직이나 회사에 더 큰 위험을 야기할 수도 있습니다.
그렇다면 포스트모텀은 어떤것을 어떻게 작성해야 좋을까요 ? 구글의 SRE팀에선 직접 정의한 템플릿을 사용하고 있습니다.
날짜: [포스트모텀 작성일]
작성자: [작성자 이름 혹은 팀 이름]
상태: [완료, 추가 조치 진행 중 등]
요약: [장애 발생에 대한 간략한 설명]
영향: [장애로 인한 영향에 대한 설명]
근본 원인: [장애의 근본적인 원인에 대한 분석]
발생 원인: [장애가 발생한 구체적인 원인]
해결책: [장애를 해결하기 위해 시행한 조치]
장애 탐지: [장애가 탐지되었던 방법 및 과정]
추가 조치: [장애 이후에 시행한 추가 조치]
회고:
- 잘 진행한 부분: [포스트모텀 과정에서 잘 수행된 부분에 대한 긍정적인 평가]
- 미흡했던 부분: [포스트모텀 과정에서 개선이 필요한 부분에 대한 비판적인 평가]
시간대별 조치사항: [장애 발생 시 시간대별로 취한 조치들에 대한 상세 기록]
추가 정보 및 참고: [필요한 경우 추가적인 정보나 참고 자료에 대한 기재]
이미 이러한 문화를 잘 갖추고 계시거나, 이와 비슷한 형식의 문서를 자연스럽게 작성하고 계실지도 모릅니다. ( 저 또한 그랬습니다 허허허 )
저 또한 사내에서 장애에 대한 문서가 위와 거의 유사한 형식으로 관리 되고 있었고, 위급 상황일 때도 해당 문서가 아주 많은 도움이 되었습니다.
그러다 우연히 책을 읽으며 유사한 내용을 보니 반갑기도 하고 , 뿌듯하기도 하네요
그래서 좀 더 이런 좋은 문화를 널리 퍼뜨렸으면 하는 마음에 이렇게 글로 녹여내게 되었습니다.
긴 글 읽어주셔서 감사합니다.
'이것저것' 카테고리의 다른 글
| DevOps 면접 질문 및 (내) 답변 (0) | 2023.07.29 |
|---|