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

Парк SSD и ОЗУ из вторичного рынка в ВКР: планирование ёмкости, износ и экономика гетерогенного железа

Поддомен: Cloud/DevOps, инфраструктура и SRE. Роль эксперта: DevOps/SRE-инженер.

В марте 2026 года РИА Новости со ссылкой на CNews зафиксировали странную на первый взгляд картину: россияне массово скупают подержанные SSD и планки оперативной памяти. Причина — не кризис перекупщиков, а искусственный интеллект: дата-центры под обучающие кластеры выгребают NAND и DRAM с рынка, оставляя потребительский сегмент с пустыми полками и ценами, которые больно смотреть. Что это значит для выпускника ИТ-специальности? Ровно одно: проектировать и защищать диплом теперь придётся в парадигме дефицита. Раньше в разделе «выбор оборудования» студент писал «берём NVMe на 2 ТБ, сервер за 300 тысяч» — и это никого не смущало. Сегодня защищаемая работа должна отвечать на вопрос: как построить отказоустойчивый сервис, когда часть парка — б/у накопители с неизвестной историей износа, а бюджет урезан вдвое. Ниже — как превратить этот тренд в сильные главы ВКР, а не в абзац «актуальность обусловлена ростом цен».

Сначала ответим на то, что спросят на предзащите

Где брать реальные данные о работе дисков, если своего сервера нет?

Три источника: (1) публичные датасеты Backblaze Drive Stats — это открытые ежемесячные выгрузки по SMART-атрибутам тысяч дисков, включая модели, которые сейчас попадают на вторичный рынок; (2) собственный стенд из 2–3 б/у SSD, купленных на «Авито», с логами smartctl -a раз в сутки за 3–4 недели — этого достаточно для демонстрации методики; (3) синтетическая модель износа (гамма-процесс), валидированная на данных Backblaze. На защите честно скажите, какой источник первичный, а какой — верификационный. Это сильнее, чем «данные взяты из интернета».

Нужна ли мне настоящая Kubernetes-инфраструктура или хватит имитационной модели?

Зависит от того, что вы защищаете. Если тема — «алгоритм прогнозирования отказов», хватит расчётной модели и офлайн-валидации. Если тема — «отказоустойчивый кластер на гетерогенном железе», нужен хотя бы kind или k3s на трёх виртуалках: комиссия любит скриншоты kubectl describe node с реальными taints и labels. Развернуть k3s на трёх ВМ — это вечер работы, а вес в главе 2 — огромный.

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

Считайте TCO на горизонте 3 лет для двух сценариев: «только новое железо» и «смешанный парк (70% новое / 30% б/у)». В формулу кладите не только закупку, но и стоимость часа простоя (по данным вашего же SLO), стоимость замен и трудозатраты на обслуживание. Разница в процентах — это и есть ваш защищаемый результат. Обязательно дайте таблицу чувствительности: что будет, если доля б/у вырастет до 50%.

Как оформить схему инфраструктуры, чтобы нормоконтроль не завернул?

Схему архитектуры — по C4 (уровни Context и Container), она отлично ложится в приложение. Схемы взаимодействия компонентов и стадии создания системы — по ГОСТ 34.601-90, если у вас автоматизированная система. Качество и надёжность описывайте через атрибуты ISO/IEC 25010 (отказоустойчивость, восстанавливаемость, производительность). Не смешивайте нотации в одной схеме — это первая причина замечаний.

Темы ВКР, которые вытекают из статьи напрямую

• Тема 1. Прогнозирование остаточного ресурса SSD в смешанном парке на основе SMART-атрибутов.

  Актуальность: на вторичный рынок попадают накопители с неизвестным TBW и историей записи; статья фиксирует сам факт массовой закупки такого железа.

  Цель: построить модель оценки остаточного ресурса и правила вывода диска из эксплуатации.

  Задачи: 1) разобрать SMART-атрибуты (ID 5, 177, 231, 241) и их связь с TBW/DWPD; 2) собрать и очистить датасет; 3) обучить модель (градиентный бустинг или регрессия Вейбулла); 4) валидировать на отложенной выборке и посчитать precision/recall по классу «отказ в течение 30 дней».

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

• Тема 2. Модель TCO инфраструктуры при дефиците комплектующих.

  Актуальность: ИИ-кластеры перетягивают поставки NAND/DRAM, бюджет студенческого или корпоративного проекта не резиновый.

  Цель: разработать методику выбора конфигурации парка с минимизацией совокупной стоимости владения при заданном SLO.

  Задачи: 1) формализовать компоненты TCO; 2) построить имитационную модель отказов; 3) сравнить сценарии закупки; 4) оценить чувствительность к цене и доле б/у.

  Структура: Гл. 1 — теория TCO и SRE-метрик; Гл. 2 — реализация модели (Python + SimPy); Гл. 3 — сценарный анализ и рекомендации.

