stringtranslate.com

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

Хаос-инжиниринг — это дисциплина экспериментирования с системой с целью создания уверенности в ее способности выдерживать нестабильные условия производства. [1]

Концепция

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

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

Оперативная готовность с использованием хаос-инжиниринга

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

Оценка для создания хаоса в среде Kubernetes завершила случайные pod, получающие данные от периферийных устройств в центрах обработки данных во время обработки аналитики в сети больших данных. Время восстановления pod было показателем устойчивости, который оценивал время отклика. [2] [3]

История

1983 – Яблоко

В то время как MacWrite и MacPaint разрабатывались для первого компьютера Apple Macintosh , Стив Каппс создал «Monkey», настольный аксессуар , который случайным образом генерировал события пользовательского интерфейса на высокой скорости, имитируя обезьяну, которая неистово колотила по клавиатуре, двигалась и щелкала мышью. Его сразу же начали использовать для отладки , генерируя ошибки, которые программисты должны были исправить, поскольку автоматическое тестирование было невозможно; у первого Macintosh было слишком мало свободного места в памяти для чего-то более сложного. [4]

1992 – Пролог Пока ABAL2 и SING разрабатывались для первых графических версий операционной системы PROLOGUE, Иэн Джеймс Маршалл создал «La Matraque», настольный аксессуар , который случайным образом генерировал случайные последовательности как легальных, так и нелегальных событий графического интерфейса на высокой скорости, таким образом проверяя критическое поведение краев базовых графических библиотек. Эта программа запускалась до поставки продукции в течение нескольких дней подряд, тем самым обеспечивая требуемую степень общей устойчивости. Этот инструмент впоследствии был расширен, чтобы включить в себя инструкции Database и другие инструкции File Access языка ABAL для проверки и обеспечения их последующей устойчивости. Разновидность этого инструмента в настоящее время используется для квалификации современной версии, известной как OPENABAL.

2003 – Амазонка

Работая над повышением надежности веб-сайта Amazon , Джесси Роббинс создал «Game day» [5], инициативу, которая повышает надежность путем целенаправленного создания крупных сбоев на регулярной основе. Роббинс сказал, что она была вдохновлена ​​обучением пожарных и исследованиями в других областях — уроками сложных систем, инженерией надежности. [6]

2006 – Гугл

Работая в Google , Крипа Кришнан создал программу, похожую на Game day от Amazon (см. выше), под названием «DiRT». [6] [7] [8] Джейсон Кахун, инженер по надежности сайтов [9] в Google, написал главу о Google DiRT [10] в книге «Chaos Engineering» [11] и описал систему на конференции GOTOpia 2021. [12]

2011 – Нетфликс

Наблюдая за миграцией Netflix в облако в 2011 году, Нора Джонс, Кейси Розенталь и Грег Орзелл [11] [13] [14] расширили дисциплину, работая вместе в Netflix, создав инструмент, который вызывал сбои в их производственной среде, среде, используемой клиентами Netflix. Цель состояла в том, чтобы перейти от модели разработки, которая не предполагала никаких сбоев, к модели, в которой сбои считались неизбежными, заставляя разработчиков рассматривать встроенную устойчивость как обязанность, а не как вариант:

«В Netflix наша культура свободы и ответственности привела нас к тому, что мы не заставляли инженеров разрабатывать свой код определенным образом. Вместо этого мы обнаружили, что можем объединить наши команды вокруг понятия устойчивости инфраструктуры, изолируя проблемы, создаваемые нейтрализацией сервера, и доводя их до крайности. Мы создали Chaos Monkey, программу, которая случайным образом выбирает сервер и отключает его в обычные часы его активности. Некоторые сочтут это безумием, но мы не могли полагаться на случайное возникновение события, чтобы проверить наше поведение перед лицом последствий этого события. Знание того, что это будет происходить часто, создало прочную согласованность среди инженеров для создания избыточности и автоматизации процессов, чтобы пережить такие инциденты, не влияя на миллионы пользователей Netflix. Chaos Monkey — один из наших самых эффективных инструментов для улучшения качества наших услуг». [15]

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

