Фраза дня: хаос инженерия

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

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

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

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

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

Есть много причин, по которым распределенная система может выйти из строя. Их размер и сложность могут вызывать, казалось бы, случайные события. Чем больше и сложнее система, тем более непредсказуемым и хаотичным выглядит ее поведение.

Инженерные эксперименты с хаосом намеренно создают турбулентные условия в распределенной системе, чтобы проверить систему и найти слабые места. Вот некоторые примеры проблем, которые может выявить эксперимент с хаосом:

• Слепые пятна. Места, в которых программное обеспечение для мониторинга не может собрать адекватные данные.
• Скрытые ошибки. Сбои или другие проблемы, которые могут вызвать сбои в работе программного обеспечения.
• Узкие места в производительности. Ситуации, в которых можно повысить эффективность и производительность.

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

Как работает Chaos Engineering
Хаос-инжиниринг похож на стресс-тестирование в том, что он направлен на выявление и исправление системных или сетевых проблем. В отличие от стресс-тестирования, Chaos Engineering не тестирует и не исправляет один компонент за раз.

Chaos Engineering исследует проблемы, которые имеют, казалось бы, бесконечное количество возможных причин. Он выходит за рамки очевидных проблем и тестирует распределенные системы на предмет проблем или наборов проблем, которые с меньшей вероятностью возникнут. Цель - получить новые знания о системе.

Обычно процесс делится на несколько этапов:

1. Установите базовую линию. Начните с установления базового уровня. Тестировщики должны определить, как система должна работать в оптимальных условиях, и указать, что составляет нормальное рабочее состояние.
2. Создайте гипотезу. Рассмотрите одну или несколько потенциальных слабостей и сформулируйте гипотезу о влиянии этих слабостей. Например, тестировщики программного обеспечения могут захотеть узнать, что произойдет, если произойдет большой всплеск трафика.
3. Контрольная работа. Проведите эксперименты, чтобы оценить последствия большого всплеска. Эксперименты могут выявить ошибку в критическом процессе или неожиданную причинно-следственную связь. Например, моделирование всплеска трафика может выявить проблему с производительностью хранилища.
4. Оценивать. Измерьте и оцените, насколько верна гипотеза, и определите, какие проблемы нужно исправить.

Команды инженеров Хаоса применяют упорядоченный подход в своих экспериментах, проверяя следующее:

• То, что они знают и понимают.
• То, что они осознают, но не понимают полностью.
• То, что они понимают, но не осознают.
• То, что они полностью не осознают и не до конца понимают.

Они используют сценарии «что, если», которые могут вызывать сбои и отказы, для оценки производительности и целостности системы.

Продвинутые принципы хаос-инженерии
Компьютерный ученый Л. Питер Дойч и его коллеги из Sun Microsystems разработали список из восьми ошибок распределенных вычислений. Это ложные предположения, которые программисты и инженеры часто делают о распределенных системах. Они являются хорошей отправной точкой при применении к проблеме инженерии хаоса. Восемь заблуждений включают:

1. Сеть надежная.
2. Нет задержки.
3. Пропускная способность бесконечна.
4. Сеть безопасна.
5. Топология никогда не меняется.
6. Есть один админ.
7. Транспортные расходы нулевые.
8. Сеть однородная.

Ведутся споры о том, являются ли эти заблуждения заблуждениями, но инженеры по хаосу продолжают использовать их в качестве основных принципов для понимания системных и сетевых проблем. В основе их лежит идея о том, что системы и сети никогда не бывают идеальными или на 100% надежными. Из-за этого у нас есть концепция «пяти девяток» для высокодоступных систем. Вместо того, чтобы стремиться к 100% доступности, инженеры могут достичь совершенства на уровне 99,999%.

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

Лучшие практики Chaos Engineering
Инженерия хаоса сложна. Следование этим передовым методам может помочь избежать проблем, связанных с перечисленными выше заблуждениями:

• Разберитесь в обычном поведении системы. Четкое понимание системы, когда она исправна, поможет в диагностике проблем.
• Смоделируйте реалистичные сценарии. Сосредоточьтесь на внедрении вероятных сбоев и ошибок. Например, если задержка была проблемой в прошлом, добавьте ошибки, которые вызывают задержку.
• Протестируйте в реальных условиях. Это дает наиболее точные результаты. Хаос-инжиниринг часто выполняется в производственной среде, особенно когда слишком громоздко или дорого дублировать большую распределенную систему для целей тестирования.
• Минимизируйте радиус взрыва. Инженерия хаоса может быть очень разрушительной. Успех требует координации между ИТ-персоналом, разработчиками и бизнес-подразделениями. Эксперименты в производственных средах редко проводятся в часы пик, и в идеале никто, использующий систему, не сможет сказать, что происходят эксперименты хаоса. Должна быть предусмотрена избыточность, чтобы услуги оставались доступными, если эксперименты действительно вызывают проблемы.

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

Инжиниринг хаоса также можно использовать для проверки поведения распределенной системы при нехватке ресурсов или возникновении единой точки отказа. Если система выйдет из строя, разработчики могут внести изменения в дизайн. После внесения изменений тест повторяется для проверки желаемых результатов.

Одна заметная системная ошибка в реальном мире была связана с хаосом инженерной мысли. В 2015 году DynamoDB Amazon столкнулся с проблемой доступности в одной из своих региональных зон. Этот провал привел к отказу более 20 веб-сервисов Amazon, которые полагались на DynamoDB в этом регионе. Сайты, которые использовали сервисы, в том числе Netflix, не работали в течение нескольких часов. Однако Netflix столкнулся с меньшими сбоями, чем другие сайты, потому что он создал и использовал инструмент инженерии хаоса под названием Chaos Kong, чтобы подготовиться к такому сценарию.

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

Инструменты хаоса
Netflix был заметным пионером в области инженерии хаоса и одним из первых применил его в производственных системах. Netflix разработала платформу автоматизации тестирования хаоса с открытым исходным кодом, получившую общее название Simian Army.

В набор Simian Army включено несколько инструментов, в том числе:

• Chaos Kong. Отключает все зоны доступности AWS.
• Chaos Monkey. Случайным образом отключает экземпляры производственной среды, чтобы вызвать сбой системы, но не влияет на активность клиентов.
• Chaos Gorilla. Как Chaos Monkey, но в большем масштабе.
• Latency. Представляет задержку для имитации сбоев и деградации сети.

Netflix Simian Army продолжает расти, поскольку создается все больше программ, вызывающих хаос, для проверки возможностей потокового сервиса. Некоторые другие инструменты инженерии хаоса включают в себя:

Simoorg. Программа с открытым исходным кодом, приводящая к сбоям. LinkedIn использует эту программу для проведения экспериментов по инженерии хаоса.

Monkey-Ops.. Инструмент с открытым исходным кодом, реализованный на Go и предназначенный для тестирования и завершения случайных компонентов и конфигураций развертывания.

Gremlin. Программа разработки хаоса, которая работает с AWS и Kubernetes и ориентирована на розничный и финансовый секторы. Он поставляется со встроенной избыточностью, которая останавливает хаос инженерных экспериментов, когда они угрожают системе.

AWS Fault Injection Simulator. Включает шаблоны ошибок, которые AWS может внедрять в производственные экземпляры. Платформа имеет встроенные средства резервирования и защиты, чтобы тестирование с введением отказов не привело к возникновению системных проблем.