포스트모템 템플릿

[ej31]

아래 블럭의 내용을 복사해서 쓰시면 되겠습니다. 👴

# 포스트 모템
> [!NOTE]  
> 모든 사항 섹션을 모두 적을 필요 없습니다.
> 필요한 부분만 선택적으로 적어야 합니다.
> 다만, 사건이 왜 발생했고 어떻게 인지했으며 두번 실수 하지않으려면 어떻게 해야하는지에 대한 분석은 꼭 포함되어> 야 합니다.





## 원인 분석

> [!NOTE]
> 무슨 일이 일어났는지, 왜 발생했는지, 사건의 심각도, 지속 기간 등 사건의 요약을 작성합니다.
> 예: 2016년 4월 11일 월요일 사전 배포 회의 중 웹 사이트 X의 운영 환경에서 버그가 발견되었습니다. 이로 인해 서비스가 45분간 다운되었습니다.






## 무슨 일이 있었나요?

> [!NOTE]
> 사건을 초래한 이벤트에 대한 간략한 설명을 포함합니다
> 예: 디버깅 완료 된 코드가 `git stash` 로 인해 커밋에서 누락 된 채 운영환경에 배포되었다.









## 기여 요인 또는 근본 원인 식별

> [!NOTE]
> 문제의 원인이 된 모든 조건에 대한 설명을 포함해주세요!
>
> 영향에 대한 설명으로 시작하고 그 영향이 발생한 이유를 확인해야합니다.
> 발생한 문제가 서비스에 미친 영향도 같이 주목해야 합니다.
> 왜 이런 일이 발생했는지, 그리고 왜 결과적으로 영향을 미쳤는지 확인하셔야 합니다.
> 최종적으로 근본 원인에 도달할 때까지 계속해서 "왜"라고 묻습니다.

> [!TIP]
> 👉 **예시**
> 1. 데이터베이스에 락이 걸려 애플리케이션이 중단되었습니다.
> 2. 데이터베이스에 대한 INSERT가 너무 많아 데이터베이스가 잠겼습니다.
> 3. 서비스에 변경 사항을 적용하고 INSERT 증가를 예상하지 않았기 때문입니다.
> 4. 부하 테스트 변경을 위한 개발 프로세스가 확립되어 있지 않기 때문입니다.
> 5. 이 정도 규모에 도달할 때까지 로드 테스트가 필요하다고 느낀 적이 없었기 때문입니다.








## 근본 원인
> [!NOTE]
> 다운타임이 발생하게 된 근본 원인, 즉 이 사고가 다시 발생하지 않도록 변경해야 하는 요소를 기록해야 합니다








## 다운타임으로 인한 영향

> [!NOTE]
> 사건이 발생하는 동안 내부 및 외부 사용자에게 어떤 영향을 미쳤는지 설명합니다.
> 가능하다면 아주 구체적으로 영향을 설명하고 정확한 숫자를 포함해서 기록하는 것이 좋습니다.

> [!TIP]
> 👉 **예시**
> 약 12억 1천만 개의 쿼리가 손실되었으며 수익에는 영향이 없습니다.
> 유저는 다운타임 45분 동안 브라우저 접속은 가능 했지만 백엔드 서버가 작동하지 않아 정상적인 페이지를 볼 수 없었습니다.
> 프론트엔드 코드에 포함 된 fetch 가 모두 작동하지 않아 브라우저에는 하얀화면만 보였습니다.
> 다운타임동안 접속한 유니크 유저는 1,200명 입니다.








## 문제를 어떻게 발견했나요

> [!NOTE]
> 팀이 사건을 어떻게 감지했는지, 사건이 발생했다는 것을 어떻게 알았는지, 감지 시간을 어떻게 단축할 수 있는지 설명하세요.
> **예:** 센트리를 통해 디스코드에 알람을 보고 받아서 즉각 온콜을 진행했습니다.









## 응답 관련 요소들

> [!NOTE]
> 이 다운타임에 누가 대응했고, 언제 대응했고, 무엇을 했는지 적어보세요.
> 이 과정에서 서비스 다운 상황 파악부터 해소까지 의사소통에 지연요소는 없었는지 작성해주세요

