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

1916
2

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограниченный доступ

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

Комментарии:

Павел Новиков (Рейтинг: 54) 08:29, 14 марта 2014

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

Сергей Плехов (Рейтинг: 33) 12:30, 25 марта 2014

У меня есть друг, который работает на стройке прорабом. Недавно, он делился со мной последними новостями.
Ему на участок, в качестве рабочей силы, пригнали 20 студентов, отрабатывать практику. Мой друг был в восторге от этого.
- Представляешь, они выкопали траншею обычными лопатами!
- А эвкаватора у вас для этого нет?
- Был, но после этого случая, я от него отказался. Студенты и так справляются. Если так пойдет и дальше, то я и от крана откажусь.
После прочтения этой статьи сразу вспомнился этот разговор.
Для указанных объемов должны использоваться соответствующие технологии: инкрементальные копии, флеш-копии позволят существенно снизить время на копирование, а использование возможностей SAP LVM, позволит создавать клоны по расписанию, без использования людских ресурсов, в течение ~30 минут.
Но, у вашего подхода, тоже есть определенные преимущества. К примеру, при использовании восстановления из бекапа, можно быть уверенными в консистентности создаваемых резервных копий.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»