Привет всем! Меня зовут Аркадий Воронов, старший специалист по качеству. В команде у меня гибридная роль: ручной тестировщик и TestOps. О второй ветке моего развития расскажу подробнее.
В статье будут затронуты темы:
- контекст ИБ: что и зачем мы тестируем;
- основные боли и ограничения,
- инсталляционное и конфигурационное тестирование,
- матрица совместимости,
- инструменты, которые укрощают «зоопарк стендов»,
- путь развития TestOps.
Погружение в контекст
Для начала кратко расскажу о продукте, с которым я работаю. JayData – это решение для поиска, классификации и маскирования конфиденциальной информации в базах данных. С обезличенной копией базы данных можно делать практически все, что угодно: тестировать, использовать в аналитике, в разработке. При этом, если данные попадут в руки к злоумышленникам, то они не смогут ими воспользоваться. Так как данные защищены, мы можем работать в закрытых контурах: без интернета и с соблюдением приказов ФСТЭК – это особенно актуально для финтеха, а также крупных игроков рынка из других отраслей.
Помим�� закрытых контуров и приказов, при разработке и тестировании продукта, наша команда сталкивается с федеральными законами и сертификацией, а именно: законом «О персональных данных» от 27.07.2006 № 152-ФЗ, «Об основах государственного регулирования внешнеторговой деятельности» от 08.12.2003 № 164-ФЗ, сертификацией ФСТЭК и так далее. Эти правовые акты говорят о том, как должны передаваться и обезличиваться персональные, финансовые и другие данные. И это неспроста – около 90% утечек финансовых организаций происходит из тестовых сред.
Jay Data отвечает требованиям регуляторов, защищает персональные данные от утечек с помощью их обезличивания. С замаскированными данными можно работать: аналитике, разработке и, конечно, тестированию. Защищенная информация предотвращает утечки, сохраняет репутацию наших заказчиков и устраняет другие проблемы на финансовых рынках.
Вызовы решений по обезличиванию данных
У решений по обезличиванию есть сразу несколько ключевых вызовов, которые напрямую влияют и на архитектуру продукта, и на подходы к тестированию.
1. Юридический, его мы немного затронули ранее. Решение должно соответствовать требованиям федеральных законов, приказам регуляторов и условиям сертификаций. Одна ошибка может привести к штрафам, которые начинаются от сотен тысяч рублей, а в случае повторных нарушений могут рассчитываться как процент от выручки компании. Поэтому при тестировании важно, как именно продукт работает в рамках регуляторных ограничений.
2. Структурированность. Системы у заказчиков сталкиваются с большими объемами структурированных данных: JSON, XML, таблицы баз данных. Если при маскировании нарушить структуру – на выходе получится набор данных, с которым невозможно работать. Например, если после маскирования даты рождения «01.01.1990», которая превращается в «XX.XX.XXXX», а в связанной колонке «возраст» остается число 36, то такое обезличивание может привести к противоречиям, делает анализ бессмысленным и ломает алгоритмы, которые опираются на взаимосвязи в данных. Задача тестирования – убедиться, что после обезличивания сохраняется формат данных, не ломаются связи между сущностями, данные по-прежнему подходят для аналитики, разработки и тестирования.
3. Еще один важный вызов – объемы баз данных и скорость обезличивания. Клиенты заинтересованы в том, чтобы маскировать большие массивы данных как можно быстрее: это деньги и время. Речь идет не о парочке гигабайтах, а о терабайтах данных, которые должны обрабатываться стабильно, без падений и деградации производительности.
4. Помимо большого объема данных, в каждый момент времени появляются новые записи: система обезличивания должна уметь работать в режиме непрерывной обработки. Поэтому при тестировании отслеживается не только корректность обезличивания, но и поведение продукта под высокой нагрузкой, масштабирование и устойчивость при постоянном обновлении данных.
Инсталляционное тестирование
С чего 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.