Книга: Руководство по 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).

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