Хабрахабр

[Перевод] Chaos Engineering: искусство умышленного разрушения

Прим. перев.: Рады поделиться переводом замечательного материала от старшего технологического евангелиста из AWS — Adrian Hornsby. В простых словах он объясняет важность экспериментов, призванных смягчить последствия сбоев в ИТ-системах. Вы, наверное, уже слышали про Chaos Monkey (или даже применяли подобные решения)? На сегодняшний день подходы к созданию подобных инструментов и их реализация в более широком контексте осуществляются в рамках деятельности, которую называют chaos engineering. Подробнее о ней читайте в этой статье.

— Tanner Walling «Но за всей этой красотой скрывается хаос и безумие».

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

Почему?

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

— Fighting Wildfires With Computers and Intuition «Кажется, будто они проникают в саму суть огня; этакие аналоги доктора Фила для пламени».

Прим. перев.: Phillip Calvin «Phil» McGraw — американский психолог, писатель, ведущий популярной телевизионной программы «Доктор Фил», в которой ведущий предлагает своим участникам решения их проблем.

Однажды в Сиэтле

В начале 2000-х Jesse Robbins, занимавший в Amazon должность с официальным названием Master of Disaster, создал и возглавил программу GameDay. Она была основана на его опыте пожарного. GameDay предназначалась для тестирования, обучения и подготовки различных систем Amazon, программного обеспечения и людей к воздействию потенциальных кризисных ситуаций.

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

«GameDay: Creating Resiliency Through Destruction» — Jesse Robbins

GameDay была призвана повысить устойчивость retail-сайта Amazon путем умышленного внедрения ошибок в критически важные системы.

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

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

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

Восстание обезьян

Вы, вероятно, слышали о Netflix — онлайн-поставщике видеоконтента. Netflix начал переезжать из собственного ЦОД в AWS Cloud в августе 2008-го. Этот шаг был вызван серьезным повреждением базы данных, из-за которого поставка DVD задержалась на трое суток (да, Netflix начинал с пересылки фильмов по обычной почте). Миграция в облако была связана с необходимостью выдерживать гораздо более высокие стриминговые нагрузки, а также желанием отказаться от монолитной архитектуры и перейти к микросервисам, которые легко масштабировать в зависимости от числа пользователей и размера команды инженеров. Пользовательская часть стримингового сервиса переехала на AWS первой, в период между 2010 и 2011 годами, за ним последовали корпоративные ИТ и все остальные структуры. Собственный ЦОД Netflix закрылся в 2016 году. Компания измеряет доступность как отношение числа успешных попыток запустить фильм к общему числу, а не как простое сравнение uptime и downtime, и старается достичь показателя в 0,9999 в каждом регионе на ежеквартальной основе (часто ей это удается). Глобальная архитектура Netflix охватывает три региона AWS. Таким образом, в случае возникновения проблем в одном из регионов компания имеет возможность перенаправлять пользователей на другие.

Повторю одну из моих любимых цитат:

— Werner Vogels «Сбои — это неизбежность; в конечном итоге любая система со временем рухнет».

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

Используя принципы избыточности (redundancy) и постепенного снижения функциональности (graceful degradation), Netflix сумел пережить сбои, не затронув конечных пользователей.

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

перев.: Кстати, для Kubernetes есть аналог под названием kube-monkey, развитие которого, похоже, прекратилось в марте этого года. Прим.

Он должен продолжать работать, если доступны всего две из них. У Netflix есть еще одно правило, предусматривающее распределение каждого сервиса по трем зонам доступности. В более глобальном масштабе Chaos Kong способен отключить целый регион AWS, чтобы подтвердить, что все пользователи Netflix могут обслуживаться из любого из трех регионов. Чтобы убедиться в выполнении этого правила, Chaos Gorilla отключает зоны доступности. И они проводят эти масштабные тесты каждые несколько недель в production, чтобы убедиться, что ничто не ускользнуло от внимания.

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

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

На сегодняшний день принципы хаос-инжиниринга формализованы; им дано следующее определение:

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

Однако в своем выступлении на AWS re:Invent-2018, посвященном хаос-инжинирингу, Adrian Cockcroft, бывший создатель облачной архитектуры Netflix, который помог компании перейти целиком на облачную инфраструктуру, представил альтернативное определение хаос-инжиниринга. На мой взгляд, оно более точное и устоявшееся:

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

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

Необходимые условия для создания хаоса

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


Некоторые обязательные элементы перед внедрением хаоса в систему (список не исчерпывающий)

Этапы хаос-инжиниринга

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

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


Этапы хаос-инжиниринга

1. Стабильное состояние

Одним из наиболее важных элементов хаос-инжиниринга является понимание поведения системы в нормальных условиях.

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

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

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

Компания использует количество заказов как одну из метрик стабильного состояния, и по веской причине. В качестве примера стабильных состояний приведем опыт Amazon. С увеличением времени загрузки на 100 мс количество заказов (а значит и продажи) снижалось на 1%. В 2007 году Грег Линден (Greg Linden), ранее работавший в Amazon, рассказал о том, как в рамках эксперимента с применением метода A/B-тестирования попробовал замедлять время загрузки страниц сайта с шагом в 100 мс и обнаружил, что даже незначительные задержки приводят к серьезному падению выручки. Именно поэтому число заказов является отличным кандидатом в метрики стабильного состояния.

