В условиях растущей сложности программных продуктов и требований к их качеству особую значимость приобретает построение гибкой и повторяемой инфраструктуры для тестирования. Современные технологии виртуализации позволяют эффективно использовать вычислительные ресурсы, упрощать сопровождение стендов и ускорять подготовку окружений. Одним из ключевых элементов такой инфраструктуры становятся виртуальные машины, развёртываемые в заданной конфигурации для проведения испытаний и отладки.

В процессе разработки и тестирования программных продуктов компании требуется регулярное развертывание виртуальных стендов, включающих один или несколько VPN-клиентов, настроенных в строго определённой конфигурации. Такая необходимость возникает при:

— проверке новых версий ПО;

— воспроизведении багов;

— регрессионном тестировании;

— демонстрации функциональности клиентам.

Выполнение этих действий вручную требует значительных временных и трудовых ресурсов, особенно при необходимости частого повторного развёртывания. Операторам приходится:

— вручную создавать виртуальные машины;

— импортировать шаблоны;

— настраивать виртуальное оборудование и сети;

— контролировать запуск и выключение ВМ;

— управлять снапшотами и экспортом;

— удалять каждый элемент виртуальной системы по отдельности после окончания работ.

Все эти процессы не только рутинные и однотипные, но и подвержены человеческому фактору. Из-за этого снижается повторяемость стендов, что значительно затрудняет отладку и командную работу. Кроме того, ошибки при удалении компонентов могут привести к засорению хранилища и неэффективному использованию вычислительных ресурсов.

В связи с этим была поставлена задача на создание специализированного программного модуля, который позволяет упростить и ускорить развёртывание виртуальных стендов. Такой модуль должен обеспечивать взаимодействие с сервером vCenter, автоматическую настройку параметров виртуальных машин и виртуальных сетей, а также поддержку загрузки конфигурации из внешнего файла. Разработка подобного решения является актуальной для предприятий, регулярно работающих с тестовыми или демонстрационными средами, особенно в области информационной безопасности и сетевой инфраструктуры.

В рамках данного исследования рассматривается задача развертывания виртуальных машин с установленными VPN-клиентами и их окружения на базе гипервизора VMware ESXi.

VMware ESXi [12] — это гипервизор, предоставляющий высокую производительность и надёжность. Он предназначен для развертывания и управления виртуализованными вычислительными средами. Одной из его ключевых функций является полное управление жизненным циклом виртуальных машин: администраторы могут создавать, конфигурировать, запускать, приостанавливать, выключать и удалять виртуальные машины (ВМ). Оператор может гибко выбирать конфигурацию виртуального оборудования: количество виртуальных процессоров, объём оперативной памяти, тип и размер виртуальных дисков, параметры сетевых интерфейсов и другие характеристики могут быть заданы индивидуально для каждой ВМ.

Важной областью применения ESXi является организация виртуальных сетей. Платформа позволяет создавать виртуальные коммутаторы (vSwitch), которые обеспечивают сетевое взаимодействие между ВМ, а также между ВМ и внешними физическими сетями. Поддерживаются механизмы изоляции трафика с помощью VLAN, привязка виртуальных интерфейсов к различным сетевым сегментам, установка правил безопасности (например, запрет на подделку MAC-адресов или включение фильтрации пакетов). Это позволяет реализовывать сложные схемы маршрутизации и безопасного обмена данными в рамках виртуальной инфраструктуры.

Таким образом, VMware ESXi предоставляет мощный и гибкий инструментарий для построения надёжной, масштабируемой и управляемой виртуальной инфраструктуры, что позволяет эффективно использовать его в инфраструктурах, требующих стандартизированного развёртывания ВМ, как, например, при тестировании программного обеспечения.

Однако по мере роста количества хостов ESXi и виртуальных машин в инфраструктуре необходимость в централизованном управлении становится всё более актуальной. Для этих целей используется специализированный программный продукт VMware vCenter Server Appliance (vCSA) — важный компонент экосистемы VMware, обеспечивающий комплексное администрирование всей виртуальной среды.

Одним из ключевых преимуществ vCSA является поддержка современных интерфейсов программного управления (включая vSphere Web Services API и vSphere REST API), что позволяет интегрировать его в автоматизированные решения и внешние системы, включая разработанный программный модуль. Благодаря этому vCSA играет центральную роль в сценариях автоматизации развёртывания, мониторинга и сопровождения виртуальных стендов.

