Привет всем! Меня зовут Аркадий Воронов, старший специалист по качеству. В команде у меня гибридная роль: ручной тестировщик и TestOps. О второй ветке моего развития расскажу подробнее.
В статье будут затронуты темы:
контекст ИБ: что и зачем мы тестируем;
основные боли и ограничения,
инсталляционное и конфигурационное тестирование,
матрица совместимости,
инструменты, которые укрощают «зоопарк стендов»,
путь развития TestOps.
Погружение в контекст
Для начала кратко расскажу о продукте, с которым я работаю. JayData — это решение для поиска, классификации и маскирования конфиденциальной информации в базах данных. С обезличенной копией базы данных можно делать практически все, что угодно: тестировать, использовать в аналитике, в разработке. При этом, если данные попадут в руки к злоумышленникам, то они не смогут ими воспользоват��ся. Так как данные защищены, мы можем работать в закрытых контурах: без интернета и с соблюдением приказов ФСТЭК — это особенно актуально для финтеха, а также крупных игроков рынка из других отраслей.
Помимо закрытых контуров и приказов, при разработке и тестировании продукта, наша команда сталкивается с федеральными законами и сертификацией, а именно: законом «О персональных данных» от 27.07.2006 № 152-ФЗ, «Об основах государственного регулирования внешнеторговой деятельности» от 08.12.2003 № 164-ФЗ, сертификацией ФСТЭК и так далее. Эти правовые акты говорят о том, как должны передаваться и обезличиваться персональные, финансовые и другие данные И это неспроста — около 90% утечек финансовых организаций происходит из тестовых сред.
Jay Data отвечает требованиям регуляторов, защищает персональные данные от утечек с помощью их обезличивания. С замаскированными данными можно работать: аналитике, разработке и, конечно, тестированию. Защищенная информация предотвращает утечки, сохраняет репутацию наших заказчиков и устраняет другие проблемы на финансовых рынках.
Вызовы решений по обезличиванию данных
У решений по обезличиванию есть сразу несколько ключевых вызовов, которые напрямую влияют и на архитектуру продукта, и на подходы к тестированию.
Юридический, его мы немного затронули ранее. Решение должно соответствовать требованиям федеральных законов, приказам регуляторов и условиям сертификаций. Одна ошибка может привести к штрафам, которые начинаются от сотен тысяч рублей, а в случае повторных нарушений могут рассчитываться как процент от выручки компании. Поэтому при тестировании важно, как именно продукт работает в рамках регуляторных ограничений.
Структурированность. Системы у заказчиков сталкиваются с большими объемами структурированных данных: JSON, XML, таблицы баз данных. Если при маскировании нарушить структуру – на выходе получится набор данных, с которым невозможно работать. Например, если после маскирования даты рождения «01.01.1990», которая превращается в «XX.XX.XXXX», а в связанной колонке «возраст» остается число 36, то такое обезличивание может привести к противоречиям, делает анализ бессмысленным и ломает алгоритмы, которые опираются на взаимосвязи в данных. Задача тестирования – убедиться, что после обезличивания сохраняется формат данных, не ломаются связи между сущностями, данные по-прежнему подходят для аналитики, разработки и тестирования.
Еще один важный вызов – объемы баз данных и скорость обезличивания. Клиенты заинтересованы в том, чтобы маскировать большие массивы данных как можно быстрее: это деньги и время. Речь идет не о парочке гигабайтах, а о терабайтах данных, которые должны обрабатываться стабильно, без падений и деградации производительности.
Помимо большого объема данных, в каждый момент времени появляются новые записи: система обезличивания должна уметь работать в режиме непрерывной обработки. Поэтому при тестировании отслеживается не только корректность обезличивания, но и поведение продукта под высокой нагрузкой, масштабирование и устойчивость при постоянном ��бновлении данных.
Инсталляционное тестирование
С чего TestOps начинают работу с ИБ-продуктом? С инсталляционного тестирования.
Инсталляционное тестирование проверяет полный жизненный цикл установки продукта в инфраструктуре заказчика. В рамках этого этапа команда тестирования проверяет:
первичную установку системы;
обновление между версиями;
масштабирование компонентов;
корректное удаление системы обезличивания;
восстановление работоспособности после сбоев.
Основная цель инсталляционного тестирования — предотвратить проблемы на этапе эксплуатации. Для бизнеса важно, чтобы продукт запустился и стабильно работал. Это базовый уровень доверия.
TestOps тестирует продукт в условиях, максимально приближенных к тем, в которых он будет работать у заказчика:
операционные системы RedOS и CentOS;
более 10 различных СУБД и их версий;
закрытые контуры без доступа в интернет;
большие объемы данных;
использование SSL / TLS, шифрование, обфусцированный код.
Это жесткие условия, характерные для финтеха, ритейла и других отраслей, с повышенными требованиями к безопасности.
Конфигурационное тестирование
Конфигурационное тестирование начинается параллельно с инсталляционным и проверяет, как система ведет себя в условиях заказчиков. На этом этапе интересна не установка, а устойчивость архитектуры.
Тестировщики проверяют работу продукта в разных вариантах развертывания: all‑in‑one на одном сервере, распределенная установка с несколькими микросервисами — на RedOS и CentOS.
В рамках конфигурационного тестирования оценивается:
горизонтальное и вертикальное масштабирование,
производительность под нагрузкой,
работа с большими базами данных — вплоть до 20 ТБ.
Система д��лжна одинаково стабильно работать как на слабом сервере небольшой компании, так и в инфраструктуре крупного заказчика, где задействуются почти все доступные ресурсы. Цель этого этапа — доказать, что продукт сохраняет стабильность и предсказуемость поведения в любой конфигурации.
В современном бизнесе вокруг каждого клиента накапливается огромное количество данных: что, где и как часто он покупает, какие способы оплаты использует, а также множество других деталей его взаимодействия с системами и сервисами, весь этот объем данных должен быть обезличен.
Отдельное внимание мы уделяем логам. И это не случайно — мы уже «садились в лужу» из‑за путанницы в логировании. Настройка в продукте очень гибкая: уровень логирования, путь, имя файлов, размер, общий лимит и ротация.
Команда тестирования использует горизонтальное масштабирование и распределенную архитектуру (вертикальное масштабирование) с параллельной обработкой таблиц и партиций, балансировкой нагрузки и максимальной утилизацией ресурсов кластера.
Результат, которым команда гордится, — линейный рост производительности, высокая отказоустойчивость и возможность маскировать 20 Тб данных за часы, а не дни.
Для кого мы тестируем?
В ИБ‑продуктах заказчик и пользователь — не всегда один и тот же человек. Офицер деперсонализации данных (DPO) инициирует покупку, решение часто принимается на уровне руководства, а эксплуатация начинается с системного администратора.
Схема выглядит так: DPO — руководство — администратор — продукт. И если на этапе установки у администратора возникают проблемы, продукт просто не доживает до эксплуатации. Бизнесу предложат найти другое решение.
Именно поэтому команда тестирует не только функциональность, но и путь продукта до пользователя. Мы пишем и проверяем подробные инструкции для администраторов, тестируем установку и сопровождение в условиях, максимально приближенных к реальным.
Моя гибридная роль находится на этом стыке: я работаю с разработкой, DevOps и тестированием, чтобы переход от покупки продукта к его использованию был максимально эффективным.
По сути, являюсь связующим звеном между продуктом и инфраструктурой заказчика. Как ручной тестировщик, я глубоко погружен в среды эксплуатации и проверяю весь жизненный цикл решения: от установки и масштабирования до обновления и корректного удаления. Работаю с RedOS и CentOS, тестирую продукт в тех условиях, в которых с ним столкнется администратор.
Моя задача: сделать так, чтобы установка продукта проходила без сюрпризов — ни для админа, ни для бизнеса.
Полигоны и матрица совместимости
Вся инфраструктура тестирования — это большой тестовый полигон, который должен покрывать максимум сценариев, с которыми продукт может столкнуться у клиентов. Одна группа стендов — у каждой один смысл и своя задача:
DEV — стенды для разработки и отладки, в которых инженеры пишут, тестируют и дорабатывают код в изолированной среде.
TEST — стенд для функционального тестирования. На них QA‑инженеры вручную проверяют корректность работы функций и сценариев.
Auto QA — стенд для автоматизированного регрессионного тестирования: запускаются автоматические тесты, чтобы быстро выявлять регрессии после изменений.
HL / LT — стенды для нагрузочного (High Load) и стресс‑тестирования (Load Testing) проверяют, как система ведет себя под высокой нагрузкой и в экстремальных условия, в том числе, используем HTOP на мастер‑узле, чтобы в реальном времени контролировать использование ресурсов во время тестов.
DevOps / QA — стенд для проверки установки, обновлений и общей инфраструктурной надежности тестирует процессы развертывания, масштабирования, восстановления и взаимодействия компонентов инфраструктуры.
Система сама по себе сложная, тестировщики сознательно не ограничиваются одной идеальной конфигурацией. Мы работаем более чем с 10 видами СУБД и их версиями, которые используются у клиентов. У одного заказчика это может быть PostgreSQL, у другого — Oracle 11g, от которого бизнес не готов отказываться. В будущем планируется поддерживать дополнительный дистрибутив — ALT Linux .
В работе используются:
СУБД: Oracle, MS SQL, PostgreSQL, HANA, QDB, ClickHouse;
ОС: RedOS, CentOS;
устаревшие версии: Oracle 11g, MS SQL 2008;
TLS‑подключения: PostgreSQL, HANA.
Когда появляется новый клиент, команда заранее проверяет его конфигурацию: поддерживается ли конкретная версия ОС и СУБД, нет ли скрытых ограничений. Это позволяет приходить на пилот с пониманием, что продукт будет стабильно работать в реальной инфраструктуре.
Укрощаем зоопарк стендов!
При таком количестве конфигураций важно управлять не стендами, а процессами. Именно поэтому у команды тестирования Jay Data выстроен единый и воспроизводимый подход к инфраструктуре, который, к тому же, работает в закрытом контуре.
Ansible — это основа, это, так сказать, база — инструмент развертывания, и живая документация: роли описывают не только установку продукта, но и всю сопутствующую инфраструктуру — мониторинг, логи, шифрование. Все это разворачивается одинаково на разных дистрибутивах и работает в закрытом контуре.
GitLab CI/CD отвечает за автоматическую линию сборки. Код, автотесты и документация хранятся в одном месте, а nightly build позволяет каждую ночь прогонять регрессию и находить проблемы до того, как их увидит пользователь. Утром ручные тестировщики получают готовые отчеты и рабочие среды по запросу.
Путь становления TestOps
Переход от ручного тестирования к инсталляционному и конфигурационному — логичный и востребованный путь развития. Тестировщик перестает быть обычным проверяльщиком качества и начинает создавать условия для тестирования.
Для полноценной работы с TestOps, нужно уверенное владение Linux: погружение в процессы, знание прав и умение читать логи. Мониторинг и анализ нагрузки тоже стал неотъемлемой частью инсталляционного и конфигурационного тестирования — ELK‑стек и Grafana должны быть вашими закадычными друзьями. Вы также должны быть на «ты» с автоматизацией и CI/CD, к тому же разбираться в контейнеризации и Docker. Большая часть навыков включает путь развития в DevOps, но как тестировщику вам нужно разбираться в вопросах безопасности и отказоустойчивости, знать нагрузочное и стресс‑тестирование. Софты также не помешают: аналитические и коммуникационные навыки must have в этой сфере.
Важный принцип: не просто тестируй, а создавай условия, в которых продукт можно надежно использовать.
А если вы только планируете начать путь тестировщика и хотите попробовать себя в тестировании нашего продукта Jay Data, присоединяйтесь к telegram-каналу CrossUp.
