Эта статья выбрана из серии статей «Практика инфраструктуры Byte Beat».

Серия статей «ByteDance Infrastructure Practice» представляет собой техническую галантерею, созданную техническими командами и экспертами отдела инфраструктуры ByteDance, в которой мы делимся с вами практическим опытом и уроками команды в процессе развития и эволюции инфраструктуры, а также всеми техническими студентами. общаться и расти вместе.

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

задний план

Что такое Хаос-инжиниринг

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

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

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

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

Я не буду здесь повторять более общие введения, связанные с хаос-инжинирингом, есть много связанных дискуссий, пожалуйста, обратитесь к «Хаос-инжинирингу: путь к стабильности системы Netflix» [1].

отраслевая практика

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

• Netflix впервые систематически предложил концепцию хаос-инжиниринга и опубликовал первую книгу в области хаос-инженерии Chaos Engineering: The Way of Netflix System Stability [1], в которой были предложены модель зрелости и применение хаос-инженерии. , и резюмирует пять высокоуровневых принципов, которые полезны для развития хаос-инжиниринга. Кроме того, Netflix открыл исходный код своего проекта Chaos Engineering — Chaos Monkey[3].
• Alibaba — одна из первых отечественных компаний, которая начала изучать хаос-инжиниринг и открытый исходный код.Его проект с открытым исходным кодом ChaosBlade[4] можно объединить с Alibaba Cloud для проведения экспериментов с хаосом.
• Будучи отличной компанией с открытым исходным кодом в области баз данных в Китае, PingCap инвестирует в область хаос-инженерии и недавно открыла свою внутреннюю платформу для практики хаос-инженерии — Chaos Mesh[5].
• Gremlin — компания по коммерциализации хаос-инженерии, которая предоставляет экспериментальную платформу хаос-инженерии для запуска сбоев путем установки своего агента на облачном хосте. При этом предлагается концепция хаоса gameday[2].

Как победить байтовую практику

Бизнес-линии ByteDance всегда могли видеть следы отработки ошибок, а также есть несколько простых инструментов, и платформа для отработки ошибок развивалась. Обнаружив, что платформа не может быть удовлетворена, мы начали вводить теоретическую концепцию хаос-инженерии, чтобы переосмыслить хаос-инженерию. Что касается хаос-инжиниринга, мы намерены обсудить его в трех частях:

• инжекция неисправности
• Автоматизированный анализ метрик
• Посадка тренировочной активности

Во время внедрения хаос-инжиниринга мы обнаружили, что нам нужно полагаться на две основные атомарные возможности, а именно на внедрение ошибок и обнаружение стабильности. Внедрение ошибок — это основа хаос-инжиниринга без особых объяснений. Возможность обнаружения стабильности может: 1. Сократить временные затраты на эксперимент.Мы можем положиться на автоматический индикаторный анализ, который поможет нам сделать вспомогательные суждения для получения большего результата. 2. Чтобы снизить стоимость риска эксперимента, мы можем полагаться на анализ автоматических индикаторов, чтобы сделать выводы о стабильности в качестве основы для решения прекратить автоматизацию эксперимента с хаосом.

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

первое поколение

Первое поколение можно считать ранним.В то время ByteDance использовала набор обучающих платформ аварийного восстановления внутри в качестве внутренней платформы сбоев.Архитектура выглядит следующим образом:

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

второе поколение

Весь этап по-прежнему в основном строится вокруг разломов, а целями этапа являются:

1. Что касается внедрения ошибок, расширяемый центр ошибок предназначен для создания точных и контролируемых ошибок.
2. Что касается практической деятельности, установите нормы хаос-инженерии и изучите передовой опыт.
3. Разделение внедрения ошибок и управления деятельностью в области хаоса.

Системный дизайн

Общий дизайн выглядит следующим образом:

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

модель отказа

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

Все сбои будут косвенно или напрямую влиять на микросервис. Наша конечная цель — наблюдать за устойчивостью самой службы при ненормальных внешних зависимостях.

Таким образом, мы расширили определение несоблюдения микроподачи в качестве цели. Модель неисправности выглядит следующим образом:

