14. 장애 관리하기
18 Jul 2023 | Site Reliability Engineering
14. 장애 관리하기
미흡한 장애 관리
- 책 참고
- 총체적 난국
- 기술적인 문제에 대한 날카로운 집중 부재
- 소통의 부재
- 프리랜서의 고용
장애 관리 절차의 기본 요소들
- 구글의 장애 관리 시스템은 장애 제어 시스템을 기반으로 함
책임에 대한 재귀적인 분리
- 자신의 역할을 명확히 이해하고 다른 이의 영역을 침범하지 않도록 하는 것이 중요
- 만일 누군가의 업무 부하가 감당하기 힘들 정도로 높아지면 그 사람을 리더에게 더 많은 지원 인력을 요청해야 함
장애 제어
- 장애 제어자 (incident commander)는 장애에 대한 높은 수준의 상태를 확인
- 장애 조치를 위한 팀을 구성하고 필요와 우선순위에 따라 책임을 나누어줌
- 다른 사람에게 위임되지 않은 모든 역할을 수행해야 함
운영 업무
- Ops 조직의 리드는 장애 제어자와 협력하여 운영 도구들을 이용해 실제 업무를 수행할으로써 장애에 대처
- 장애를 조치하는 동안에는 오직 운영팀만이 시스템을 변경할 수 있어야 한다
의사 소통
- 장애 조치팀의 대외 창구
- 장애 대응팀의 현황을 정기적으로 의사 결정자들에게 (주로 이메일을 통해) 전달하는 것
- 장애 조치 문서를 최신의 상태로 유지하는 역할도 겸할 수 있음
계획
- 운영팀을 도와 버그를 수집하거나, 저녁 식사를 주문하거나, 업무 분장을 돕거나…
확실한 컨트롤 타워
- 장애 조치 팀원들은 소위 War Room으로 활용할 목적으로 만들어진 공간에 함께 있는 것이 좋음
- 구글은 IRC(Internet Relay Chat)를 사용함
실시간 장애 조치 문서
- 장애 조치 문서의 예시는 부록 C에서 볼 수 있음
명확하고 즉각적인 업무 이관
- 교대 작업 중요함!
적절하게 관리한 장애 조치
- 책 참고
언제 장애를 선언할 것인가?
- 문제가 심각해졌을 때 부랴부랴 장애 관리 프레임워크를 발동시키는 것보다는 장애를 빨리 선언하고 최대한 간결한 해결책을 찾아 장애를 조치하는 것이 더 나음
- 다음 중 어느 한 조건이라도 해당된다면 이를 장애라고 판명
- 문제를 해결하기 위해 다른 팀의 도움이 필요한가?
- 문제가 사용자에게 영향을 미쳤는가?
- 문제 발생 이후 한 시간 동안 집중적으로 분석했는데도 문제가 해결되지 않았는가?
요약
장애 조치에 대한 모범 사례
- 우선 순위 : 우선 출혈을 막고 서비스를 되살린 후에 근본 원인에 대한 증거를 찾자
- 사전 준비 : 장애 조치에 참여한 사람들의 자문을 받아 장애 관리 절차를 미리 개발하고 문서화 해 두자.
- 신뢰 : 장애 조치에 참여 중인 모든 사람들에게 충분한 자율권을 보장하자
- 감정 조절 : 장애를 조치하는 동안 스스로의 감정적 상태에 주의를 기울이자. 만일 너무 부담이 된다면 다른 이에게 도움을 청하자
- 대체 방안에 대한 모색 : 주기적으로 현재 선택할 수 있는 방법에 대해 다시 생각하고 이 방법이 여전히 유효한지, 아니면 다른 방법을 찾아야 하는지를 판단하자.
- 실습 : 이 과정을 정기적으로 수행해서 자연스럽게 활용할 수 있는 수준으로 만들자
- 개선 : 그리고 계속해서 개선하자. 모든 팀 구성원들이 모든 역할에 익숙해질 수 있도록 독려하자
14. 장애 관리하기
미흡한 장애 관리
- 책 참고
- 총체적 난국
- 기술적인 문제에 대한 날카로운 집중 부재
- 소통의 부재
- 프리랜서의 고용
장애 관리 절차의 기본 요소들
- 구글의 장애 관리 시스템은 장애 제어 시스템을 기반으로 함
책임에 대한 재귀적인 분리
- 자신의 역할을 명확히 이해하고 다른 이의 영역을 침범하지 않도록 하는 것이 중요
- 만일 누군가의 업무 부하가 감당하기 힘들 정도로 높아지면 그 사람을 리더에게 더 많은 지원 인력을 요청해야 함
장애 제어
- 장애 제어자 (incident commander)는 장애에 대한 높은 수준의 상태를 확인
- 장애 조치를 위한 팀을 구성하고 필요와 우선순위에 따라 책임을 나누어줌
- 다른 사람에게 위임되지 않은 모든 역할을 수행해야 함
운영 업무
- Ops 조직의 리드는 장애 제어자와 협력하여 운영 도구들을 이용해 실제 업무를 수행할으로써 장애에 대처
- 장애를 조치하는 동안에는 오직 운영팀만이 시스템을 변경할 수 있어야 한다
의사 소통
- 장애 조치팀의 대외 창구
- 장애 대응팀의 현황을 정기적으로 의사 결정자들에게 (주로 이메일을 통해) 전달하는 것
- 장애 조치 문서를 최신의 상태로 유지하는 역할도 겸할 수 있음
계획
- 운영팀을 도와 버그를 수집하거나, 저녁 식사를 주문하거나, 업무 분장을 돕거나…
확실한 컨트롤 타워
- 장애 조치 팀원들은 소위 War Room으로 활용할 목적으로 만들어진 공간에 함께 있는 것이 좋음
- 구글은 IRC(Internet Relay Chat)를 사용함
실시간 장애 조치 문서
- 장애 조치 문서의 예시는 부록 C에서 볼 수 있음
명확하고 즉각적인 업무 이관
- 교대 작업 중요함!
적절하게 관리한 장애 조치
- 책 참고
언제 장애를 선언할 것인가?
- 문제가 심각해졌을 때 부랴부랴 장애 관리 프레임워크를 발동시키는 것보다는 장애를 빨리 선언하고 최대한 간결한 해결책을 찾아 장애를 조치하는 것이 더 나음
- 다음 중 어느 한 조건이라도 해당된다면 이를 장애라고 판명
- 문제를 해결하기 위해 다른 팀의 도움이 필요한가?
- 문제가 사용자에게 영향을 미쳤는가?
- 문제 발생 이후 한 시간 동안 집중적으로 분석했는데도 문제가 해결되지 않았는가?
요약
장애 조치에 대한 모범 사례
- 우선 순위 : 우선 출혈을 막고 서비스를 되살린 후에 근본 원인에 대한 증거를 찾자
- 사전 준비 : 장애 조치에 참여한 사람들의 자문을 받아 장애 관리 절차를 미리 개발하고 문서화 해 두자.
- 신뢰 : 장애 조치에 참여 중인 모든 사람들에게 충분한 자율권을 보장하자
- 감정 조절 : 장애를 조치하는 동안 스스로의 감정적 상태에 주의를 기울이자. 만일 너무 부담이 된다면 다른 이에게 도움을 청하자
- 대체 방안에 대한 모색 : 주기적으로 현재 선택할 수 있는 방법에 대해 다시 생각하고 이 방법이 여전히 유효한지, 아니면 다른 방법을 찾아야 하는지를 판단하자.
- 실습 : 이 과정을 정기적으로 수행해서 자연스럽게 활용할 수 있는 수준으로 만들자
- 개선 : 그리고 계속해서 개선하자. 모든 팀 구성원들이 모든 역할에 익숙해질 수 있도록 독려하자
Comments