Решения VMware, включая ESXi и vCenter, входят в состав платформы виртуализации VMware vSphere — интегрированного комплекса продуктов и технологий для создания и управления виртуализированной ИТ-инфраструктурой. vSphere обеспечивает полный стек инструментов, необходимых для развёртывания, мониторинга и масштабирования вычислительных ресурсов, а также для автоматизации задач, связанных с виртуальными машинами и хостами.

С целью определения оптимального подхода к оптимизации процесса развертывания виртуальных стендов был проведён анализ существующих решений, применяемых в индустрии. Рассматривались как универсальные системы управления инфраструктурой, так и специализированные инструменты, ориентированные на работу с виртуализацией. При анализе учитывались такие критерии, как поддержка VMware vSphere, гибкость настройки, требования к инфраструктуре, удобство интеграции и масштабируемость.

В таблице 1 приведена сводная оценка рассмотренных программных решений и разработанный программный модуль (сокращённо: ПМ ОРВК) по ряду критериев.

Таблица 1

Обзор аналогичных программных решений

Условные обозначения:

+ — указанная возможность присутствует;

— — указанная возможность отсутствует;

+/- — указанная возможность реализована частично.

Таким образом, разработка собственного модуля позволяет устранить ключевые недостатки аналогов, предоставив инструмент, специально адаптированный под инфраструктуру компании, с простым способом задания конфигурации и полной интеграцией с API vCenter.

Концептуальная модель, представленная на рисунке 1, отражает взаимодействие основных компонентов, участвующих в процессе развёртывания виртуализированных VPN-клиентов. В состав модели входят следующие сущности: пользователь, программный модуль, сервер vCenter и сервер ESXi.

Рис. 1 Концептуальная модель ПМ ОРВК

Пользователь инициирует процесс развёртывания путём запуска программного модуля и передачи ему конфигурационного файла, содержащего параметры будущего стенда. Программный модуль анализирует входные данные, валидирует их и формирует соответствующие запросы к серверу vCenter с использованием официального API VMware.

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

Сервер ESXi, в свою очередь, отвечает за физическое развёртывание компонентов стенда — он создаёт виртуальные машины, подключает их к необходимым виртуальным сетям, назначает ресурсы и выполняет действия, описанные в переданной конфигурации. Результатом работы является полностью подготовленный стенд, готовый к последующей настройке VPN-клиентов другим программным модулем.

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

Для разработки ПМ ОРВК требовался язык программирования, обеспечивающий удобную работу с технологиями VMware vSphere через соответствующий SDK, а также допускающий использование разработанного решения в виде подключаемого модуля или библиотеки. Важными критериями стали наличие встроенных средств для обработки JSON-файлов, кроссплатформенность (возможность запуска без изменений на Windows и Linux) и динамическая типизация, упрощающая работу с переменными. Дополнительным преимуществом считалось наличие среды исполнения в большинстве дистрибутивов Linux по умолчанию.

В таблице 2 приведён сравнительный анализ некоторых языков по указанным ранее параметрам.

Таблица 2

Сравнение языков программирования

Условные обозначения:

+ — указанная возможность присутствует;

— — указанная возможность отсутствует.

Из всех рассмотренных языков наиболее удобными для решения поставленной задачи являются Python и Go, так как они имеют официальные библиотеки для vSphere, нативные средства работы с JSON и удобную кроссплатформенность. PowerShell подходит для использования в среде Windows, но ограничен по производительности. C++ и Rust обладают высокой эффективностью, но требуют значительных усилий для интеграции с vSphere. Java является компромиссным вариантом, но её статическая типизация может усложнить разработку.

Между Python и Go был выбран Python, поскольку разработка на Go потребовала бы больших усилий. Единственное преимущество Go — высокая производительность, но в данном случае она избыточна, так как основная нагрузка ложится на сам стек vSphere, а ПМ ОРВК выполняет лишь управленческие функции.

Для разработки программного модуля были рассмотрены несколько сред, подходящих для работы с языком Python. Основные критерии выбора включали наличие открытого исходного кода, поддержку отладки, инструментов рефакторинга и линтеров. Также были приняты во внимание необязательные, но значительно упрощающие работу. К ним относятся встроенная поддержка системы контроля версий Git и автодополнения.

