[DevOps] 장애 보고서 템플릿

장애보고서(COE)에 들어가야할 것.

ex ) 예시

장애 상황 요약

- CDB 마이그레이션을 위해서 호스트 환경변수를 변경하여 애플리케이션을 재배포
- 하지만 여전히 환경변수로 CDB 엔드포인트가 애플리케이션에 주입되고 있었음.
- 그러한 상황에서 구 CDB 인스턴스를 제거하여 장애가 발생.

장애의 영향 범위

- 고객 영향: 장애 인지 후 고쳐지기 약 n분 동안 사용이 불가했음.
  - 금전적 영향이나 2차 비즈니스 피해는 없음.
- 비기능적 요구사항: 가용성 조건
- 2차 피해: CS 인입이나 커뮤니티 반잉이 소량 있었음.

장애 상황 타임라인

- (상황 전) [11:30] 마이그레이션 정상 동작 확인. 구 CDB 인스턴스 삭제
- (상황 전) [11:35] 구 CDB 인스턴스 삭제 완료
- [11:41] 상황 발생: 모든 API 요청에 5xx 서버사이드 에러로 응답
- [11:50] 상황 인지
- [12:01] 데이터베이스, 애플리케이션 매트릭과 로그 확인 -> 애플리케이션 단 문제 있음.
- [12:10] 환경변수 확ㅇ니 (shell, deployment) -> 호스트가 변경 전 값으로 설정
- [13:10] 우선 매니페스트를 클러스터에서 수정하여 환경변수 수정 -> 증상 해소
- [13:14] Github 워크플로우의 헬름 커맨드 확인 -> 설정 문제 발견
- [13:19] 워크플로우를 수정하여 재배포했을 때 정상 작동 확인

5Whys를 통한 근본 원인 분석

• 왜 애플리케이션이 다운됐는가?
  • 변경했다고 생각했던 호스트 환경변수가 실제로는 변경되지 않았기 때문이다.
• 왜 환경변수가 변경되지 않았는가?
  • helm 벨류 파일을 수정했으나, 깃헙 액션에서 기존 값을 더 높은 우선순위로 지정하고 있었다ㅏ.
• 왜 Github Actions 워크플로우의 수정은 일어나지 않았는가?
  • 마이그레이션 작업 플랜에서 깃헙 액션 워크플로우를 간과하였다.
• 왜 불완전한 마이그레이션 작업 플랜이 검증없이 그대로 수행되었는가?
  • 마이그레이션 작업 시에는 반드시 체크해야하는 목록 등 작업 플랜의 템플릿이 없었다.
• 왜 CDB 마이그레이션이 올바르게 완료되지 않았는데 해당 사실을 몰랐는가?
  • 호스트 변경했다고 생각한 애플리케이션이 pod로 정상적으로 떠올랐고, API 요청이 성공했기 때문에 검증이 된 것으로 착각하였다.

RCA로부터 도출한 재발 방지 방안

• 단기적 방안
  • (증상 해소) Deployment의 환경변수를 올바른 호스트를 바라보도록 수정하여 재배포한다.
  • 워크플로우의 헬름 커맨드의 밸류 설정 부분을 수정한다.
• 장기적 방안
  • 종류별 작업 플랜의 템플릿을 만든다.
    • 작업 순서, 올바르게 작업이 되었는지 검증하는 방법, 작업이 실패했을 때 롤백하는 방법 등
    • 모든 컴포넌트 정상 동작 확인을 위한 체크리스트
    • (예시) Github Actions 워크플로우의 신설, 수정, 삭제 등이 필요한가?
  • 시스템 자동 검증 및 failover 수행 등 자동화 도입