Книга: Руководство по DevOps

Устраивайте Game Days, чтобы репетировать неполадки

В этой части мы опишем специальные тренировки восстановления после аварий. Они называются игровыми днями (Game Days). Этот термин придуман Джессом Роббинсом, одним из основателей сообщества Velocity Conference и сооснователем компании Chef, и стал популярен благодаря его работе в компании Amazon, где он отвечал за программы по обеспечению доступности сайтов и где его называли «мастером аварий». Идея игровых дней появилась из такого направления, как адаптивное проектирование (resilience engineering). Роббинс определяет адаптивное проектирование как «тренировку, направленную на увеличение адаптивности с помощью намеренных масштабных сбоев во всех критических системах».

Роббинс отмечает, что, «когда вы собираетесь спроектировать машстабируемую систему, лучшее, на что вы можете надеяться, — это надстроить надежную платформу над абсолютно ненадежными компонентами. Из-за этого вы оказываетесь в ситуации, где сложные сбои неизбежны и непредсказуемы».

Следовательно, мы должны обеспечить бесперебойную работу сервисов во время аварий, теоретически во всей системе, в идеале — без кризисного вмешательства (или вручную). Как шутит Роббинс, «сервис протестирован только тогда, когда мы ломаем его в эксплуатации».

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

Команда Game Day определяет и проводит тестовые задания, например проверяет переключение баз данных (то есть симулирует отказ первичной базы данных и переключение на вторую базу) или отключает важное сетевое соединение, чтобы выявить проблемы в каком-либо из анализируемых процессов. Все обнаруженные проблемы и сложности анализируются, устраняются и снова тестируются.

В запланированный момент мы устраиваем сбой. Как это описывает Роббинс, в Amazon они «буквально отключали питание устройств — без предупреждения — и затем позволяли системам выходить из строя естественным образом, а сотрудникам — следить за этими процессами, независимо от того, как они бы стали развиваться».

Такой подход помогает нам выявлять скрытые дефекты наших систем. Они оказываются доступны для наблюдения только благодаря намеренному внесению сбоев в системы. Роббинс объясняет: «Вы можете обнаружить, что некоторые системы наблюдения или управления, нужные для процессов восстановления, не работают из-за той же симулированной вами аварии. Или вы можете найти новые точки отказа, о которых вы до этого и не подозревали». Такие тренировки постепенно становятся все более интенсивными и сложными с той целью, чтобы они воспринимались как обычная часть обычного рабочего дня.

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

Отличный пример симулирования сбоев — программа восстановления после аварий компании Google (Disaster Recovery Program, DiRT). Крипа Кришнан, главный инженер программ Google, на момент написания этой книги руководит этой программой уже семь лет. За это время они симулировали землетрясение в Кремниевой долине, из-за которого комплекс зданий и офисов Google в городе Маунтин-Вью[151] оказался отсоединен от остальной компании, полную потерю питания в крупнейших дата-центрах и даже нападение пришельцев на города, где жили инженеры организации.

По словам Кришнан, «тестировщики часто обходят стороной бизнес-процессы и коммуникации. Системы и процессы очень тесно переплетены, и разделять тестирование систем и тестирование бизнес-процессов — нереалистичный подход: отказ бизнес-системы скажется на бизнес-процессе, и наоборот, работающая система без нужного персонала не очень-то полезна».

Во время симулирования таких аварий было сделано несколько открытий:

• когда соединение было прервано, переход коммуникации на рабочие места инженеров не помог;

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

• когда у дата-центров закончилось топливо для запасных генераторов, никто не знал процедур для экстренных закупок у поставщика, из-за чего одному сотруднику пришлось использовать личную кредитную карту и закупить топлива на 50 000 долларов.

С помощью создания аварий в контролируемых условиях мы можем успешно тренироваться и придумывать нужные сценарии. Еще один важный результат Game Days — то, что работники знают, кому звонить и с кем разговаривать. Так они налаживают отношения с сотрудниками других отделов, чтобы можно было успешно работать вместе во время аварий, превращая сознательные действия в бессознательные шаблоны и привычки.

Оглавление книги