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

Адаптивность требует, чтобы мы сначала продумали режимы отказа и затем протестировали, работают ли они так, как нам нужно. Один из способов проделать это — специально создавать сбои в эксплуатационной среде и репетировать масштабные аварии, чтобы убедиться, что мы можем быстро восстановиться после инцидентов, когда они на самом деле произойдут, в идеале — так, чтобы клиенты этого не заметили.

История Netflix и сбоя Amazon AWS-EAST в начале этой главы — не единственный пример. Еще более интересный пример адаптивности Netflix произошел во время «Великой перезагрузки Amazon 2014», когда почти 10 % всех серверов EC2 [149]Amazon пришлось перезагрузить, чтобы срочно установить обновление для системы безопасности Xen. Кристос Каланцис, специалист по конструированию облачных баз данных в Netflix, вспоминает: «Когда мы узнали о срочной перезагрузке EC2, у нас отвисла челюсть. Когда мы получили список того, сколько серверов Cassandra будут затронуты этим, мне стало плохо». Каланцис продолжает: «Потом я вспомнил все тренировки с Chaos Monkey. Моя реакция была: “Ну же, давайте!”»

И опять результаты оказались поразительными. Из более чем 2700 узлов Cassandra, используемых в эксплуатации, 218 были перезагружены, а перезагрузка 22 закончилась неудачей. Каланцис и Брюс Вонг, занимающийся проектированием хаоса (Chaos Engineering), писали: «В те выходные Netflix был недоступен ровно ноль секунд. Регулярные и постоянные упражнения в устранении сбоев, даже на уровне баз данных, должны быть частью плана по развитию адаптивности каждой компании. Если бы Cassandra не участвовала в тренировках Chaos Monkey, эта история закончилась бы совсем по-другому».

Что еще более удивительно, в те выходные не только в Netflix никто не работал над устранением инцидентов из-за сбоев узлов Cassandra, никого вообще не было в офисе — все сотрудники были в Голливуде, где отмечали завершение очередного этапа работ. Это еще один пример того, как благодаря проактивному фокусированию на адаптивности то, что для одних компаний могло оказаться серьезным кризисом, для других — всего лишь еще один обычный рабочий день [150](cм. приложение 9).

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

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

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

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

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

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