Dev стенд что это

Стенд для нагрузочного тестирования: от 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 — короткое резюме от меня

Жиза — как мы используем этот стенд

Что можно — какие тесты можно проводить

Команда — кто здесь понадобится нагрузочнику, насколько самостоятельно выполнение тестов

Pros and cons — основные + / —

Advice — совет напоследок обзора стенда

DEV — место бурлящей жизни и регулярной поломки разработчиками

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 (стенд на базе инфраструктуры Продуктивного контура) – опасно, но крайне эффективно

Summary: Мало кто вас сюда пустит. Но если пустит — польза не только в качестве достоверных результатов, но и в тренировке для команды поддержки PROD. Только нежнее с боевой инфрой! И не забывайте про очистку от разного мусора после тестов.

Жиза: Чтобы быть уверенными в высокой доступности новых, серьёзных по нагрузке сервисов, финальные тесты мы проводим здесь. Особенно это актуально, когда у нас мало времени, например, при запуске срочных выплат населению страны последних пары лет.

Пользователи Госуслуг засыпают, а мы собираемся на ночной zoom и аккуратно тестируем на PROD-инфраструктуре. Тюним на месте, записываем изменения конфигов «на лету» себе в тикеты «на утро». Отдельно заказываем новые VM туда, где понимаем, что не успеем дотюниться до запуска сервиса.

Конечно, для этого нужна аккуратная и дотошная подготовка скриптов для очистки мусора после тестов и выверенный чёткий план тестирования с автоматизацией запуска тестов.

Что можно: Конечно, не всё. В первую очередь это стресс-тесты — короткие, точные, до первых узких мест, чтобы затем произвести тюнинг. Можно сразу в онлайне, чтобы не уходить потом на ещё одни работы. Не получится использовать инфраструктуру PROD, если у вас интенсивная пользовательская нагрузка 24/7 и нет микросервисов, которые вы можете изолировать от влияния на пользователей на 99%+.

Команда: Берите с собой в онлайн ВСЕХ ключевых участников проекта — разработку, сопровождение PROD, специалистов по сети, виртуализации, железу. В общем, всех, кто будет (а лучше не будет, не зря же делается НТ) разбираться с проблемами PROD в день запуска нового сервиса. Ведь это же боевая тренировка!

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

Pros and cons:

+ не только НТ, но и тренировка для команды

+ в нехватке времени можно тюнить на лету (конечно, сохраняя улучшения в репозиториях)

– требуется хорошая подготовка плана и скриптов очистки

– не для каждого сервиса возможно НТ на инфраструктуре PROD

Advice: Все же помнят хорошую практику: всё что выкатывается на PROD должно тестироваться? Это же касается и ваших скриптов НТ, тестовых данных, скриптов очистки от мусора после НТ. Всё должно быть протестировано на младших контурах, считайте, что это такой же релиз.

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

Во всём нужна мера, потому что, как говорил один мой знакомый менеджер: «Работа отнимает всё отведенное на неё время».

Вместо заключения

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

Я бы описал рекомендованный путь становления процессов НТ в компании по части стендов так:

UAT – отсюда можно стартовать регрессионное НТ

DEV – для новых сервисов, которые будут нагружены

PROD – когда отдельного стенда НТ нет, а ожидается новая большая нагрузка

LT – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой

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

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

что такое dev стенд

Стенд для нагрузочного тестирования: от DEV до PROD

Меня зовут Василий Кудрявцев, и вот уже 10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

И сегодня мы поговорим не об инструментах или общих подходах (для этого есть курсы – один из крупных веду я, а еще у многих есть коллеги-эксперты и тот самый чатик в телеге на 3400+ участников), а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд. Особенно это мечта актуальна для небольших продуктовых команд.

Тем не менее, за последний год мы увеличили количество проводимых тестов почти в 10 раз и команду раза в два. Где же мы проводим более 1000 нагрузочных тестов в год без отдельного стенда, спросите вы? Ответ: мы использовали все стенды по максимуму, под шум (крики) продуктовых команд! ��

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

