Недавняя недоступность сервисов облачной службы Amazon на 24 часа, породила множество мнений и статей на эту проблему. Оказалось, что облака тоже падают. Тем острее становится вопрос не столько сделать сервис надежнее, но и что делать в непредвиденном случае.
Heroku рассказывает свою историю о том, как они справились с отказами на Amazon. Принимая на себя 100% ответственности за простои перед своими клиентами, они в то же время делятся рядом стратегий, которые использовали, чтобы восстановить свои сервисы до полного рабочего состояния. Одна из самых интересных стратегий Heroku вовсе не была технической изюминкой, а заключалась в том, как они продуманно развертывали свой операционный персонал в ответ на чрезвычайную ситуацию. Какова их стратегия ?
- Системы мониторинга сразу предупредили операционный персонал о проблеме
- Дежурный инженер классифицировал проблему как серьезную, в результате чего Менеджер по Авариям (далее МпА) был срочно разбужен
- МпА связался с веб-службой Amazon. Он и представитель веб-службы Amazon были в постоянном тесном контакте и работали над решением проблемы
- МпА известил инженеров Heroku. Все команды: тех. поддержка, работа с данными, другие инженерные службы работали круглосуточно, чтобы все восстановить в режим он-лайн.
- Когда стало ясно, что отключение было серьезное, режим работы МпА был установлен по ротации, 8 часов за смену, для того, чтобы обеспечить «свежую голову», непрерывно контролирующую ситуацию.
- Текущие обновления статуса были установлены чаще, даже если они не добавляли существенной новой информации, просто, чтобы всем было видно, что Heroku работает над решением проблемы.
# Система управления аварийными ситуциями
Chrishenn в своих комментариях на сообщение Heroku на Hacker News, считает, что Heroku использовала системы реагирования на чрезвычайные ситуации на основе модели «Системы управления аварийными ситуциями»: методический инструмент, используемый для управления, контроля и координации реагирования на чрезвычайные ситуации. Картинка модели из Википедии:
Я никогда раньше не слышал о «Системе управления аварийными ситуциями», но она выглядит заслуживающей изучения, если вы ищете проверенную структуру. Chrishenn говорит, что она работает: Я пережил это на собственном опыте и могу сказать, что она работает очень хорошо, но я никогда не видел раньше ее использование в этом контексте. Самое замечательное ее свойство - это ее расширяемость - она будет работать для команды практически любого размера. Я был бы заинтересован в том, чтобы узнать, используют ли ее какие-либо другие технологические компании / группы поддержки баз данных.
# Выводы
- Надо иметь систему мониторинга, чтобы вы немедленно узнавали, когда появляются проблемы.
- Быть солидным клиентом, тогда Amazon поможет вам конкретно с вашими проблемами. Это, кажется, существенно помогло Heroku. Я заметил на форумах разработчиков Amazon, что многие люди забыли это сделать, и поэтому не получили индивидуальную помощь, которая им была необходима.
- Иметь структурированный процесс реагирования на чрезвычайные ситуации. Heroku имеет дежурного инженера, МпА, определен процесс реагирования, и возможность привлечения всех необходимых ресурсов, когда это необходимо. Это звучит как будто Heroku обрабатывает инцидент, как хорошо смазанный механизм. Это требует практики, причем практики предварительной, до отказа, вместо того, чтобы стараться выявить все эти вещи, когда система электронной коммерции выходит из строя.
- Признание того, что усталые люди принимают плохие решения и организация 8-ми часовой ротации координаторов для предотвращения такого рода повторных отказов действительно гениально.
- Политика Heroku по обновлению статуса демонстрирует проницательное понимание психологии клиента. Управление чувствами и ожиданиями клиента было большим шагом. Никто не хочет чувствовать себя брошенным в критической ситуации. Даже если обновления статуса не содержат много деталей, они показывают, что Heroku был там и обслуживал.
- Не давайте невыполнимых обещаний и поставляйте в полном объеме обещанное. Сообщения Heroku о статусе были осмысленными, обнадеживающими и честными. Heroku не знал, в чем была проблема, или когда сервис будет действовать снова, так что они просто этого не говорили. Ничто не создает негодование быстрее в таких ситуациях, чем ложь.