Концепция хаос-инжиниринга близка к концепции Phoenix Servers, впервые представленной Мартином Фаулером в 2012 году. [16]

Инструменты для создания хаоса

Обезьяна Хаоса

Chaos Monkey — это инструмент, изобретенный Netflix в 2011 году для проверки устойчивости своей ИТ-инфраструктуры. [13] Он работает путем намеренного отключения компьютеров в производственной сети Netflix, чтобы проверить, как оставшиеся системы реагируют на сбой. Chaos Monkey теперь является частью более крупного набора инструментов под названием Simian Army, разработанного для моделирования и тестирования ответов на различные системные сбои и пограничные случаи.

Код Chaos Monkey был выпущен Netflix в 2012 году под лицензией Apache 2.0. [17] [18]

Название «Обезьяна Хаоса» объясняется в книге « Обезьяны Хаоса» Антонио Гарсиа Мартинеса: [19]

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

Армия обезьян

Simian Army [18] — это набор инструментов, разработанный Netflix для проверки надежности, безопасности и устойчивости своей инфраструктуры Amazon Web Services , включающий следующие инструменты: [20]

Другой

«День хаоса» Voyages-sncf.com 2017 года [23] игрофицировал симуляцию сбоев на этапе подготовки к производству [24] для представления на конференции DevOps REX 2017 года. [25] Основанная в 2019 году компания Steadybit популяризировала хаос на этапе подготовки к производству и проектирование надежности. [26] Ее открытый исходный код Reliability Hub расширяет Steadybit. [27] [28]

Proofdock может вводить сбои инфраструктуры, платформы и приложений в Microsoft Azure DevOps . [26] Gremlin — это платформа «сбой как услуга». [29] Project Storm от Facebook имитирует сбои в центрах обработки данных для обеспечения устойчивости к стихийным бедствиям. [30]

Смотрите также