Договоримся о терминологии

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

2. Максимальная производительность — уровень пропускной способности системы, после которого система перестаёт удовлетворять предъявленным к ней требованиям — по времени отклика, доступности, утилизации ресурсов.

3. Тест определения максимальной производительности — ступенчатое повышение нагрузки на систему до достижения этого самого уровня.

Как у нас организована нагрузка

Инструменты:

· Протоколы – наиболее часто это REST-ы и web по http, бывают и скрипты нагрузки на БД / очереди

· Запуск тестов в Jenkins

· Мониторинг в Grafana + Clickhouse

· Для мониторинга генераторов нагрузки — Prometheus

· Redis и Postgres для хранения тестовых данных, FTP для больших файлов

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

3+ регулярно нагружаемые крупные системы:

· Единый портал государственных услуг (ЕПГУ)

· Единая система идентификации и аутентификации (ЕСИА)

· Система межведомственного электронного взаимодействия (СМЭВ, шина данных)

· …и еще с десяток периодически нагружаемых прикладных систем и сервисов

Основные типы тестов:

· Проверка стабильной нагрузки — короткий тест с заданным tps

· Стресс-тесты — проверка работы под большой нагрузкой в течение короткого времени

· Классическая максимальная производительность

Команда инженеров:

1 лид и 4 нагрузочника разного опыта и происхождения, со средним опытом в НТ =

Вернемся к нагрузочным стендам

Разделим типы стендов на несколько категорий и поймём, что же можно на них тестировать и какие риски / ограничения нужно держать в уме:

1. DEV — стенд разработки

2. UAT — стенд регрессионного функционального тестирования

3. LT — отдельный стенд нагрузочного тестирования

4. 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 (стенд регрессионного функционального тестирования) — относительно стабильный контур по сборкам, но слабый по железу

Summary: Как и для ФТ — хороший стенд для проверки новых релизов по старой функциональности (применимо и для НТ). Так и хочется добавить к нему железа, и пусть весь мир (другие стенды) подождут. Но в итоге тестов будет ждать и остальная команда.

Жиза: С этого стенда мы начинали в РТЛабс проводить регулярное НТ — в данном случае проверка релизов на не-ухудшение производительности. В частности, на небольшом железе мы сравниваем «выдерживание» ступени стабильной нагрузки по основным показателям производительности. Дефектов обычно находится не так много, как хотелось бы, потому что у этого стенда всегда много «но» по сравнению с 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 – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой

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

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

Готовим тестовое окружение, или сколько тестовых инстансов вам нужно

Сколько в вашем проекте тестовых стендов — 5, 10 или больше 10? Навскидку, нужны стенды для каждой команды разработки, стенды для QA под каждый проект, менеджерам проектов тоже нужны стенды, а еще CI — трудно это все точно разграничить и не вызвать конфликтные ситуации. Одним словом, почему бы нам не делать тестовый стенд ровно тогда, когда он нужен? Нужен сейчас тестовый стенд — мы его сделали, не нужен — мы его удалили.

Именно такой подход предложил Александр Дубровин (adbrvn) на Highload++ 2017 в своем докладе, расшифровку которого вы найдете под катом.

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

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

Немного истории

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

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

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

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

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

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

В JIRA начинают падать тикеты, возле Васи начинают собираться разработчики со словами: «Да как же так? Все же сделано!» и кто-то наконец спрашивает: «А у тебя какая ветка на тест раскатана?» Вася смотрит — не та. Ветка быстро исправляется, тикеты в JIRA закрываются, все хорошо. Вася продолжает тестировать, у него все работает.

Но в это время в другом конце комнаты разработчик Вова думает: «Странно, а почему у меня не работает?» Но он быстро понимает, что ветка не та. Раскатывает ту, что нужно, и проблемы снова у Васи.

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

Другая история. Разработчик Коля знает про Васины проблемы, заранее приходит к нему и спрашивает, какой тестовый стенд сейчас свободен. Вася указывает свободный, и все хорошо. Через пару дней они встречаются снова, и Вася спрашивает у Коли: «Ты нам тестовый стенд вернешь? Ты его занимал на часок, а уже 2 дня прошло».

