ЦОД в дипломе: отказоустойчивость, мониторинг и экономика вычислительных мощностей

В марте 2026 года Wildberries & Russ запустила второй собственный ЦОД в Подмосковье: около 5,5 тыс. кв. м и проектная мощность порядка 8 МВт. Для интернет-ритейла это не просто «ещё один дата-центр», а заявка на управляемую инфраструктуру: мощности нужны и маркетплейсу, и цифровым сервисам группы. Для выпускника ИТ такой кейс ценен тем, что даёт язык для ВКР: требования к доступности, резервированию, энергоэффективности и мониторингу. Здесь можно проектировать отказоустойчивый контур, считать PUE и TCO, строить C4-диаграммы и проверять SLO. Не нужно притворяться, что у вас есть доступ к объекту Wildberries & Russ: достаточно публичных фактов, корректных допущений и воспроизводимой модели. Ниже — как превратить новость в инженерную работу, которую реально защитить.

Темы ВКР и инженерная часть: три сценария на базе кейса

Как встроить кейс в главы 1–3

Глава 1: не пересказ новости, а рамка требований

Факты из статьи используйте как исходные ограничения: площадь около 5,5 тыс. кв. м, проектная мощность около 8 МВт, второй собственный ЦОД под Москвой. Дальше нужна инженерная рамка. Формализуйте нефункциональные требования через ISO/IEC 25010: доступность, производительность, безопасность, сопровождаемость. Постройте C4-диаграмму контекста: цифровые сервисы компании, пользователи, инфраструктурный контур, внешние каналы. Не надо выдумывать внутреннюю топологию Wildberries & Russ — опишите целевую модель и явно укажите допущения. Хороший приём — таблица «собственный ЦОД vs облако/колокация» по критериям: CAPEX, OPEX, контроль, скорость масштабирования, зависимость от оператора, требования к ИБ.

Глава 2: проектирование и воспроизводимый стенд

Здесь статья превращается в техническую часть. Сделайте C4 Container/Deployment, схему сетевой сегментации, контур резервирования питания и охлаждения, план размещения Kubernetes-кластеров. Для практики не нужен реальный ЦОД: поднимите стенд в kind/minikube или Docker Compose, эмулируйте телеметрию через OpenTelemetry Collector, а правила алертинга храните в Git. Покажите, как вы контролируете запас мощности и дисбаланс стоек. Пример правила Prometheus:

groups:
  - name: dc_capacity
    rules:
      - alert: DataCenterPowerHeadroomLow
        expr: |
          sum(dc_power_draw_kw) / sum(dc_power_capacity_kw) > 0.80
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Осталось менее 20% мощности ЦОД"
          runbook: "Проверить capacity planning и очередь миграции"

      - alert: RackPowerImbalance
        expr: |
          max by (rack) (rack_power_draw_kw)
          /
          max by (rack) (rack_power_limit_kw) > 0.85
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "Стойка близка к лимиту по питанию"

Метрики `dc_power_draw_kw`, `dc_power_capacity_kw` и `rack_power_limit_kw` — это не «магия Wildberries», а ваш учебный экспортер. Важно показать цепочку: источник метрики → сбор → хранение → алерт → действие по runbook. Для Kubernetes добавьте `topologySpreadConstraints`, чтобы поды не сбивались в одну зону доступности. Это уже прикладной DevOps/SRE-результат, а не реферат про дата-центры.

Глава 3: тестирование, метрики и защита результата

Считайте не «красоту схемы», а управляемые величины: SLA/SLO/SLI, error budget, MTTR, RTO/RPO, PUE, утилизацию стоек, запас по мощности. Для TCO задайте формулу и допущения:

TCO = CAPEX_ЦОД
    + OPEX_энергия
    + OPEX_охлаждение
    + OPEX_обслуживание
    + OPEX_сеть
    + OPEX_персонал

PUE = общее_потребление_ЦОД / потребление_ИТ-оборудования

Проведите сценарный анализ: утилизация 60%, 75%, 85%; PUE 1,3 и 1,5; разные тарифы на энергию. Если точных данных компании нет, используйте диапазоны и sensitivity analysis. Комиссия любит вопросы «откуда цифры?» — на каждую ставку должна быть ссылка, расчёт или явное допущение. BPMN-схема инцидента «потеря питания → переключение → деградация сервиса → восстановление» отлично закрывает практическую часть по отказоустойчивости.

Нормоконтроль: что положить в приложения

Схемы C4/UML и BPMN оформляйте с легендой, подписями и ссылками из текста. Для автоматизированной системы ориентируйтесь на ГОСТ 34, для программной документации — на ГОСТ 19. Код и конфиги выносите в приложения, но не скриншотами: лучше листинг с версией, назначением и коротким комментарием. Проверьте, что каждая задача из введения заканчивается выводом в заключении. Если вы решаете, как написать ВКР без «воды», начните с матрицы «задача → глава → результат → метрика» — она сразу показывает слабые места.

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

• Формализовать нефункциональные требования к ЦОД через ISO/IEC 25010, а не общими словами.
• Строить C4/UML и BPMN-схемы для инфраструктурных сценариев и аварий.
• Настраивать мониторинг на OpenTelemetry/Prometheus и писать алерты с runbook.
• Считать PUE, TCO и метрики доступности с корректными допущениями.
• Защищать архитектурные решения через RTO/RPO, SLA/SLO и анализ ограничений.

FAQ: что чаще всего спрашивают на консультации

Чек-лист: что проверить перед сдачей

Типичные ошибки студентов

Источник: Wildberries запустила новый собственный дата-центр под Москвой (опубликовано 2026-03-30)