Хаос Инжиниринг

Почему Хаос должен быть частью вашей распределенной системной инженерии?

Важность Chaos Engineering в создании отказоустойчивых и динамичных системных архитектур

Зачем нам нужен хаос?

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

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

Традиционного подхода к мониторингу может быть недостаточно для получения необходимого уровня прозрачности для управления такими сложными распределенными системами. Чтобы избежать усталости от предупреждений и одновременно поддерживать эффективность групп SRE (Site Reliability Engineering), необходим баланс между низкоуровневой детализацией и высокоуровневым обобщенным представлением показателей мониторинга.
Несмотря на множество элементов управления которые созданы для того, чтобы SRE могли быстро реагировать на нежелательные инциденты в производственных системах, нам нужны средства контроля, которые помогут нам максимально упреждающе избегать инцидентов.

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

Как внести хаос в вашу дисциплину системной инженерии?

Для начала, если вы еще не знакомы с основными принципами инженерии хаоса, это хорошее место для начала - https://principlesofchaos.org/.
Когда дело доходит до создания хаоса для вашего конкретных систем и платформ, это зависит от инструментов и технологий, которые вы используете. Излишне говорить, что если ваша система находится в общедоступной облачной инфраструктуре, такой как AWS, Google Cloud или Azure, принципы проектирования или области для внесения контролируемых отказов могут быть очень похожими у поставщиков облачных услуг.

Некоторые моменты, которые следует учитывать при внедрении хаотической инженерии в вашу организацию или практику системной инженерии, включают:

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

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

  • Экземпляр EC2 прекращает работу.
  • Группа автомасштабирования EC2 не реагирует на события масштабирования.
  • Ошибка уровня API S3 (возможно, вы знаете https://aws.amazon.com/message/41926/ ??).
  • Сбои контейнера Docker.
  • Задержка обслуживания.
  • Лямбда-функции замедляют отклик.
  • Медленные запросы к базе данных.
  • Отработка отказа базы данных.
  • Распределенная обработка данных.
  • ЦП, память, дисковый ввод-вывод, сетевая нагрузка
  • Сбои диска.
  • Сбои процессов / служб
  • Зона доступности становится недоступной.
  • Отключение по региону.
  • … и так далее.

Еще одним фактором при выборе областей для введения контролируемых отказов являются требования доступности (SLA / SLO / SLI / RTO / RPO и т. Д.) Вашей системы.

Заключительные мысли

Хаос-инжиниринг - это новая область системной инженерии, которая еще не получила широкого распространения, и такие компании, как Netflix, Google, Amazon, Microsoft, Facebook (я уверен, что здесь не хватает некоторых великих имен) были пионерами в этой области. Если вы еще не знаете, Netflix's Simian Army - популярный набор инструментов в области хаос-инженерии. См. Https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116.

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

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

Для справки: я обнаружил, что https://github.com/dastergon/awesome-chaos-engineering - очень хорошее место, где можно найти множество ссылок на различный связанный контент.