И снова проблема — либо разработчику искать другой стенд, либо все будут бодро ждать, пока он закончит тестирование.

На самом деле на схеме выше отображено не все. Здесь не хватает менеджеров. Иногда менеджеры хотят смотреть еще не протестированный сырой код. Подход стандартный — мы снова выделяем уголок тестового сервера и делаем еще тестовые стенды.

Плавно развивая такую схему, мы получаем бесконтрольное изменение тестовых стендов. Схема плоха тем, что мы действительно не контролируем такие стенды — мы не знаем:

В этот момент мы задумались — что же делать? Зачем нам столько тестовых стендов? Почему бы нам не делать тестовый стенд ровно тогда, когда он нужен? Нужен сейчас тестовый стенд — мы его сделали, не нужен — мы его удалили.

Следующий шаг в этой идее — делать тестовый стенд под каждую ветку кода.

Вроде идея хорошая, но есть технические нюансы. Нам нужны стенды:

Суровая реальность

Еще есть суровая реальность, в которой у нас:

Сказано — сделано!

Docker/docker-compose

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

Замечательно — мы будем использовать docker — это стильно, модно, молодежно.

Распиливаем монолит выделяем сервисы

Docker пропогандирует микросервисный подход и здесь мы встаем перед проблемой, потому что у нас монолит.

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

В какой-то момент мы посмотрели на компонентную схему нашей системы и увидели, что здесь у нас есть load-balancing, здесь — приложение на php, здесь — node.js-приложение. Почему бы нам не запускать именно это, как сервис. Давайте найдем то, что мы можем запускать в docker-контейнерах.

Настраиваем сеть

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

В документации имеется целый огромный раздел про настройку сетей.

Docker умеет использовать различные типы сетей. В нашем случае очень помогла сеть типа macvlan. Это технология, которая позволяет на одном физическом сетевом интерфейсе реализовывать пачку виртуальных сетевых интерфейсов. При этом docker сам будет управлять этими интерфейсами: создавать, добавлять на машину и получать уже внешние, по отношению к хост-машине, IP-адреса.

Таким образом мы можем запустить пачку контейнеров, дать фронт-контейнеру (балансеру) возможность получить внешний IP-адрес и открыть на нем 80-ый порт. Мы уже можем постучаться туда при помощи браузера.

Поднимаем DNS и API

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

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

В нашем случае мы выбрали префикс sj. Получается, нам приходится перекрывать домены только с префиксом sj — таких явно немного.

Еще одна часть DNS — это API. Как уже говорилось, необходимо поднимать тестовые стенды быстро. Поэтому нам нужен DNS-сервер, который позволяет быстро добавлять и быстро убирать запись по API в автоматическом режиме.

Решение — PowerDNS. Этот сервер позволяет достаточно быстро и просто прикрутить к нему API и при помощи скриптов добавлять и удалять тестовые стенды.

Замечательно! Мы подняли и настроили DNS, научили наши контейнеры в него прописывать свои IP, но чего-то не хватает.

Делаем SSL-CA

Мы живем в XXI веке. Очевидно, что весь интернет — SSL и тестовые стенды должны поддерживать SSL. Достаточно много багов специфичны для SSL, и mixed content — только вершина айсберга.

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

Велосипед пишется за один день и позволяет при помощи GET-запросов получать сертификаты, сгенерированные уже на конкретное имя домена.

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

Автоматизируем

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

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

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

Плюсы

Минусы

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

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

Тогда, мы перестали их создавать автоматически, а появилась кнопка в JIRA, CI научилась запускать и останавливать тестовые стенды, собирать с них логи.

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

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

Было: «Вася, а какой тестовый свободный — мне свою задачу раскатить потестировать».

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

Стало: «Жму кнопку и через полторы минуты получаю новый тестовый стенд под конкретную задачу».

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

