Поиск по сайту:

Как «хаос-инжиниринг» помогает избежать незапланированных простоев


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

Идея добавления хаоса в систему обычно приписывается Netflix. В 2011 году компания опубликовала Chaos Monkey, инструмент, который она создала для отключения частей своей производственной инфраструктуры. Создавая случайные сбои в отслеживаемых средах, Netflix обнаружил, что может обнаруживать скрытые проблемы, которые оставались незамеченными во время регулярных тестов.

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

Повышение устойчивости

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

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

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

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

Добавление хаоса в ваши системы

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

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

Если вы используете Kubernetes, kube-monkey использует оригинальные принципы Netflix и упаковывает их для использования в вашем кластере. Он работает по принципу согласия, поэтому ресурсы Kubernetes с меткой kube-monkey/enabled будут иметь право на произвольное прекращение.

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

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

Для расширенного контроля Mangle от VMWare — это «инструментарий хаоса», предназначенный для нескольких различных механизмов развертывания. Он работает с Kubernetes, Docker, VMware vCenter и общими подключениями SSH. Mangle позволяет определять пользовательские ошибки для компонентов приложений и инфраструктуры. Сбои приложений должны влиять на одну службу. Сбои в инфраструктуре нацелены на общие компоненты, которые могут вывести из строя несколько служб.

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

Разработка собственных экспериментов с хаосом

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

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

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

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

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

Вот краткое изложение процесса эксперимента с хаосом:

  1. Разработайте гипотезу : Система устойчива к повышенной задержке в сети.
  2. Разработайте целенаправленный эксперимент: «Мы искусственно увеличим задержку до 500 мс для 70 % запросов». Убедитесь, что у вас есть четкая стратегия отката и восстановления.
  3. Проведите эксперимент. Посмотрите, как это повлияет на ваше приложение. Как можно скорее отмените вредные изменения в производственной среде.
  4. Проанализируйте результаты. Если вы решите, что ваша система недостаточно устойчива, внесите улучшения и повторите процесс.

Нетехническая сторона Chaos Engineering

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

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

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

Краткое содержание

Термин «инженерия хаоса» относится к практике целенаправленного разрушения вещей в процессе производства для выявления ранее скрытых проблем. Хотя поначалу этот подход может показаться сложным, специальные инструменты, такие как Chaos Monkey, могут помочь вам начать работу с минимальным риском.

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

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

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

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