구름 | 장애 대응 특강 노트 정리

모니터링 요소의 예

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

모니터링 수치에 대한 지속적인 리팩토링이 필요하다

장애 발생시 행동 절차

• 장애 관련 확인
  • 에러 메시지가 갑자기 많이 늘었는지?
  • 해당 메시지가 늘어나면 해당 에러메시지를 확인한다.
    • 이 때 장애의 원인까진 파악하지 않는다.
    • 장애라는 것만 확인
• 장애라면 유관자에게 장애 발생 전파

장애가 시작되고 끝날 때까지 지속해서 유관 부서에 상태를 공유합니다.

장애를 혼자 덮개끔 하는 회사 분위기를 지양해야한다.

전사가 대응해야한다.

우수한 장애 대응 예시 :

라인 장애 대응 문화

• 찾기 쉬운 담당자 연락망
• 기준표에 따른 장애 등급 분류
• 근무일 기준 1일 이내에 1차 보고 완료 필수
  • 비개발부서도 이해할 수 있는 요약 + 개발자가 상세 정보를 확인할 수 있도록 서비스 형태, 대응 이력 등 상세 기술
• 회고는 5일 이내 실시해야 함. 가능한 많은 인원이 참여해 다양한 피드백을 주고 받으며 개선점 찾기.
  [원문 링크]

우아한 형제들 - 모의 장애 훈련에 진심입니다.

• 참여자, 진행자, 설계자, 관찰자
• 실제 운영환경과 유사한 베타에서 임의로 장애를 발생시킨다.
• 평소 장애 대응을 주로 하지 않은 사람들이 복구와 전파를 체험함
• 설계자와 관찰자는 개입하지 않고, 회고에 추후 개선점을 기록함.
• 진행자가 상황 종료 즉시 회고를 진행. 훈련 소감을 남김
  [원문 링크]

장애 분석 절차

• 에러 메시지 분석
• 보통 장애의 90%는 간단한 작업으로 해결된다.
  • 장애 메뉴얼의 필요성
  • 장애 메뉴얼에 관련 에러 메시지나 상황이 있다면 해당 방법으로 처리
• 우리 코드의 버그일까?
  • 최근에 배포된 코드와의 연관성을 고민
• 사용하는 외부 API의 오류인가?
  • 관련 사용 API 형태 확인

장애 관련 에러 메시지 확인

• 서버의 에러 로그 내용
  • 내부 서버 에러인가?
  • 외부 3rd Party 에러인가?
  • 클라이언트에서 발생하는가?장애 원인파악보다 서비스 정상화가 우선
  • DB 스키마 변경은 롤백하기 어렵다. 새로운 것을 추가하는 형태로만 가는게 좋음.

장애 보고서에 들어가야 하는 내용

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

누가 문제를 만들었는가 절대 언급하면 안된다.

어떻게 개선할까 에 초점을 준다.

장애 회고의 내용

• 참가자
  • 서비스 관련 부서
    • 개발팀 / 시스템인프라(SRE) / 기획, 그리고 관련 높은 분
• 어떤 내용을 하는가?
  • 개선이 목표
  • 장애의 발생을 없앨 수는 없는가?
    • 적절한 테스트 단계가 빠졌는지?
    • 구조적으로 문제가 있는지?
      • 서비스 구조 개선

결론

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