Возвращаясь к своему первому вопросу, сколько же тестовых стендов нам нужно? Я не знаю, сколько нам нужно тестовых стендов, потому что сегодня их нужно 20, завтра — 15, послезавтра 25.

Но я точно знаю, что у нас ровно столько тестовых стендов, сколько нужно здесь и сейчас.

Время летит незаметно, и до фестиваля конференций РИТ++ осталось совсем немного, напомним он пройдет 28 и 29 мая в Сколково. Пользуясь случаем, приводим небольшую подборку заявок RootConf для широкого круга слушателей:

Dev стенд что это

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

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

Задача

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

Gitlab CI, Terraform, Bash, любое приватное/публичное облако.

Технические сложности:

Алгоритм

Gitlab CI выполняет pipeline. Связывает все остальные компоненты воедино.

Terraform создаёт и удаляет экземпляры виртуальных машин.

Bash сценарии подготавливают конфигурационные файлы специфичные для каждого стенда.

Структура репозитория

.gitlab-ci.yml:

Остановимся подробнее на каждом шаге нашего пайплайна:

Запуск пайплайна происходит с объявлением переменной NAME_ENV, содержащей имя нового стенда:

Разработчики не имеют доступа к Git репозиторию и могут вносить в него изменения только через запуск pipeline.

modules/base/main.tf:

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

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

scripts/env.sh:

При создании нового окружения:

В каталоге DEPLOY_DIR создаётся директория с именем окружения.

Из файла scripts/subnets.txt мы извлекаем одну свободную подсеть.

На основе полученных данных генерируем конфигурационные файлы для Terraform.

Для фиксации результата отправляем каталог с файлами окружения в git репозиторий.

scripts/subnets.txt:

В данном файле мы храним адреса наши подсетей. Размер подсети определяется переменной CIDR в файле scripts/create_env.sh

Результат

Мы получили фундамент который позволяет нам развернуть новый стенд путём запуска pipline’a в Gitlab CI.

Снизили затраты нашей компании на инфраструктуру.

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

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

Можем поиграться с триггерами Gitlab и разворачивать новые стенды из пайплайнов команд разработчиков передавая версии сервисов.

Среды, код и релизы

Лучшие практики по именованию и разграничению сред в соответствии с их предназначением, взаимному соответствию сред и ветвей кода, и процессу выпуска.

Именование сред

Разработки [dev] — та среда (база данных, сайт, ВМ и т.д.), где развёртываем свежий код и смотрим, что получается.

Демо [demo] — тут промежуточный результат показывается заказчику. Пока развёрнутый здесь полуготовый функционал ждёт внимания заказчика, на [dev] можно всё сломать, работая дальше.

Тестовая [test] — тут тестируется функциональность. Среда наполнена тестовыми данными, которые могут отражать редко возникающие (в рабочей среде) случаи или быть удобными для тестирования. Пока тут идёт тестирование того, что готовится в продакшен, на [dev] уже появляется код следующего релиза.

Промежуточная [stage], она же предпродакшен — тут тестируется развёртывание. Сюда развёртывается последний бэкап системы из продакшена, чтобы проверить обновление на версию.

Продакшен [prod] — тут работают пользователи.

Связь с кодом

В зависимости от системы бывает, что код идёт в развёртывание вместе с конфигурацией (набором переносимых настроек). При этом, сам код ведётся в репозитории, а конфигурация в среде.

Изначально, код, попадающий в ветвь /dev, выкатывается в среду [dev], где настраивается конфигурация к нему. Затем, код и конфигурация (иногда по частям) переносятся в другие среды.

Путь кода

То, что исправляется в /main при тестировании, естественно → /dev.

Путь конфигурации

[dev] → экспорт в репозиторий отдельно от кода.

Ошибки проектирования систем

Рассмотрим, что в архитектуре системы может сделать невозможным гладкий выпуск.

Двусторонняя зависимость

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

То, что делает путь релиза таким трудным или уникальным — ошибка архитектуры. Её совершают из побуждений «сделать что-то автоматическим», закладывая возможность в единый конфигуратор системы, вместо того, чтобы закладывать в более низко-уровневые инструменты, или «получить быстрый результат», используя такую возможность.

