Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM

Привет Хабр! Поговорим про хаос инженерию, зачем она нужна SRE, какой у нас этот хаос, ну и немного поиграем с Chaoskube.

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

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

• Принципы хаос-инжиниринга

• Архитектура системы хаоса

• Хаос эксперименты

Принципы хаос-инжиниринга

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

• Варьируйте реальные события. Используйте смысловые и фактически произошедшие сбои в качестве основы для новых хаос-инъекций.

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

• Автоматизируйте эксперименты для непрерывного выполнения. Упражнения с хаосом не должны стать рутиной и должны выполняться в новых версиях или при изменении инфраструктуры.

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

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

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

• Применяйте наблюдаемость для объяснения влияния на конечного пользователя системы. SRE не только мониторят инфраструктуру, но и используют четыре золотых сигнала, мониторинг производительности приложения (APM) и мониторинг реального пользователя (RUM), чтобы узнать, как эксперимент влияет на конечного пользователя.

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

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

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

Далее давайте выясним, что такое эксперименты с хаосом.

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

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

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

SRE идеально подходят для написания экспериментов благодаря своему глубокому знанию наблюдаемости системы. Создаем две отдельные группы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте проведем эсперимент на практике.

Для этого нам нужен кластер Кубера, Helm3 и Chaoscube.

Для начала добавим чарт репу

helm repo add chaoskube https://linki.github.io/chaoskube && helm repo list

Установим чарт

helm install chaoskube chaoskube/chaoskube \
  --version=0.1.0 \
  --namespace chaoskube \
  --create-namespace \
  --values chaoskube-values.yaml

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

less chaoskube-values.yaml | tee

kubectl get -n chaoskube deployments

Параметр interval предписывает Chaoskube убивать под каждые 20 секунд. Целевыми подами являются любые с меткой environment=test, а пространство имен kube-system должно быть явно исключено (!) из списка пространств имен, чтобы искать поды для уничтожения.

Можно периодически проверять журнал Chaoskube, чтобы увидеть его действия по удалению пода. Сначала найдем под:

POD=$(kubectl -n chaoskube get pods -l='app.kubernetes.io/instance=chaoskube' --output=jsonpath='{.items[0].metadata.name}')

И проверим его логи

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

Создадим nginx.yaml с содержимым

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
	deployment.kubernetes.io/revision: "1"
  labels:
	app: nginx
	app-purpose: chaos
  name: nginx
spec:
  replicas: 8
  selector:
	matchLabels:
  	app: nginx
  template:
	metadata:
  	annotations:
    	chaos.alpha.kubernetes.io/enabled: "true"
  	labels:
    	environment: test
    	app: nginx
    	app-purpose: chaos
	spec:
  	containers:
  	- image: nginx
    	name: nginx

Создадим

kubectl apply -f nginx.yaml

Создадим еще одно пространство имен

kubectl create namespace more-apps

Напишем манифест подов, которые в нем запустим

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
	deployment.kubernetes.io/revision: "1"
  labels:
	app: ghost
	app-purpose: chaos
  name: ghost
spec:
  replicas: 3
  selector:
	matchLabels:
  	app: ghost
  template:
	metadata:
  	annotations:
    	chaos.alpha.kubernetes.io/enabled: "true"
  	labels:
    	app: ghost
    	environment: test
    	app-purpose: chaos
	spec:
  	containers:
  	- image: ghost:3.11.0-alpine
    	name: ghost

Деплойменты и соответственно поды имеют метки, чтобы хаос с ними работал

Шаблон Deployment and Pod имеет метку app-purpose: chaos, что делает Pod подходящей целью для Chaoskube. Метка предоставляется как значение конфигурации во время установки чарта Helm.

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

watch kubectl get deployments,pods --all-namespaces -l app-purpose=chaos


Хаос работает.

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

• Зарегистрироваться на бесплатный вебинар