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

Далее он продолжает: «Я как-то говорил с одним коллегой о недавнем масштабном сбое у нас в Netflix, он произошел, честно говоря, из-за глупейшей ошибки. На самом деле сбой случился из-за одного инженера, за последние 18 месяцев уже дважды полностью выводившего Netflix из строя. Но, конечно, мы его ни за что не уволили бы. За те же 18 месяцев этот инженер продвинул уровень наших эксплуатации и автоматизации вперед не на километры, а на световые годы. Его работа позволила нам безопасно делать развертывания каждый день, и он сам лично провел огромное число развертываний кода».

Рапопорт заключает: «В DevOps должно быть место для таких инноваций и для вытекающего из них риска ошибок. Да, в эксплуатации у вас будет больше сбоев. Но это хорошо, за это нельзя наказывать».

Как мы видели во введении к этой главе, намеренное создание неполадок в среде эксплуатации (например, с помощью Chaos Monkey) — один из способов укрепления адаптивности к сбоям. В этой части мы опишем процессы симуляции и введения сбоев в систему, чтобы удостовериться, что наши системы спроектированы и выстроены правильно, а неполадки контролируемы и происходят, как запланировано. Для этого мы регулярно (или даже непрерывно) будем проводить тесты, чтобы убедиться: системы выходят из строя плавно и предсказуемо.

Как пишет Майкл Нейгард, автор книги Release It! Design and Deploy Production-Ready Software [148], «Подобно тому как в машины встраивают зоны смятия, чтобы при аварии пассажиры оставались в безопасности, вы можете определить, какие элементы системы важнее всего, и спроектировать режимы отказа, способные держать трещины подальше от этих элементов. Если вы специально не определяете режимы отказа, то результат будет непредсказуемым — и, как правило, опасным».

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

История 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 они «буквально отключали питание устройств — без предупреждения — и затем позволяли системам выходить из строя естественным образом, а сотрудникам — следить за этими процессами, независимо от того, как они бы стали развиваться».

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