• Target— То есть целевой микросервис, упомянутый выше, перед запуском хаос-эксперимента необходимо уточнить, какой сервис внедряется в разлом, и этот сервис является основной целью наблюдения.
• Scope Filter- Соответствуя радиусу взрыва в концепции хаос-инжиниринга, в целях снижения риска экспериментов мы не будем затрагивать полный поток сервиса. Обычно отфильтровывается единица развертывания, которая является либо компьютерным залом, либо кластером, либо даже с точностью до уровня инстанса или даже уровня трафика.
• Dependency- Зависимость, мы думаем, что сбой затронул так называемый сервис, но на самом деле его зависимости ненормальны. Исключение может исходить от промежуточного программного обеспечения, нижестоящей службы или зависимого процессора, диска, сети и т. д.
• Action- События сбоя, то есть описывают, какой сбой произошел с внешними зависимостями службы, например, нижестоящая служба возвращает отказ, происходит потеря пакета или задержка; другим примером является исключение записи на диск, занятое чтение, полная запись и другие непредвиденные ситуации.

В соответствии с моделью неисправности псевдокод для объявления неисправности описывается следующим образом:

spec. //微服务application A 的 cluster1集群内10%的实例cpu突然满载
    tareget("application A").
    cluster_scope_filter("cluster1").
    percent_scope_filter("10%").
    dependency("cpu").
    action("cpu_burn").
    end_at("2020-04-19 13:36:23")
spec. //服务application B 的 cluster2集群所依赖的下游application C突然延时增加100ms
tareget("application B").
cluster_scope_filter("cluster2").
dependency("application C").
action("delay, 200ms").
end_at("2020-04-19 13:36:23")

Дизайн центра неисправностей

Мы разработали набор декларативных интерфейсов на основе описанной выше модели неисправности. Когда вы вводите определенную ошибку, просто добавьте оператор ошибки, поскольку описанная выше модель вступает в силу; если вы хотите прекратить работу ошибки, просто удалите объявление. Центр сбоев начинает искать условия условий на внутренней платформе системы НИОКР и автоматически устанавливает агент сбоя для реализации цели внедрения сбоя, отправляя соответствующие инструкции агенту. Центр ошибок соответствующим образом заимствован из архитектуры и концепции Kubernetes, и его архитектура разработана следующим образом:

Центр отказов состоит из трех основных компонентов: API-сервера, планировщика и контроллера, а также основного хранилища и т. д. вAPI ServerОтвечает за упаковку etcd и предоставление декларативного интерфейса для внешнего мира;SchedulerОн отвечает за синтаксический анализ объявления ошибки и непрерывный поиск экземпляра, соответствующего Цели, и нижестоящего экземпляра/промежуточного программного обеспечения/физического устройства, соответствующего Зависимости в соответствии с объявлением; после этого,ControllerОшибка действия анализируется в исполняемые инструкции и отправляется агенту соответствующего экземпляра, или вызывается API соответствующего промежуточного программного обеспечения для точного внедрения ошибки.

Принципы выбора эксперимента

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

• От оффлайна к производству
• От малого к большому
• Из прошлого в будущее
• От рабочего дня до дня отдыха

От оффлайна к производству

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

Тестовая среда -> Промежуточная среда -> Трафик, специфичный для среды предварительного просмотра -> Рабочий трафик производственного кластера

От малого к большому

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

Контролируемый трафик -> единый интерфейс -> одна машина -> один кластер -> одно машинное помещение -> полная ссылка

Из прошлого в будущее

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

Воспроизведение сбоев из исторических инцидентов -> типы сбоев из исторических инцидентов и аналогичных ссылок -> различные случайные сбои и полные ссылки.

От рабочего дня до дня отдыха

В данной статье речь идет о выборе времени проведения эксперимента по инженерии хаоса.День отдыха относится к любому времени. Мы рекомендуем начинать время эксперимента с рабочего дня, а оптимальное время — около 15:00 рабочего дня (каждый бизнес будет рассматриваться в соответствии со своими пиковыми и низкопиковыми периодами). В течение этого периода соответствующий персонал, как правило, работает, и любая ситуация может быть решена своевременно. Первоначальной целью хаос-инжиниринга было раннее выявление проблем в контролируемой среде. Конечно, по мере того, как Chaos Engineering продолжает развиваться, мы будем постепенно пытаться экспериментировать в любой момент времени. Лучший путь:

День днем ​​днем ​​-> Вечернего дня вечером -> День отдыха -> Случайное время

Эксперимент Дизайн

На этом этапе мы разрабатываем передовые методы проведения экспериментов с хаосом для бизнес-систем. Следуя этому процессу, эксперимент с хаосом станет более целенаправленным, а наблюдения — более содержательными.

Перед экспериментом

0. ⚠️ Прежде чем начать свой первый эксперимент с Chaos, убедитесь, что в вашем сервисе применен отказоустойчивый режим, и будьте готовы обрабатывать возможные ошибки, в противном случае не пробуйте его.

1. Способность подготовиться к введению неисправности
А. Возможность моделирования неисправностей экспериментальной платформы ByteDance Chaos Engineering
б. Свяжитесь с каждой проверяющей стороной, чтобы вручную создать ошибку

2. Выберите гипотезу для этого эксперимента, например:
А. Бизнес не пострадает из-за сбоя нижестоящей службы.
б) джиттер сети Redis не повлияет на бизнес.
в) На бизнес не повлияет внезапное уничтожение модуля.
г. В случае сбоя основной нижестоящей зависимости план перехода на более раннюю версию должен быть эффективным, а побочные эффекты приемлемыми.

3. Выберите показатели, отражающие экспериментальную гипотезу, и наблюдайте.
4. Выберите показатели, отражающие потерю обслуживания, и установите базовый уровень.
5. Общение внутри организации.

В эксперименте

1. Внимательно следите за соответствующими показателями во время выполнения, так как в любой момент может потребоваться прекратить эксперимент.
2. Помня об экспериментальных предположениях, соберите соответствующие индикаторы, чтобы помочь в последующем анализе экспериментальных результатов.
3. Во время эксперимента экспериментальные параметры (диапазон и интенсивность ошибок) можно в любой момент отрегулировать в соответствии с колебаниями индекса, и еще несколько попыток приведут к лучшим результатам.

После эксперимента

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

Суммировать

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

Третье поколение

После завершения практики на предварительном этапе уже доступна основная возможность хаоса — внедрение ошибок, и бизнес-направления ByteDance также начали путь хаоса. Итак, на данном этапе наши цели:

1. В части автоматизированного индикаторного анализа возможности индикаторного анализа дополняются.
2. С точки зрения внедрения ошибок, обогатите типы ошибок.
3. С точки зрения практической деятельности, практическая деятельность, обобщенная на предыдущем этапе, будет ускорена, а практические формы будут дополнительно изучены, чтобы получить большую ценность.

Системный дизайн

Исходя из вышеуказанных целей, общая конструкция выглядит следующим образом:

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

На уровне платформы добавьте автоматическое прочесывание сильных и слабых зависимостей и боритесь с красными и синими модулями.

Автоматизированный просмотр метрик

В эксперименте с хаосом сортировка и сбор соответствующих индикаторов — утомительное и трудоемкое занятие. После наблюдения за процессом эксперимента с хаосом мы суммируем три категории индикаторов следующим образом:

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

индикатор неисправности

• Определение индикатора- Индикатор неисправности возникает из-за неисправности, а индикатор колеблется из-за неисправности. Например, мы вводим ошибку: задержка redis увеличивается на 30 мс, тогда показатель — это средняя задержка между целевым сервисом -> redis, задержка pct99 и т. д. Этот индикатор может помочь пользователям визуально увидеть возникновение и окончание сбоев.
• как с этим бороться- Для таких индикаторов просто покажите это, что может гарантировать, что пользователи могут четко видеть, когда сбой начинается и когда он заканчивается.
• доступ- От сбоя, когда платформа совершает сбой, платформа знает, какие непосредственные индикаторы будут затронуты.

индикатор стоп-лосс

