Сценарный активный эксперимент практики ByteDance Chaos Engineering

задний план

С тех пор, как Netflix запустил первую версию Chaos Mokey в 2010 году, хотя разработка хаос-инженерии длилась десять лет, она была реализована только на нескольких крупных фабриках.

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

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

Что такое активное экспериментирование на основе сценариев?

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

Согласно модели зрелости Chaos Engineering Maturity Model (CMM) [4], построение должно вестись одновременно из двух измерений «профессиональность» и «степень применения». Среди них «мастерство» отражает эффективность и безопасность системы хаос-инжиниринга, а «степень применения» измеряет широту и глубину экспериментов по хаос-инженерии. На средних и ранних стадиях хаотического инженерного строительства эти два момента являются ключевыми путями для успешного внедрения хаотического инженерного дела.

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

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

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

Как прорваться через этот этап и успешно достичь конечной цели хаос-инженерии?

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

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

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

混沌工程演变图

Диаграмма эволюции Chaos Engineering

Как построить активный эксперимент на основе сценария

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

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

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

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

Сценарий Активный эксперимент Топология возможностей

Активный контроль

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

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

Экспериментальная сцена

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

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

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

Цепочка вызовов зависимостей службы

автоматизация

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

Его можно отделить от высокоуровневых принципов хаос-инжиниринга [2]:

Допущения об устойчивом состоянии для услуг: Найдите общие индикаторы, которые могут описать стабильное состояние сервиса, это могут быть метрики, оповещения и т. д. Перед проведением эксперимента эти индикаторы стабильного состояния должны находиться в стабильном состоянии; если во время проведения эксперимента доступность или стабильность услуги затронуты, индикаторы стабильности изменятся, например, резкие колебания кривой показателей, срабатывание сигнал тревоги и т. д.; когда эксперимент закончится, индикатор стабильности вернется в предыдущее стабильное состояние. Если предположение об устойчивом состоянии изменяется при проведении эксперимента, это сильная зависимость.
Проведение экспериментов в производственной среде: рекомендуется проводить эксперименты в производственной среде в условиях контроля рисков, так как поведение системы будет меняться в зависимости от среды и моделей трафика, а пользователи системы не будут взаимодействовать с вашей системой, как вы могли бы ожидать. Конечно, проведение экспериментов по хаос-инжинирингу в производственной среде, вероятно, будет вредным. Чтобы избежать большего влияния на пользовательский опыт, необходимо хорошо контролировать радиус взрыва эксперимента, например, отсеивать небольшой объем экспериментального трафика. , что требует оснащения платформы хаоса экспериментами Возможность фильтрации и планирования трафика.
Разнообразные события реального мира: То есть возможность имитации различных неисправностей. Поскольку это эксперимент на основе сцены, спрос на диверсификацию не такой сильный, как у FIT.
Минимизируйте «радиус взрыва».: Если вы решите провести эксперимент в онлайн-среде, вам необходимо иметь возможность фильтровать экспериментальный трафик, то есть отфильтровывать минимальный трафик, необходимый для эксперимента, и строго контролировать масштаб влияния «взрыва». .
Непрерывная автоматизация запущенных экспериментов: Благодаря инженерным возможностям процессы экспериментальной фильтрации целевых объектов, скрининга экспериментального потока, выполнения экспериментов, обнаружения установившегося состояния, создания экспериментальных отчетов и сбора отзывов о результатах экспериментов последовательно соединяются в автоматизированный поток выполнения, чтобы уменьшить зависимость от человека. Кроме того, эксперименты по хаос-инжинирингу никогда не бывают одноразовыми, и следует использовать нормализованные текущие эксперименты, чтобы постоянно гарантировать, что высокая доступность и эластичные механизмы сервисов соответствуют ожиданиям.

Продвинутые принципы инженерии хаоса

Стандарты обслуживания и технические характеристики

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

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

Например, как определить устойчивое состояние службы?

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

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

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

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

