[Тестирование IT-систем, Системное администрирование, DevOps] Хаос на практике: зачем ломать production?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет! Меня зовут Олег Сидоренков, и я отвечаю за IT-инфраструктуру в компании ДомКлик.Ломать — не строить! Так обычно говорят люди, пытаясь показать деструктивный процесс простым, не требующим усилий. Сегодня я хочу вам рассказать о пользе Chaos Engineering (хаос-инженерия), зачем это нужно и как подойти к своему первому в жизни эксперименту.Хаос-инженерия — это дисциплина проведения экспериментов в распределенных информационных системах с целью укрепления уверенности в способности системы противостоять турбулентным условиям в эксплуатационной среде.Развитие этой дисциплины началось в 2010 году, когда компания Netflix выпустила продукт под названием Chaos Monkey, который случайным образом завершает работу виртуальных машин и контейнеров, работающих внутри производственной среды. Это было связано с переходом Netflix на облачную инфраструктуру от Amazon, и команда хотела убедиться, что при потере инстанса AWS сервис не пострадает.Представим, что у вас большая, распределенная инфраструктура. С чего начинать эксперимент? На какие этапы разбить цикл работ? 
1. План работДля начала постарайтесь разбить свою инфраструктуру на слои.
Начинайте составлять план эксперимента с самых очевидных для вас мест, например, с тех компонентов инфраструктуры, в которых были сбои в эксплуатации. Затем переходите к элементам, которые были введены в production не так давно и уверенности в их безотказности нет. Также важно понимать, что нет необходимости проводить эксперимент, в результате которого вы заведомо уверены, например:
У вас есть сервис, который работает с БД. Архитектура изначально правильная, кластер из двух серверов: master и hot standby. Вы знаете, что с недоступной базой сервис работать не будет. Вы отключаете оба хоста и ставите галочку в чек-листе, что сервис действительно не работает.
Так делать не надо. Здесь вы ничего нового для себя не узнаете, разве что проверите свой кластер мониторинга. Цель планирования — узнать новые сценарии, при которых сервис в процессе эксплуатации может деградировать. Сам план может быть в виде таблице, рассмотрим на примере с БД:СервисКластер БД PostgresСценарии отказаВыход из строя первичного инстанса.Имитация сбоя1. Отключение сервера Master.2. Отключение сетевого интерфейса.3. Заполнение файловой системы на 100%.Ожидаемый результат1. Срабатывание системы мониторинга.2. Сработал фейловер. Hot Standby успешно запромоутился до Primary не более чем за 1 минуту.3. Коннекты приложения подцепились к новому Master-инстансу БД не более чем за 5 минут.Фактический результатКомандаOPS + DEVКак можно заметить, всё начинается с простых ситуаций, которые могут часто встречаться на практике. Фактический результат заполняется по итогу эксперимента. Если всё прошло по плану, то можно переходить к другому сервису или гипотезам, а если нет, то составляем задачи на доработку и повторяем эксперимент.2. ЭкспериментПосле составления плана определите, кто может вам понадобиться из смежных команд для оценки результата и помощи в восстановлении работоспособности сервиса. Будет удобней создать отдельный чат и фиксировать в нем все этапы эксперимента. Подробные описания отклонений могут помочь при устранении недочетов в отказоустойчивости сервиса. А на каком стенде проводить? Всё зависит не только от идентичности эксплуатационной и другой среды, но и от количества общего трафика, загруженности сервисов, которые так или иначе могут повлиять на ход эксперимента. Поэтому вся его полнота раскроется только в эксплуатационной среде, но это не призыв бежать и срочно что-то ломать. Сначала потренируйтесь на самом близком по уровню схожести стенде. В случае работы с production-средой никогда не забывайте про «план отката». Он обязательно должен быть, чтобы вы могли быстро восстановить работоспособность сервисов. То есть сам эксперимент должен быть полностью подконтролен, вы должны быть уверены, что у вас под рукой есть все средства для восстановления: процедуры и бэкап наготове, сетевой доступ на месте, как и старый-добрый ssh.С чего можно начать?1) Сетевые задержкиС развитием микросервисной архитектуры общая архитектура становится всё сложней. Конечно, всё делается из благих побуждений: удобная разработка, независимые друг от друга элементы сервиса. Но в какой-то момент может появиться такой микросервис, отказ которого приводит к цепной реакции и вся архитектура начинает валиться, как карточный домик. И тут хочется вспомнить крылатую фразу «сеть не идеальна». Причины могут быть разные, но суть остается одной: приложение должно уметь обрабатывать отказы смежных сервисов, чтобы это не приводило к полной деградации функциональности.Сценарии отказаПлохая доступность смежного сервиса/Полная недоступностьИмитация сбоя1. Использовать утилиту tc для шейпинга трафика (задержка 200 мс).2. Имитируем полную сетевую недоступность смежного сервиса.Ожидаемый результат1. Приложение в случае таймаута использует retry-запрос.2. Приложение обрабатывает ошибку смежного сервиса и это не приводит к падению основной функциональности.2) Недоступность хранилища данныхФайловое хранилище — практически незаменимый спутник большинства сервисов. Приведу в пример тестирование нашего сервиса FS. У нас есть два кластера хранилища: основной (S3) и резервный (NFS). Соответственно, архитектурная задумка заключается в возможности обращения к резервному хранилищу на чтение/запись, если с основным какие-то проблемы.Сценарии отказаЧастичная недоступность основного файлового хранилища Имитация сбояИспользовать утилиту tc для отбрасывания трафика (потеря 15% пакетов).Ожидаемый результатСервис продолжает работать. Ошибки обращения к основному хранилищу обрабатываются, задействуется резерв..Теперь смотрим на графики:
Фон ошибок обращения к основному хранилищу после запуска эксперимента.
Количество ошибок в приложении.Здесь мы убедились, что резерв вполне справляется со своей обязанностью.3) Нехватка ресурсовДостаточно частая ситуация, которая возникает по разным причинам. Нехватка CPU, памяти или задержка времени ответа от диска — каждый админ видел подобное оповещение на своей борде мониторинга. Обычно это неминуемо приводит к деградации сервиса и увеличению ошибок. Для обладателей Kubernetes и микросервисной архитектуры есть множество инструментов для проведения хаос-экспериментов в кластере: Litmus Chaos и Chaos Mesh подойдут под разные сценарии отказов, а если захотите стать сами сеятелем хаоса, то можно посмотреть в сторону KubeInvaders и Kube DOOM. Для подконтрольного эксперимента также подойдет проверенный инструмент stress-ng.Сценарии отказаНехватка процессорного времени для сервисаИмитация сбояstress --cpu 32 --vm 7 --vm-bytes 8G -t 300Ожидаемый результатИз-за нехватки CPU Kubernetes должен эвакуировать pod на другую ноду. Ожидается простой до 5 минут.В процессе подобных экспериментов наблюдаем за состоянием сервиса:
Health check приложения.Приложение ожидаемо отвечает ошибкой, но после эвакуации оно снова доступно.4) Нагрузочное тестирование приложенияВ идеальном мире все приложения перед попаданием в production должны проходить испытания на стенде нагрузочного тестирования (НТ). Это делается для определения рамок нормальной работы приложения. Есть ли изъяны в коде, или всё решается горизонтальным масштабированием, какой максимальный RPS способен выдавать сервис, когда начинаются ошибки, и так далее. Для тестирования, как правило, используют готовые решения: Apache JMeter, Яндекс.Танк, Gatling, The Grinder и другие. Перейдем к примеру:Сценарии отказаСоздать ступенчатый Logon-шторм, используя скрипты JMeter. Помимо обычной авторизации генерируем внутренний трафик «хождения» пользователя по внутренним сервисам, чтобы уйти от синтетики и приблизить результат к боевому сценарию.Имитация сбояЗапуск нескольких сценариев JMeterОжидаемый результатПриложение держит двойную нагрузку. Если сервис начинает деградировать, видим оповещения в панели мониторинга
RPS заметно вырос, но с тем и выросло время ответа.Получилось создать нагрузку на сервис до 6500 RPS, это в три. раза больше пиковой дневной нагрузки. Смотрим, как чувствует себя микросервис:
Появился троттлинг.В ходе эксперимента заметили, что появился троттлинг, при этом трафик по подам распределялся неравномерно. Это отклонение мы зафиксировали для дальнейшего изучения. Далее смотрим на график ошибок приложения:
График RPS по 5xx-кодам ответа.Фактический результат соответствует ожиданиям, но при этом найден интересный баг с трафиком на поды внутри кластера Kubernetes, и он отправляется прямиком в бэклог на исправление. Следующий эксперимент можно будет проводить в этом направлении. 3. РезультатыСуществует два варианта исхода подобных испытаний:
- Ожидаемый результат соответствует фактическому. Вы убедились, что сервис устойчив к данному виду неисправностей.
- Сервис не справился. Вы зафиксировали все ключевые нюансы его падения и смогли быстро его восстановить.
Оба результата полезны. В первом случае вы стали более уверены в отказоустойчивости системы, во втором — извлекли уроки, создали задачи на исправление и наработали опыт быстрого восстановления в случае нештатной ситуации.ЗаключениеУ этой дисциплины есть определенные достоинства. Она позволяет упреждающе устранять потенциальные проблемы до появления негативного воздействия и повышает уверенность в надежности системы. На первый взгляд может показаться, что Chaos Engineering нужна только прикладным командам и команде инфраструктуры, но это не так. Рассмотрим пользу для каждой из сторон:
- Пользователь: повышенная доступность и надежность обслуживания означает отсутствие простоев, нарушающих их эксплуатационный опыт.
- Бизнес: Chaos Engineering может помочь предотвратить чрезвычайно большие потери доходов и затраты на обслуживание, создать более счастливых и вовлеченных инженеров.
- IT-инженеры: выводы, полученные в результате экспериментов, могут помочь снизить количество инцидентов, найти узкие места (bottleneck), дать лучшее понимание сценариев отказа систем, улучшить дизайн архитектуры, модернизировать мониторинг для более быстрого определения проблем.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, IT-инфраструктура, Карьера в IT-индустрии, DevOps] Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] Fortinet Single Sign-On. Описание технологии
- [Виртуализация, DevOps, Облачные сервисы, Kubernetes] Вебинар «Ошибки PRO-уровня при внедрении Kubernetes»
- [Настройка Linux, Информационная безопасность, Системное администрирование] AD + Freeradius + Google Autheticator. Установка с нуля для Cisco Anyconnect и не только
- [Спам и антиспам, Системное администрирование, IT-компании] Kак исправить «DMARC Record not found»
- [Big Data, Промышленное программирование, Разработка для интернета вещей] Вебинар «Удаленный мониторинг станков. Рассказываем, показываем, подключаем»
- [Системное администрирование, Программирование, IT-инфраструктура, DevOps] CI/CD — обещания и реальность (перевод)
- [Информационная безопасность, Системное администрирование, Сетевые технологии] Как устроена фильтрация спама в Zimbra
- [Управление проектами, Управление продуктом] Как наладить бизнес-мониторинг продукта
- [Облачные вычисления, DevOps, Kubernetes] Как жили до Kubernetes: сравниваем самый популярный оркестратор с другими решениями
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_sistemnoe_administrirovanie (Системное администрирование), #_devops, #_chaos_engineering, #_otkazoustojchivost (отказоустойчивость), #_monitoring (мониторинг), #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:36
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Всем привет! Меня зовут Олег Сидоренков, и я отвечаю за IT-инфраструктуру в компании ДомКлик.Ломать — не строить! Так обычно говорят люди, пытаясь показать деструктивный процесс простым, не требующим усилий. Сегодня я хочу вам рассказать о пользе Chaos Engineering (хаос-инженерия), зачем это нужно и как подойти к своему первому в жизни эксперименту.Хаос-инженерия — это дисциплина проведения экспериментов в распределенных информационных системах с целью укрепления уверенности в способности системы противостоять турбулентным условиям в эксплуатационной среде.Развитие этой дисциплины началось в 2010 году, когда компания Netflix выпустила продукт под названием Chaos Monkey, который случайным образом завершает работу виртуальных машин и контейнеров, работающих внутри производственной среды. Это было связано с переходом Netflix на облачную инфраструктуру от Amazon, и команда хотела убедиться, что при потере инстанса AWS сервис не пострадает.Представим, что у вас большая, распределенная инфраструктура. С чего начинать эксперимент? На какие этапы разбить цикл работ?  1. План работДля начала постарайтесь разбить свою инфраструктуру на слои.  Начинайте составлять план эксперимента с самых очевидных для вас мест, например, с тех компонентов инфраструктуры, в которых были сбои в эксплуатации. Затем переходите к элементам, которые были введены в production не так давно и уверенности в их безотказности нет. Также важно понимать, что нет необходимости проводить эксперимент, в результате которого вы заведомо уверены, например: У вас есть сервис, который работает с БД. Архитектура изначально правильная, кластер из двух серверов: master и hot standby. Вы знаете, что с недоступной базой сервис работать не будет. Вы отключаете оба хоста и ставите галочку в чек-листе, что сервис действительно не работает.
 Фон ошибок обращения к основному хранилищу после запуска эксперимента.  Количество ошибок в приложении.Здесь мы убедились, что резерв вполне справляется со своей обязанностью.3) Нехватка ресурсовДостаточно частая ситуация, которая возникает по разным причинам. Нехватка CPU, памяти или задержка времени ответа от диска — каждый админ видел подобное оповещение на своей борде мониторинга. Обычно это неминуемо приводит к деградации сервиса и увеличению ошибок. Для обладателей Kubernetes и микросервисной архитектуры есть множество инструментов для проведения хаос-экспериментов в кластере: Litmus Chaos и Chaos Mesh подойдут под разные сценарии отказов, а если захотите стать сами сеятелем хаоса, то можно посмотреть в сторону KubeInvaders и Kube DOOM. Для подконтрольного эксперимента также подойдет проверенный инструмент stress-ng.Сценарии отказаНехватка процессорного времени для сервисаИмитация сбояstress --cpu 32 --vm 7 --vm-bytes 8G -t 300Ожидаемый результатИз-за нехватки CPU Kubernetes должен эвакуировать pod на другую ноду. Ожидается простой до 5 минут.В процессе подобных экспериментов наблюдаем за состоянием сервиса:  Health check приложения.Приложение ожидаемо отвечает ошибкой, но после эвакуации оно снова доступно.4) Нагрузочное тестирование приложенияВ идеальном мире все приложения перед попаданием в production должны проходить испытания на стенде нагрузочного тестирования (НТ). Это делается для определения рамок нормальной работы приложения. Есть ли изъяны в коде, или всё решается горизонтальным масштабированием, какой максимальный RPS способен выдавать сервис, когда начинаются ошибки, и так далее. Для тестирования, как правило, используют готовые решения: Apache JMeter, Яндекс.Танк, Gatling, The Grinder и другие. Перейдем к примеру:Сценарии отказаСоздать ступенчатый Logon-шторм, используя скрипты JMeter. Помимо обычной авторизации генерируем внутренний трафик «хождения» пользователя по внутренним сервисам, чтобы уйти от синтетики и приблизить результат к боевому сценарию.Имитация сбояЗапуск нескольких сценариев JMeterОжидаемый результатПриложение держит двойную нагрузку. Если сервис начинает деградировать, видим оповещения в панели мониторинга  RPS заметно вырос, но с тем и выросло время ответа.Получилось создать нагрузку на сервис до 6500 RPS, это в три. раза больше пиковой дневной нагрузки. Смотрим, как чувствует себя микросервис:  Появился троттлинг.В ходе эксперимента заметили, что появился троттлинг, при этом трафик по подам распределялся неравномерно. Это отклонение мы зафиксировали для дальнейшего изучения. Далее смотрим на график ошибок приложения:  График RPS по 5xx-кодам ответа.Фактический результат соответствует ожиданиям, но при этом найден интересный баг с трафиком на поды внутри кластера Kubernetes, и он отправляется прямиком в бэклог на исправление. Следующий эксперимент можно будет проводить в этом направлении. 3. РезультатыСуществует два варианта исхода подобных испытаний:
=========== Источник: habr.com =========== Похожие новости:
Блог компании ДомКлик ), #_testirovanie_itsistem ( Тестирование IT-систем ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:36
Часовой пояс: UTC + 5