Хабрахабр

Continuous Monitoring – автоматизация проверок качества ПО в CI/CD Pipeline

Сейчас на хайпе тема DevOps. Конвейер непрерывной интеграции и доставки CI/CD внедряют все, кому не лень. Но большинство не всегда уделяют должное внимание обеспечению надежности работы информационных систем на различных этапах CI/CD Pipeline. В данной статье я хотел бы поговорить о своем опыте автоматизации проверок качества ПО и реализации возможных сценариев по его «самовосстановлению».

Источник
Я работаю инженером в отделе управления ИТ-услугами в компании «ЛАНИТ-Интеграция». Мое профильное направление — внедрение различных систем мониторинга производительности и доступности приложений. Я часто общаюсь с ИТ-заказчиками из разных сегментов рынка на предмет актуальных вопросов по мониторингу качества их ИТ-сервисов. Основная задача — минимизировать время цикла релиза и увеличить частоту их выпуска. Это, конечно, все хорошо: больше релизов – больше новых фич — больше довольных пользователей — больше прибыли. Но на деле не всегда все получается хорошо. При очень высоких темпах развертывания сразу всплывает вопрос о качестве наших релизов. Даже при полностью автоматизированном конвейере одна из самых больших проблем — перевод сервисов из тестирования в производство, не влияющий при этом на время безотказной работы и взаимодействие пользователей с приложением.

По итогам многочисленных бесед с заказчиками я могу сказать, что контроль качества релизов, проблема надежности приложения и возможность его «самовосстановления» (например, откат к стабильной версии) на различных этапах конвейера CI/CD – среди самых волнующих и актуальных тем.

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

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

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

Также помним, что у нас DevOps. Один из путей решения – это внедрять процессы проверки качества ПО на различных этапах CI/CD Pipeline, добавлять различные сценарии по восстановлению системы при возникновении аварий. Поэтому все наши проверки и сценарии должны быть автоматизированы. Бизнес ожидает максимально быстрого получения нового продукта.

Задача разбивается на две составляющие:

  • контроль качества сборок на этапе тестирования (автоматизировать процесс отлавливания некачественных сборок);
  • контроль качества ПО в прод среде (механизмы автоматического обнаружения проблем и возможные сценарии по их самовосстановлению).

Для того, чтобы реализовать поставленные задачи, требуется система мониторинга, способная обнаруживать проблемы и передавать их в системы автоматизации на различных этапах конвейера CI/CD. Также положительным моментом будет, если данная система предоставит полезные метрики для различных команд: разработки, тестирования, эксплуатации. И совсем замечательно, если и для бизнеса.

Для сбора метрик можно использовать совокупность различных систем (Prometheus, ELK Stack, Zabbix и тд), но, на мой взгляд, под данные задачи лучше всего подходят решения класса APM (Application Performance Monitoring), которые способны сильно упростить вам жизнь.

Сейчас, работая в интеграторе, я достаточно хорошо знаю рынок систем мониторинга. В рамках моей работы в службе сопровождения я начинал делать аналогичный проект, используя решение класса APM от компании Dynatrace. Можно отследить всю цепочку взаимодействия между различными информационными сервисами: от уровней фронтенд веб- и мобильных приложений, back-end серверов приложений, интеграционной шиной до конкретного вызова в БД. Мое субъективное мнение: Dynatrace лучше всего подходит для решения таких задач.
Решение Dynatrace предоставляет горизонтальное отображение каждой пользовательской операции с глубокой степенью детализации до уровня выполнения кода.

Источник. Автоматическое построение всех зависимостей между компонентами системы

Источник. Автоматическое определение и построение пути прохождения операции сервиса

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

Далее перейдем к более подробному рассмотрению, как решать поставленные задачи с помощью системы Dynatrace.

Первая задача – это найти проблемы как можно раньше на этапах конвейера доставки приложения. Только «хорошие» сборки кода должны достигать прод среды. Для этого в ваш pipeline на этапе тестирования должны быть включены дополнительные мониторы по проверки качества ваших сервисов.

Рассмотрим по шагам, как это реализовать и автоматизировать данный процесс:

Источник

