Разработка приложения тестирования отказоустойчивости программных систем с использованием виртуальных сред (на примере конкретного действующего субъекта)

1.1. Технико-экономическая характеристика предметной области и предприятия

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

Пример: «ООО «Софт-Интегратор» специализируется на разработке корпоративных информационных систем. В 2024 году компания реализовала 17 проектов, из которых 5 завершились претензиями клиентов по причине сбоев в работе ПО при пиковых нагрузках. Это указывает на недостаточную проработку отказоустойчивости на этапе тестирования».

Сложности:

• Отсутствие открытых данных о деятельности ООО «Софт-Интегратор» (приходится моделировать реалистичные показатели);
• Необходимость корректно связать общую тему надёжности ПО с конкретной проблемой предприятия.

Время: 10–12 часов.

1.2. Характеристика комплекса задач и обоснование необходимости автоматизации

Анализируется текущий процесс тестирования отказоустойчивости в ООО «Софт-Интегратор»: ручные методы, используемые инструменты, частота тестов, время на выполнение. Обосновывается переход к автоматизированному подходу с использованием виртуальных сред.

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

Сложности:

• Нужно чётко сформулировать «узкие места» текущего процесса;
• Требуется знание современных подходов к тестированию (Chaos Engineering, fault injection и др.).

Время: 8–10 часов.

1.3. Анализ существующих разработок и выбор стратегии автоматизации

Рассматриваются аналоги: Chaos Monkey, Gremlin, Litmus, а также open-source решения. Проводится сравнительный анализ по критериям: поддержка виртуальных сред, гибкость сценариев, интеграция с CI/CD, стоимость. Обосновывается выбор собственной разработки или адаптации существующего инструмента.

Пример: «Хотя Chaos Monkey эффективен в среде AWS, он не поддерживает локальные виртуальные среды на базе VMware, которые используются в ООО «Софт-Интегратор». Поэтому принято решение о разработке собственного приложения».

Сложности:

• Требуется актуальная информация о современных инструментах;
• Необходимо избегать поверхностного перечисления без анализа применимости.

Время: 10–12 часов.

1.4. Обоснование проектных решений

Формулируются требования к будущему приложению: поддержка Docker/Kubernetes, возможность имитации сетевых сбоев, генерация отчётов, интеграция с Jenkins. Обосновывается выбор технологического стека (Python + Flask, Ansible, Prometheus).

Пример: «Для реализации сценариев отказа будет использован Ansible, позволяющий управлять виртуальными машинами и контейнерами. Интерфейс приложения — веб-панель на Flask, что обеспечивает кроссплатформенность и простоту развёртывания».

Сложности:

• Необходимо увязать архитектурные решения с требованиями предприятия;
• Риск излишней технической детализации в аналитической главе.

Время: 8–10 часов.

Выводы по главе 1

Подводятся итоги анализа: выявлены проблемы в процессе тестирования отказоустойчивости в ООО «Софт-Интегратор», обоснована необходимость автоматизации, выбрана стратегия разработки собственного приложения с использованием виртуальных сред.

Время: 4–6 часов.

2.1. Разработка проекта автоматизации

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

Пример: «Пользователь (тестировщик) через веб-интерфейс выбирает тестовый сценарий отказа (например, «отключение одного из узлов кластера Kubernetes»). Система автоматически развёртывает тестовую среду, запускает сценарий и фиксирует поведение ПО».

Сложности:

• Требуются навыки проектирования ИС и работы с инструментами вроде Draw.io или StarUML;
• Легко перегрузить главу избыточной детализацией.

Время: 12–15 часов.

2.2. Информационное обеспечение задачи

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

Пример: «Таблица test_scenarios содержит поля: id, name, description, target_environment (docker/k8s/vm), failure_type (network/cpu/memory), script_path».

Сложности:

• Необходимо продумать логику хранения данных без избыточной сложности;
• Риск несоответствия с последующей реализацией.

Время: 8–10 часов.

2.3. Программное обеспечение задачи

Приводятся фрагменты кода, описания модулей, алгоритмы работы. Акцент на реализации сценариев отказа в виртуальной среде. Обоснование выбора библиотек и фреймворков.

Пример: «Модуль network_failure.py использует библиотеку python-iptables для блокировки сетевого трафика к целевому контейнеру на 30 секунд, имитируя обрыв связи».

Сложности:

• Требуется написание рабочего (или хотя бы демонстрационного) кода;
• Необходимо соблюдать баланс между объёмом кода и пояснениями.

Время: 20–25 часов.

2.4. Контрольный пример реализации проекта и его описание

Демонстрируется работа приложения на примере тестирования отказоустойчивости веб-сервиса ООО «Софт-Интегратор». Приводятся скриншоты интерфейса, логи выполнения, результаты анализа.

Пример: «При имитации отказа одного из трёх узлов базы данных PostgreSQL кластер автоматически переключился на резервный узел. Время простоя составило 8 секунд, что соответствует SLA».

Сложности:

• Требуется настроить виртуальную среду и запустить тест;
• Необходимо чётко интерпретировать результаты.

Время: 15–20 часов.

Выводы по главе 2

Подтверждается достижение цели: разработано и протестировано приложение для автоматизированного тестирования отказоустойчивости в виртуальных средах, адаптированное под условия ООО «Софт-Интегратор».

Время: 4–6 часов.

3.1. Выбор и обоснование методики расчёта экономической эффективности

Обосновывается применение методики расчёта по ГОСТ 34.602–89 или внутренним стандартам Синергии. Определяются статьи затрат: трудозатраты разработчиков, стоимость ПО, инфраструктуры.

Пример: «Экономический эффект рассчитывается как разница между стоимостью ручного тестирования (8 часов × 1500 руб./час) и автоматизированного (2 часа × 1500 руб./час + амортизация ПО)».

Сложности:

• Необходимо корректно оценить ставки и время;
• Риск несоответствия выбранной методике требованиям вуза.

Время: 6–8 часов.

3.2. Расчёт показателей экономической эффективности проекта

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

Пример: «Годовой экономический эффект от внедрения приложения составляет 1 080 000 руб., срок окупаемости — 4 месяца».

Сложности:

• Требуется точность в расчётах;
• Нужно учесть все виды затрат (включая обучение персонала).

Время: 10–12 часов.

Выводы по главе 3

Подтверждается экономическая целесообразность разработки и внедрения приложения для тестирования отказоустойчивости в ООО «Софт-Интегратор».

Время: 4–6 часов.

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