Джин Ким - Руководство по DevOps

После масштабного сбоя AWS EAST 2011 г. в компании Netflix активно обсуждали, как сделать, чтобы системы сами справлялись с неполадками. Из этих дискуссий вырос инструмент под названием Chaos Monkey.

С тех пор этот сервис развился в целый набор инструментов, известный как «Обезьянья армия Netflix» и призванный симулировать разные уровни сбоев.

• Горилла Хаоса (Chaos Gorilla): симулирует отказ целой зоны доступности AWS.

• Хаос-Конг (Chaos Kong): симулирует отказ целого региона AWS, например североамериканского или европейского.

Среди других бойцов Обезьяньей армии можно отметить следующих.

• Обезьяна Задержек (Latency Monkey): создает искусственные задержки или остановку работы на уровне связи «клиент — сервер», соответствующей ограничениям REST, чтобы симулировать плавный отказ сервиса и проконтролировать, что зависимые сервисы отвечают на это надлежащим образом.

• Обезьяна Согласованности (Conformity Monkey): находит и выводит из работы инстансы AWS, не соответствующие стандартным значениям (например, когда инстансы не принадлежат к автоматически масштабируемой группе или когда в каталоге сервиса не указан адрес электронной почты ответственного инженера).

• Обезьяна Доктор (Doctor Monkey): просматривает результаты проверок работоспособности каждого инстанса, выявляет больные инстансы и проактивно отключает их, если ответственные за них инженеры не устраняют проблему вовремя.

• Обезьяна Уборщик (Janitor Monkey): следит за тем, чтобы в облачной среде не было мусора и хлама; ищет неиспользуемые ресурсы и избавляется от них.

• Обезьяна Безопасности (Security Monkey): расширение Обезьяны Согласованности; ищет и выводит из работы инстансы с нарушениями безопасности и уязвимыми местами, например неверно настроенные группы безопасности AWS.

Ленни Рачицки о преимуществах Transperant Uptime («прозрачности работы сервисов для клиентов»):

1. Снижаются издержки на поддержание сервисов, так как пользователи сами могут идентифицировать проблемы ваших систем без звонков или писем в службу поддержки. Пользователям больше не приходится угадывать, локальные у них проблемы или глобальные, они могут быстрее определить причины сбоя и сообщают о неполадках, уже зная существо проблемы.

2. В противоположность общению один на один по электронной почте контакт с пользователями во время выхода сервиса из строя становится продуктивнее, так как благодаря открытости интернета можно обращаться сразу к большой аудитории. Вы тратите меньше времени на воспроизведение одной и той же информации и можете сосредоточиться на решении проблемы.

3. Создается единый пункт для пользователей, куда они могут обратиться, когда сервис выходит из строя. Вы экономите их время. Иначе они потратили бы его на долгий поиск по форумам или вашему блогу.

4. Доверие — краеугольный камень перехода на модель SaaS (Software as a Service, программное обеспечение как услуга). Ваши клиенты ставят свой бизнес в зависимость от вашего сервиса или платформы. И текущим, и потенциальным клиентам нужна уверенность в вашем сервисе. Им нужно знать, что они не останутся без помощи, если у вас возникнут проблемы. Предоставлять информацию о форс-мажорах в режиме реального времени — лучший способ строить доверительные отношения. Больше вы не оставите клиентов в одиночестве без информации о текущей ситуации.

5. Всего лишь вопрос времени, когда же все серьезные SaaS-провайдеры начнут публиковать данные о работоспособности своих сервисов. Пользователи сами потребуют этого.

Многие проблемы IT-организаций описаны в первой половине книги The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, авторы Джин Ким, Кевин Бер и Джордж Спаффорд.

По ссылке можно услышать рассказ Пола О’Нила об опыте, приобретенном в должности CEO компании Alcoa; там также говорится и о расследовании смерти работавшего в компании подростка, в котором О’Нил принял участие: https://www.youtube.com/watch?v=tC2ucDs_XJY.

Если вы хотите больше узнать о картировании потока ценности, посмотрите книгу Карен Мартин и Майка Остерлинга Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation.

Более подробную информацию об объектно-реляционных отображениях можно найти в статье на сайте Stack Overflow: http://stackoverflow.com/questions/1279613/what-is-an-orm-and-where-can-i-learn-more-about-it.

Информативные статьи для начинающих о методиках гибкой методологии разработки и о том, как использовать их в эксплуатации, можно найти в блоге Agile Admin: http://theagileadmin.com2011/02/21/scrum-for-operations-what-is-scrum/.