Jump to content

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

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

Концепция

[ редактировать ]

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

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

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

[ редактировать ]

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

1983 – Яблоко

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

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

2003 – Амазонка

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

2006 – Гугл

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

2011 – Нетфликс

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

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

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

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

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

[ редактировать ]

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

[ редактировать ]
Логотип Chaos Monkey, используемый Netflix

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

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

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

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

Обезьянья армия

[ редактировать ]

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

На самом верху иерархии обезьяньей армии Хаос Конг размещает полноценный « Регион » AWS. [21] Потеря целого региона случается, хотя и редко, но Chaos Kong моделирует реакцию системы и восстановление на события такого типа.

Chaos Gorilla удаляет полную « зону доступности » Amazon (один или несколько целых центров обработки данных, обслуживающих географический регион). [22]

Платформа разработки хаоса Proofdock

[ редактировать ]

Proofdock — это платформа проектирования хаоса, которая фокусируется на платформе Microsoft Azure и службах Azure DevOps и использует их . Пользователи могут вносить сбои на уровне инфраструктуры, платформы и приложения. [23]

Стедибит

[ редактировать ]

Steadybit, основанная в 2019 году, представляет собой платформу для проектирования хаоса и устойчивости, целью которой является сокращение времени простоя и улучшение видимости системы для раннего обнаружения проблем. Steadybit также управляет Центром надежности на GitHub — коллекцией расширений хаос-инжиниринга с открытым исходным кодом. [23]

Gremlin — это платформа «отказ как услуга». [24]

Фейсбук Шторм

[ редактировать ]

Чтобы подготовиться к потере центра обработки данных, Facebook регулярно тестирует устойчивость своей инфраструктуры к экстремальным событиям. Программа, известная как Storm Project, имитирует массовые сбои в центрах обработки данных. [25]

Дни хаоса

[ редактировать ]

Voyages-sncf.com устроил «День хаоса» [26] в 2017 году геймифицировали моделирование неудач на этапе подготовки к производству. [27] Свои результаты они представили на конференции DevOps REX 2017. [28]

См. также

[ редактировать ]

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

[ редактировать ]
  1. ^ «Принципы хаос-инжиниринга» . www.principlesofchaos.org . Проверено 21 октября 2017 г.
  2. ^ Сивах, Гаутам (29 ноября 2022 г.). Оценка эксплуатационной готовности с помощью моделирования хаоса в архитектуре Kubernetes в больших данных (pdf) . Международная конференция по интеллектуальным приложениям, коммуникациям и сетям (SmartNets) 2022 года. Ботсвана. стр. 1–7 . Проверено 3 января 2023 г.
  3. ^ «Ведущий подкаста о машинном обучении и влиятельный человек в сфере технологий: Гаутам Сивах» . Лос-Анджелес Еженедельник . 7 октября 2022 г.
  4. ^ Херцфельд, Энди. «Обезьянка жива» . Фольклор . Проверено 11 сентября 2023 г.
  5. ^ «Игровой день» . Глоссарий AWS Well-Architected Framework . Амазонка . 31 декабря 2020 г. Проверено 25 февраля 2024 г.
  6. ^ Jump up to: а б Лимончелли, Том (13 сентября 2012 г.). «Инженерия устойчивости: учимся преодолевать неудачи» . Очередь АКМ . 10 (9) – через ACM.
  7. ^ Кришнан, Крипа (16 сентября 2012 г.). «Выветривание неожиданного» . Очередь АКМ . 10 (9): 30–37. doi : 10.1145/2367376.2371516 – через ACM.
  8. ^ Кришнан, Крипа (8–13 ноября 2015 г.). 10 лет краха Google (html) . 2015 Усеникс ЛИЗА. Вашингтон, округ Колумбия . Проверено 25 февраля 2024 г.
  9. ^ Бейер, Бетси; Джонс, Крис (2016). Проектирование надежности объекта (1-е изд.). О'Рейли Медиа . ISBN  9781491929124 . OCLC   1291707340 .
  10. ^ «Глава 5. Google DiRT: Тестирование аварийного восстановления» . Сайт книги «Инженерия Хаоса» . О'Рейли Медиа . 30 апреля 2020 г. Проверено 25 февраля 2024 г.
  11. ^ Jump up to: а б Джонс, Нора; Розенталь, Кейси (2020). Хаос-инжиниринг (1-е изд.). О'Рейли Медиа . ISBN  9781492043867 . OCLC   1143015464 .
  12. ^ Кахун, Джейсон (2 июня 2021 г.). «СМОТРЕТЬ: DiRT по Chaos Engineering в Google» (видео) . youtube.com . ПЕРЕЙТИ К Конференциям .
  13. ^ Jump up to: а б «Обезьянья армия Netflix» . Технический блог Netflix . Середина . 19 июля 2011 года . Проверено 21 октября 2017 г.
  14. ^ США 20120072571 , Орзелл, Грегори С. и Израилевский, Юрий, «Проверка устойчивости сетевых приложений», опубликовано 22 марта 2012 г.  
  15. ^ «Обновление Netflix Chaos Monkey» . Технический блог Netflix . Середина . 19 октября 2016 г. Проверено 21 октября 2017 г.
  16. ^ «ФениксСервер» . 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. ^ Jump up to: а б «SimianArmy: инструменты для вашего облака, работающие в отличной форме. Chaos Monkey — это инструмент обеспечения устойчивости, который помогает приложениям выдерживать случайные сбои экземпляров» . Netflix, Inc., 20 октября 2017 г. Проверено 21 октября 2017 г.
  19. ^ «Mais qui sont cessinges du Chaos?» [Но кто эти обезьяны хаоса?]. 15 марта (на французском языке). 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. ^ «Обезьянья армия Netflix» , medium.com , получено 12 декабря 2017 г.
  23. ^ Jump up to: а б Миллер, Рон (22 сентября 2022 г.). «Steadybit хочет, чтобы разработчики участвовали в хаос-инжиниринге перед началом производства» . Технический кризис .
  24. ^ «Gremlin собирает 18 миллионов долларов на расширение платформы тестирования «отказ как услуга»» . ВенчурБит . 28 сентября 2018 г. Проверено 24 октября 2018 г.
  25. ^ Хоф, Роберт (11 сентября 2016 г.), «Интервью: как буря Facebook предотвращает катастрофы в центрах обработки данных проекта» , Forbes , получено 21 октября 2017 г.
  26. ^ «Дни хаоса» . Дни хаоса (на французском языке) . Проверено 18 февраля 2022 г.
  27. ^ «DevOps: отзыв от Voyages-sncf.com» . Блог модератора (на французском языке). 17 марта 2017 года . Проверено 21 октября 2017 г.
  28. ^ devops REX (3 октября 2017 г.). «[devops REX 2017] Days of Chaos: развитие devops-культуры на Voyages-Sncf.com с помощью геймификации» . Проверено 18 февраля 2022 г.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 9055db0986d7479cedbf2bdb68c3062c__1720840500
URL1:https://arc.ask3.ru/arc/aa/90/2c/9055db0986d7479cedbf2bdb68c3062c.html
Заголовок, (Title) документа по адресу, URL1:
Chaos engineering - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)