В таблице 3 приведено сравнение наиболее популярных сред разработки по данным критериям.

Таблица 3

Сравнение сред разработки

Условные обозначения:

+ — указанная возможность присутствует;

— — указанная возможность отсутствует.

В результате проведённого анализа можно сделать вывод, что наибольшее количество преимуществ имеет Visual Studio Code. Эта среда сочетает лёгкость, расширяемость и поддержку всех необходимых функций: отладки, автодополнения кода, инструментов рефакторинга, интеграции с системой контроля версий и линтеров. Кроме того, VS Code является полностью бесплатным и открытым решением, доступным для Windows, Linux и macOS.

Альтернативой может служить PyCharm, особенно в коммерческой версии, обладающей развитой функциональностью. Однако её бесплатная версия ограничена по возможностям, а полная — требует лицензирования. Остальные среды — Thonny, Spyder, Wing и IDLE — уступают по нескольким критериям: либо по качеству отладки и расширяемости, либо по поддержке современных инструментов разработки.

Для автоматизации процессов развертывания и управления виртуальными машинами на базе VMware vSphere был разработан алгоритм, обеспечивающий выполнение всех ключевых функций модуля. Схема алгоритма представлена на рисунке 2. Алгоритм охватывает операции создания, управления и удаления виртуальных машин, а также их экспорта и импорта.

ПМ ОРВК начинает свою работу со считывания аргументов, переданных ему при вызове. Параметр «action» указывает программному модулю, что ему нужно сделать.

Есть 11 возможных вариантов хода программы. Их можно условно разделить на 4 группы:

— управление стендом (создание, удаление);

— управление ВМ (запуск, отключение, создание снапшота);

— работа с шаблонами (импорт OVA/OVF-образов, экспорт образов);

— прочее (пересоздание ВМ, проверка существования ВМ, вывод MAC-адресов).

Рис. 2. Схема алгоритма ПМ ОРВК

Все эти группы, кроме последней, вынесены в отдельные подпрограммы и представлены на рисунках 3, 4 и 5.

Подпрограмма управления стендом включает в себя функции создания и удаления стенда. Схема алгоритма подпрограммы представлена на рисунке 3. Сначала происходит считывание данных из JSON-файла и их валидация, после чего управление передаётся подпрограммам развёртывания или удаления стенда, схемы которых представлены на рисунках 7 и 8 соответственно.

Рис. 3. Схема алгоритма подпрограммы управления стендом

Подпрограмма управления ВМ, представленная на рисунке 4, включает в себя функции запуска, отключения и создания снапшота. Запуск и отключение происходят по схожему принципу: ПМ ОРВК подключается к vSphere, ищет ВМ по названию и запускает или отключает её.

Рис. 4. Схема алгоритма подпрограммы управления ВМ

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

На рисунке 5 представлена подпрограмма работы с шаблонами, она включает в себя операции импорта и экспорта виртуальных машин в виде OVA- и OVF-образов.

Рис. 5. Схема алгоритма подпрограммы работы с шаблонами

На рисунке 6 представлена подпрограмма пересоздания виртуальной машины. Этот процесс происходит пошагово:

— сначала проверяется, что для подключения ВМ к стенду есть все необходимые коммутаторы;

— далее удаляется старая виртуальная машина;

— затем вместо неё создаётся новая из шаблона.

На любом из этих шагов программа может остановиться, если в процессе возникнет ошибка.

Рис. 6. Схема алгоритма подпрограммы пересоздания ВМ

Подпрограмма развёртывания стенда, представленная на рисунке 7, отражает одну из основных функций ПМ ОРВК. Для того, чтобы можно было удобно распознавать, какой объект к какому стенду относится, генерируется GUID. В процессе этот идентификатор будет приписан к каждому созданному элементу. Развёртывание начинается с определения и создания необходимых для работы коммутаторов. На каждом коммутаторе создаётся порт-группа, к которой в дальнейшем будут подключены виртуальные машины. Затем создаются и подключаются сами ВМ.

Рис. 7. Схема алгоритма подпрограммы разворачивания стенда

На рисунке 8 представлена подпрограмма удаления стенда. Она находит все элементы, принадлежавшие стенду, и удаляет их. При том не важно, является ли стенд целым, программа всё равно корректно распознает нужные элементы по GUID и удалит их.

