[기술포스팅 원문] https://tech.devsisters.com/posts/incident-management-principles/

[기술포스팅 요약] 데브시스터즈의 장애 대응 원칙과 방법을 소개합니다. 이 문서는 장애 탐지, 대응 및 예방을 위한 전사적 가이드라인을 제공하며, 서비스 운영의 안정성을 높이는 데 목적이 있습니다.

• 장애 대응의 목표
  • 서비스의 빠른 정상화가 최우선
  • 개발자뿐만 아니라 모든 구성원이 대응 가능해야 함
  • 문제의 근본 원인을 찾기보다 즉각적인 복구를 우선
• 에스컬레이션과 상황 전파
  • 오탐 가능성을 감안하더라도 장애 의심 시 즉시 공유
  • 장애가 의심되면 시간과 장소에 상관없이 다른 사람을 호출
  • 반복 호출되는 알람은 적절한 문서화 및 개선 필요
• 장애 대응을 위한 환경 준비
  • 랩탑 휴대 및 개발/운영 환경(Wireguard, SSH 등) 사전 셋업
  • Wi-Fi가 없는 환경에서도 대응 가능하도록 LTE 모뎀/폰 준비
• 장애 감지 및 알람 대응
  • Slack 알람 티어 설정(Tier 0~2) 및 즉각 대응 가능하도록 준비
  • 모든 알람에 대해 최소한의 대응이 필요
  • 대응 필요 없는 알람은 조건 수정 및 티어 재배치
• 기록과 커뮤니케이션
  • 장애 대응 중 실행된 액션을 객관적으로 공유
  • 기록을 남겨 장애 대응에 참여하지 않은 구성원도 학습 가능하도록 함
  • 유관 부서와의 커뮤니케이션 시 기술적 배경이 적은 사람도 이해할 수 있도록 설명
• 장애 회고(Postmortem)
  • 같은 유형의 장애가 반복되지 않도록 문서화 및 개선
  • 비난 없는 회고를 통해 시스템 개선 방향 도출
  • 장애 대응 과정 중 최선을 다했음을 신뢰하는 문화 조성
• 알람 티어링 체계
  • Tier 0: 즉시 대응이 필요한 최우선 알람(FRT 15분 이내)
  • Tier 1: 업무 시간에는 즉시, 야간에는 다음날 오전까지 대응
  • Tier 2: 즉각적인 대응이 필요하지 않지만 개입이 필요한 알람
• 효과적인 장애 대응 방법
  • 장애 발생 시 대응팀을 구성하여 역할 분배(지휘자, 기록가 포함)
  • 장애 대응 채널을 Slack 및 Datadog Incident를 활용하여 구성
  • 장애 대응 과정에서 모든 변경 사항을 공유 및 문서화
  • 장애 해결 후 종료 메시지 공유 및 포스트모템 진행
• 포스트모템 프로세스
  • 장애 요약, 발생 원인, 해결 과정, 재발 방지 방안 문서화
  • 5 Whys 기법을 활용하여 근본 원인 분석
  • 장애 대응 과정에서 얻은 교훈과 개선 사항 정리

데브시스터즈는 장애 대응의 체계적인 원칙을 통해 서비스 안정성을 확보하고 있으며, 반복적인 장애를 방지하기 위한 프로세스를 지속적으로 개선해 나가고 있습니다.

이 게시글은 [GPT-4o model]를 통해 요약되었으며, 정보 공유 목적으로 게시되었습니다. 원문 게시물에 대한 책임이나 이해 관계가 없습니다. - 소프트웨어QA 포럼