Примечания и ссылки

  1. ^ "Принципы хаос-инжиниринга". principlesofchaos.org . Получено 21 октября 2017 г. .
  2. ^ Сивах, Гаутам (29 ноября 2022 г.). Оценка эксплуатационной готовности с использованием моделирования хаос-инжиниринга на архитектуре Kubernetes в больших данных (pdf) . Международная конференция 2022 года по интеллектуальным приложениям, коммуникациям и сетям (SmartNets). Ботсвана. стр. 1–7 . Получено 3 января 2023 г.
  3. ^ «Ведущий подкаста о машинном обучении и влиятельный человек в сфере технологий: Гаутам Сивах». LA Weekly . 7 октября 2022 г.
  4. ^ Херцфельд, Энди. «Обезьяна живёт». Фольклор . Получено 11 сентября 2023 г.
  5. ^ "Game day". AWS Well-Architected Framework Glossary . Amazon . 31 декабря 2020 г. Получено 25 февраля 2024 г.
  6. ^ ab Limoncelli, Tom (13 сентября 2012 г.). «Проектирование устойчивости: как научиться принимать неудачи». ACM Queue . 10 (9) – через ACM.
  7. ^ Кришнан, Крипа (16 сентября 2012 г.). «Выдержка неожиданностей». ACM Queue . 10 (9): 30–37. doi :10.1145/2367376.2371516 – через ACM.
  8. ^ Кришнан, Крипа (8–13 ноября 2015 г.). 10 лет сбоев Google (html) . 2015 Usenix LISA. Вашингтон, округ Колумбия . Получено 25 февраля 2024 г.
  9. ^ Бейер, Бетси; Джонс, Крис (2016). Site Reliability Engineering (1-е изд.). O'Reilly Media . ISBN 9781491929124. OCLC  1291707340.
  10. ^ "Глава 5. Google DiRT: Тестирование восстановления после сбоев". Веб-сайт книги "Chaos Engineering" . O'Reilly Media . 30 апреля 2020 г. Получено 25 февраля 2024 г.
  11. ^ ab Джонс, Нора; Розенталь, Кейси (2020). Chaos Engineering (1-е изд.). O'Reilly Media . ISBN 9781492043867. OCLC  1143015464.
  12. ^ Кахун, Джейсон (2 июня 2021 г.). «СМОТРЕТЬ: The DiRT о Chaos Engineering в Google» (видео) . youtube.com . Конференции GOTO.
  13. ^ ab "The Netflix Simian Army". Netflix Tech Blog . Medium . 19 июля 2011 г. Получено 21 октября 2017 г.
  14. ^ US 20120072571, Орзелл, Грегори С. и Израилевский, Юрий, «Проверка устойчивости сетевых приложений», опубликовано 22.03.2012 
  15. ^ "Netflix Chaos Monkey Upgraded". Netflix Tech Blog . Medium . 19 октября 2016 г. Получено 21 октября 2017 г.
  16. ^ "PhoenixServer". martinFowler.com . Мартин Фаулер (инженер-программист) . 10 июля 2012 г. . Получено 14 января 2021 г. .
  17. ^ "Netflix libère Chaos Monkey dans la jungle Open Source" [Netflix выпускает Chaos Monkey в джунгли с открытым исходным кодом]. Le Monde Informatique (на французском) . Получено 7 ноября 2017 г.
  18. ^ ab "SimianArmy: Инструменты для вашего облака, работающего в лучшей форме. Chaos Monkey — это инструмент обеспечения устойчивости, который помогает приложениям выдерживать случайные сбои экземпляров". Netflix, Inc. 20 октября 2017 г. Получено 21 октября 2017 г.
  19. ^ "Mais qui sont ces singes du chaos ?" [Но кто эти обезьяны хаоса?]. 15marches (на французском). 25 июля 2017 г. Получено 21 октября 2017 г.
  20. ^ SemiColonWeb (8 декабря 2015 г.). «Инфраструктура: методы для адаптера для новых облачных архитектур? - Блог D2SI». Блог D2SI (на французском языке). Архивировано из оригинала 21 октября 2017 года . Проверено 7 ноября 2017 г.
  21. ^ "Chaos Engineering Upgraded", medium.com , 19 апреля 2017 г. , получено 10 апреля 2020 г.
  22. ^ "The Netflix Simian Army", medium.com , получено 12 декабря 2017 г.
  23. ^ "Days of Chaos". Days of Chaos (на французском) . Получено 18 февраля 2022 г.
  24. ^ "DevOps: отзыв от Voyages-sncf.com". Блог модератора (на французском). 17 марта 2017 г. Получено 21 октября 2017 г.
  25. ^ devops REX (3 октября 2017 г.). «[разрабатывает REX 2017] Days of Chaos: le développement de la Culture devops chez Voyages-Sncf.com в качестве помощника по геймификации» . Проверено 18 февраля 2022 г.
  26. ^ ab Miller, Ron (22 сентября 2022 г.). «Steadybit хочет, чтобы разработчики занимались хаос-инжинирингом до начала производства». Tech Crunch .
  27. ^ Steadybit/reliability-hub-db, Steadybit, 26 августа 2024 г. , получено 26 августа 2024 г.
  28. ^ "Home". Steadybit Reliability Hub . Получено 26 августа 2024 г.
  29. ^ "Gremlin привлекает 18 миллионов долларов на расширение платформы тестирования "отказ как услуга"". VentureBeat . 28 сентября 2018 г. . Получено 24 октября 2018 г. .
  30. ^ Хоф, Роберт (11 сентября 2016 г.). «Интервью: как проект Facebook «Шторм» предотвращает катастрофы в центрах обработки данных». Forbes . Получено 26 августа 2024 г.

Внешние ссылки