Ифт стенд что это

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

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

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

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

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

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

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

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

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

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

Основной — Gatling
Протоколы – наиболее часто это REST-ы и web по http, бывают и скрипты нагрузки на БД / очереди
Запуск тестов в Jenkins
Мониторинг в Grafana + Clickhouse
Для мониторинга генераторов нагрузки — Prometheus
Redis и Postgres для хранения тестовых данных, FTP для больших файлов

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

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

Единый портал государственных услуг (ЕПГУ)
Единая система идентификации и аутентификации (ЕСИА)
Система межведомственного электронного взаимодействия (СМЭВ, шина данных)
…и еще с десяток периодически нагружаемых прикладных систем и сервисов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pros and cons:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем результативного НТ и рабочих стендов!

госуслуги
нагрузочное тестирование
тестовый стенд
performance testing
load testing
тестирование по

Интеграционное тестирование

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

Зачем нужно интеграционное тестирование?

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

В каких случаях проводится?

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

Как упростить подготовку данных для тестирования

Генерация связанных данных для сложных тестовых полигонов может тормозить все тестирование и увеличивать time-to-market. Рассказываем, как упростить задачу с помощью SyntWork — инструмента в составе Platform V Works.

Привет, Хабр! Меня зовут Сергей Петровский, я руководитель IT-направления в СберТехе — компании, которая строит цифровой фундамент Сбера.

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

SyntWork, о котором пойдёт речь, входит в семейство инструментов Platfrom V Works для agile-разработки. Эта статья — первая в цикле материалов о Works. В следующих статьях расскажем про другие инструменты: в Works много сервисов для agile-разработки, и каждый достоин отдельного материала.

В чём проблема с подготовкой тестовых данных

В том, что это долго и трудно.

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

Пример связанных данных: пользователь – карта – услуги — статусы

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

А если backend приложения — это десятки автоматизированных систем, каждая из которых является самостоятельным продуктом со своим владельцем? Получается сложная архитектура, которую тем не менее нужно полностью повторить в тестовой среде.

Архитектура со сложным backend

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

Так перед нами встаёт задача подготовки связанных тестовых данных.

Связанные тестовые данные — это не плоская таблица со значениями в ячейках, а состояние целого стенда интеграционно-функционального тестирования (ИФТ) или приёмо-сдаточных испытаний (ПСИ).

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

АС – автоматизированная система. Взаимосвязи АС в тестовом контуре. Результат подготовки тестовых данных на тестовом стенде

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

Мобильное приложение и тестовые пользователи в данном случае — только пример. Вместо них могут быть виды услуг или другие сущности, которые нужно протестировать: тарифы, товарные позиции, услуги, учётные записи и сервисы в интеграционных системах.

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

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

Главный вопрос, который приходится решать продуктовой команде, — как получить реальные данные, если зачастую они относятся к чувствительным и нельзя просто взять и скопировать их в тестовый контур?

Для этого у нас есть два подхода: обезличивание и синтез данных.

Как работаем с обезличиванием: self-service-инструменты

Есть две методики обезличивания:

необратимое (ISO/IEC 29100 anonymization);
обратимое (ISO/IEC 29100 pseudo-anonymization).

У каждой есть свои плюсы и минусы:

Необратимое	Обратимое
+ полная анонимизация	– возможна деанонимизация
+ подходит для dev-сред	+ подходит для dev- и prod-сред
– нарушается распределение данных	+ сохраняется распределение данных
– нарушается корреляция данных	+ сохраняется корреляция данных

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

На самом деле в этом процессе много подводных камней, например:

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

Рассказываем, как мы решаем эти вопросы и проводим обезличивание данных.

Для поддержания целостности данных надо иметь карты взаимосвязей данных для каждой системы. Но в нашем IT-ландшафте создание такой карты — сизифов труд: работа заняла бы больше года, а данные устарели до того, как мы смогли бы воспользоваться картой.

Поэтому решили не делать карту целиком, а вместо неё дать продуктовым командам инструменты самообслуживания (self-service) для получения обезличенных данных.

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

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

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

Пайплайн получения обезличенных данных

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

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

Если тестовые стенды надо регулярно обновлять данными с прома, процедуру легализации и обезличивания можно интегрировать в ETL-процесс.

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

На этот случай у продуктовых команд должны быть скрипты генерации тестовых наборов, связанных данных. И даже в случае нарушения связанности команда всё равно получает ценность в виде больших объёмов обезличенных prod like-данных.

Как работаем с синтезом данных: SyntWork

Для некоторых задач обезличивание как метод не подходит. Например, ни один тип анонимизации не решает задач, связанных с подготовкой данных для обучения ML-моделей во внешних средах. Если, скажем, у «Яндекса» есть достаточное количество данных, на которых мы могли бы обучить наши модели, то он всё равно не может ими поделиться из-за наличия чувствительных данных.

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

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

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

Решить эти вопросы нам помогает SyntWork, который, напомню, входит в состав Platform V Works — семейства инструментов для agile-разработки, командной работы и управления сквозным производственным процессом. Works позволяет выстроить полную архитектуру цикла DevOps, ускорить, упорядочить разработку и заместить зарубежные инструменты производственного процесса.