Бывает, что в покупной системе есть несколько путей создания вещей, таких как структуры данных или объекты. Например, в ELMA-BPM есть создание объектов через конфигуратор, а есть через плагин к Visual Studio. Выбирайте более низко-уровневый способ, иначе попадёте на описанную двустороннюю зависимость.

Логика в базе данных

Переразвернуть базу данных гораздо сложнее чем пересобрать код.

Из-за этого, в системах, где много логики в базе, разработчики работают на одном общем экземпляре БД. Обычно они говорят, что им нужна общая БД для разработки, так как: а) там всегда развёрнут последний код от каждого из них и б) там готовы тестовые данные.

Из-за постоянной работы в общей базе (читай «среде»), в свою очередь, теряется смысл ветвления кода в репозитории.

В итоге, от /dev бессмысленно отделять ветви фич, что, в свою очередь, не позволяет выделять длинные работы и делать релизы независящими от них.

Кроме того, поскольку перенос из среды в среду (ибо это из базы в базу) сложнее, количество сред в процессе пытаются сократить, не выходя за [dev] → [stage] → [prod] (а то и [dev] → [prod]). Тестируют и демонстрируют функционал прямо на [dev].

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

Как мы перестали тратить неделю на выдачу dev-стенда

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

Объем баз данных процессинга у нас составляет порядка 6 ТБ. На одной копии баз разработчики мешают друг другу, поэтому фактический объем занимаемого базами пространства растет быстро и пропорционально. Хотя как быстро… слишком быстро для службы сопровождения и недостаточно быстро для тех, кому копии баз нужны. И вот почему.

Для тестирования нужно, чтобы тестовый стенд полностью соответствовал текущей версии продакшена (то же самое относится к стенду предпродакшна). Основной бэкап системы копируется в течение целых суток, затем развертывается на стенде. Во время этих длительных операций стенды недоступны, так что копирование переносится на выходные и праздники, когда со стендами никто не работает. Получаем задержку от 1 до 5 дней. Чтобы предварительно согласовать сам процесс копирования, тоже нужно время — ведь тестовых стендов у нас несколько, обычно от трех до шести. Добавляем 2-3 суток на согласование времени простоя стенда. Перед тем, как попасть на согласование к администратору, заявка еще стоит в очереди. В сумме получаем очень большую задержку.

Чем помог Delphix

Что может ускорить процесс и сэкономить место? Виртуализация баз данных. Рассмотрели разные варианты: Oracle SnapClone, NetApp+Oracle Cloud, просто снапшоты на массивах. Всё требует сложной настройки. Решения Oracle, к тому же, работают только с БД Oracle.

Затем присмотрелись к Delphix. Внедрять его просто, он поддерживает разные БД — Oracle, SQL Server, DB2, Sybase ASE. Для всех операций предусмотрен интерфейс. Через него разработчики и тестировщики могут самостоятельно управлять своими копиями — обновлять, сохранять/восстанавливать состояние, останавливать/запускать и т.д. Также есть API и CLI для интеграции с CI/CD системами или своими процессами.

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

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

Мы стараемся проводить нагрузочное тестирование в условиях максимально приближенных к проду. Если прод на физических дисках – то и нагрузочный стенд тоже. В этом случае помогает наличие у Delphix кнопки V2P, которая позволяет сделать «честную» базу из виртуальной.

Что касается экономии дискового пространства, то показания нашего дэшборда Delphix, конечно, привирают — сокращение объема в 73 раза слишком сказочно. У нас в процессинге копия прода с ежедневными снепшотами и архивными журналами транзакций за 2 недели (200 ГБ в сутки) занимает 4,5 ТБ дискового пространства. Еще 1,5 ТБ — девять клонов размеров от 50 до 500 ГБ, каждый из которых тоже хранит историю ежедневных снепшотов. Всего получается 6 ТБ.

