Оценка эффективности ИТ-портфеля в ВКР: метрики, архитектура и экономика внедрения
Инвестиционное подразделение Фонда развития интернет-инициатив отчиталось о росте чистой прибыли по итогам 2025 года в 33 раза — до 1,35 млрд рублей. Звучит как триумф, но эксперты называют прибыль «бумажной» и указывают на аномальный резерв под обесценение долей в более чем 100 ИТ-компаниях. За этой новостью прячется отличный сюжет для выпускной работы: ценность ИТ-продукта нельзя измерить одной строкой в отчёте. Нужны технические метрики, прозрачный пайплайн данных и честная экономическая модель. Именно умение связать код, инфраструктуру и деньги отличает защищаемую ВКР от пересказа документации. Ниже — три готовые темы, разбор по главам и метрики, которые ждёт комиссия.
Что произошло и почему это тренд для диплома
Сюжет прост: фонд держит доли в сотне с лишним ИТ-компаний, и когда часть из них теряет в стоимости, разницу закрывают резервом. Прибыль возникает не потому, что продукты стали лучше, а потому что изменилась оценка активов. Для выпускника здесь важен сдвиг: инвесторы всё чаще смотрят не на выручку, а на инженерные сигналы — доступность сервиса, скорость релизов, деградацию SLA. Если вы умеете собирать такие сигналы и переводить их в решения, ваша работа защищается сама собой.
Три темы ВКР, которые вырастают из этой новости
Тема 1. Сервис мониторинга здоровья портфеля ИТ-компаний на OpenTelemetry и Prometheus
Актуальность: фонд с портфелем из 100+ компаний не может оценивать их «на глаз» — нужна единая система метрик вместо разрозненных дашбордов.
Цель: разработать систему сбора, хранения и визуализации продуктовых и инфраструктурных метрик.
Задачи: проанализировать источники метрик и требования ISO/IEC 25010; спроектировать сбор через OpenTelemetry Collector; настроить хранилище и дашборды; провести нагрузочное тестирование и оценить накладные расходы.
Структура: Гл. 1 — обзор метрик, стандартов и аналогов; Гл. 2 — архитектура (диаграммы C4, UML), схема развёртывания в Kubernetes; Гл. 3 — тестирование, SLO, расчёт TCO внедрения.
Тема 2. Модель раннего предупреждения обесценения ИТ-активов
Актуальность: резерв под обесценение — ровно та точка, где технические сигналы (отток пользователей, падение SLA) встречаются с финансовыми. Кейс ФРИИ показывает, насколько это чувствительная зона.
Цель: построить модель, которая по инженерным и продуктовым метрикам относит компанию к группе риска.
Задачи: сформировать признаки из метрик продукта; обучить и провалидировать классификатор; завернуть модель в API; описать экономический эффект от раннего реагирования.
Структура: Гл. 1 — IAS 36, признаки обесценения, обзор ML-подходов; Гл. 2 — пайплайн признаков, архитектура сервиса, API; Гл. 3 — валидация (precision/recall), сценарии внедрения, экономика.
Тема 3. ETL-пайплайн и автоматизация отчётности инвестиционного фонда
Актуальность: «бумажная» прибыль возникает там, где данные собирают вручную в таблицах. Прозрачный пайплайн — прямой ответ на этот риск.
Цель: снизить трудозатраты и число ошибок при подготовке отчётности.
Задачи: описать источники и требования по ГОСТ 34.602-89; спроектировать DAG-граф загрузки; реализовать контроль качества данных; посчитать эффект от внедрения.
Структура: Гл. 1 — анализ процессов, обзор ETL-инструментов; Гл. 2 — архитектура пайплайна и модель данных; Гл. 3 — тесты, метрики свежести данных, экономика.
Аналитическая глава: обоснование стека без вкусовщины
Самое слабое место студенческих работ — фраза «выбрали Prometheus, потому что он популярный». Комиссия это видит сразу. Стройте сравнение по измеримым критериям: стоимость владения, кардинальность метрик, задержка записи, сложность эксплуатации, наличие готовых экспортёров. Ниже — рабочий шаблон таблицы для первой главы.
| Критерий | Prometheus + Grafana | ClickHouse + Grafana | ELK-стек |
|---|---|---|---|
| Тип данных | Числовые метрики | Метрики и события | Логи и метрики |
| Стоимость хранения | Низкая | Средняя (сжатие колоночное) | Высокая |
| Горизонт хранения | 15–90 дней без downsampling | Годы | Зависит от индексов |
| Сложность внедрения | Низкая | Средняя | Высокая |
| Кому подходит | SLO, алертинг в реальном времени | Аналитика портфеля за годы | Разбор инцидентов |
Вывод в дипломе формулируйте так: «Комбинация Prometheus для оперативного контура и ClickHouse для исторического анализа выбрана по критериям X, Y, Z; альтернатива ELK отклонена из-за стоимости хранения при кардинальности более N». Это защищаемо.
Проектная часть: архитектура и интеграции
Здесь нужны схемы: контекстная диаграмма C4, диаграмма компонентов, последовательность для сбора метрик. Опишите, как данные попадают в систему от портфельных компаний: агент → коллектор → хранилище → дашборд. Ниже — реальный фрагмент конфигурации коллектора, который уместно вставить в приложение к ВКР.
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'portfolio-api'
scrape_interval: 15s
static_configs:
- targets: ['api-1:9100', 'api-2:9100']
processors:
memory_limiter:
limit_mib: 512
batch:
timeout: 5s
exporters:
prometheusremotewrite:
endpoint: "http://prometheus:9090/api/v1/write"
service:
pipelines:
metrics:
receivers: [prometheus]
processors: [memory_limiter, batch]
exporters: [prometheusremotewrite]Не забудьте про безопасность: mTLS между коллектором и хранилищем, ролевая модель доступа к дашбордам, маскирование чувствительных меток. В инвестиционном контуре это не формальность, а требование к проекту.
Тестирование и метрики: что измерять и как отчитываться
Глава с тестированием — та, где ВКР выигрывает или проигрывает. Опирайтесь на два слоя метрик: инженерные (DORA, SLO) и эксплуатационные (RTO/RPO). Для каждого показателя указывайте целевое значение и способ измерения — иначе это декларация, а не результат.
| Метрика | Что показывает | Целевое значение | Инструмент |
|---|---|---|---|
| Error Rate (SLI) | Доля 5xx от общего числа запросов | ≤ 0,5 % | PromQL, Grafana |
| RTO | Время восстановления сервиса | ≤ 30 мин | Учебные учения, журнал инцидентов |
| RPO | Допустимая потеря данных | ≤ 15 мин | Настройки репликации |
| Lead Time for Changes | Скорость доставки изменений | ≤ 1 день | CI/CD-пайплайн |
| Свежесть данных | Задержка ETL-загрузки | ≤ 1 час | Мониторинг пайплайна |
Пример запроса для контроля SLO по ошибкам:
sum(rate(http_requests_total{job="portfolio-api", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="portfolio-api"}[5m]))Нагрузочное тестирование описывайте сценариями: 100, 500, 1000 виртуальных пользователей, фиксация p95 и p99 задержки, точки насыщения. Отдельным подразделом — экономика. Считайте TCO (серверы, лицензии, трудозатраты) и NPV проекта внедрения. И обязательно прокомментируйте новость: резерв под обесценение в модели риска — это надбавка к ставке дисконтирования. Тогда ваша работа будет отвечать на реальный вопрос «а если актив подешевеет», а не только «сколько стоит сервер».
Чему вы научитесь на такой работе
- Проектировать сбор метрик от разнородных источников и обосновывать выбор хранилища.
- Строить диаграммы C4 и UML так, чтобы они читались без пояснений автора.
- Считать TCO и NPV, защищая каждую цифру источником или допущением.
- Работать с CI/CD-пайплайнами и понимать, зачем нужны метрики доставки.
- Оформлять ТЗ по ГОСТ 34.602-89 и описание программы по ГОСТ 19.402-78.
- Связывать инженерные показатели с бизнес-решениями — навык, который прямо просят на собеседованиях.
- Первая глава ссылается на первоисточник и дату публикации — новость от 27.03.2026.
- Каждая задача из введения отражена в выводах по главам и в заключении.
- Все схемы пронумерованы, подписаны и упомянуты в тексте.
- Целевые значения метрик обоснованы, а не взяты «из головы».
- ТЗ оформлено по ГОСТ 34.602-89, листинги — по ГОСТ 19.402-78.
- Экономический расчёт содержит допущения и источники ставок.
- Список литературы включает стандарты ISO/IEC 25010 и IAS 36.
- Метрики без обоснования. Написано «доступность 99,9 %», но откуда взято — непонятно. Свяжите показатель с классом системы и ожиданиями заказчика.
- Подмена терминов. SaaS, PaaS, IaaS и «облако» используются как синонимы. Дайте определения в первой главе и держитесь их до конца.
- Экономика отдельно от техники. Расчёт TCO идёт в вакууме, метрики производительности — сами по себе. Свяжите их: рост кардинальности метрик прямо увеличивает стоимость хранения.
- Игнорирование ТЗ. ГОСТ 34.602-89 прописан формально, без реальных требований. Комиссия это замечает мгновенно.
Частые вопросы
Обязательно ли писать работающий код для такой ВКР?
Зависит от кафедры. Чаще достаточно прототипа: коллектор поднимается в Docker, метрики идут в хранилище, дашборд строится. Полноценный продакшен никто не требует, но скриншоты живых графиков резко усиливают защиту.
Где брать тестовые данные, если нет реальных пользователей?
Генератор нагрузки на базе k6 или Locust плюс синтетические метрики. Опишите параметры генерации — это честнее, чем выдавать выдуманные цифры за реальные. При необходимости используйте открытые наборы данных по ИТ-рынку.
Как оформлять UML и C4-диаграммы?
Единый нотационный аппарат: не смешивайте UML-классы и блок-схемы ГОСТ без пояснений. Каждая диаграмма — с легендой, подписью и ссылкой из текста. Инструменты: PlantUML, draw.io, Mermaid.
Хватит ли трёх глав, если тема широкая?
Три главы — оптимум: анализ, проектирование, тестирование и экономика. Расширять стоит не числом глав, а глубиной: больше сценариев, честная валидация, разбор отказов.
Практический итог
Новость про миллиардную прибыль и резерв под обесценение — это не финансовая сводка, а приглашение к теме. Возьмите технические метрики, свяжите их с деньгами, добавьте прозрачный пайплайн данных — и получите ВКР, которую можно защищать без оговорок «в учебных целях». Начните с одной темы, распишите задачи и проверьте, что каждая из них даёт измеримый результат. Если чувствуете, что не хватает структуры или данных для расчётов, — это решаемо.
Источник: Фонд, созданный, чтобы ИТ-шники не уезжали «на силиконщину», отчитался о миллиардной прибыли (опубликовано 2026-03-27)
```