• Тема 3. Отказоустойчивый кластер Kubernetes на гетерогенном железе.

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

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

  Задачи: 1) классифицировать узлы по надёжности (labels, taints); 2) настроить репликацию хранилища; 3) развернуть мониторинг на OpenTelemetry; 4) провести chaos-эксперимент с отключением узла.

  Структура: Гл. 1 — анализ паттернов отказоустойчивости; Гл. 2 — проектирование и развёртывание; Гл. 3 — тесты на отказ и оценка RTO/RPO.

Как встроить материал статьи в главы: разбор по разделам

Глава 1. Экономический контекст вместо «актуальности» на полстраницы

Не пересказывайте новость. Разложите её на факторы и постройте C4-диаграмму уровня Context: потребительские закупки → ритейл → оптовые поставки DRAM/NAND → ИИ-дата-центры. Дальше добавьте в главу 1 небольшую таблицу влияния дефицита на архитектурные решения — она сразу показывает, что вы умеете связывать экономику и инженерию. Метрики надёжности описывайте через ISO/IEC 25010, стадии создания системы — через ГОСТ 34.601-90.

Глава 2. Сбор телеметрии и управление гетерогенным парком

Здесь вы показываете, что умеете не только рисовать, но и настраивать. Минимальный рабочий контур: smartctl_exporter на каждом узле → Prometheus → Grafana → алерт по износу. Ниже — фрагмент конфигурации, который можно вставить в приложение и защитить.

# prometheus/scrape.yml — сбор SMART с узлов смешанного парка
scrape_configs:
  - job_name: 'smartctl'
    scrape_interval: 300s
    static_configs:
      - targets:
          - 'node-01:9633'   # новые NVMe, гарантия действует
          - 'node-02:9633'   # б/у SATA SSD, история неизвестна
          - 'node-03:9633'
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

# Правило вывода узла из ротации: износ > 85% ИЛИ ошибки записи за 7 дней
groups:
  - name: storage-health
    rules:
      - alert: SsdWearCritical
        expr: smartctl_device_percentage_used > 85
        for: 1h
        labels: {severity: warning}

Дальше — правило планирования в Kubernetes. Б/у узлам выдаём метку надёжности и taint, чтобы туда не попадали stateful-нагрузки без репликации:

# Помечаем узел как «вторичный» по состоянию железа
kubectl label node node-02 hardware-trust=refurbished
kubectl taint node node-02 reliability=low:NoSchedule

# В манифесте StatefulSet требуем три реплики на разных узлах
# topologySpreadConstraints:
#   - maxSkew: 1
#     topologyKey: kubernetes.io/hostname
#     whenUnsatisfiable: DoNotSchedule

Глава 3. Метрики, которые действительно считают, а не перечисляют

Слабое место большинства ВКР — раздел «оценка эффективности», где написано «система работает быстро». Замените это на измеримые величины. Ниже — набор, который защищается без вопросов.

Формулу TCO вынесите в листинг — она станет ядром третьей главы:

TCO = Σ(CAPEX_i) + Σ(OPEX_year × 3)
      + (часы_простоя × стоимость_часа)
      + (замены_дисков × цена_диска_вторичного_рынка)
      + (трудозатраты_на_обслуживание × ставка_инженера)

# Сценарий A: только новое железо
# Сценарий B: 70% новое / 30% refurbished
# ΔTCO = (TCO_A - TCO_B) / TCO_A × 100%

Схемы, которые стоит построить: C4-диаграмма контейнеров (сборщик телеметрии, хранилище метрик, планировщик, API отчётов); UML sequence для сценария «деградация узла → алерт → миграция нагрузки»; BPMN для процесса закупки и ввода б/у комплектующего в парк. Три схемы — три разных нотации, комиссия это отмечает отдельно.

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

• Проектировать отказоустойчивые схемы хранения с учётом неоднородного железа и реальных бюджетов.
• Настраивать сбор телеметрии через OpenTelemetry/Prometheus и формулировать алерты по износу, а не по факту падения.
• Считать TCO и SLO так, чтобы цифры выдерживали перекрёстные вопросы комиссии.
• Оформлять схемы по C4, UML и ГОСТ 34.601-90, не смешивая нотации.
• Проводить chaos-эксперименты и корректно интерпретировать RTO/RPO.

Источник: Новых на всех не хватает. В России расцвел рынок подержанных SSD и оперативной памяти (опубликовано 2026-03-24)