Обзор Chaos Engineering от ByteDance

Система хаос-инжиниринга ByteDance в основном включает платформу активного эксперимента на основе сценариев, платформу FIT и платформу противостояния красно-синих.

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

Общая схема архитектуры ByteDance Chaos Engineering

План строительства активного эксперимента ByteDance на основе сценариев

Блок-схема активного экспериментирования на основе сценариев

1. Экспериментальная цель

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

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

2. Субъекты

Расставьте приоритеты в реализации основных сервисов ByteDance, установите образцовый эталон, а затем расширяйтесь до более широких масштабов.

3. Индекс стабильности и автоматическое обнаружение колебаний

Стабильный показатель:

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

Схема обнаружения колебаний индикатора:

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

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

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

Автоматическое обнаружение колебаний:

Сначала мы обратились к схеме детектирования онлайн-сигналов тревоги: при выполнении активных учений мы сначала обучили модель детектирования показателей стабильности в реальном времени посредством машинного обучения, а затем использовали модель для детектирования изменений кривой индикатора в реальном времени. Однако из-за короткого времени активного эксперимента (всего 60–120 секунд для одного экспериментального узла), редких точек данных метрик (за экспериментальное время одного узла можно собрать только 2–4 точки данных) и низкого экспериментального трафика ( контроль радиуса взрыва 5~10 QPS), поэтому эффект обнаружения, основанный на машинном обучении, не идеален.

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

После непрерывной настройки эффект обнаружения индикатора в этом сценарии был наконец оптимизирован до ожидаемого уровня.

Оптимизация:

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

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

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

4. Минимизируйте контроль радиуса взрыва

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

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

Было подтверждено, что точность определения метрик стабильности может быть гарантирована, когда экспериментальный трафик составляет 5~10 запросов в секунду. Поэтому при выполнении эксперимента сначала случайным образом выберите экземпляр из сервисного канареечного кластера в качестве экспериментальной цели, рассчитайте отклонение трафика экземпляра от ожидаемого трафика, чтобы восстановить значение веса, а затем отрегулируйте трафик экземпляра, изменив вес кластера. .

5. Метод проверки

Платформа управления микросервисами ByteDance создает карту топологии вызовов между сервисами путем агрегирования журналов трассировки сервисов.Через OpenAPI вы можете запросить список всех нижестоящих зависимых сервисов первого уровня от сервиса.

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

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

6. Отчет об эксперименте

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

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

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

7. Автоматическая калибровка экспериментальных результатов

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

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

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

8. Полная экспериментальная процедура

Блок-схема активного эксперимента на основе сценария

Ценность активного экспериментирования на основе сценариев

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

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

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

Недавняя работа активного эксперимента на основе сценариев

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

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

Будущее планирование активных экспериментов на основе сценариев

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

Далее мы расширим инициативный эксперимент со сценами на более широкий спектр услуг и больше бизнес-сценариев, чтобы активные эксперименты на уровне сыграли большую роль.

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

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

Проект с открытым исходным кодом Netflix Chaos Engineering — Chaos Monkey:GitHub.com/Netflix/Проверить…
ПРИНЦИПЫ РАЗРАБОТКИ ХАОСА:принципы хаоса.org/\?wolf=en co…
Chaos Engineering: путь к стабильности системы в Netflix:О, Reilly.com/library/VIE…
«Инженерия хаоса»:woohoo.info Q.capable/article/M3E…
Проект с открытым исходным кодом Alibaba Chaos Engineering — ChaosBlade:GitHub.com/ultrasonic-spicy-…
Проект с открытым исходным кодом PingCAP Chaos Engineering — Chaos Mesh:Обычный github.com/ лист / чек ...
Краткое изложение практики ByteDance Chaos Engineering:Tickets.WeChat.QQ.com/Yes/kz\_Yes DDR B…

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

Для отправки резюме обращайтесьtech@bytedance.com"