Открытый исходный код генератора хаоса от Netflix, Chaos Monkey
Netflix демонстрирует, что компаниям, которые думают о переходе на облачную инфраструктуру, необходимо построить свои системы, чтобы они потерпели неудачу.
Фраза создан для неудач не вселяет уверенности, так как говорит о том, что продукт находится в нескольких шагах от взрыва.
Прежде чем приступить к объяснению термина хаос-инжиниринг, мы полагаем, что вы должны обладать некоторыми знаниями о важности тестирования в цикле разработки программного обеспечения. Вот где на сцену выходят интеллектуальные тестовые примеры и концепции.
В наше время инкрементальных выпусков и гибкой разработки, постоянное изучение программного обеспечения является обязательным условием для обеспечения бесперебойной, безупречной и согласованной работы для пользователей.
В настоящее время технологические организации внедряют современные автоматизированные способы тщательного и полного тестирования программного обеспечения.
Принимая во внимание современную техническую инфраструктуру и распределенные системы, тестирование кажется более сложным и трудным для изучения со всех точек зрения. Поэтому организации разрабатывают более разумные способы тестирования своих систем от единичного до функционального, до тестирования инфраструктуры.
Одна из таких концепций, представленных Netflix, - это инженерия хаоса.
Chaos Engineering: тестирование инфраструктуры на уровне Netflix
Инжиниринг хаоса был представлен Netflix, одним из крупнейших сервисов подписки на медиа с около 150 миллионами платных подписок по всему миру.
Прежде чем мы поймем эту концепцию, вот краткое объяснение терминов, которые мы собираемся использовать в этом блоге.
В современном жизненном цикле приложения есть четыре среды, которые используются технологическими компаниями по всему миру для разработки программного обеспечения.
- Среда разработки: где программа разрабатывается / кодируется.
- Тестовая среда: где продукт копируется и тщательно тестируется, чтобы обеспечить ожидаемую работу.
- Среда приемочного тестирования: где клиент тестирует систему и проверяет, соответствует ли она ожиданиям или нет.
- Производственная среда: рабочая среда, в которую попадает продукт после прохождения приемочных испытаний.
Что такое Chaos Engineering?
Достижения в области крупномасштабных распределенных программных систем меняют правила игры в программную инженерию. Как отрасль, мы быстро применяем методы, повышающие гибкость разработки и скорость развертывания.
Вслед за этими преимуществами следует срочный вопрос: «Насколько мы можем быть уверены в сложных системах, которые мы запускаем в производство?»
Проще говоря, хаос-инжиниринг - это дисциплинированный подход к выявлению уязвимостей в системах в производственной среде. Он реализован для проверки надежности, стабильности и способности системы выжить в нестабильных и неожиданных условиях.
Когда мы рассматриваем крупномасштабные распределенные системы, существует множество вероятностей сбоев, включая сбой приложений, сбой сети, сбой инфраструктуры, сбой зависимости и т. Д.
Более того, система разрабатывается в виде микрокомпонентов и развертывается в облачной архитектуре, что делает ее более подверженной сбоям и сбоям.
Потребность в инженерии хаоса
Вот несколько моментов, которые оправдывают создание хаоса:
- Повышает устойчивость системы.
- Вы узнаете слабые стороны системы.
- Это проактивный характер, в отличие от реактивного характера традиционного тестирования.
- Он выявляет скрытые угрозы и сводит к минимуму риски.
Разница между Chaos Engineering и тестированием
Первая концепция тестирования состоит в том, что у него есть несколько наборов входных и прогнозируемых выходов для получения желаемого поведения системы. Его возможности ограничены, поскольку он не генерирует совершенно новых знаний о том, как система будет вести себя, если что-то пойдет не так.
Chaos Engineering проводит обширные, тщательные и непредсказуемые эксперименты, которые генерируют новые знания о поведении, свойствах и производительности системы. Он имеет более широкий охват и незапланированные комбинации, позволяющие очень внимательно наблюдать за системой с различными форматами обучения.
Эксперименты с хаосом безграничны, что создает больше возможностей для тестирования системы со всех точек зрения. Вы можете создать преднамеренный хаос, чтобы проверить, выдержит ли система его или нет.
Вход Netflix в область Chaos Engineering
В 2011 году Netflix решила перейти от физической инфраструктуры к облаку, чтобы предоставить пользователям лучший опыт потоковой передачи видео.
Команда инженерных инструментов Netflix предложила новаторскую идею тестирования отказоустойчивости системы без какого-либо влияния на обслуживание клиентов.
Они создали инструмент Обезьяна Хаоса, вдохновленный идеей обезьяны, которая входит на ферму и случайным образом уничтожает предметы.
Из блога Netflix Technology:
«Chaos Monkey - это инструмент, который случайным образом отключает наши производственные экземпляры, чтобы убедиться, что мы сможем пережить этот распространенный тип сбоя без какого-либо воздействия на клиента».
В отличие от физической среды предполагается, что облачный переход Netflix имеет больше сбоев, поскольку он абстрактен и распределен по своей природе. Причина запуска инструмента Chaos Monkey в системе Netflix проста:
Главное в облаке - избыточность и отказоустойчивость. Поскольку ни один компонент не может гарантировать 100% безотказной работы (и даже самое дорогое оборудование в конечном итоге выходит из строя), мы должны разработать облачную архитектуру, в которой отдельные компоненты могут выходить из строя, не влияя на доступность всей системы. По сути, мы должны быть сильнее, чем наше самое слабое звено. - Технический блог Netflix
После успеха инструмента Chaos Monkey команда Netflix создала набор инструментов, поддерживающих принципы разработки хаоса, и назвала его Simian Army, чтобы проверить надежность и отказоустойчивость инфраструктуры AWS.
Прямо сейчас проект ушел в отставку, и новый проект - это только Chaos Monkey.
Список инструментов, разработанных Netflix
- Обезьяна хаоса
- Обезьяна с задержкой
- Доктор Обезьяна
- Соответствие Обезьяна
- Дворник Обезьяна
- Обезьяна безопасности
- Хаос Горилла
- 10–18 Обезьяна
Все это инструменты хаоса, которые постоянно тестируют систему на предмет всевозможных сбоев, повышая уровень уверенности в способности системы выжить.
Как можно использовать Chaos Engineering в облачной инфраструктуре?
Вы можете сказать: «Мы не Netflix, и у нас нет такой крупномасштабной системы или огромной клиентской базы, как Netflix».
Это правда. Но со временем он эволюционировал и не ограничивается одной организацией или цифровой компанией, такой как Netflix.
Есть много компаний с огромной клиентской базой, которые стремятся предложить своим пользователям беспроблемный опыт. А чтобы обеспечить стабильную производительность и постоянную доступность, медицинские, образовательные и финансовые организации проводят эксперименты с хаосом.
Четыре основных шага к реализации Хаос-Инжиниринга
Хаос в распределенных системах требует, чтобы две группы контролировали и отслеживали действия: экспериментальная группа, которая экспериментирует, и контрольная группа, которая занимается результатами экспериментов.
- Определите установившееся состояние, которое представляет нормальное поведение системы.
- Инженеры Chaos предполагают ожидаемый результат, когда что-то пойдет не так.
- Спроектируйте эксперименты с переменными, чтобы отразить реальные события, такие как сбой зависимостей, сбой сервера, сбой сети или памяти и т. Д.
- Измерение воздействия тестов и наблюдение за разницей в установившемся состоянии в обеих группах.
Если команда инженеров может найти слабые места в системе, то это успешный эксперимент с хаосом, в противном случае они расширяют свои гипотетические границы.
При обнаружении слабых мест команда устраняет эти проблемы до того, как они станут общесистемными.
Примечание. Поскольку эксперименты с хаосом проводятся в производственной среде или ближе к производственной среде, есть вероятность, что это может повлиять на качество обслуживания клиентов. Так что всегда разумно планировать самые маленькие эксперименты и быть готовым осторожно справиться с воздействием.
Конечная цель Chaos Engineering: откройте для себя сценарий «Что, если»
Распределенная система обычно имеет больше точек отказа из-за своей сложности и крупномасштабного характера. Chaos Engineering пытается обнаружить эти точки отказа и определить, что произойдет в случае недоступности ресурса или объекта.
Это очень подходящая практика в современных подходах к разработке программного обеспечения, таких как DevOps и архитектура микросервисов.
Сегодня не только Netflix, но и многие гигантские организации используют его, чтобы гарантировать, что система выдержит любые сбои, а затем исправляют проблемы в системе во время экспериментов с хаосом.
Компании, использующие инструменты хаоса
- Microsoft
- Амазонка
- Twilio
Chaos Engineering и DevOps: лучше разбирайтесь в своей системе во время частых выпусков
Принципы хаоса - лучший подход для проверки способности системы противостоять сбоям, когда речь идет о разработке программного обеспечения на основе DevOps.
Системные архитекторы и тестировщики спешат выпустить программное обеспечение, и вы можете обнаружить неизвестные условия, выполняя хаос-инжиниринг в распределенных, постоянно меняющихся и сложных методологиях разработки.
За последние несколько лет мы стали свидетелями радикальных изменений в структурах и методах разработки программного обеспечения. На смену монолитной архитектуре пришла облачная и микросервисная архитектура для быстрого создания программного обеспечения.
Здесь также лучше всего работает хаос, поскольку он может выявить точки отказа зависимости или соединения, которые являются общими в структуре микросервисов системы.
Chaos Engineering: больше, чем превентивный механизм
Эта цитата имеет гораздо больший смысл при понимании идеи, лежащей в основе принципов хаоса. Вам нужно извлечь уроки из неудач, чтобы улучшить вашу систему, сделать ее более устойчивой и повысить уверенность в ее возможностях.
Существует множество инструментов для борьбы с хаосом, и многие организации экспериментируют с различными методами и инструментами, чтобы сделать его более зрелым и полезным.
Умышленно создавая хаос в системе, организация может добиться долгосрочной отказоустойчивости программного обеспечения. Отказоустойчивость и качество считаются важными факторами, когда мы говорим о распределенных системах с более быстрыми циклами выпуска.
