Будни команды поддержки. Создание тестовых систем

Введение

Не знаю, как в других фирмах, но создание тестовых систем у нас является большой головной болью. Немного цифр для понимания ситуации: размер БД нашей основной системы SAP ERP составляет порядка 6ТБ и рост базы составляет примерно 200 ГБ в месяц. Так что несколько лет назад перед нами встала серьёзная проблема, связанная с создание тестовых систем.

Задачу «беспроблемного» создания тестовых систем мы решали тремя путями:

1. Использование стандартной процедуры копирования продуктивной системы.
2. Создание клонов продуктивной системы.
3. Использование специализированных программных продуктов, в нашем случае TDMS.

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

Стандартная процедура копирования

Несколько лет назад, когда размер продуктивной системы не превышал примерно 3 ТБ, мы пользовались стандартной процедурой копирования системы. Закрывали тестовую систему и примерно за неделю копировали данные из продуктива. Но однажды стало понятно, что за неделю мы не уложимся и начались поиски другого пути решение. Основным критериям для нас было общее время недоступности тестовой системы. Так как в нашей компании постоянно идут проекты, то отключение на долгое время тестовой системы невозможно. Нам максимум согласовывали неделю и то со скрипом.

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

1. Требуется большое количество оборудования, так как, если сервера, на которых «поднимаются» копии систем не очень мощные, то копирование займёт слишком большое время.
2. За время копирования текущая тестовая система, в части разработок, уйдёт от состояния копии системы, и придётся проводить работы по выравниванию.
3. Процедура подмены одной тестовой системы на другую нетривиальна.

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

Создание клонов продуктивной системы

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

В этой технологии можно выделить следующие плюсы:

1. Простота реализации: «поднять» копию продуктивной системы на основе резервной копии – это достаточно рутинная процедура, не требующая особых навыков. Плюсом также является проверка корректности работы подсистемы резервного копирования, т.е. есть большая уверенность, что в случае аварии продуктивной системы, мы сможем легко поднять резервную копию.
2. Высокая скорость работ, по сравнению со стандартной системой копирования мандантов. В нашей компании, по нормативу на создание клона мы отводим 5 календарных дней.
3. Система получается наиболее близкой к продуктивной среде.

Но у этой технологии был выявлен и ряд существенных минусов:

1. Необходимость в дополнительном оборудовании, так как клоны должны где-то работать, и даже большая проблема – это дисковое пространство, так как продуктивная система достаточно большая, то и клоны получаются не маленькие.
2. Сложность интеграционного тестирования. Когда мы поднимаем клон, то да мы получаем копию продуктивной системы и можем на ней тестировать процессы, но только те, которые остаются в рамках этой системы. Не знаю как в других компаниях, но у нас таких процессов немного, большая часть процессов происходит сразу в нескольких системах и в случае с клоном каждый раз возникает вопрос: «С чем интегрировать клон, чтобы тестировать межсистемные процессы?» В итоге получается, что после «подъёма» клона, надо либо перенастраивать на него тестовые сервера от других систем, в этом случае основная тестовая система повисает в воздухе, либо «поднимать» клоны всех остальных систем. Честно сказать, мы ходили обоими этими путями и в любом случае это большие трудозатраты.
3. После того как клон сделан, его очень сложно убить. Так как в процессе тестирования начинается: «а давайте ещё протестируем другие процессы», -  а потом ещё другой проект туда переехал и клоны начинают жить своей жизнью. Приходит другой проект и просит клон для тестирования. Мы говорим: «вот есть существующий клон, берите его», - а они отвечают: «не этот не подойдёт, давайте новый». В худшие времена у нас существовала до 3-х клонов продуктива, честно сказать для отдела интеграции это - ночной кошмар.

Несмотря на все минусы, это основная технология, которую мы сейчас используем. Основная рекомендация – это чётко следить, за целевым назначением клонов систем и как только его цели достигнуты, не допускать его дальнейшего существования, нещадно удалять. Также до создания клона надо продумать модель его интеграции с другими система. Заявления проектной команды, что нам интеграция не нужна, на поверку оказывается не всегда истинным. Чаще всего поднимаем «клон без интеграции», а потом прибегает проектная команда и говорит: «Все хорошо, но половину процессов нельзя тестировать, так как нет интеграции, давайте хоть как-то сделаем интеграцию», - начинается маленький аврал.

Использования