Что такое Хаос Инжиниринг?

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

С появлением методов DevOps организации от стартапов до предприятий постепенно внедрили свои собственные методы тестирования хаоса в свои рабочие процессы разработки. Независимо от того, выполняется ли проектирование хаоса конкретными командами или в рамках обязанностей инженеров по надежности сайта (SРЕ),практика проектирования хаоса предназначена для выявления скрытых слабых мест в системах, приложениях и службах, гарантируя, что она может противостоять самым экстремальным ситуациям для полной отказоустойчивости.

Chaos Engineering vs. Тестирование производительности

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

 

Хаос (инженерия) рождается

Практика инженерии хаоса возникла у Netflix примерно в 2008 году после того, как они официально запустили свой потоковый сервис. После проблемы с повреждением базы данных примерно в 2011 году Netflix планировала перевести свой центр обработки данных в облако через AWS (Amazon Web Services). Фактически, им потребовалось восемь лет, чтобы окончательно завершить миграцию. В 2015 году AWS пережила сбой, в результате чего Netflix вышел из работы на несколько часов. Это были первые дни облачных вычислений, поэтому они не были такими надежными, стабильными и отказоустойчивыми, как сейчас. Когда они обнаружили, что переход в облако не создал некоторых ожидаемых преимуществ, таких как масштабируемость, время безотказной работы, избегание единых точек отказа, автоматическое масштабирование и т. Д., Они решили, что им нужен способ тестирования этих неожиданных проблем, чтобы убедиться, что их службы запущены и работают, и, в конечном счете, избежать воздействия на пользователей и вызвать разочарование. Из этого опыта родилась инженерия хаоса.

 

Принципы и шаги chaos engineering

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

 

Шаг 1: Создайте гипотезу

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

 

Шаг 2: Определите переменные и предугадывайте эффекты

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

 

Шаг 3: Запустите эксперимент

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

 

Шаг 4: Измерьте воздействие

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

 

Инструменты хаос-инжиниринга

Давайте вернемся к внедрению хаос-инжиниринга с Netflix. После того, как они приняли решение перейти в наступление и начать процесс выдачи ресурсов для инженерной команды, им нужно было создать формализованный набор практик и инструментов, чтобы помочь инженерным командам в проведении испытаний хаоса. Одно из ранних приложений, которое представил Netflix, называлось Chaos Monkey. Каждый день это приложение случайным образом выбирало набор кластеров и отключало этот экземпляр в какой-то момент в течение дня, чтобы наблюдать, как реагируют остальные системы. Очевидно, что это создает болезненный опыт для инженерных команд, у которых достаточно головной боли в сети, чтобы иметь дело с ежедневной, но, в конце концов, это ставит команды в лучшее положение, чтобы понять последствия этих отключений не только в отношении их сети, но и с точки зрения воздействия на пользователей.

Хотя может показаться нелогичным выделять ресурсы и отдельных лиц для «ломания» вещей, упреждающее проведение этих тестов хаоса помогает построить более устойчивую сеть и создать лучший, более надежный пользовательский опыт. Реальный мир не работает в контролируемой тестовой среде. С момента создания Chaos Monkey он прошел через несколько обновлений и стал популярным приложением с открытым исходным кодом. И в свое время это была всего лишь одна часть набора инструментов для разработки хаоса под названием «Обезьянья армия». Комплект Simian Army был расформирован в 2018 году, но включал в себя следующие инженерные утилиты хаоса для конкретных задач:

 

Хаос Конг

Chaos Kong был разработан для имитации полного региона AWS, который удаляется или удаляется, чтобы увидеть, как система восстанавливается и реагирует, перемещая трафик в другой регион без снижения производительности. Опять же, это происходит редко, но в рамках инженерии хаоса ничто не выходит за рамки.

 

Обезьяна соответствия