SyntWork — система генерации и управления синтетическими тестовыми данными. Принцип действия основывается на генерации связанных тестовых данных, описанных как сущности в entity-relationship diagram (ER-диаграмме) или в визуальном интерфейсе. Сущности — это объекты данных в автоматизированных системах. В нашем случае это могут быть: клиент, дебетовая карта, кредит.

Пример связки сущностей на ER-диаграмме

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

Вот как это выглядит. На этапе подготовки к тестированию QA-специалист готовит в визуальном интерфейсе внешнюю по отношению к его продукту среду. Зная нужный набор тестовых данных и состояний систем, ищет нужный шаблон среди готовых, например, «пользователь с банковскими картами X и услугами Y». Шаблоны предустановлены в системе или созданы другими пользователями.

Тестировщик получает набор артефактов по выбранным сущностям и шаблонам — ФИО, номер карты, логин тестового пользователя, затем отслеживает статусы по всем системам и видит, готовы ли они работать с тестовыми данными, чтобы он мог приступить к тестированию функционала.

Ценность такого подхода в том, что специалист не тратит время на подготовку тестовой среды вручную или самодельными скриптами и видит состояние «здоровья» задействованных систем в его тестовых сценариях.

Как устроен SyntWork

Сервис решает следующие задачи:

репозиторий бизнес- и тестовых сценариев, связанных с получением тестовых данных;
переиспользование способов генерации тестовых данных;
снижение трудоёмкости подготовки связных тестовых данных для проведения ИФТ и ПСИ;
упрощение работы QA-специалистов: им необязательно знать, как строить полные цепочки связных данных, осваивать технологии и автоматизацию другой команды или общаться с поставщиками данных;
единый канал обращений пользователей тестовых данных и администраторов тестовых стендов;
мониторинг «здоровья» тестовых сценариев и систем;
тиражирование тестовых сценариев;
подключение модулей обезличивания и синтеза данных по запросу.

Допустим, в компании есть тестовый контур с множеством тестовых АС, имитирующих продуктивную среду. У каждой АС — свой владелец и свои правила взаимодействия со смежными системами.

QA-специалисту регулярно нужны тестовые пользователи с заданным набором метапараметров — подключённые услуги, выданные сертификаты, открытые счета. Все эти услуги и счета создаются в тестовых контурах АС 1 — АС N.

За создание сущностей отвечает архитектор. Он знает, какие вызовы АС 1 — N нужны для создания, например, нового пользователя, и описывает эти действия в виде Job-в в Jenkins. Таким образом сложная последовательность вызовов в тестовом контуре превратилась в запуск Job-а.

Теперь нужно выстроить логику со связанными данными, например, пользователь — счёт 1, счёт N. За формирование этой логики и отвечает SyntWork. Архитектору достаточно занести сущности в модель данных сервиса, и у QA-специалиста будет инструмент для создания связанных тестовых данных в любых объёмах!

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

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

Чтобы подготовить тестовые данные, тестировщику достаточно нажать кнопку в пользовательском интерфейсе и проследить, чтобы процесс подготовки прошёл по плану, а тестовые АС не выдали ошибку. Если что-то пойдёт не так, сбой отобразится в пользовательском интерфейсе, а специалист сможет быстро диагностировать проблему — и это тоже положительно скажется на общем time-to-market.

Наконец, ещё один бонус — тестировщику не нужно придумывать множество фамилий, номеров счетов, телефонов. В SyntWork есть генераторы, которые заполняют поля реалистичными данными, так что в итоговом наборе точно не будет значений вроде «123123» или «qwerty».

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

Есть такой стандарт PCI DSS — Payment Card Industry Data Security Standard. Он касается безопасности индустрии платёжных карт. PCI DSS нужно соблюдать даже по отношению к тестовым пользователям с тестовыми банковскими картами. То есть для того чтобы сгенерить тестовую карту, нужно дать доступ QA-специалисту к защищённому контуру — а это в принципе невозможно.

Тут на помощь приходит SyntWork. Сервис выступает как прокси между системой, соответствующей нормам PCI DSS, и продуктовыми командами. Благодаря инструментарию управления сущностями специалисты, ответственные за безопасность, могут создавать шаблоны и цепочки действий, отвечающие требованиям стандарта. А QA-специалист получает уже артефакты работы этих действий и может оперировать тестовыми банковскими картами, не нарушая защищённого периметра.

Структура сервиса

Давайте разберём, что такое модель данных, которую создаёт архитектор. По сути, это описание последовательности действий АС для создания нужной сущности. Эту последовательность может выполнить любая подходящая среда, например Jenkins, Apache Nifi, Cron или любая другая. Такую среду мы называем executor.

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

В поставку SyntWork входит ядро, в котором есть логика работы с сущностями: возможность создавать модели данных, шаблоны, взаимосвязи данных. Также входит пользовательский интерфейс, executor Apache Nifi и визуальный интерфейс ручного executor-а.

Роли пользователей

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

Пример интерфейса с индикатором прогресса подготовки тестовых данных

Создаёт и изменяет сущности в SyntWork, а также настраивает способы их генерации.

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

Итоги

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

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

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