Heroku Emergency Strategy: Incident Command System and 8 Hour Ops Rotations for Fresh Minds

원제 : Heroku Emergency Strategy: Incident Command System and 8 Hour Ops Rotations for Fresh Minds

번역 : Heroku 응급상황 전략: 사고지휘관 시스템과 맑은 정신을 위한 운영요원 8시간 교체

Resolved: Widespread Application Outage(해결: 광범위한 응요프로그램 정지)에서, Heroku는 Amazon 장애를 어떻게 다루었는지 이야기합니다.  장애시간에 대한 100% 책임을 다하기 위해, Heroku는 서비스를 완전히 제대로 동작하게 되돌리기 위해 사용한 여러 전략을 공유했습니다.

Heroku의 가장 흥미로운 전략중 하나는 전혀 기술적이지 아니지만, 응급상황에 대한 반응에서 Heroku가 운영요원 인원들을  얼마나 주의깊게 다루었는가입니다. Heroku의 전략의 개요입니다:

 

• Monitoring systems은 즉각 운영요원에게 문제를 알려야합니다.
• 대기중인(on-call) 기술자는 부상자분류(triage logic)에 따라 문제를 적용하고 심각성에 따라  분류하여, 대기중인 Incident Commander(사고지휘관)이 편안하게 잠에서 깨어날수 있게 합니다.
• IC는 AWS에 연락합니다. AWS 는 그들의 AWS를 대표하는 상시적인 연락창구이고 AWS와 문제를 해결하기 위해 긴밀하게 일하고 있습니다.
• IC는 Heroku 기술자에게 경보를 발령합니다. 모든 구성원:지원, 데이터, 다른 기술팀 모든 것을 온라인으로 되돌리기위해 열심히 일합니다.
• 운영팀은 8시간 교대의 응급 IC 를 시작합니다. 장애가 심각하다고 판명되면, 모든 시간에 상황에 대한 맑은 정신을 유지하게 합니다.
  
• 새로운 정보를 더할 게 없더라도, Heroku가 문제를 해결하고 있음을 모두에게 알리기 위해, 상태 갱신은 자주합니다.

Incident Command System

Hacker News 에 있는 Heroku 글의 댓글을 단 Chrishenn은  Incident Command System(http://en.wikipedia.org/wiki/Incident_command_system) 모델에 근거한 응급상황 대응 시스템을 사용했다고 생각합니다: 응급상황 대응의 지휘, 통제, 조정을 위한 시스템적인 도구.  wikipedia에 있는 모델 그림입니다:

ICS를 들어본 적 없지만, 검증된 구조를 찾고 있다면 충분히 가치 있습니다. Chrishenn는 ICS에 대해 다음과 같이 말합니다:

나는 처음으로 경험해봤고 ICS가 매우 잘 동작했다고 말할수 있지만, 그러나 이런 맥락에서 사용된 것을 보지 못했습니다. ICS에 대한 가장 큰 것은 확장성입니다--ICS는 어떤 크기의 팀을 위해서 동작합니다. 다른 기술 회사/백엔드 팀에서 ICS를 사용하는지 관심있습니다.

I've experienced it first hand and can say it works very well, but I have never seen it used in this context. The great thing about it is it's expandability---it will work for teams of nearly any size. I'd be interested in seeing if any other technology companies/backend teams are using it.

배운 교훈

• 문제가 있음을 즉시 알리는 모니터링 시스템을 갖추라(Have a monitoring system so you know immediately when there are problems).
• Amazon이 여러분의 문제를 돕게끔 정말 큰 고객이 되라(Be a really big customer so Amazon will help you specifically with your problems). 이 점이 Heroku를 많이 도운 것처럼 보인다. 나는 Amazon 개발자 포럼에서 많은 사람들이 이 점을 잊어버리고 필요한 개인적인 도움을 얻지 않는다는 것을 지적했습니다.
• 구조화된 응급상황 대응 프로세스를 갖추라(Have a structured emergency response process). Heroku는 대기중인 기술자와 IC 조정자,  단계적 확대 프로세스와 필요할때 모든 조직을 참여시키는 역량이 있었습니다. Heroku가 사고를 톱니바퀴(well oiled machine)처럼 처리한 것처럼 들립니다. 실습이 필요하며, EBS가 떨어질때 이 모든 것을 구분하기 위해 노력하는 대신 장애를 마주하는 실습입니다. 
  
• 지친 사람들이 나쁜 결정을 한다는 것을 인식하고 조정자를 8시간 교대하여 2차 실패를 차단한 것은 정말 천재적입니다.(Recognizing that tired people make bad decisions and putting the coordinator on 8 hour rotation to prevent this type of secondary failure is really genius).
• Heroku의 상태 갱신 정책은 고객의 심리상태의 통찰적이해를 보여줍니다.(Heroku's status update policy shows an insightful understanding of customer psychology). 고객의 감정과 기대를 관리하는 것은 커다란 진보입니다. 어떤 사람도 압박이 심한 상황에서 포기를 느끼고 싶지 않습니다. 상태 갱신이 자세한 것을 담지 않았어도, 그들은 Heroku가 거기에 있으며 문제를 다루고 있음을 보여주었습니다.
• 기대 이상 약속하지 말고 미진한 것을 전달하지 마세요(Do not over promise and under deliver). Heroku의 상태 메시지는 측정되고, 안심시키고, 정직했습니다. Heroku는 무엇이 잘못되었는지 다시 서비스가 재개될지 몰랐으며, 그들은 말할 수 없었습니다. 어떤 것도 이런 상황에서 거짓말보다 더 빨리 분노를 만들지 않았습니다.  
  

Related Articles

• Hacker News Thread