Conformity Monkey – это сервис, который работает в AWS с целью выявления инстансов, которые не соответствовали предопределенным правилам. Любой экземпляр, который не соответствует правилам, которые были достаточно гибкими, чтобы быть настроенными и настроенными на запуск с разной частотой, был идентифицирован, и уведомление по электронной почте отправляется владельцу или группе. С тех пор Conformity Monkey была переведена на услуги Spinnaker.

 

Горилла Хаоса

Горилла Хаоса похожа на Обезьяну Хаоса, но в более широком масштабе. Вместо того, чтобы имитировать сбои на отдельных инстансах AWS, Chaos Gorilla имитировала сбой всей зоны AWS. Эта утилита была разработана, чтобы показать, как крупномасштабная катастрофа повлияла на пользователей или клиентов в другом регионе, что идеально подходило для того, как была настроена инфраструктура и бизнес-модель Netflix. Если облачная платформа может выдержать этот тест, правильно обеспечив надлежащую работу балансировщиков нагрузки и прерывание служб, то она может выдержать все, что на нее бросают.

 

Обезьяна задержки

Latency Monkey, как следует из названия, используется для тестирования служб на соответствие сетевым задержкам или полным сбоям, чтобы помочь определить, как службы и их зависимости реагировали на эти смоделированные задержки. Однако, как и веб-сервисы в целом, в других приложениях могут быть неизвестные последствия, которые на первый взгляд могут быть нелегко идентифицированы, поэтому такая утилита, как Latency Monkey, так важна для измерения отказоустойчивости между службами.

 

Доктор Обезьяна

Утилита Doctor Monkey использовалась для выполнения проверок работоспособности отдельных экземпляров и мониторинга работоспособности (загрузка ЦП, память, ресурсы и т. д.) всей системы. Кроме того, Doctor Monkey может сообщать о состоянии экземпляра и удалять из обслуживания любые экземпляры, которые он считает непригодными для всей системы.

 

10-18 Обезьяна

Название 10-18 Monkey происходит от аббревиатур локализации и интернационализации и локализации, L10n и i18n. Цифры представляют собой количество букв между первой и последней буквами. Поскольку клиенты Netflix проживают по всему миру, наличие метода мониторинга надежности их потоковых сервисов в разных регионах было чрезвычайно важным. Преимущество утилиты 10-18 Monkey заключается в том, что она может проверять наличие проблем с конфигурацией и производительностью в нескольких географических регионах, которые обслуживают и используют разные языки и наборы символов.

 

Уборщика Обезьяна

Как насчет всех этих неиспользуемых ресурсов AWS? Введите Уборщик Обезьяна. Утилита Janitor Monkey предназначена для поиска и удаления неиспользуемых ресурсов. Как и Chaos Monkey, он также настраивается и расширяется, чтобы его можно было использовать с другими облачными провайдерами. Пользователи предоставляют набор правил, а Janitor Monkey выходит на работу, определяя те неиспользуемые ресурсы, группы и тома, которые являются кандидатами на очистку и удаление, и отправляет уведомление. Со временем функционал был заменен новым сервисом под названием Swabbie.

 

Вывод: Chaos Engineering — принципы, примеры и инструменты

Со временем хаос-инжиниринг перерос в собственную полноценную индустрию. В настоящее время существует множество инструментов с открытым исходным кодом и коммерческих инструментов, таких как Litmus Chaos, Gremlin, Chaos Mesh и многих других, которые организации могут использовать. Создание устойчивых систем предназначено не только для технологических компаний. Распределенные системы стали более сложными, что означает, что сбои труднее предсказать. Кроме того, из-за различных проблем с регулированием и соответствием банкам, государственным учреждениям, фармацевтическим компаниям, образовательным учреждениям и т. Д. Необходимо регулярно тестировать свои системы и услуги, чтобы убедиться, что они соответствуют деловым и критически важным требованиям. Тестирование производительности и тестирование хаоса являются проактивными подходами к обучению созданию устойчивых систем путем наблюдения за сбоями.