Импортозамещение ИТ-инфраструктуры в дипломе: экономическое обоснование и метрики TCO
25 марта 2026 года CNews сообщил: компания «Крайон» подвела финансовые итоги 2025 года, и чистая прибыль выросла почти в три раза. Для выпускника ИТ-направления это не просто новость из мира бизнеса. Это готовая доказательная база под тему, где нужно показать не «я умею писать код», а «я умею считать инфраструктуру»: TCO, срок окупаемости, отказоустойчивость, импортозамещение. Заказчики на защите всё чаще спрашивают именно об экономике решения, а не о количестве строк. Ниже — как превратить эту публикацию в рабочую канву ВКР, какие метрики собрать и где обычно сыпятся студенты.
Три темы ВКР, которые опираются на этот кейс
1. Оценка экономической эффективности миграции корпоративной инфраструктуры на отечественные серверные платформы
- Актуальность: рост финансовых показателей вендора «Крайон» — косвенное подтверждение устойчивого спроса на отечественное железо и СХД. Значит, расчёт окупаемости такой миграции — задача с реальными входными данными, а не абстракция.
- Цель: разработать модель оценки совокупной стоимости владения (TCO) и срока окупаемости при переходе с зарубежной платформы на отечественную.
- Задачи: собрать исходный профиль нагрузок; сравнить 3–4 платформы по критериям ISO/IEC 25010; построить финансовую модель на 5 лет; проверить чувствительность к курсу и ставке дисконтирования.
- Структура: Гл. 1 — анализ рынка и нормативной базы (реестр отечественного ПО/оборудования, ГОСТ 34.601-90); Гл. 2 — архитектура целевого стенда и модель расчёта; Гл. 3 — расчёты, сценарии «пессимистичный/базовый/оптимистичный», выводы.
2. Проектирование отказоустойчивого кластера СХД для среднего бизнеса с расчётом эксплуатационных затрат
- Актуальность: вендоры, показывающие кратный рост прибыли, обычно растут на проектах именно такого класса — кластеры, резервирование, сервисные контракты.
- Цель: спроектировать кластер с заданными RTO/RPO и посчитать стоимость владения за 3 года.
- Задачи: обосновать топологию (active-active / active-passive); выбрать протоколы репликации; рассчитать требуемую ёмкость и IOPS; оценить стоимость лицензий и поддержки.
- Структура: Гл. 1 — теория отказоустойчивости и SLA; Гл. 2 — схемы, спецификация, ТЗ по ГОСТ 34.602-89; Гл. 3 — тесты на отказ узла, расчёт затрат.
3. Система мониторинга парка серверов на OpenTelemetry и Prometheus с оценкой эффекта от снижения простоев
- Актуальность: чем больше оборудования продаётся, тем острее вопрос наблюдаемости. Мониторинг — тот раздел диплома, который легко защитить: есть замеры «до/после».
- Цель: разработать контур мониторинга и оценить сокращение времени простоя в денежном выражении.
- Задачи: спроектировать сбор метрик и трассировок; настроить алертинг; провести нагрузочный тест; посчитать экономию от снижения MTTR.
- Структура: Гл. 1 — обзор подходов (pull/push, стандарт OpenTelemetry); Гл. 2 — архитектура и конфигурация в Kubernetes; Гл. 3 — эксперименты, метрики, экономика.
Аналитическая глава: как превратить новость в обоснование
Первая глава — это не пересказ статьи, а рамка выбора. Опирайтесь на факт роста рынка, но обязательно добавьте критерии сравнения. Хорошо работает таблица, где строки — варианты решения, столбцы — измеримые характеристики.
| Критерий | On-prem (отечественное железо) | Публичное облако | Гибрид |
|---|---|---|---|
| TCO за 5 лет | Высокий CAPEX, низкий OPEX | Низкий вход, растущий OPEX | Средний, зависит от баланса |
| Соответствие требованиям импортозамещения | Полное | Зависит от провайдера | Частичное |
| Управляемость и аудит | Максимальная | Ограничена договором | Высокая для критичного контура |
| Масштабирование | Дискретное, по закупкам | Эластичное | Комбинированное |
| Риск блокировки вендором | Низкий | Средний/высокий | Средний |
Обоснование стека пишите через задачи, а не через модность. Kubernetes — потому что нужна воспроизводимость окружений между стендом и промышленной эксплуатацией. OpenTelemetry — потому что нужен единый формат метрик, логов и трассировок без привязки к одному вендору. Prometheus и Grafana — потому что это де-факто стандарт и по ним легко найти сопоставимые данные.
Проектная часть: архитектура, ТЗ, интеграция
Здесь статья даёт вам право говорить о «промышленном» масштабе. Не рисуйте абстрактные квадратики — привязывайте каждый компонент к требованию. Типовое ТЗ оформляется по ГОСТ 34.602-89, стадии разработки — по ГОСТ 34.601-90, а требования к качеству удобно раскладывать по ISO/IEC 25010: производительность, надёжность, сопровождаемость, безопасность.
Фрагмент манифеста развёртывания сервиса инвентаризации — хороший пример того, как в дипломе показать управление ресурсами (requests/limits) и обосновать расчёт ёмкости:
apiVersion: apps/v1
kind: Deployment
metadata:
name: hw-inventory
spec:
replicas: 3
template:
spec:
containers:
- name: api
image: registry.local/hw-inventory:1.4.2
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
Что обязательно показать в проектной главе
- Схему целевой архитектуры в нотации C4 или UML-компонентов — с зонами отказа.
- Алгоритм обработки отказа: кто перехватывает трафик, за сколько секунд, что видит пользователь.
- Точки интеграции: реестр оборудования, система закупок, служба поддержки, СМЭВ-подобные внешние сервисы, если они есть в контуре.
- Спецификацию оборудования с указанием, чем обусловлен каждый параметр (не «взяли 2 ТБ», а «2 ТБ = объём данных × коэффициент роста × запас 30%»).
Тестирование и метрики: где защита выигрывается или проигрывается
Самая частая претензия комиссии — «вы не показали, как измеряли». Нагрузочное тестирование, отказоустойчивость и мониторинг должны быть оформлены как эксперимент: гипотеза, методика, результат, погрешность.
| Метрика | Что показывает | Как получить |
|---|---|---|
| RTO | Целевое время восстановления после отказа | Учебный отказ узла кластера, замер вручную |
| RPO | Допустимая потеря данных | Настройка репликации, расчёт по журналу транзакций |
| MTTR / MTBF | Ремонтопригодность и надёжность | Логи инцидентов, выгрузка из системы мониторинга |
| P95 времени отклика | Пользовательский опыт под нагрузкой | Нагрузочный тест, отчёт с перцентилями |
| Утилизация CPU/RAM | Запас мощности и обоснование закупки | Prometheus + Grafana, снапшоты за период |
Если нет доступа к реальной инфраструктуре, разворачивайте стенд локально или в учебном облаке и честно указывайте в работе: «эксперимент проведён на стенде, масштаб нагрузок приведён к промышленному коэффициентом 1:10». Это нормальная практика, её принимают, если методика описана.
Чему вы научитесь на такой теме
- Переводить бизнес-событие в технические требования и обратно — навык, который отличает архитектора от кодера.
- Считать TCO, NPV и срок окупаемости, не подгоняя цифры под желаемый вывод.
- Обосновывать выбор стека ссылками на стандарты и замеры, а не на «популярность на GitHub».
- Оформлять ТЗ, схемы и протоколы испытаний так, чтобы их не пришлось переписывать после первой рецензии.
- Ссылка на отраслевой источник (в т.ч. публикация CNews от 2026-03-25) стоит во введении и в списке литературы.
- Каждая задача из введения закрывается конкретным разделом и выводом.
- Есть минимум одна схема архитектуры и одна таблица сравнения решений.
- ТЗ оформлено по ГОСТ 34.602-89, стадии — по ГОСТ 34.601-90.
- Все метрики имеют единицы измерения и способ получения.
- Экономические расчёты содержат допущения и анализ чувствительности.
- Выводы не противоречат цифрам из третьей главы.
- Подмена понятий SaaS, PaaS и IaaS без обоснования. Модель обслуживания определяет, кто платит за администрирование. Если вы пишете «облако дешевле», но считаете только железо, комиссия это заметит. Решение: распишите OPEX отдельной строкой с учётом ФОТ администраторов.
- Отсутствие измеримых метрик эффективности. Формулировка «стало быстрее и надёжнее» не защищается. Решение: минимум три метрики с числами «до/после» и описанием методики замера.
- Игнорирование требований ГОСТ при оформлении ТЗ и документации. Это снимает баллы даже при сильной технической части. Решение: сверьте состав разделов ТЗ по ГОСТ 34.602-89 заранее, а не в ночь перед защитой.
Частые вопросы
Нужно ли писать код в дипломе по такой теме?
Зависит от направления. Для прикладных специальностей достаточно конфигураций, манифестов, скриптов автоматизации и прототипа на стенде. Для исследовательских тем можно ограничиться моделью и симуляцией нагрузок. Главное — чтобы артефакт можно было продемонстрировать и объяснить.
Где брать данные для экономических расчётов, если нет заказчика?
Открытые прайс-листы вендоров, отраслевые обзоры, публикации профильных изданий, данные Росстата по средним зарплатам в ИТ. Все допущения выносите в отдельный подраздел с указанием даты получения цены — тогда расчёт можно защитить.
Как оформить диаграммы, чтобы их приняли?
UML для поведения и структуры, C4 для уровней архитектуры, BPMN для процессов. Каждая диаграмма должна иметь легенду, единый стиль и ссылку в тексте («см. рисунок 3»). Не смешивайте нотации в одном рисунке.
Насколько сложна реализация по сравнению с чисто программной темой?
Инфраструктурная тема требует меньше строк кода, но больше дисциплины: спецификации, замеры, обоснования. Если вам ближе алгоритмы и разработка, берите мониторинг или автоматизацию развёртывания — там кода хватит.
Источник: Компания «Крайон» подвела финансовые итоги 2025 г.: чистая прибыль выросла почти в три раза (опубликовано 2026-03-25)
```