Рис. 8. Схема алгоритма подпрограммы удаления стенда

Наиболее целесообразными методами тестирования для разрабатываемого программного модуля являются модульное и функциональное тестирование, а также элементы тестирования «чёрного ящика». Это позволяет добиться высокой надёжности без избыточного дублирования функциональности сторонних библиотек.

Модульное тестирование проводилось с целью изолированной проверки отдельных компонентов программного модуля, отвечающих за обработку входных данных, выбор сценария выполнения и взаимодействие с внешней библиотекой pyVmomi. Учитывая архитектуру решения и активное использование API VMware, основная часть логики реализована на уровне обработки параметров, а вызовы к внешним системам выполняются через готовую обёртку, что делает модульное тестирование основным инструментом проверки корректности работы.

Для написания тестов использовался фреймворк pytest, обеспечивающий удобную структуру и высокую читаемость кода тестов. Вместо реальных обращений к API применялась библиотека pytest-mock, позволяющая создавать mock-объекты и подменять поведение вызовов к pyVmomi. Это позволило изолировать тестируемые участки от инфраструктурных зависимостей и сфокусироваться на логике самого модуля.

В ходе тестирования были проверены:

— корректность разбора и валидации JSON-конфигураций;

— выбор соответствующего сценария работы модуля на основе аргументов командной строки;

— устойчивость к ошибкам ввода и отсутствию параметров;

— логика обработки исключений;

— структура формируемых запросов к API;

— корректная генерация логов и сообщений об ошибках.

Для оценки покрытия кода тестами применялось расширение pytest-cov, позволяющее контролировать полноту тестирования отдельных функций и блоков программы. Это обеспечило количественную оценку охвата и помогло выявить недостаточно проверенные участки кода.

Модульные тесты запускались локально, без подключения к серверу vCenter, что обеспечило высокую скорость выполнения и воспроизводимость результатов. Такой подход позволил проводить итеративную разработку и выявлять ошибки на ранних этапах, до интеграции с инфраструктурой.

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

Для количественной оценки полноты тестирования было выполнено измерение покрытия кода с использованием инструмента pytest-cov. Результаты оценки покрытия можно увидеть на рисунке 9.

Рис. 9. Отчёт о покрытии кода

В ходе модульного тестирования программного модуля были проверены все ключевые функции, реализующие основные сценарии работы: развёртывание и удаление стенда, пересоздание виртуальных машин, управление их состоянием, создание снапшотов, импорт образов, а также получение MAC-адресов и экспорт. Для тестирования использовались библиотеки pytest, pytest-mock и pytest-cov, что обеспечило удобную организацию тестов и отслеживание покрытия кода.

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

Согласно отчёту о покрытии, уровень покрытия кода тестами составил 96.54 %, что свидетельствует о высоком качестве тестирования. Это значение подтверждает, что практически все участки кода были проверены, а логика функционирования модуля протестирована на достаточном уровне для дальнейшего использования и сопровождения.

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

Тестовая среда для функционального тестирования была развёрнута в изолированной лабораторной инфраструктуре. Она включала в себя следующие компоненты:

— хостовая машина с Windows, на которой установлен VMware Workstation;

— виртуальная машина с установленным гипервизором VMware ESXi;

— виртуальная машина с установленным vCenter Server Appliance (vCSA), работающая поверх ESXi;

— настроенное сетевое подключение (режим bridged), обеспечивающее доступ к ESXi и vCSA по отдельным IP-адресам;

— консольный Python-модуль, запущенный на хостовой Windows-машине, взаимодействующий с API vCenter через pyVmomi.

Такое развертывание имитирует рабочую инфраструктуру и позволяет протестировать поведение модуля в условиях, приближённых к эксплуатационным: с созданием реальных виртуальных машин, настройкой сетей, взаимодействием с API и обработкой всех этапов развёртывания.

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

Дополнительно к модульному и функциональному тестированию было проведено ручное тестирование методом «чёрного ящика» с привлечением третьих лиц. Это позволило оценить поведение исключительно с точки зрения внешнего интерфейса и документации.

Тестирование заключалось в пошаговом выполнении ключевых сценариев — развёртывания, удаления, пересоздания и управления виртуальными машинами — с использованием подготовленного JSON-файла конфигурации и CLI-интерфейса модуля.

