chapter8. Service Failure

  • 학습목표
    • 가장 일반적인 서비스 장애의 7가지 유형과 그 원인
    • 업무 중단 최소화를 위한 유지보수 작업의 스케줄 방법
    • 스케줄된 장애 시간 내에 유지보수 작업을 수행하기 위한 모범 방안
    • SLA(Service Level Agreements) 준수를 위한 서비스 성능 평가하기
    • 서비스 장애의 대응과 해결을 위한 효과적인 절차
    • 서비스 장애의 주원인 분석하기
  1. 장애의 유형: 장애의 유형을 세분화함으로써 장애가 발생시 얼마나 빨리 대응할지, 장애를 누구에게 알릴지, 사용자에게도 알릴지에 대한 결정을 내릴 수 있게 해준다.(스케줄된 유지보수, 스케줄되지 않은 장애, 서비스 저하, 부분적인 서비스 장애, 전체적인 서비스 장애, 분산 환경 기반 서비스 장애, 제 3자에 의한 장애)
  2. 스케줄된 유지보수: 적절한 로깅과 모니터링으로 노후와 과다사용 때문에 문제가 발생하지 않게 예측하고 최소한의 중단만으로 구성요소를 관리/교체한다.
  3. 스케줄되지 않은 장애: 경고없이 일어나는 장애를 말한다. 설정의 결함, 하드웨어 고장, 인간의 실수(root로써 잘못된 명령어, 서버에서 부적당한 케이블 분리, 설정 파일 오타, 생산 서버에서 새로운 SW, 설정 실험), 화재 같은 것이 있다.
  4. 부분적인 서비스 장애: 일부 기능가 정상 작동하지 않는 것.
  5. 전체적인 장애와 서비스 저하: 전체적인 서비스 장애도 있지만 서비스 성능이 저하되는 현상도 있는데 예시는 다음과 같다. (과도한 네트워크 트래픽으로 인한 응답느림, 서버 풀에 있는 한 서버가 고장나 몇 개의 HTTP 요청 간헐적 실패, 한 서비스의 과도한 페이징으로 인한 다른 서비스 느려짐)
  6. 분산 서비스의 장애: 분산된 서비스는 DNS나 NFS처럼 원격의 시스템에 존재하지만 다른 시스템의 기능에 중요한 역할을 하는 서비스이다. 원격 서버가 다른 누군가의 제어권 내에 있다면 상대방이 해결해주는 것을 기다려야만 할 수 도 있다. 영향을 최소화 하려면 각 서비스 자원에 여분의 것이 있는지 확인, 분산된 서비스에 대한 리스트 문서화, 자주 고장나는 서비스 로컬로 구축
  7. 제 3자에 의한 장애: 분산된 서비스 장애와 유사하게 보인다. 하지만 제 3자에 의한 장애에서는 장애를 겪게된 시스템의 시스템 관리자는 원격 시스템이 존재하는 지조차도 모르며, 그 시스템에 있는 서비스를 확실하게 이용하지도 않는다. 대표적인 장애가 백본의 고장이다.
  8. 유지보수 윈도우: 시스템 관리자의 으뜸가는 책임 중에 하나가 조직에서의 유지보수 윈도우(라우터의 재부팅, 서버의 업그레이드, 디스크 드라이브 추가 등과 같은 일상적인 스케줄 된 유지보수에 예약된 시간)을 지정하는 것이다. 유지보수 윈도우는 서비스가 보증되지 않는 시간을 조건으로 지정함으로써, 관리자는 작은 문제를 고치거나 혹은 서버를 업그레이드 할 수 있는 시간을 가지게 된다. 유지보수 윈도우를 결정할 때는 세 가지 요소를 고려해야 한다. 이용률이 가장 적을 때, 최대한의 유지보수 시간, 업무에 따른 요구사항이 그것이다.
  9. SLA(Service Level Agreement) 준수 모니터링: 고객은 그들의 공급자로부터 특정 레벨의 서비스를 기대하여 그 레벨은 지정하여 약정에 사인하여 협의한 것이 서비스 레벨 협정이다. SLA의 일반적인 기준이 가동시간과 응답시간이다. 이 기준을 만족시킬 수 있도록 모니터링을 진행해야한다.
  10. 생산적 가치 유지: 생산적 가치는 생산 서버에서의 위험을 최소화하며, 장애가 발생하는 것을 맨 먼저 막을 수 있는 규칙이다. 기본적인 생산적 가치는 다음과 같다.
    1. 생산용 서버와 테스트 서버 구분
    2. 모든 유지보수 작업을 공지할 것
    3. 시스템 관리자는 로그파일과 모니터 내용에 주의를 기울일 것
    4. 장애에 빠르게 대응할 것
  11. 장애 처리 절차: 단계적 상승 절차는 문제를 적합한 관할 구역으로 올려 보냄으로써 결국 그 문제를 해결할 수 있는 구역 내의 사람에게 도달하게 하는 것을 의미한다. 장애에 대한 처리 절차를 개발함으로써 커뮤니케이션 처리와 트러블 티켓 업데이트와 같은 중요한 작업을 실수하지 않도록 할 수 있다. 장애처리 절차에 대한 가이드라인은 적임자에게 문제를 배정하기, 지속적인 커뮤니테이션 유지, 처리 활동 로그 유지 등이 있다.
  12. 주원인 분석:주원인이란 문제의 근원이 되는 곳으로 주원인 분석을 하여 제거를 하면 그 결과를 일으킨 문제를 영원히 없애버리게 한다. 주원인을 파악하려면, 진행 중인 문제의 초기 증상부터 시작해서, 문제가 된 이벤트나 상태까지 문제를 추적해 나가야 한다.