Прибавляем еще 15% свободного места (900 ГБ), чтобы Delphix мог нормально работать. Таким образом, затрачивая всего около 7 ТБ, мы можем получить тестовую копию с данными, актуальными на любой момент времени в течение двух последних недель.

Раньше для того, чтобы хранить девять физических копий базы в 6 ТБ, нам требовалось 54 ТБ (или

20 ТБ с учетом сжатия в 2-3 раза на СХД). И, в отличие от новой системы, здесь разработчики не могли управлять этими копиями и восстанавливать предыдущие состояния — при разрушении данных можно было только перезаливать из копии прода.

Также Delphix позволяет быстро делать под разные проекты разные ветки одного и того же контейнера — и все это за минимальное время. Разработчики не боятся повредить данные, они могут откатиться и восстановить предыдущее состояние. Это дает прирост производительности.

Но есть нюансы.

Впечатления от Delphix в основном положительные, хотя идеально не все. Самая большая проблема — с использованием дисков. Каждый блок данных хранится только один раз для всех виртуальных копий, и пока все виртуальные копии не перестанут использовать блок, удалить его невозможно. Здесь могут возникнуть организационные проблемы — не все пользователи готовы поддерживать короткий жизненный цикл своих стендов. Если тестовый стенд живет на старой копии прода, то занимаемое место увеличивается. Мы решаем этот вопрос экстенсивно, расширением дисков, что можно делать без прерывания сервиса. Следим, чтобы всегда сохранялось 15% свободного места. Если его будет меньше, система просто перестанет выполнять любые операции с виртуальными копиями. Хотя сами базы останутся доступны.

Для систем с интенсивным дисковым вводом-выводом пропускная способность сети, скорее всего, будет лимитирующим фактором. В зависимости от конкретного профиля нагрузки система может начать работать лучше при виртуализации. В зависимости от нагрузки среднее время ожидания «db file sequential read» составляет 5-10 мс, что довольно неплохо даже для промышленных систем.

К Delphix «классические» диски подключаются любым способом, который поддерживает ESX, и у вендора есть список рекомендаций, как сделать это с максимальной производительностью. Мы используем SAN. Сама система презентует диски, на которых расположены файлы виртуальных баз, только по протоколу NFS. По этой причине нужно быть внимательными к пропускной способности канала и его загруженности. В нашем случае имеет смысл размещать на дисковых массивах только файлы данных для Delphix, чтобы никакие активности в банке не влияли на скорость ввода/вывода для виртуальных баз.

Сейчас мы работаем на Delphix 5.1.9, но присматриваемся к версии 5.2 — в ней пользовательский интерфейс ушел от флэша и, как утверждает вендор, стал намного удобней. Delphix произвел впечатление на наших коллег, и вслед за процессингом мы подумываем перенести на эту систему разработчиков profile, CRM, интернет-банк.

Стенд для нагрузочного тестирования: от 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 – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой

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

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

Контур продуктивный или демонстрационный что это

Элегантные трюки в notebook на персональном компьютере (ноутбуке) — это хорошо и интересно. Но как только речь заходит об исполнении кода в продуктивном контуре, тут же появляются масса ограничений в виде:

Нынче в России такая фаза, что для задач data science язык python позиционируется как «серебряная пуля». Похоже, что такой тезис выдвинули те, кто продают курсы по DS на python. А дальше маховик пошел. В целом, это вполне нормально — почти все процессы в физическом мире являются колебательными.

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

Проблема 1

Плохо то, что причины такого поведения скрыты за кулисами от обычного разработчика. Такая рулетка в продуктивном контуре при согласованных ресурсах и выделенном окне времени на расчеты мало кому нравится.

Можно, например, почитать:

Проблема 2

Типичная связка pandas + sql / spark для данных среднего объема (сотни Гб — десятки Тб) по скорости и объему требуемых аппаратных ресурсов очень сильно проигрывает связке data.table + Clickhouse на типичных задачах (преобразования data.frame ). Технические детали и актуальные тесты можно посмотреть на страничке Database-like ops benchmark. Желающие могут сами скачать тесты, выполнить их на своей инфраструктуре и составить собственное мнение.