• Определение индикатора- Индикатор стоп-лосса очень важен для целевой службы / целевого бизнеса, указывающий на максимальный предел, что упражнение может нести. Индикатор может быть связан с самой услугой (например, внешняя скорость ошибки), или это может быть связано с далеким Бизнес-индикаторы (например, в каждые минуты по требованию), он может даже поступать из индекса средней линии (например, максимальный индекс допуска в нижней строке); это также может быть некоторая комбинация различных показателей упомянутый выше.
• как с этим бороться- Для таких индикаторов необходимо очень точно определить ключевые пороги.Как только флуктуация достигает порога, это означает, что достигнута нижняя граница потерь.Любая операция должна быть немедленно остановлена, а неисправность должна быть устранена.

Индикатор наблюдения

• Определение индикатора- Индикаторы наблюдения очень полезны для обнаружения новых проблем во время экспериментов с хаосом. Наблюдаемые метрики должны охватывать все, что связано с обслуживанием и сбоями. Например, четыре золотых индикатора SRE (задержка, трафик, ошибки и насыщение) самой службы, такие как связанные индикаторы, на которые может повлиять сбой (сбой задержки redis, приведет ли он к изменениям в других индикаторах redis). • redis qps, reids ошибки, понижение уровня обслуживания) изменения qps), такие как связанные записи сигналов тревоги, связанные журналы.
• как с этим бороться- Четкого порога для таких показателей нет, но именно по этим показателям часто легче всего найти различные потенциальные проблемы при посмертном анализе.Мы внедрили методы машинного обучения при работе с такими показателями, и по сравнению с историческими закономерностями показателей, это Можно сделать автоматическое обнаружение аномалий.

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

Практика противостояния красных и синих

Практика конфронтации красно-синих в ByteDance заимствована из хаоса [2], введенного Gremlin. Во внутренней практике ByteDance мы также постоянно корректировались в соответствии с местными условиями и, наконец, превратились в практику противостояния красно-синих, представленную ByteDance. Целью реализации красно-синей конфронтации является помощь бизнес-системе в проведении всестороннего исследования, а также ее можно рассматривать как централизованную проверку цели построения стабильности бизнес-системы.

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

Разработка процесса

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

红蓝对抗一旦开启后，主要操作将由蓝方主导，除非发生预期外情况（这一般也意味着防守失败）或者需要操作预案开关，否则红方在此过程中，基本处于 stand by 状态。 Основной процесс выглядит следующим образом:

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

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

Сильная и слабая зависимость Автоматическая практика кардинга

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

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

Общий процесс автоматической сортировки сильных и слабых зависимостей выглядит следующим образом:

Суммировать

На этом этапе мы дополнили возможности индексного анализа, и за счет внедрения машинного обучения стоимость индексного анализа значительно снизилась.

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

будущая стадия

Хаос проект для инфраструктуры

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

Однако чем ближе вы подходите к инфраструктуре, тем сложнее имитировать сбои. Например, ядро ​​компонента хранилища, диск, его имитация неисправности должны будут шаг за шагом углубляться в состояние ядра ОС и даже физический уровень для имитации неисправности.

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

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

IAAS With Chaos

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

Полностью автоматизированный эксперимент со случайным хаосом

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

Интеллектуальная диагностика неисправностей

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

конец

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

использованная литература

1. «Инженерия хаоса: путь к стабильности системы в Netflix»: https://www.oreilly.com/library/view/chaos-engineering/9781491988459/
2. «Как провести GameDay»: https://www.gremlin.com/community/tutorials/how-to-run-a-gameday/
3. Проект с открытым исходным кодом Netflix Chaos Engineering — Chaos Monkey: https://github.com/Netflix/chaosmonkey
4. Проект с открытым исходным кодом Alibaba Chaos Engineering — ChaosBlade: https://github.com/chaosblade-io/chaosblade
5. Проект с открытым исходным кодом PingCAP Chaos Engineering — Chaos Mesh: https://github.com/pingcap/chaos-mesh
6. Платформа распределенного тестирования на соответствие — Jepsen: https://jepsen.io/
7. Zhou, Xiang, et al. "Latent error prediction and fault localization for microservice applications by learning from system trace logs." Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 2019. https://dl.acm.org/doi/10.1145/3338906.3338961

поделиться больше

gdb запрашивает усеченный файл coredump для устранения неполадок

Практика улучшения ByteDance на движке хранения RocksDB

ByteDance самостоятельно разработала графовую базу данных триллионов уровней и практику графовых вычислений

Добро пожаловать в техническую команду ByteDance