Наводим мосты между Dev и Ops

 Чаще всего среда тестирования больше, чем просто виртуальный сервер: 

• Несколько виртуальных машин. А как же серверы приложений, менеджеры очередей, балансировщики нагрузки, серверы БД, веб-серверы?
• Процесс развертывания прикладного ПО. Корпоративные системы далеко не так просты в установке, как хотелось бы.
• Тестовый набор данных — обезличенный, ограниченный по глубине хранимой информации, иначе тестовые отчеты будут выполняться слишком долго.
• Хотя бы минимальная документация. А что, ваш отдел информационной безопасности разрешает бесконтрольно создавать серверы и заливать туда данные из промышленных систем?

Согласитесь, услуга по развертыванию виртуалки, скорее всего, не будет «бутылочным горлышком», замедляющим весь процесс тестирования. И ее автоматизация не ускорит процесс выведения новых возможностей ПО в продуктив. По нашему опыту, непосредственно работы по настройке оборудования занимают не более 15% времени при создании тестовой среды. Его большая часть уходит на проведение миграции данных, развертывание ППО и интеграцию со смежными системами. Поэтому мы считаем, что при построении частных облаков стоит включать в каталог услуги по созданию сред бизнес-приложений, а не только элементы виртуальной инфраструктуры. Какие преимущества это может дать?

Эффективность использования тес­товых сред. Ресурсы существующих сред больше не будут простаивать, а новые среды станут создаваться по мере необходимости. У разработчиков больше не будет резона резервировать среды «впрок». А админы точно будут знать, чья это среда и нужна ли она.

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

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

Много времени на развертывание занимают согласование и документирование. Казалось бы, техническими средствами это сложно исправить. Но так как автоматически разворачиваемые среды полнос­тью унифицированы, их согласование может выполняться в упрощенном порядке. Теперь поговорим о технических средствах, которые могут все это автоматизировать. И главный инструмент — оркестратор. Это программный продукт для автоматизации управления сразу многими элементами ИТ-инфраструктуры. Таким образом, основной его характеристикой можно считать возможность гибкого управления как можно большим числом таких элементов, как серверы, виртуальные машины, системы хранения, сеть, терминальные сервисы, службы каталогов и пр. Существуют как решения от известных производителей ПО управления (BMC, Microfocus, IBM, Microsoft), так и продукты на свободном ПО (Red Hat, Cloudify и др). Выбор непрост. 

По нашему опыту, нужно обратить внимание на следующие возможности ПО:

• есть ли необходимые модули или компоненты по автоматизации нужного оборудования и ПО;
• соответствует ли оно требованиям ИБ (например, безопасное хранение паролей управляемых сис­тем);
• каковы средства управления жизненным циклом создаваемых сред и возможности по настройке ролевой модели;
• возможна ли необходимая настройка графического интерфейса портала и средств отчетности;
• есть ли возможность интеграции с публичными облаками.

О последнем пункте стоит поговорить отдельно. С одной стороны, большинство компаний на сегодняшний день с опаской смотрят на публичные облака. Сможет ли провайдер облака обес­печить необходимую доступность? Что делать, если что-то сломается? Как обезопасить данные? Все эти вопросы действительно важны, и маловероятно, что прямо завтра бизнес-критичные системы будут массово переноситься в облака. Но критичность сред разработки и тестирования ниже, а частота изменений в них выше. Это ли не идеальный кандидат на миграцию? Таким образом, возможность управлять ресурсами пуб­личного и частного облаков из одного средства автоматизации станет критичной в самом ближайшем будущем. А это уже гибридное облако.

Вычислительные ресурсы внешнего облачного провайдера представляются в оркестраторе как среда виртуализации, аналогичная по возможностям локальным виртуальным инфраструктурам, таким как VMware vSphere или Microsoft Hyper-V. Интеграция с ними не сложнее, чем настройка управления локальной фермой. Более сложной является задача обеспечить прозрачную миграцию приложений из частного облака в публичное и обратно. Например, если требуется временно расширить имеющиеся вычислительные ресурсы за счет внешних. Здесь многое будет зависеть как от архитектуры приложений, так и от инфраструктуры. Используется ли микросервисная архитектура или речь идет о монолитном приложении? Насколько интенсивен обмен данными между различными модулями приложения? Что за данные обрабатываются и каковы требования по их защите? Как обеспечить сетевую связность между облаками? Наверное, это тема для отдельной статьи. Что стоит подчеркнуть, так это то, что автоматизация и оркестрация ИТ-инфраструктуры в гибридных средах — одна из четырех основных технологических тенденций этого года и последующих лет (Gartner, 2019 Planning Guide Overview: Architecting Your Digital Ecosystem).

Кстати, к выбору средства автоматизации нужно привлечь не только ИТ-специалистов, но и разработчиков. Ведь в их руках имеются инструменты CI/CD1 — например, Jenkins или Gitlab, которые могут быть использованы как средства автоматизации. В частности, с помощью плагинов Jenkins может управлять созданием виртуальных машин. Если же средств автоматизации, имеющихся в инструментах CI/CD, окажется недостаточно, то обратите внимание на возможность интеграции выбранного оркестратора с ними. Ведь следующим шагом после автоматизации развертывания среды будет ее включение в конвейер разработки и тестирования.

Но создание отдельной среды, например для тестирования, — это только полдела. Часто бывает так, что разрабатываемое приложение само по себе, без окружения, не может полноценно функционировать. Ему нужно получать данные из одних смежных систем и передавать их в другие. Окружение приложения может включать справочники, шины данных, средства ETL, какие-либо шлюзы, службу каталогов и т.п. А раз без них приложение не может функционировать, то и качественно протестировать его не получится — набор возможных проверок очень ограничен. Решение: тестовая среда должна включать не только само приложение, но и некий минимальный набор смежных систем. И тогда это будет уже не среда, а полноценный тестовый полигон. Его создание выходит за рамки CI/CD, но может быть успешно обеспечено возможностями частного облака и его средствами автоматизации/оркестрации.