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

ЦОД в ВКР: расчёт отказоустойчивости и экономики на примере второго дата-центра RWB

27 марта 2026 года компания RWB сообщила о вводе в эксплуатацию второго собственного центра обработки данных в особой экономической зоне «Дубна». Событие выглядит как обычная новость из ленты ИТ-инфраструктуры, но для выпускника направления «Информатика и вычислительная техника», «Прикладная информатика» или «Информационная безопасность» это готовый полигон для дипломной работы.

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

Три темы ВКР, которые вырастают из этой новости

1. Проектирование отказоустойчивого сегмента ЦОД с резервированием N+1

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

• Цель: разработать проект отказоустойчивого сегмента инфраструктуры с заданными показателями доступности.
• Задачи: проанализировать схемы резервирования (N, N+1, 2N); обосновать уровень Tier; спроектировать топологию сети и СХД; рассчитать значения RTO и RPO для каждого сервиса.
• Структура: глава 1 — теория отказоустойчивости и стандарты; глава 2 — архитектура и схемы резервирования; глава 3 — имитационное моделирование отказов и расчёт эффективности.

2. Гибридная инфраструктура: собственный ЦОД плюс облачный контур

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

• Цель: обосновать модель размещения сервисов между собственным ЦОД и облаком.
• Задачи: классифицировать сервисы по чувствительности к задержке и требованиям к данным; сравнить colocation, IaaS и on-prem по критериям; построить сценарий миграции; описать единый CI/CD-пайплайн для обоих контуров.
• Структура: глава 1 — анализ моделей обслуживания; глава 2 — проектирование гибридной платформы, оркестрация через Kubernetes; глава 3 — пилотная миграция сервиса и оценка затрат.

3. SRE-контур мониторинга распределённого ЦОД: OpenTelemetry, Prometheus, Grafana

Актуальность. Две площадки невозможно эксплуатировать «на глазок». Нужен наблюдаемый контур: метрики, трассировки, логи и формализованные SLO.

• Цель: спроектировать систему мониторинга и оповещения для сервисов, работающих на нескольких площадках.
• Задачи: определить перечень метрик и SLO; настроить сбор данных через OpenTelemetry; реализовать правила алертинга; рассчитать бюджет ошибок.
• Структура: глава 1 — обзор средств наблюдаемости; глава 2 — архитектура сбора и хранения телеметрии; глава 3 — эксперименты, дашборды, оценка снижения времени реакции на инцидент.

Аналитическая глава: чем её наполнить по существу

Первая глава в таких работах чаще всего проваливается, потому что студент пересказывает учебник. Вместо этого сделайте её главой обоснования выбора — с таблицами и критериями. Опирайтесь на стандарты: ISO/IEC 25010 для характеристик качества, ГОСТ 34.602-89 для структуры технического задания, ГОСТ 19.701-90 для правил оформления схем.

Ключевой приём: выбор стека нужно не постулировать, а выводить из ограничений. Ограничения формулируйте сами и фиксируйте в ТЗ — «доступность не ниже 99,95%», «RPO не более 15 минут», «PUE не выше 1,4», «бюджет эксплуатации не более X в год». Дальше любое решение проверяется на соответствие этим числам. Именно такой ход отличает работу, которую хочется защищать, от компиляции статей.

Проектная глава: что должно быть на схемах

Минимальный комплект графики для темы про ЦОД:

• схема развёртывания (UML Deployment или C4 Container) с явным делением на площадки;
• функциональная схема системы по ГОСТ 19.701-90 — блоки и связи, без «облачков» и картинок из интернета;
• схема сетевой сегментации: DMZ, сегмент управления, сегмент СХД, служебные VLAN;
• схема репликации данных между основным и резервным контуром с указанием режима (синхронный/асинхронный).

Отдельный плюс — описание инфраструктуры как кода. Даже фрагмент манифеста показывает, что вы понимаете воспроизводимость:

# Фрагмент: правило расчёта доступности сервиса за окно
groups:
  - name: slo_rules
    rules:
      - record: slo:api_availability:ratio
        expr: |
          sum(rate(http_requests_total{code!~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

Глава с тестированием: где взять цифры вместо обещаний

Именно здесь работа становится доказуемой. Нагрузочное тестирование (k6, Locust, JMeter) даёт кривые зависимости времени отклика от числа одновременных пользователей. Тесты на отказ — управляемое выключение узла или целого контура — дают фактическое время восстановления, которое сравнивается с заявленным RTO.

Полезный приём для расчётной части — бюджет ошибок. Для SLO 99,95% за 30 дней допустимо около 21,6 минуты недоступности. Дальше вы показываете, укладывается ли спроектированная схема резервирования в этот лимит при единичном отказе. Это простая арифметика, которая в глазах комиссии выглядит куда убедительнее фразы «система надёжна».

Не забудьте экономический раздел: сравнение капзатрат на оборудование и площадку с моделью аренды на горизонте 3–5 лет, расчёт точки окупаемости и чувствительности к загрузке. Для темы про собственный ЦОД это самый естественный способ показать практическую значимость.

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

• Обосновывать архитектурные решения через ограничения и метрики, а не через «так принято».
• Считать показатели надёжности и энергоэффективности, а не только описывать их словами.
• Работать с оркестрацией (Kubernetes), наблюдаемостью (OpenTelemetry, Prometheus, Grafana) и средствами нагрузочного тестирования.
• Оформлять техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90 — навык, который напрямую пригодится на первой работе.
• Отделять инфраструктурные риски от прикладных и говорить о них на одном языке с заказчиком.

Частые вопросы

Обязательно ли писать код, если тема про инфраструктуру ЦОД?

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

Где брать исходные данные для расчётов, если нет доступа к реальному дата-центру?

Три источника: публичные материалы организаций по эксплуатации ЦОД, данные отчётов о доступности облачных провайдеров, и собственный стенд. Стенд поднимается локально: несколько виртуальных машин, контейнерный кластер, имитация отказов через управляемое отключение узлов. Данные из новости используются как обоснование актуальности, а числовые значения вы задаёте в ТЗ сами и затем проверяете.

Хватит ли времени на такую работу в рамках обычного дипломного семестра?

Да, если сузить рамки. Не «спроектировать ЦОД», а «спроектировать отказоустойчивый сегмент для конкретного сервиса с заданным SLA». Один сервис, два контура размещения, набор метрик — этого достаточно для полноценной ВКР.

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

Используйте нотацию UML Deployment для размещения компонентов и схему по ГОСТ 19.701-90 для функциональной части. Стройте в draw.io, PlantUML или аналогичных редакторах — экспорт в векторный формат даёт нормальную печать. Скачанные из интернета картинки без подписи и ссылки на источник — гарантированный минус.

Источник: RWB ввела в эксплуатацию второй собственный ЦОД в ОЭЗ «Дубна» (опубликовано 2026-03-27)