На рисунке показан поток автоматизированных шагов проверки качества ПО:

  1. разворачивание системы мониторинга (установка агентов);
  2. определение событий оценки качества вашего ПО (метрики и пороговые значения) и передача их в систему мониторинга;
  3. генерация нагрузки и тестов производительности;
  4. сбор данных о производительности и доступности в системе мониторинга;
  5. передача данных о тестах, основанных на событиях оценки качества ПО, из системы мониторинга в систему CI/CD. Автоматический анализ сборок.

Шаг 1. Разворачивание системы мониторинга

При этом решение Dynatrace имеет приятную особенность – оно использует универсальный агент OneAgent, который устанавливается на OS инстанс (Windows, Linux, AIX), автоматически обнаруживает ваши сервисы и начинает собирать данные мониторинга по ним. Сначала необходимо установить агенты в вашу тестовую среду. Аналогичная ситуация будет для облачных и контейнерных платформ. Вам не требуется настраивать отдельно агент для каждого процесса. Dynatrace отлично вписывается в концепт «инфраструктура как код» (Infrastructure as code или IaC): есть уже готовые скрипты и инструкции под все популярные платформы. При этом процесс установки агентов вы также можете автоматизировать. Встраиваете агент в конфигурацию вашего сервиса, и при его развертывании вы сразу получаете новый сервис с уже работающим агентом.

Определение событий оценки качества вашего ПО Шаг 2.

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

Например, это могут быть время выполнения (с разделением на среднее, медиану, перцентили и др.), ошибки (логические, сервисные, инфраструктурные и др.) и различные инфраструктурные метрики (memory heap, garbage collector, thread count и др.). Далее необходимо определить, какие метрики вы хотите включить в проверку для каждого из уровней.

Что я под этим подразумеваю — разработчик/тестировщик может написать простой JSON файл, который определяет показатели проверки качества ПО. Для автоматизации и удобства использования командой DevOps появляется концепция «Мониторинг как код».

В качестве пары ключ/значение используются объекты из Dynatrace API (описание API можно посмотреть тут Dynatrace API). Давайте рассмотрим пример такого JSON-файла.

, { "timeseriesId": "service.ResponseTime ", "aggregation": "avg", "tags": "Backend", "severe": 4000000, "warning": 8000000 }, { "timeseriesId": "docker.Container.Cpu", "aggregation": "avg", "severe": 50, "warning": 70 } ]
}

Файл представляет собой массив определений временных рядов (timeseries):

  • timeseriesId – проверяемая метрика, например, Response Time, Error count, Memory used и т.д.;  
  • aggregation — уровень агрегации метрик, в нашем случае avg, но вы можете использовать любую необходимую для вас (avg, min, max, sum, count, percentile);
  • tags – тег объекта в системе мониторинга, или можно указать конкретный идентификатор объекта;
  • severe и warning – данные показатели регулируют пороговые значения наших метрик, если значение тестов превышает порог severe, то наша сборка помечается как не успешная.

На следующем рисунке представлен пример использования таких трешолдов.

Источник

Генерация нагрузки Шаг 3.

Вы можете использовать любой из удобных вам инструментов тестирования, например, Jmeter, Selenium, Neotys, Gatling и т.д. После того, как мы определи уровни качества нашего сервиса, необходимо сгенерировать тестовую нагрузку.

Рекомендуется добавлять дополнительные заголовки в HTTP-запросы теста. Система мониторинга Dynatrace позволяет захватывать различные метаданные из ваших тестов и распознавать, какой из тестов относится к какому циклу релиза и какому сервису.

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

Источник

Таким образом, система может различать различные тесты между собой. При запуске каждого нагрузочного теста вы отправляете дополнительную контекстную информацию в Dynatrace с помощью API события из сервера CI/CD.

Источник. Событие в системе мониторинга о запуске нагрузочного тестирования

 Сбор данных о производительности и передача данных в систему CI/CD Шаг 4-5.

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

Событие о необходимости проверки качества ПО формируемое на сервере CI/CD для отправки в систему мониторинга

В каждом событии о запуске проверки содержится информация о сервисе, номере сборке, времени тестирования. В нашем примере событие о проверки качества называется perfSigDynatraceReport (Performance_Signature) – это готовый плагин для интеграции с Jenkins, который разработали ребята из T-Systems Multimedia Solutions. Плагин собирает значения производительности во время сборки, оценивает их и сравнивает результат с предыдущими сборками и нефункциональными требованиями.