> [!TIP]
> 👉 **예시**
> 최초 루시를 통해 상황이 전파 되었습니다. 해당 시간은 오전 11:30 이었고 와탭을 통해 확인했습니다.
> 모든 팀원이 문제를 인식하는데까지는 약 15분의 시간이 걸렸습니다. (11:45)
> 이후 정확한 문제확인을 위해 센트리 및 AWS 의 EC2 메트릭을 확인했습니다.
> 모든 팀원이 직무별 미팅을 참석해 장애 상황을 인지하는데까지 더 많은 시간이 걸렸습니다.
> 최종적으로 45분간 다운타임이 있었습니다.










## 해결

> [!NOTE]
> 문제를 해결한 방법을 설명하세요.
> 임시 해결책이 있는 경우 장기적인 해결책과 함께 이를 설명합니다.

> [!TIP]
> **예시**
> 순환참조 에러를 해결하기 위해 우선 긴급 롤백을 진행했습니다.
> 롤백 완료 후 해당 문제를 일으키는 함수를 핫픽스로 수정한 뒤 재배포 했습니다.
> 해당 문제사항이 해결 됐는지 2시간동안 추가적으로 모니터링했으며 서비스가 안정적으로 돌아가는 것을 확인한 뒤
> 이 서비스 다운 건에 대한 대응은 마무리 되었습니다.









## 타임라인

> [!NOTE]
> 서비스 다운 사건에 대한 타임라인을 자세히 설명해주세요.
> **주목할만한 리드업 이벤트, 활동 시작, 알려진 첫 번째 영향 및 에스컬레이션을 포함합니다.**
> 모든 결정이나 변경 사항, 사건이 종료된 시기, 영향을 받은 후의 사건과 함께 기록해 두세요

> [!TIP]
> 👉 **예:** 
> 모든 시간은 GMT+09:00 입니다
> 
> ⏰ 11:15 홈페이지 메인에서 서비스 다운이 와탭을 통해 최초 보고
> 
> ⏰ 11:30 루시를 통해 서비스 다운 상태 최초 확인 및 팀원에게 전파
> 
> ⏰ 14:53 메인 페이지를 통해..
> 
> …
> ⏰ 15:10 상황 종료











## 백로그 확인

> [!NOTE]
> 스프린트 백로그를 검토해서 이 사고를 예방하거나 최소한 그 영향을 줄일 수 있었던 작업이 있는지 확인해보세요.
> 없다면 추가해주세요!








## 재발생 여부 및 분석

> [!NOTE]
> 만약 이 사건과 똑같거나 비슷한 사건이 과거에 있었다면 왜 이 사건이 다시 벌어졌는지 분석해주세요.










## 배운 교훈

> [!NOTE]
> 이 특정 사건에서 배운 교훈을 적어보세요.

> [!TIP]
> **아래 템플릿을 활용해보세요**
> - 무엇이 잘 되었나요?
>   - ✍️ Reason 1
>   - ✍️ Reason 2
>   
>  - 무엇이 잘못되었나요?
>    - ✍️ Reason 1
>    - ✍️ Reason 2
>    
> - 이 다운타임과 관련해 운이 좋았던 항목이 있나요?
>   - ✍️ Reason 1
>   - ✍️ Reason 2








## 조치항목 (액션아이템)

> [!NOTE]
> 향후 이러한 종류의 사고를 방지하기 위해 수립한 문화 혹은 규칙을 적시해주세요
> 그리고 어떤 수립한 문화 혹은 규칙에 대한 책임자가 누구인지, 어떻게 작업을 완료해야 하는지, 가능하다면 어떻게 추적되는지까지 적어주세요.
> 다운 타임에 관련 된 작업 항목은 Github Issue 혹은 Jira 티켓 형식이어야 하며 해당 이슈는 서비스 다운타임과 관련 된 작업 항목임을 이모지 등의 수단을 통해 반드시 포함시키고 이 곳에 멘션 혹은 링크하셔야 합니다.

> [!TIP]
> **아래 템플릿을 사용하세요. 수정해도 괜찮습니다.**
> - 향후 기여 요인을 방지하는 데 필요한 수정 사항
>     - ..
> - 문제가 다시 발생할 경우 문제를 완화하는 데 도움이 될 수 있는 준비 작업
>     - ..
> - 남은 사후 단계
>     - ..
> - 사고 대응 프로세스 개선
>     - ..