Проблема 3

Стенд для нагрузочного тестирования: от 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 – когда уже научитесь тестировать, поймете систему и действительно сможете использовать дорогое удовольствие с пользой

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

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

Маркеры дня рождения

Сводим параметры в одну таблицу потенциалов (Табл. 18). Она и станет основой для анализа природного потенциала личности.

Потенциалы личности человека.

15 – 65	границы физических возможностей, физический потенциал.
56 – 41	границы эмоциональных возможностей, эмоциональный потенциал.
21 – 65	границы интеллектуальных возможностей, интеллектуальный потенциал.

1. Важное примечание. Исследователь А.В. Солодкий (Петропавловск-Камчатский) связал эти потенциалы с работой и степенью развития чакромов. Это выглядит так:

— число 65, второй столбец физического контура – 2 чакром. Свадхистана.

-число 56 эмоционального контура – 3 чакром. Манипура.

— число 41 эмоционального контура – 4 чакром. Анахата.

-число 21 – правополушарное мышление.

-число 65 –левополушарное мышление.

Важно заметить, что столбцы интеллектуального потенциала в ниже приведённом рассчёте соответствуют ЛЕВШЕ.Для правшей надо складывать 56 и 65.Таков будет их невербальный интеллект. Это происходит потому, что при входе в Сушумну, то есть из головы в позвоночник, происходит поворот энергии. Правое полушарие управляет левой стороной тела. И наоборот. Путаница возникает из-за того, что правый столбец в интеллектуальном потенциале отражает работу левого полушария. Но это верно только для правшей.

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

Шестой чакром – как образный, или невербальный интеллект. Аджна.

Тогда седьмой чакром (Сахасрара) будет характеризоваться как «от» и «до». То естьот 21 до 65.

Контур продуктивный или демонстрационный что это

Хронально-векторная диагностика врожденной емкости чакр и кармического жизненного кода разработана известными отечественными учеными и исследователями (А. А. Бухтояровым, А. В. Жажковым, М. Сиддиком).

ХВД относится к современной нумерологии, синтезирующей несколько областей знаний: фазовое развитие человека, биоритмология, математические идеи.

Формула данной диагностики описана в книге Фалеса Аргивянина “3ЭОН”, в ней же читатель может ознакомиться с полной историей возникновения метода ХВД. Однако, информация в книге подана достаточно сжато, поэтому читателю требуется много самостоятельной работы и практического опыта, чтобы широко охватить возможности метода.

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

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

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

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

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

Бонусом я предлагаю освоить авторский анализ совместимости в отношениях (я+партнер или я+ребенок), основанный на методе ХВД.

Метод ХВД позволяет:

• Заранее обнаружить возможные проблемы, с которыми человек потенциально столкнется в разных жизненных периодах;

• Составить индивидуальный код кармических задач и оптимальные варианты его отработки;

• Определить врожденные емкости чакр для анализа врожденного уровня здоровья и потенциально уязвимых органов

• Оценить чакральную совместимость с партнером и уроки, которые заложены в ваших отношениях;

• Спрогнозировать вероятность положительных или негативных событий в определенные возрастные периоды и подобрать подходящий метод управления данными событиями;

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

• Определить общий уровень энергетики, слабые и сильные места в организме;

• Найти таланты и потенциал, который станет ключом для вашего успеха.

Популярные вопросы и ответы

Какие преимущества ХВД перед астрологическим анализом натальной карты или другими методами нумерологического анализа?

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

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

У меня малая емкость какой-либо чакры. Возможно ли это исправить?

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

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

Одинакова ли судьба всех людей, рожденных в одну дату?

Нет. Потому что развитие линии судьбы каждого человека зависит от многих факторов:

• Местности и окружения, в котором он растет и формирует свои привычки, характер, потребности;

• Личной воли, решения и выбора человека в той или иной жизненной ситуации;

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

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

Какие чакры важнее развивать – верхние или нижние?

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

Как правильно увеличивать емкость чакр?

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

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