Событие в системе мониторинга о старте проверки качества сборки. Источник

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

Результат статистики по сборкам на сервере CI/CD. Источник

Также для удобства вы можете добавить в отчет показатели сравнения текущей сборки с предыдущей. Для каждой отдельной сборки мы видим статистику по каждой заданной нами метрике на протяжении выполнения всего теста. Мы также видим, если были нарушения в определенных пороговых значениях (warning и severe-трешолды). На основе совокупных показателей вся сборка помечается как стабильная, нестабильная или провальная.

Просмотр детализированной статистики по сборкам на сервере CI/CD. Источник

Детализированное сравнение двух сборок

При необходимости можно перейти в интерфейс Dynatrace и там более детально просмотреть статистику по каждой вашей сборке и сравнить их между собой.

Сравнение статистики по сборкам в Dynatrace. Источник
 
Выводы

В итоге мы получаем сервис «мониторинг как услуга», автоматизированный в конвейере непрерывной интеграции. Разработчику или тестировщику необходимо только определить список метрик в JSON-файле, а все остальное происходит автоматически. Мы получаем прозрачный контроль качества релизов: все уведомления о производительности, потреблении ресурсов или архитектурных регрессиях.

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

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

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

Автоисправление как код

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

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

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

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

Но я приведу несколько примеров на основе решения APM (в качестве примера опять будет Dynatrace), которое также поможет облегчить вашу жизнь. Вы можете использовать любую систему или совокупность систем: Prometheus, ELK Stack, Zabbix и т.д.

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

  • уровень пользователей (браузеры, мобильные приложения, IoT-устройства, поведение пользователей, конверсия и тд.);
  • уровень сервиса и операций (производительность, доступность, ошибки и тд.);
  • уровень инфраструктуры приложения (OS-метрики хоста, JMX, MQ, web-server и тд);
  • уровень платформ (виртуализация, облако, контейнер и т.д).

Уровни мониторинга в Dynatrace. Источник

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

Ниже представлен пример для взаимодействия с Ansible.

Источник

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

Плохой deploy – откат версии 1.

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

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

Деградация производительности операций после деплоя. Источник

Загрузка ресурсов под 100% — добавить ноду в маршрутизацию 2.

На следующем примере система мониторинга определяет, что на одном из компонентов наблюдается загрузка CPU на 100%.

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

Масштабирование под после инцидента

Отсутствие места на жестком диске – чистка диска 3.

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

Загрузка диска 100%
 
4. Низкая активность пользователей или низкая конверсия – переключение между синей и зеленой веткой

Это позволяет быстро переключаться между ветками при доставке новых релизов. Я часто встречаю заказчиков, использующих два контура (blue-green deploy) для приложений в прод среде. При этом деградация по производительности и доступности может не наблюдаться. Часто после деплоя могут произойти кардинальные изменения, которые не сразу удается заметить. На следующем рисунке показан пример, на котором при падении конверсии происходит переключение между ветками ПО. Для оперативного реагирования на такие изменения лучше использовать различные метрики, отражающие поведения пользователей (количество сессий и действий пользователей, конверсия, bounce rate).

Падение конверсии после переключения между ветками ПО. Источник

Механизмы автоматического определения проблем

В конце приведу еще один пример, за что мне больше всего нравится Dynatrace.

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

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

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

Пример определения корневой причины сбоя. Источник

На следующем рисунке изображен процесс мониторинга проблем с вашим приложением со старта инцидента.

Визуализация возникающей проблемы с отображением всех компонентов и событий на них

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

При возникновении проблемы разработчики оперативно получают полную информацию для ее анализа на уровне кода в прод среде. Дополнительно советую интегрировать систему мониторинга с Service Desk или баг-трекер.

В итоге у нас получился конвейер CI/CD со встроенными автоматизированными проверками качества ПО в Pipeline. Мы минимизируем количество некачественных сборок, повышаем надежность системы в целом и, если у нас все-таки нарушается работоспособность системы, мы запускаем механизмы по ее восстановлению.

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

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

Источник

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

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

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

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

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