В ходе проверки были выявлены некоторые недостатки, касаемые сообщений об ошибках и информационных сообщений, а также были даны некоторые рекомендации, касаемые удобства использования ПМ ОРВК.

Проведение ручного тестирования позволило выявить проблемы, которые не всегда можно обнаружить средствами автоматизированного тестирования, и повысить удобство и надёжность использования модуля конечным оператором.

Были приведены испытания, направленные на подтверждение достижения основной цели разработки — сокращения ресурсозатрат при организации тестирования программных продуктов. Для этого была выполнена оценка эффективности использования программного модуля в условиях, приближенных к реальной эксплуатации.

В качестве ключевых показателей эффективности были выбраны:

— общее время, затрачиваемое на развёртывание и удаление виртуального стенда;

— количество ручных действий, необходимых оператору для выполнения этих операций.

Снижение этих параметров напрямую свидетельствует о сокращении времени, трудоёмкости и вероятности ошибок, возникающих при повторяющихся рутинных действиях. Сравнительный анализ был выполнен между традиционным ручным способом через интерфейс vSphere Client и использованием разработанного программного модуля.

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

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

Результаты представлены в таблице 4.

Таблица 4

Сравнение времени выполнения операций

В ручном режиме оператору требовалось выполнить последовательность однотипных действий в интерфейсе vSphere Client, включая выбор шаблона, настройку параметров ВМ, подключение сетевых интерфейсов, запуск машин и подтверждение удаления каждой из них. Все этапы сопровождались визуальной проверкой и ожиданием загрузки интерфейса.

В автоматизированном режиме все параметры задавались один раз в конфигурационном JSON-файле. Для запуска достаточно одной CLI-команды, после чего развёртывание выполняется программным модулем без участия пользователя.

Вывод: ПМ ОРВК сокращает среднее время развёртывания стенда более чем в 2,5 раза, а время удаления — более чем в 7 раз. Это обеспечивает значительное повышение эффективности работы и способствует достижению основной цели разработки — сокращению ресурсозатрат при организации тестирования.

Одним из показателей снижения ресурсозатрат, наряду со временем, является количество ручных действий, необходимых оператору для выполнения стандартных операций. Многоступенчатый процесс ручного развёртывания тестового стенда включает последовательное создание и настройку виртуальных машин, что требует значительного количества операций в графическом интерфейсе vSphere Client.

С целью количественной оценки был проведён сравнительный анализ числа действий (в основном — кликов мышью и форм ввода), необходимых для выполнения типового сценария развёртывания и удаления стенда, состоящего из двух виртуальных машин, каждая из которых подключена к двум сетям.

Результаты представлены в таблице 5.

Таблица 5

Количество действий при различных способах управления стендом

Развёртывание вручную включает следующие этапы:

— Импорт шаблона ВМ;

— Ввод имени;

— Назначение ресурсов (пул, хост);

— Настройка оборудования;

— Добавление сетевых адаптеров;

— Назначение каждой сети;

— Подтверждение и запуск развёртывания — отдельно для каждой ВМ.

Удаление вручную требует:

— Поиск каждой ВМ;

— Завершение работы;

— Удаление ВМ и связанных ресурсов;

— Повторение для каждой машины.

В случае с программным модулем все параметры задаются заранее в JSON-файле, после чего выполняется единственная команда CLI-интерфейса.

Вывод: использование программного модуля позволяет снизить количество действий более чем в 40 раз, что значительно снижает вероятность ошибок, связанных с человеческим фактором (например, выбор неверной сети, неполное удаление ресурсов, повторное задание уже использованных имён и т. д.).

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

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

Результатом выполнения работы является рабочий программный модуль для оперативного развёртывания виртуализированных VPN-клиентов. По результатам производственного тестирования цель снижения ресурсозатрат при организации тестирования продуктов компании достигнута.

Литература:

