ифт стенд что это
Автоматизация нагрузочного тестирования банковского ПО для терминалов
В этом посте речь пойдет о тестировании серверного ПО, которое обслуживает огромную сеть банковских терминалов в России и за рубежом. Название банка мы раскрыть не можем, некоторые строчки конфигов скрыты.
Итак, мы занимаемся разработкой данного ПО, используя современный CI/CD подход, чем обеспечивается высокая скорость поставки фич, хотфиксов и релизов в продакшн. В начале года нам была предложена задача обеспечить нагрузочным тестированием разрабатываемое решение и продемонстрировать заказчику способность встраивать в CI/CD любые подзадачи и шаги.
Помимо общих слов, хотелки сводились к следующему: необходимо обеспечить автоматический деплой ПО на нагрузочный стенд, придумать легкий способ генерации данных, внедрить автоматический и полуавтоматический способ запуска тестов, снабдить тесты автоматическим триггером старта и остановки по событию, подключить механику НТ к трекеру задач для короткого репортинга, подключить систему тестирования к доступной системе аналитики НТ, создать возможность “покраски” плохих и хороших релизов для дальнейших действий в workflow (выкатить или отправить репорт). Требования, надо признать, абсолютно адекватные и понятные.
Автоматизация
Начнем издалека. Мы постоянно слышим одно и то же: “Автоматизировать нагрузочное тестирование банковского и финансового ПО невозможно! У нас слишком много взаимосвязей! Мы очень сложные!”. Этот вызов только усиливал азарт решения задачи. Нам всегда хотелось проверить сложность на конкретном примере.
Помните замечательную картинку про тестирование в виде пирамидки и рожка с мороженым? Пирамидка – это когда у вас много дешевых автоматических Unit-тестов и мало дорогих UI. Рожок с мороженным – наоборот. Рожок – это дорого, неповоротливо и не масштабируется, пирамидка – дешево и гибко.
Вместо того, чтобы заниматься нагрузочным тестированием ПО на уровне взаимодействий систем, в секторе банковского ПО традиционно все тестируют через UI, как повелось со времен неразъемных систем и приложений. На это уходит много времени и сил, что делает разработку банковского ПО медленной, некачественной и нетехнологичной. Мы в компании “Инфосистемы Джет” были избавлены от этих стереотипов — разработчики сами писали юнит-тесты на свой код, функциональные тестировщики прекрасно программировали UI-тесты через Selenium+Cucumber. Осталось только встроить в процесс дополнительную стадию нагрузочного тестирования.
Проектирование инфраструктуры
В самом начале мы решили отказаться от взаимосвязей, которые усложняют и размывают ответ на вопрос, насколько производительный и надежный код мы разрабатываем. Например, авторизация и выдача токенов на проведение операций — это функциональность сторонней системы, исследовать производительность которой в рамках задачи было бы избыточно. Помимо этого мы сразу отказались от интеграции с несколькими back-office системами, сделав заглушку, отвечающую нашей системе с определенной задержкой (все мы знаем, как опасно тестировать систему на сверхбыстрых моках).
Но самое значительное изменение в парадигме тестирования ‒ это отказ от нагрузочного тестирования UI-терминала. До сих пор это кажется странным, но до нас данное серверное ПО нагрузочно тестировали именно через UI ATM. Происходило это следующим образом: эмулировался некоторый средний пользователь, который проходил какой-то пул сценариев с набором средних пауз (paсing, think time), а нагрузочный инструмент был вынужден создавать нагрузку, которая состоит из длительных и “холодных” сценариев с нескольких лоад-генераторов HP Loadrunner, в то время как результирующая нагрузка на одну ноду API-сервера составляла всего около сотни(!) транзакций в секунду. (Оставим за скобками безумную картину, когда тысячи граждан пытаются нажимать на контролы одного банковского терминала). В итоге из стенда было выброшено практически все, что не имело отношения к производительности бэкенда ATM.
После проектирования и осмотра оставшейся инфраструктуры стало примерно понятно, как будет выстроен процесс, какие бенефиты будут получены, и нужно было приступать к созданию самого процесса НТ.
CI/CD процесс и программное обеспечение
Код ПО выкладывается во внутреннем git-репозитории (GitLab). После коммита по специальному триггеру Jenkins вытаскивает код на сборочную машину и пытается собрать релиз с прогоном всех заведенных Unit-тестов. После успешной сборки с помощью скриптов собранный билд инсталлируется в два тестовых окружения ‒ НТ и ФТ ‒ и делает рестарт тестинга. После подъема бэкенда Jenkins прогоняет друг за другом ФТ, UI и ИФТ-тесты. Нагрузочное тестирование запускается отдельной задачей, но про это стоит рассказать отдельно.
Как всем известно, классический инструмент нагрузочного тестирования состоит из трех “столпов”: генератора тестовых данных, лоад-генератора и анализатора полученных результатов. Поэтому задачу мы решали в трех направлениях.
Чтобы собрать релевантный запрос к API и не переписывать каждый раз XML под изменяющуюся спецификацию, мы пошли другим путем ‒ мы “грабим” TOP-10 основных платежных сценариев в момент прогона UI-тестов. Для этого на тестовом стенде мы развернули tshark, из дампа которого и собираем XML (его впоследствии будем отправлять в API). Это позволяет экономить кучу времени и сил на подготовку тестовых данных.
В качестве лоад-генератора мы использовали самый популярный инструмент на Open Source рынке ‒ JMeter, но в качестве обвязки к нему использовали Yandex.Tank. Мощности JMeter для отправки 100 транзакций в секунду на одну ноду хватает с лихвой, а Tank дает нам удобство в автоматизации и несколько полезных фич ‒ автостопы, интерактивные графики, возможность использования других генераторов нагрузки без перекраивания процесса НТ и т.д.
Самое сложное на этапе конструирования НТ ‒ это аналитическая часть. Так как на рынке пока нет отдельных решений по созданию своей аналитики для тестирования производительности, мы решили использовать Overload от Яндекса. Overload – это сервис для хранения и анализа результатов нагрузочных тестов. Нагрузку вы создаете со своих лоад-генераторов, а результаты загружаете на сервис и наблюдаете их там в виде графиков. Сейчас сервис находится в публичной бете, а для “Инфосистемы Джет” Яндекс создал пилотный приватный инстанс.
Все данные с нашего JMeter поступают в Overload в агрегированном виде и не содержат никакой персональной информации о платежах и клиентах ‒ пользователь видит только графическое представление тестов производительности.
Самое интересное
После того как билд попадает на нагрузочный стенд, посредством скриптов в Jenkins запускается специальная задача для нагрузочного тестирования. Задача настроена классическим способом, через shell-скриптинг и параметризацию.
Например, так можно конфигурировать автостопы:
Так выглядит конфиг Yandex.Tank:
А так выглядит пример shell-script запуска всего процесса НТ:
Как видите, все настройки достаточно примитивны. При автоматическом запуске джоба дефолтные параметры применяются автоматически, при ручном же запуске вы можете конфигурировать стрелялку параметрами Jenkins, не разбираясь в документации и не копаясь на Linux-машинке и перебирая необходимые конфиги.
Режим “Запуск по кнопке” для разработчика выглядит так:
После запуска теста вы получаете ссылку в Console View Jenkins и Telegram, перейдя по которой можно наблюдать нагрузочный тест в реальном времени:
Если результаты теста вышли за пределы SLA, то тест автоматически останавливается и вы получаете репорт в Telegram, почту и JIRA о проблемах с релизом. Если же результат хороший, то после репорта релиз получает статус SUCCESS и готов для деплоя на нагруженную среду, в продакшн.
Скрин с экрана Telegram:
А так бот репортит результаты в JIRA:
В качестве корпоративной “плюшки” от Яндекса мы получили доступ к сравнению тестов:
и доступ к построению регрессионных отчетов по KPI-метрикам:
Проблемы и решения
Данный рассказ был бы неполным, если бы мы не описали несколько граблей, на которые наткнулись в процессе своей работы.
Мониторинг. Очевидно, что при нагрузочном тестировании вы обязаны использовать средства не только бизнес-мониторинга (валидация транзакций, размер очереди, скорость прохождения), но и системного мониторинга (потребление процессора, объем памяти, число дисковых операций, метрики, которые вы придумали сами и т.д.). Хорошо, когда у вас вся инфраструктура построена на Linux ‒ использование встроенного решения на telegraf поверх ssh решает эту задачу ‒ все данные автоматически заливаются в бэкенд статистики и строятся синхронно с агрегатами бизнес-метрик. Но что делать, если у вас часть тестового окружения построена на Windows-платформе?
Мы обсуждали разные варианты и пришли к такому:
В данном случае, все метрики с серверов и load-генераторов пишутся в InfluxDB локальными агентами telegraf, а мониторинг Яндекс.Танка уже извлекает данные из InfluxDB простейшим скриптом и пушит данные в Overload. Такой подход позволяет отказаться от поддержки всего зоопарка операционных систем со стороны Яндекс.Танка и избежать необходимости коннекта “от одного ко всем”.
Написав простейший скрипт, вроде:
Мы можем заставить Яндекс.Танк собирать Custom-метрики из InfluxDB таким конфигом мониторинга:
В результате получаем такие графики в Overload:
Репортинг. Мы использовали два вида репортинга результатов.
Краткий отчет ‒ небольшой объем метаинформации с распределением времен и сообщением от автостоп-плагина ‒ отправлялся в виде сообщения в Telegram-чат, на который были подписаны разработчики, архитектор, менеджер и тестировщики.
Регрессионный отчет ‒ расширенный отчет, где к краткой информации добавлялось сравнение с эталонными результатами ‒ отправлялся в виде комментария в JIRA.
Для этого мы использовали скрипт на Groovy для Telegram и простенькую либу (подробнее на https://pypi.python.org/pypi/jira/) для провязки c API JIRA.
Заключение
Как можно заметить, данная задача не из разряда Rocket Science, и вы могли читать подобные статьи здесь, здесь и даже смотреть видео здесь. Под капотом лежат обычные скрипты и сервисы ‒ мы всего лишь хотели продемонстрировать, что на самом деле к эре “Devops” и повальной автоматизации финансовый сектор готов уже давно, просто нужно иметь смелость и политическую волю внедрять современные и быстрые процессы.
Какие бенефиты мы можем получить от автоматизации?
Команда нагрузочного тестирования компании “Инфосистемы Джет”.
Интеграционные релизы в СберТехе
Добрый день, уважаемые хабражители!
Я расскажу о том, как происходит управление интеграционными релизами в компании «Сбербанк-Технологии», где я работаю. Хотелось бы поделиться опытом и обсудить его с коллегами по ИТ-отрасли. Подобные вещи практикуются и в других крупных ИТ-инфраструктурах – было бы интересно сравнить.
В СберТехе одновременно делается больше сотни проектов, каждый из которых может вносить изменения в несколько автоматизированных систем. Систем насчитывается несколько сотен, многие из них интегрированы друг с другом через сервисную шину. Это порождает огромное количество взаимозависимостей между проектами: доработки в одном проекте могут влиять на функционал другого. Интеграционные релизы направлены на объединение реализуемых проектов в один пул, синхронизацию их доработок и доведение всех проектов до одномоментного внедрения.
По сути, управление интеграционными релизами является частью процесса управления релизами, одного из 10 базовых процессов ITIL. Без него изменения большой ИТ-инфраструктуры практически невозможны: большинство проектов никогда бы не закончилось, пытаясь учесть все новые и новые доработки автоматизированных систем. Кроме того, одномоментное ночное внедрение минимизирует простой систем, что немаловажно для удобства клиентов.
За счет перекрытия соседних интеграционных релизов достигается равномерная нагрузка на разработчиков и других участников процесса.
Как инженеры a1qa проводили приёмо-сдаточные испытания ПО: Часть 1. Теоретическая
Вот уже более двух лет команда a1qa работает на проекте по созданию платежной системы для одного крупного банка. Поначалу задачи нашей команды сводились только к тестированию системы, однако через некоторое время заказчик поручил нам подготовку и проведение приёмо-сдаточных испытаний.
Задача эта нетипичная для тестировщиков. Поэтому мы решили поделиться своим опытом и рассказать, как её грамотно выполнить, оправдав доверие заказчика.
Что такое приёмо-сдаточные испытания (ПСИ)?
Прежде чем выпускать продукт на рынок, заказчик должен убедиться в возможности использования разработанного решения, в его безопасности, надёжности, корректном функционировании и проверить другие характеристики, описанные в требованиях к продукту.
ПСИ особенно актуальны для проектов, на которых выпуск некачественного продукта может привести к значительным финансовым потерям (к слову, наш проект именно к таким и относится).
Итак, цели проведения ПСИ:
Избежать хаоса в подготовке и проведении ПСИ, развеять сомнения в методах убеждения и их эффективности помогают различные нормативно-правовые документы, которые стандартизируют процессы разработки и тестирования.
Один из таких документов, обязательный для любых приёмо-сдаточных испытаний, – это «Программа и методика испытаний».
Документ «Программа и методика испытаний»: что нужно знать тестировщику
Написанием и форматированием данного документа обычно занимаются специально обученные люди, например, технические писатели.
Однако знать, из чего состоит документ, тестировщику не помешает. Кроме того, подготовка одного из разделов может быть поручена именно тестировщикам.
Обратимся к официальной документации. Согласно межгосударственному стандарту ГОСТ 19.301-79, документ «Программа и методика испытаний» должен иметь следующую структуру:
Какой из разделов под силу подготовить функциональному тестировщику? Конечно же, «Методы испытаний». Об этом поговорим позже, а пока ещё немного теории.
Критерии успешности приёмо-сдаточных испытаний
Как правило, успешность ПСИ определяется на этапе заключения контракта. Одним из таких критериев может быть процент успешно пройденных во время демонстрации проверок. Например, если на проверку выносятся 100 тест-кейсов и критерий pass-rate составляет 80%, то 80 тест-кейсов должно быть успешно пройдено, иначе считается, что продукт приёмку не прошел, а значит, не может быть допущен к опытной и промышленной эксплуатации.
На практике же успешность приёмо-сдаточных испытаний чаще определяется не одним критерием, а совокупностью нескольких. Например, учитывается процент реализованных требований от общего числа и ограничение по количеству дефектов того или иного приоритета. Оперируя данными по этим критериям, принимается решение об успешности ПСИ.
На этом необходимая теория заканчивается. В следующей части расскажем, как приёмо-сдаточные испытания проводила команда a1qa и какие трудности ей пришлось преодолеть.
Стенд для нагрузочного тестирования: от DEV до PROD
Содержание
Меня зовут Василий Кудрявцев, и вот уже 10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.
И сегодня мы поговорим не об инструментах или общих подходах (для этого есть курсы – один из крупных веду я, а еще у многих есть коллеги-эксперты и тот самый чатик в телеге на 3400+ участников), а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.
Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд. Особенно это мечта актуальна для небольших продуктовых команд.
Тем не менее, за последний год мы увеличили количество проводимых тестов почти в 10 раз и команду раза в два. Где же мы проводим более 1000 нагрузочных тестов в год без отдельного стенда, спросите вы? Ответ: мы использовали все стенды по максимуму, под шум (крики) продуктовых команд! 🙂
Я попробовал обобщить личный опыт последних лет, успехи прорыва в результативности тестов и, соответственно, в повышении производительности, которого мы смогли достичь в компании за последнее время.
Договоримся о терминологии
НТ — нагрузочное тестирование, для меня это синоним тестирования производительности. В НТ входят всевозможные подвиды тестов, направленные на проверку показателей производительности системы: время отклика, пропускная способность, % успешных операций или доступность, утилизация ресурсов.
Максимальная производительность — уровень пропускной способности системы, после которого система перестаёт удовлетворять предъявленным к ней требованиям — по времени отклика, доступности, утилизации ресурсов.
Тест определения максимальной производительности — ступенчатое повышение нагрузки на систему до достижения этого самого уровня.
Как у нас организована нагрузка
Инструменты:
Протоколы – наиболее часто это REST-ы и web по http, бывают и скрипты нагрузки на БД / очереди
Запуск тестов в Jenkins
Мониторинг в Grafana + Clickhouse
Для мониторинга генераторов нагрузки — Prometheus
Redis и Postgres для хранения тестовых данных, FTP для больших файлов
В общем, всё как у взрослых людей. В следующих статьях расскажем об этом подробнее, если интересно. А сейчас едем дальше.
3+ регулярно нагружаемые крупные системы:
Единый портал государственных услуг (ЕПГУ)
Единая система идентификации и аутентификации (ЕСИА)
Система межведомственного электронного взаимодействия (СМЭВ, шина данных)
…и еще с десяток периодически нагружаемых прикладных систем и сервисов
Основные типы тестов:
Проверка стабильной нагрузки — короткий тест с заданным tps
Стресс-тесты — проверка работы под большой нагрузкой в течение короткого времени
Классическая максимальная производительность
Команда инженеров:
1 лид и 4 нагрузочника разного опыта и происхождения, со средним опытом в НТ =
Вернемся к нагрузочным стендам
Разделим типы стендов на несколько категорий и поймём, что же можно на них тестировать и какие риски / ограничения нужно держать в уме:
DEV — стенд разработки
UAT — стенд регрессионного функционального тестирования
LT — отдельный стенд нагрузочного тестирования
PROD — стенд на базе инфраструктуры Продуктивного контура
Каждый опишем с нескольких сторон по такой схеме:
Summary — короткое резюме от меня
Жиза — как мы используем этот стенд
Что можно — какие тесты можно проводить
Команда — кто здесь понадобится нагрузочнику, насколько самостоятельно выполнение тестов
Advice — совет напоследок обзора стенда
Summary: Отличное место для нагрузки пилотных решений или новых микросервисов, но задержаться на нём для исследований бывает сложно. Особенно, если архитектура монолитная.
Жиза: Не самый активный стенд именно для нагрузки, но супер-массовые новые сервисы сначала тестим здесь — социальные выплаты, сервисы для выборов, онлайн-запись в школы. Конечно же, в микросервисах, особенно часто в кубере. Здесь не проверить какой-нибудь scaling, но 50-70% проблем на данном стенде мы закрывали, хоть пользовались им не так часто, как стоило бы.
Отступление в рамках темы
Отдельного внимания здесь в описании DEV заслуживает наше детище для Системы межведомственного электронного взаимодействия (СМЭВ). Изначально мы планировали собрать стенд LT, но заказчики-разработчики пожелали проверять новые решения и тюнинг/рефакторинг старых здесь и сейчас. У нас вышел эдакий Монстр, которого мы прозвали DEV-LT! По необходимости могли и мощностей накинуть для достижения нужных цифр, но и не ждали отлаженных новых релизов и прочих pipeline-ов для проверки разных гипотез.
В итоге за пару месяцев мы протестили отказоустойчивость при отключении разных сервисов системы, протюнили с десяток компонент и повысили общую производительность системы раза в три (с учётом пост-тестов на других стендах, конечно же). Это был суровый марафон, но глаза горели у всех!
Что можно: стресс-тесты и общая максимальная производительность всего комплекса здесь бессмысленны. Только точечный тюнинг и проверка отдельных компонентов тестами со стабильными потоками (количество открытых соединений / thread-ов) или подачей стабильной нагрузки.
Команда: Если времени мало, то практически в онлайне с разработчиком. Если побольше — в режиме чатика. Очень удобно поработать devops-ом: сделать «кнопку» для разработчика и дать ему «пофрустрировать» самому до желаемого результата. Не забудьте про мониторинг, чтобы он получал удовольствие! Главное вовремя остановить, не доводить до уровня «хочу 100к tps выжать, 12 ночи всего, запускаю ещё тест!»
Pros and cons:
+ экономит время тюнинга на поздних этапах, что особенно актуально для багов по производительности (все мы знаем, они бывают ОЧЕНЬ дорогими)
+ можно запускать «на коленке» и получать реальный value
– не подходит для основательных выводов по максималке / не применить к PROD — нужны дополнительные тесты на других контурах
– стенд обычно шаток и разработчики любят его ломать, а иногда его потом сложно восстановить
– сложно с тестированием интеграций, DEV, как правило, изолирован
Advice: Совет подойдёт и для других стендов — «одно изменение за раз!». Разработчики любят побежать азартно вперёд, и применить много «оптимизаций» между тестами за один раз. Потом приходится часто искать, что именно улучшило или ухудшило производительность. Поэтому лучше стараться делать одно улучшение/изменение за раз и оценивать тестом, хотя бы коротким.
UAT (стенд регрессионного функционального тестирования) — относительно стабильный контур по сборкам, но слабый по железу
Жиза: С этого стенда мы начинали в РТЛабс проводить регулярное НТ — в данном случае проверка релизов на не-ухудшение производительности. В частности, на небольшом железе мы сравниваем «выдерживание» ступени стабильной нагрузки по основным показателям производительности. Дефектов обычно находится не так много, как хотелось бы, потому что у этого стенда всегда много «но» по сравнению с PROD. И это несмотря на то, что по конфигурации компонентов он к нему ближе, чем любой другой.
Что можно: Лучше проводить тесты стабильной нагрузки 10-60 минут. Длительность зависит от вашей ступени стабильной нагрузки, за которую вы сможете адекватно оценить показатели производительности. Если у вас быстрая система с 100-500+ tps и временем отклика в пределах секунды (шина данных, например), то хватит и коротких тестов. Если что-то пользовательское с множеством сценариев — лучше погонять подольше и заодно оценить надежность.
Команда: Как правило, лучший друг нагрузочника — это функциональщик. В данном случае вдвойне, так как это его стенд! Он подскажет, когда и сборка более-менее стабильна и когда можно поломать стенд тестами. С дефектами тут сложнее, чем на DEV — у нас по крайней мере были наводки и на инфраструктурные сбои, а разбор может быть не таким быстрым, как хотелось бы.
Pros and cons:
+ хороший стенд для старта нагрузочного тестирования в плане стабильности и отладки (в том числе на новых готовящихся версиях системы). И для того, чтобы потом куда-то переезжать с тестами на другие стенды
+ обычно неплохая поддержка со стороны ФТ и сопровождения, так как релизы должны ехать в PROD без простоев. А вы, в том числе, занимаете время подготовки релиза 🙂
– придётся выбирать время для тестов, чтобы не мешать ФТ
– сильную нагрузку целиком на систему не подать ввиду слабости стенда по железу, то есть сложно оценить максимальную производительность в целом
Advice: Не убивайте стенд, пожалейте функциональщиков! Не только проведением нагрузки днём, но и забиванием БД тестовыми или созданными в тестах данными. Проработайте процедуры очистки.
LT (отдельный стенд нагрузочного тестирования)
На какой хватит средств какой построите, такой и будет! Но в любом случае он лучше остальных стендов, потому что СВОЙ.
Summary: Здесь всё понятно — идеальный стенд практически для любых целей НТ. Не надо сидеть по ночам / ждать пока он освободится (в пределах одной тестируемой системы, конечно). В некоторых банках даже построили интеграционные стенды НТ. Правда пока я не видел стенд, выдерживающий 100% нагрузку по профилю с Прода, со всех каналов-систем.
Жиза: Выше я рассказывал о том, как мы применяем стенд DEV-LT. Пока мы видим неплохую пользу в совмещении целей для этого контура с учетом имеющейся инфраструктуры PROD для больших тестов (об этом ниже).
Из опыта других компаний могу сказать, что отдельный контур это действительно долго, дорого и замечательно. Причём для стабильного стенда крупной системы «долго» — это скорее всего минимум год, а «дорого» — не только закупка оборудования, но ещё и отдельная команда админов разного профиля. Ведь у вас небольшой PROD, а значит нужны инженеры СПО, ППО, DBA и т.д.
При этом на других стендах можно и нужно ловить 80-90% проблем. Это значит, что в микросервисной архитектуре огромные стенды становятся всё менее полезными.
Что можно: ВСЁ. Ну, правда. Интеграционные нагрузочные тесты можно проводить с эмуляторами, хорошо идут регрессионные тесты, стресс-тест/максималка/надежность/отказоустойчивость и любые другие, которые вы ещё себе придумаете между релизами.
Команда: Если хотите работать эффективно, а не чинить стенд неделями, когда ребята с PROD / тестовых контуров смогут уделить вам время, то только отдельная команда. Если стенд небольшой, можно не выделять отдельно системных администраторов / DBA на задачи одного этого стенда. Но инженеры ППО точно нужны — системы нужно и поднимать с нуля и поддерживать (поднимать) после регулярных тестов и релизов, которые будут их ломать.
Pros and cons:
+ подходит для всех нужных нагрузочных тестов (с интеграционным НТ может быть сложно, но возможно!)
+ не нужно ждать очередь на стенд, есть время для улучшений / экспериментов
+ можно готовить нужные наборы тестовых данных, тестировать объемы
– дорого и долго — и по подготовке железа, и в поддержке
– команде сопровождения нужно долго набираться опыта
– бывает сложно отслеживать все изменения на PROD / тестовых контурах, чтобы тестовый стенд НТ был актуален
Advice: Не надейтесь, что стенд НТ взлетит быстро, особенно если команда собирается с нуля. Исключения — небольшие и простые системы, по ним и PROD просто и быстро собрать.
И раз уж у вас отдельный стенд — пробивайте получение копии БД с PROD (урезанной, обезличенной), это повысит качество тестирования.
Ещё совет— не делайте прогнозирование / домножение результатов, полученных на стенде НТ, для PROD, если у вас LT сильно меньше по ресурсам. Горизонтальное масштабирование — непростая штука. Да простят меня мастера-архитекторы – иногда позволяю себе «умножить на 2» производительность, полученную на стенде НТ, который в 2 раза слабее Прода по ресурсам, при микросервисной архитектуре и не загруженности всех узлов по метрикам серверов. Можно предположить, что на Прод будет не хуже.
Сравнение производительности простой web-ки на node.js при увеличении ресурсов машины в 2 раза.
Как-то студенты курса по НТ проводили простой эксперимент по оценке влияния повышения ресурсов сервера, на котором крутилась простая веб-страничка c node.js под капотом, практически ничего не делающая. Результат налицо. Теперь храню эту картинку и показываю всем, кто любит «умножать на 10».
PROD (стенд на базе инфраструктуры Продуктивного контура) – опасно, но крайне эффективно
Жиза: Чтобы быть уверенными в высокой доступности новых, серьёзных по нагрузке сервисов, финальные тесты мы проводим здесь. Особенно это актуально, когда у нас мало времени, например, при запуске срочных выплат населению страны последних пары лет.
Пользователи Госуслуг засыпают, а мы собираемся на ночной zoom и аккуратно тестируем на PROD-инфраструктуре. Тюним на месте, записываем изменения конфигов «на лету» себе в тикеты «на утро». Отдельно заказываем новые VM туда, где понимаем, что не успеем дотюниться до запуска сервиса.
Конечно, для этого нужна аккуратная и дотошная подготовка скриптов для очистки мусора после тестов и выверенный чёткий план тестирования с автоматизацией запуска тестов.
Что можно: Конечно, не всё. В первую очередь это стресс-тесты — короткие, точные, до первых узких мест, чтобы затем произвести тюнинг. Можно сразу в онлайне, чтобы не уходить потом на ещё одни работы. Не получится использовать инфраструктуру PROD, если у вас интенсивная пользовательская нагрузка 24/7 и нет микросервисов, которые вы можете изолировать от влияния на пользователей на 99%+.
Для тех, кто по каким-то причинам не хочет в этом участвовать, есть отличный аргумент — или мы сейчас проконтролируем что будет, или будем смотреть на это в онлайне, на живых пользователях и чинить, теряя SLA.
Pros and cons:
+ не только НТ, но и тренировка для команды
+ в нехватке времени можно тюнить на лету (конечно, сохраняя улучшения в репозиториях)
– требуется хорошая подготовка плана и скриптов очистки
– не для каждого сервиса возможно НТ на инфраструктуре PROD
Advice: Все же помнят хорошую практику: всё что выкатывается на PROD должно тестироваться? Это же касается и ваших скриптов НТ, тестовых данных, скриптов очистки от мусора после НТ. Всё должно быть протестировано на младших контурах, считайте, что это такой же релиз.
Ну и конечно, так как НТ на PROD — это часто ночные работы, не замучайте команду в ночь перед запуском важных сервисов. Если не успеваете, лучше ребятам поспать ночь и с утра уже готовиться к проблемам на PROD, быстрее будут реагировать.
Во всём нужна мера, потому что, как говорил один мой знакомый менеджер: «Работа отнимает всё отведенное на неё время».
Вместо заключения
Как видите, у каждого стенда НТ найдутся свои нюансы, а главное – своя польза. Уже давно прошли те времена, когда подрядчик требовал нагрузочный стенд, а заказчик закупал его месяцами, тратя огромные деньги. С новыми средствами НТ и микросервисной архитектурой тесты можно проводить на разных этапах и на разных стендах достаточно быстро.
Я бы описал рекомендованный путь становления процессов НТ в компании по части стендов так:
UAT – отсюда можно стартовать регрессионное НТ
DEV – для новых сервисов, которые будут нагружены
PROD – когда отдельного стенда НТ нет, а ожидается новая большая нагрузка
LT – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой
Конечно, эти стенды у вас могут называться по-другому, типы тестов тоже. Я старался использовать плюс-минус общепринятые понятия. На закрепление терминологии не претендую.
Пишите в комментариях про ваш опыт использования тестовых стендов для НТ. Буду рад почерпнуть что-то новое, в том числе по поводу плюсов и минусов каждого.