구름 세미나 - 장애대응

장애 확인

• 장애가 발생한 지 모르는 것이 가장 큰 문제

잘못된 장애 인지 순서

• 고객 문의가 급증한다 → 개발팀에 연락
  • 고객 불만이 쌓임 → 고객이 줄어듬 → 회사의 매출이 줄어든다 → 내가 짤린다?
• 사장님이 써보다가 안된다. → 개발팀에 연락

안정적인 장애 인지

• 고객이 인지하기 전에 버그를 수정 → 조용히 배포 → 없었던 일로 만듬 (점수함 패치)

장애 인지 방법

• 모니터링 → 현재 상황을 인지해야 함.
• 무엇을 모니터링 해야 하는지? → 서비스에 영향을 주는 모든 것
  • 만약에 에러메세지는 발생하지 않는데 매출이 발생하지 않으면 ? → 장애같지 않아도 장애일 수 있음.
• 장애에 대한 정의가 필요함 → 도메인 특성도 고려할 것. (장애 같지만 장애가 아닌 경우도 있음)

모니터링 요소의 예

• 현재 정상 서버의 수
• 현재 요청 수(API 별)
• 현재 요청 실패 수 (API 별)
• 디스크 사용량
• 네트워크 사용량
• 로그 크기

이상 수치에 대한 알림 필요

• 알림이 너무 자주오면 알림이 중요하지 않게 느껴지며, 오히려 장애를 알 수 없게 됨.
• 모니터링 수치에 적절한 알람을 설정 → 해당 알림이 정말로 장애를 알려주는 지? → 조정
• 알람 레벨을 구분하는 것이 좋음

장애 발생 시

• 장애 확인
  • 에러 메세지가 갑자기 많이 늘었는지?
    • 해당 메세지가 늘어나면 해당 에러메세지를 확인한다
      • 이 때 장애의 원인까지 파악하지 않는다
      • 장애라는 것만 확인
• 장애라면 유관자에게 장애 발생 전파
  • 팀 내 공유
  • 연관 부서 공유
    • 고객문의를 하는 팀
    • 우리 팀 API를 사용하는 다른 팀
    • 전사 장애 페이지
• 유관 부서에 지속적으로 상태 공유 (상황 끝날 때까지)
• 장애 분석
  • 에러 메세지 분석
  • 보통 장애의 90%는 간단한 작업으로 해결되는 경우도 많음
    • 장애 메뉴얼의 필요성
    • 장애 메뉴얼에 관련 에러메세지나 상황이 있다면 해당 방법으로 처리
  • 우리 코드의 버그?
    • 최근에 배포된 코드와의 연관성을 고민
  • 사용하는 외부 API의 오류인가?
    • 관련 사용 API 상태 확인

중요한 점

• 혼자서 해결하려 하지 말 것
• 장애 관련 에러메세지를 먼저 확인 → 에러메세지를 많이 발생하는 순으로 Sort하도록 모니터링 툴을 만들면 유용함.
  • 서버의 에러 로그 내용
    • 내부 서버 에러 인가?
    • 외부 3rd Party 에러 인가?
    • 클라이언트에서 발생하는가?
• 장애 대응 메뉴얼 꼭 필요

새로운 장애 발생 시

• 장애 원인 파악은 중요도가 낮음
• 서비스 정상화가 우선
• 하지만 배포 후 장애가 발생했다면 장애 원인파악이 더 중요함.
  • rollback 또는 빠른 재배포
  • rollback의 경우 DB 스키마에 대한 이슈가 있을 수 있음. DB는 컬럼을 추가하는 형태로만 변경할 것을 권장
  • 테스트를 최대한 꼼꼼하게 작성할 것
• 장애 보고서 작성
• 서버가 부족하면 서버 급히 증설
• 기존 코드의 버그라면 긴급히 수정 후 배포

장애 보고서

• 발생했던 장애에 관한 보고서가 필요
• 장애요약
  • 어떤 장애였는지? 왜 발생했는지?
• 장애 영향도
  • 유저 어느 정도가 영향을 받았는지?
  • 영향 받은 서비스는?
    • 우리뿐 아니라. API를 사용하는 외부 팀
• 장애 원인
• 장애 처리 타임라인 별 행동
  • 발생, 탐지, 유관부서 전파. 각각 장애 해결을 위한 대응 행동 및 시간
• 장애 재발 대비책
• 그 외 추가 정보

장애 회고

• 장애에 대한 회고 필요
• 누가 문제를 만들었는가? 절대 언급하지 말 것
  • 장애 회고의 초점은 어떻게 개선할 것인가?
• 장애 회고의 내용
  • 참가자
    • 서비스 관련 부서
      • 개발팀/시스템인프라/기획, 그리고 관련 높은 분
  • 어떤 내용을 하는가?
    • 개선이 목표
    • 장애의 발생을 없앨 수는 없는가?
      • 적절한 테스트 단계가 빠졌는지?
      • 구조적으로 문제가 있는지?
        • 서비스 구조 개선
    • 장애의 탐지는 적절했는가?
      • 수정할 모니터링 지표는 없는가?(추가/삭제/값 수정)
    • 장애 대응 방식은 적절했는지?
      • 자음번에 이런걸 하면 더 쉽게 원인을 찾을 수 있을 듯 하다?

장애 대비 연습

• 예상할 수 있는 장애를 연습하며 실제 대응 능력 향상

장애 대응 메뉴얼의 필요성

• 작은 장애는 팀 내에서 처리가 되기 때문에 메뉴얼이 있으면 좋음
• 보통 경험 많은 시니어나 장애를 처리하던 사람이 계속 장애를 처리하는 경향 있음
• 좋은 방법은 주도적으로 장애 처리를 해보는 것이지만 현실적으로 힘듬
  • 이때 장애 대응 메뉴얼을 전달해주면서 시작해볼 수 있음

장애 대응 리소스

• 많은 곳에서 장애 대응은 개발팀/운영팀에서 하게 됨
• 그리고 On-Call이라는 이름으로 해당 장애를 우선 처리하는 인력이 있음.
• 서비스를 운영하다보면 아주 사소한 장애들도 많기 때문에 장애 대응 메뉴얼이 있으면 리소스를 아낄 수 있음.

결론

• 장애 처리에서 장애 탐지는 굉장히 중요하다.
• 장애가 발생하면, 먼저 유관 부서에 꼭 공유하자.
  • 중간 상황, 종결도 항상 공유하자.
• 장애보고서/장애 대응 메뉴얼을 작성하자.
• 무엇보다 중요한 것은 장애 회고
  • 위의 모든 것들이 장애 회고를 통해서 조금씩 개선해 나가야 한다.

Reference

• https://engineering.linecorp.com/ko/blog/line-failure-reporting-and-follow-up-process-culture/
• https://techblog.woowahan.com/6557/
• https://www.youtube.com/watch?v=TkYm33_9ZoQ