1. Гайдук И. О., Касимов Р. А., Кононова А. И., Федоров А. Р., Федотова Е. Л. Методические указания по подготовке выпускной квалификационной работы по направлению подготовки бакалавров 09.03.04 «Программная инженерия» / под ред. Л. Г. Гагариной. М.: МИЭТ, 2024. 36 с.
2. ГОСТ 19781–90. Обеспечение систем обработки информации программное. Термины и определения. Введ. 01.01.1992. М.: Стандартинформ, 2010. 14 с.
3. ГОСТ 19.401–78. Единая система программной документации. Текст программы. Требования к содержанию и оформлению. Введ. 01.01.1980. М.: Стандарт информ, 2010. 2 с.
4. ГОСТ 19.701–90 (ИСО 5807–85). Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения. Введ. 01.01.1992. М.: Стандартинформ, 2010. 24 с.
5. ГОСТ 7.89–2005. Система стандартов по информации, библиотечному и издательскому делу. Оригиналы текстовые авторские и издательские. Общие требования. Введ. 01.07.2006. М.: Стандартинформ, 2006. 18 с.
6. ГОСТ Р 7.0.5–2008. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления. Введ. 01.01.2009. М.: Стандартинформ, 2020. 24 с.
7. ГОСТ 15971–90. Системы обработки информации. Термины и определения. Введ. 01.01.1992. М.: Изд-во стандартов, 1991. 14 с.
8. ГОСТ 19.101–2024 Единая система программной документации. Виды программ и программных документов
9. ГОСТ 19.001–77 Единая система программной документации. Общие положения
10. Олифер В., Олифер Н. Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание. — СПб.: Питер, 2021. — 1008 с.: ил.
11. Шаньгин В. Ф. Защита информации в компьютерных системах и сетях. / В. Ф. Шаньгин, Москва: ДМК Пресс, 2012. — 592 с.: ил.
12. developer.broadcom.com [Электронный ресурс] VMware vSphere API Reference Documentation URL: https://developer.broadcom.com/xapis/vsphere-web-services-api/latest/ (дата посещения: 14.12.2024)
13. docs.morpheusdata.com [Электронный ресурс] Morpheus v8.0.0 Documentation URL: https://docs.morpheusdata.com/en/latest/ (дата посещения: 25.01.2025)
14. developer.hashicorp.com [Электронный ресурс] Vagrant Documentation URL: https://developer.hashicorp.com/vagrant/docs (дата посещения: 25.01.2025)
15. developer.hashicorp.com [Электронный ресурс] Terraform Documentation URL: https://developer.hashicorp.com/terraform/docs (дата посещения: 26.01.2025)
16. docs.cloudbolt.io [Электронный ресурс] CloudBolt Software Docs URL: https://docs.cloudbolt.io/home/en-us/ (дата посещения: 2.02.2025)
17. docs.python.org [Электронный ресурс] Python 3.11.11 documentation URL: https://docs.python.org/3.11/ (дата посещения: 8.02.2025)
18. go.dev [Электронный ресурс] Documentation URL: https://go.dev/doc/ (дата посещения: 8.02.2025)
19. docs.oracle.com [Электронный ресурс] Help Center URL: https://docs.oracle.com/en/ (дата посещения: 8.02.2025)
20. learn.microsoft.com [Электронный ресурс] Документация по PowerShell URL: https://learn.microsoft.com/ru-ru/powershell/ (дата посещения: 8.02.2025)
21. en.cppreference.com [Электронный ресурс] C++ reference URL: https://en.cppreference.com/w/ (дата посещения: 8.02.2025)
22. doc.rust-lang.org [Электронный ресурс] The Rust Programming Language URL: https://doc.rust-lang.org/book/ (дата посещения: 8.02.2025)
23. code.visualstudio.com [Электронный ресурс] Visual Studio Code documentation URL: https://code.visualstudio.com/docs (дата посещения: 9.02.2025)
24. www.jetbrains.com [Электронный ресурс] Getting started URL: https://www.jetbrains.com/help/pycharm/ (дата посещения: 9.02.2025)
25. github.com [Электронный ресурс] Home URL: https://github.com/thonny/thonny/wiki (дата посещения: 9.02.2025)
26. docs.spyder-ide.org [Электронный ресурс] Welcome to Spyder’s Documentation URL: https://docs.spyder-ide.org/current/index.html (дата посещения: 12.02.2025)
27. wingware.com [Электронный ресурс] Index of All Documentation URL: https://wingware.com/doc (дата посещения: 12.02.2025)
28. docs.python.org [Электронный ресурс] IDLE URL: https://docs.python.org/3.11/library/idle.html#idle (дата посещения: 13.02.2025)