12주5일차_실제_장애_사례_분석_및_블레임리스_문화

내용

3.2 Blameless Incident Response (비난 없는 장애 대응)

• 책임 추궁 대신 원인 분석 → 장애 발생 시, “누가 잘못했는가?”가 아니라 왜 이런 일이 발생했는가?를 분석
• 투명한 공유 및 개선 → 장애 원인과 대응 과정을 Post-Mortem을 통해 공유하고, 향후 개선점을 논의
• 재발 방지를 위한 학습 기회 제공 → 같은 장애가 반복되지 않도록 시스템적 해결책을 찾는 데 집중

[1] blameless문화가 무엇인지 교육 필요, 조직의 대표부터 선행하는 것을 보여줘, 조직 내로 확산되도록 유도 [2] 장애 재발 방지를 위한 업무에 시간을 투자하는 것에 대해 조직과 팀내의 공감대를 형성하는것

나부터 문제를 최대한 안만들기 위해 노력하기.. 예를 들면 커밋 빠뜨린 거 없는지랑 문서화 최대한 잘하기… 기록이 중요하다! 왜 이런 기능을 만들게 됐는지와 어떤 부분들을 수정했는지 바로바로 알 수 있도록 강조하기

누군가를 비난하는 문화 안에선 언젠가 자신도 비난 받음의 대상이 될 수 있음을 상기한다.

기존 프로세스 휴먼 리스크 발생 소지 있는지 점검 -> 크로스체크와 가이드 문서화 진행 문제 인식 공감 및 어디서든 장애가 날 수 있으니 로그 적재/알림 등으로 미리 대비 하는 것 개선점 타팀간에도 활발하게 공유하기

4.1 토론 주제

1. 최근 경험한 IT 장애 사례는 무엇인가?
   • 개발서버에 올라간 서비스 접속 장애.
   • 키오스크 및 포스에서 상품이 0원으로 결제되는것.(0원상품이 아닌데)
2. 해당 장애의 근본 원인은 무엇인가?
   • 개발 서버에 컨테이너없이 서비스 제공을 위한 의존성을 체크하던중, 기존 서비스에 끼칠 영향을 체크하지 못하고, 특정패키지(nginx 재설치.) 제거 후 업그레이드시, 의존된 모든 패키지를 제거해버림.
   • mariaDb클라이언트 삭제, Nginx 일시적 중지, 등
   • 주문 상품이 비동기로 불리는데, 주문이 로드 되기전에 포스 담당자가 결제 버튼을 눌러서 0원 결제
3. 대응 과정에서 개선할 점은 무엇인가?
   • 서비스는 컨테이너화해서 배포.(다른 서비스에 미칠 영향 최소화)
   • 중요한 로직은 동기적으로 처리, 중요한 로직은 프론트, 서버단에서 유효성 검증 필.
4. 어떻게 하면 같은 장애가 다시 발생하지 않을까?
   • 장애 회고 문서화 및 공유
   • PR 기반의 코드 리뷰 문화.
   • 개발 가이드에 예외케이스에 대한 검증을 추가하고 팀내에서 공유.

인사이트

• DB 백업 체크, 개인 계정 권한 제한, 주기적 계정 암호 변경 및 보안 점검
• 1. 외부 api 오류 시 배포에 문제가 되지 않도록 이전 배포 파일을 준비하기

• 개발 서버 등에서 테스트가 잘 된다고 방심하지 말 것 (협력사의 API 설계 문서를 보고선

  가 문제가 될 것 같다고 생각만 했는데 진짜 문제가 일어남..

수업

• s3또한 aws 버전 백업을 지원한다.
• 책임 추궁 대신 원인 분석.