Опубликовано: 24.09.2026 | Источник: CNews (новости)

Рынок ПО для ИТ-инфраструктуры в дипломе: от тренда Orion soft до защищаемых метрик

Orion soft отчитался о результатах 2025 года, и главный вывод отчёта простой: спрос на инфраструктурное ПО в России продолжает расти, но растёт он на фоне жёсткой экономии. Бизнес оптимизирует затраты и урезает бюджеты на цифровизацию — об этом же говорят данные ИСИЭЗ НИУ ВШЭ о структуре затрат организаций на ИТ. Для выпускника это не абстрактная новость, а готовая рамка для ВКР: любое техническое решение теперь защищается не «красотой архитектуры», а связкой «эффект — стоимость — срок». Если в вашей работе нет расчёта совокупной стоимости владения, сравнения с альтернативами и измеримых метрик, комиссия задаст неудобный вопрос. Ниже — как превратить этот рыночный сигнал в структуру диплома, которую сложно развалить на защите.

Что именно из статьи переносится в текст ВКР

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

Три темы ВКР, которые вырастают из этой публикации

Тема 1. Оценка совокупной стоимости владения отечественной платформой виртуализации при миграции с зарубежного стека

Актуальность: статья прямо фиксирует конфликт — рынок растёт, а бюджеты урезают. Значит, решение должно быть экономически обоснованным, а не «модным».

Цель: разработать методику расчёта TCO и применить её к сценарию миграции инфраструктуры организации.

• проанализировать состав текущей инфраструктуры и лицензионные ограничения;
• сформировать критерии сравнения платформ (производительность, стоимость владения, поддержка);
• построить модель затрат на горизонте 3–5 лет;
• оценить риски перехода и предложить план миграции.

Структура: Глава 1 — анализ рынка и подходов к оценке TCO; Глава 2 — модель инфраструктуры и методика расчёта; Глава 3 — расчёты, сценарии, выводы по экономике.

Тема 2. Проектирование отказоустойчивого кластера Kubernetes для внутреннего сервиса организации

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

Цель: спроектировать и проверить кластер, обеспечивающий заданные показатели доступности.

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

Структура: Глава 1 — теоретические основы оркестрации и отказоустойчивости; Глава 2 — архитектура кластера, схемы, манифесты; Глава 3 — тестирование, метрики, оценка внедрения.

Тема 3. Методика мониторинга ИТ-инфраструктуры на OpenTelemetry и оценка качества по ISO/IEC 25010

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

Цель: построить контур наблюдаемости и оценить его вклад в сокращение времени восстановления.

• проанализировать существующие подходы к сбору телеметрии;
• спроектировать схему сбора метрик, логов и трассировок;
• реализовать прототип и настроить оповещения;
• измерить MTTR до и после внедрения.

Структура: Глава 1 — обзор стандартов и инструментов; Глава 2 — проектирование контура наблюдаемости; Глава 3 — эксперимент, метрики, выводы.

Аналитическая глава: как обосновать стек, а не перечислить его

Сравнение решений

Классическая ошибка — таблица «Kubernetes vs Docker Swarm vs Nomad» без весов критериев. Сделайте иначе: выведите критерии из требований вашего объекта (например, «поддержка на территории РФ», «наличие сертифицированной сборки», «порог входа для команды из двух человек»), присвойте веса и защитите их. Тогда выбор перестанет быть вкусовым.

Нормативная база

В аналитическом разделе уместно опереться на ГОСТ 34.602-89 при описании требований к системе и на ISO/IEC 25010 при выборе характеристик качества. Это снимает половину вопросов комиссии: вы не придумали критерии, вы взяли их из стандарта.

Увязка с трендом из статьи

Отдельный подпункт: «Влияние экономических ограничений на выбор инфраструктурного решения». Здесь одна-две ссылки на публикацию и вывод — дальше только ваши аргументы.

Проектная часть: схемы, алгоритмы, интеграция

Что должно быть на схемах

• контекстная диаграмма (кто и как взаимодействует с системой);
• диаграмма развёртывания с указанием узлов, сетей, точек отказа;
• схема потоков данных и мест сбора телеметрии;
• алгоритм обработки отказа или планового обновления.

Минимальный рабочий фрагмент

Код в дипломе нужен не для объёма, а для доказательства работоспособности. Достаточно конфигурации, которая демонстрирует резервирование и ограничения ресурсов.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-api
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    spec:
      containers:
        - name: api
          image: registry.local/billing-api:1.4.0
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080

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

Тестирование и метрики: чем закрывать третий раздел

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

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

Чему вы научитесь на такой работе

• обосновывать выбор технологии через требования и стандарты, а не через личные предпочтения;
• считать экономику внедрения: TCO, стоимость простоя, эффект от сокращения простоев;
• работать с инструментами оркестрации, конвейерами CI/CD и системами сбора телеметрии;
• оформлять техническую документацию в соответствии с ГОСТ 34 и описывать архитектуру так, чтобы её понял не только автор.

Частые вопросы студентов

Обязательно ли разворачивать реальный кластер или хватит макета?

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

Где брать данные для нагрузочного тестирования, если нет доступа к промышленной системе?

Два пути: генератор синтетической нагрузки с обоснованным профилем (соотношение чтения и записи, размер объектов) либо обезличенная выборка из открытых наборов данных. Любой вариант требует описания профиля нагрузки в тексте.

Требует ли вуз код, если тема экономическая?

Для тем вроде оценки TCO код не обязателен, но нужны расчётные модели и выгрузки, которые можно проверить. Если тема про проектирование системы — конфигурации и скрипты становятся частью приложения к работе.

Как оформлять диаграммы, чтобы их приняли?

Используйте UML для поведения и структуры, а для развёртывания — нотацию с явными узлами и связями. Каждая диаграмма должна иметь номер, название и ссылку в тексте: «на рисунке 7 показано…». Диаграмма без пояснения в тексте обычно считается неиспользованной.

Источник: Рынок ПО для ИТ-инфраструктуры продолжает расти — Orion soft отчитался о результатах 2025 года (опубликовано 2026-03-25)