Они заметили закономерность в поведении показателя SPS (starts-per-second) и его значительные колебания при возникновении сбоев в системе. Netflix же использует метрику на стороне сервера, связанную с началом воспроизведения, — число нажатий на кнопку «play». Метрика получила название «Пульс Netflix'а» (Pulse of Netflix).

Число заказов в случае Amazon и Пульс Netflix'а — отличные барометры стабильного состояния, поскольку они совмещают пользовательский опыт и операционные метрики в единый, измеримый и высоко предсказуемый показатель.

Измеряйте, измеряйте и еще раз измеряйте

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

— Ian Malpass «Максимально упростите инженерам доступ к данным, которые они могут посчитать или перевести в графическую форму».

2. Гипотеза

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

  • Что, если остановится механизм рекомендаций?
  • Что, если упадет балансировщик нагрузки?
  • Что, если отвалится кэширование?
  • Что, если задержка возрастет на 300 мс?
  • Что, если упадет master-база?

Конечно, следует выбрать только одну гипотезу и не нужно усложнять ее без необходимости. Начинайте с малого. Я люблю начинать с гипотезы персонала. Слышали ли вы о факторе автобуса (bus factor)? Фактор автобуса — это мера риска, связанная с тем, что знания неравномерно распределены между членами команды. Он позволяет подсчитать минимальное количество ее участников, после внезапной потери которых проект остановится из-за недостатка знаний или опыта.

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

Сделайте проблему общей для всех!

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

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

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

Что, если сервис «Shop by Category» перестанет загружаться на главной странице? Возьмем, к примеру, упомянутый retail-сайт Amazon.

Стоит ли грузить страницу, оставляя пустое пространство как на скрине внизу? Стоит ли возвращать ошибку 404?

Стоит ли пожертвовать частью функциональности и, например, позволить странице развернуться и скрыть ошибку?

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

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

3. Разработайте и проведите эксперимент

  • Выберите одну гипотезу;
  • Определите рамки эксперимента;
  • Определите связанные показатели, измерение которых будет проводиться;
  • Известите организацию.

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

Это путешествие. Для меня хаос-инжиниринг — это не только разрушение различных элементов production-систем. Разрушение путем хорошо спланированных экспериментов ради укрепления уверенности в способности вашего приложения перенести турбулентные условия. Путешествие в мир познания, неразрывно связанный с таким занятием, как разрушение систем в контролируемой среде — любой среде, будь то локальное dev-окружение, beta, staging или prod. «Укрепление уверенности» — ключевой момент в данном случае, поскольку он является предшественником культурных изменений, необходимых для успешного внедрения хаос-инжиниринга и практики повышения надежности в вашей компании.

Просто попытайтесь сделать docker stop database в локальном окружении и посмотрите, сможете ли вы без последствий справиться с этой проблемой. Честно говоря, большинство команд очень многое узнают, «ломая» вещи даже в не-production-среде. Высока вероятность, что нет.

Остановка базы данных — пример

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

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

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

  • Какое количество клиентов затронет эксперимент?
  • Какая функциональность пострадает?
  • Какие места будут затронуты?

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


Пример основанного на DNS канареечного выката для хаос-экспериментов

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

е. Любопытно, что Adrian Cockcroft сказал мне, что одной из причин, по которой Netflix начал использовать базы NoSQL, являлось отсутствие в них схемы для изменений или откатов, поэтому там намного проще постепенно обновлять или исправлять отдельные записи с данными (т. они более дружественны к хаос-инжинирингу).

4. Наблюдайте и учитесь

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

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

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

Проводите подробный анализ (postmortem) по итогам каждого эксперимента!

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

Один из наиважнейших принципов при написании хорошего COE — быть беспристрастным и избегать упоминания конкретных людей. Ключом к успеху в этом процессе являются открытость и прозрачность в отношении того, что пошло не так. Amazon использует коллекцию «принципов лидерства» (Leadership Principles) для поощрения такого поведения — например, самокритичность, аналитический подход, приверженность высочайшим стандартам и ответственность являются ключевыми компонентами процесса COE и операционного совершенства в целом. Это часто непросто в среде, которая не поощряет подобное поведение и не допускает возможности провала.

В отчете COE имеется пять основных разделов:

  1. Что произошло (хронологический порядок)?
  2. Каким было воздействие на клиентов?
  3. Почему произошла ошибка? (Пять «почему?»)
  4. Что мы узнали?
  5. Как предотвратить это в будущем?

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

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

5. Исправляйте и улучшайте!

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

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

Преимущества хаос-инжиниринга

Преимуществ много. Я выделю два, на мой взгляд, наиболее важных:

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

Пожалуй, самая важная из них — это естественная эволюция к «безвинной» (non-blaming) культуре, когда вопрос «Зачем ты это сделал?» превращается в «Как мы можем избежать этого в будущем?». Во-вторых, эффективно проведенные хаос-эксперименты всегда вызывают более обширные перемены (преимущественно культурные), чем предполагалось. И это прекрасно! В результате команда становится счастливее, эффективнее, заинтересованнее и успешнее.

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

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

P.S. от переводчика

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

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть