Как организовать управление майнинговым ЦОД: ключевые процессы и контроль

Как организовать управление майнинговым ЦОД: ключевые процессы и контроль

На небольшой майнинговой площадке многое ещё можно держать в голове.

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

Пока оборудования немного, такая схема работает.

С ростом площадки всё меняется. Асик переставили в другой контейнер, но в реестре осталось старое место. Ночная смена нашла проблему и написала о ней в Telegram, утром сообщение затерялось. Оборудование отправили в ремонт, а его статус обновили не во всех таблицах. Перед выставлением счетов приходится снова сверять время работы, тарифы и простои.

В какой-то момент сотрудники начинают тратить время уже не на саму площадку, а на выяснение, какие данные сейчас правильные.

Именно здесь управление майнинговым ЦОД перестаёт быть вопросом отдельных программ. Важно связать между собой оборудование, мониторинг, работу сотрудников, склад, расчёты и отчётность.

С мониторинга всё только начинается

Представим площадку на 2 000 асиков.

Утром оператор видит, что несколько десятков устройств работают с отклонениями. Сам по себе красный статус ещё мало о чём говорит. Нужно понять масштаб проблемы.

У одного асика снизился хешрейт?

Перегревается целый ряд?

Группа устройств одновременно пропала из сети?

Проблема появилась только в одном контейнере?

Допустим, из мониторинга одновременно исчезли 48 асиков одного контейнера. Проверять каждое устройство по отдельности — последнее, с чего стоит начинать. У этих асиков есть общий участок инфраструктуры, поэтому сначала имеет смысл проверить питание, сеть, коммутатор и сам контейнер.

Другая ситуация: из всей группы только один асик держит заметно меньший хешрейт. Здесь уже нужно смотреть конкретное устройство, его температуру, реджекты, режим работы и историю показателей.

Поэтому нормальный мониторинг асиков — это не просто список онлайн / офлайн.

Оператору важно быстро ответить на два вопроса:

что изменилось и где искать причину?

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

Но даже хороший мониторинг не решает следующую проблему.

Кто займётся асиком после сигнала мониторинга

Отклонение можно обнаружить за несколько секунд и всё равно потерять несколько часов на его устранение.

Типичная ситуация выглядит так:

В 12-м ряду просели несколько асиков, посмотрите.

Сообщение появляется в рабочем чате. Один сотрудник идёт проверять оборудование, другой параллельно спрашивает про питание. Через час в чате уже десятки новых сообщений.

К вечеру асик по-прежнему работает нестабильно.

Кто его проверял? Что уже исключили? Нужно продолжать диагностику или начинать сначала?

Если на эти вопросы отвечает только переписка, процесс слишком сильно зависит от конкретных людей.

Гораздо надёжнее, когда сигнал мониторинга превращается в задачу или инцидент.

У проблемы появляется конкретный асик или группа оборудования, ответственный, приоритет и срок. Сотрудник фиксирует результаты диагностики и выполненные действия, а после завершения остаётся история.

Получается простая цепочка:

отклонение → задача → ответственный → диагностика → действие → результат.

Она особенно важна на крупных площадках, где одновременно могут идти десятки разных работ.

Ночная смена не должна оставлять утренней загадки

Передача между сменами — ещё один процесс, который хорошо работает «на словах», пока площадка небольшая.

Допустим, ночью возникла проблема с группой асиков.

Сотрудник проверил питание — всё нормально. Проверил сеть. Нашёл один возможный источник проблемы, но закончить работу до конца смены не успел.

Утром приходит следующий оператор.

Если информация осталась только в Telegram или у сотрудника в голове, часть диагностики придётся повторять.

Новая смена снова выясняет, какие асики затронуты, что уже проверено и на каком этапе остановилась работа.

На одном инциденте потеряется 15–20 минут. Если таких задач несколько, время быстро складывается в часы.

Поэтому вместе с незавершённой задачей должны передаваться:

ответственный, результаты диагностики, комментарии, выполненные действия и текущий статус.

Тогда следующая смена продолжает работу с того же этапа.

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

У каждого асика должна быть одна история

С оборудованием возникает похожая проблема.

Асик приняли на склад. Затем установили в контейнер. Через два месяца сняли для диагностики. Потом отправили в ремонт, вернули и установили уже в другую ячейку.

Физически оборудование прошло понятный путь.

В информационных системах всё может выглядеть иначе.

В одной таблице асик ещё находится в старом контейнере.

В складском файле он уже числится в ремонте.

Оператор знает, что устройство вернулось.

Клиент видит старый статус.

И начинается выяснение, какая запись актуальная.

Поэтому у конкретного асика должен быть постоянный идентификатор и единая история.

Обычно основой становятся S/N и MAC-адрес. К ним уже привязываются модель, клиент, статус, место установки, документы, перемещения и ремонт.

Тогда вопрос:

Где сейчас этот асик?

решается не звонком кладовщику и не поиском по нескольким таблицам.

Открывается конкретный S/N — и видно последнее подтверждённое место оборудования.

То же самое работает при спорных ситуациях. Если клиент спрашивает, когда асик был снят, когда ушёл в ремонт и когда вернулся в работу, история не восстанавливается по памяти.

Она уже есть.

Складской учёт — это часть эксплуатации

На майнинговой площадке склад нельзя рассматривать отдельно от технической работы.

Допустим, оператору нужно проверить асик с определённым S/N.

Знать, что он «на площадке», недостаточно.

Нужно понимать:

площадка → контейнер → ряд → ячейка.

Эти же данные нужны при перемещении оборудования, ремонте и инвентаризации.

Если место установки отдельно записывает техническая команда, отдельно — склад, а ещё одна версия передаётся клиенту, расхождения практически неизбежны.

Лучше зафиксировать размещение один раз и использовать его дальше во всех процессах.

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

Биллинг майнинг-хостинга начинается до конца месяца

Расчёты с клиентами часто воспринимают как отдельную финансовую задачу.

Наступило первое число — берём тариф и считаем.

На практике основные данные для начисления формируются весь месяц.

Например, клиент размещает 150 асиков.

Для расчёта могут понадобиться:

• тариф;
• время работы;
• мощность оборудования;
• данные телеметрии;
• показания счётчика;
• подтверждённые простои;
• условия SLA;
• корректировки.

Если в конце месяца всё это собирается вручную, начинается знакомая история.

Техническая команда выгружает одно время работы. Финансовая использует другую таблицу. Информация о простое находится в задачах. По нескольким асикам нужно отдельно уточнять мощность.

Сам расчёт может быть правильным, но его получение занимает слишком много времени.

Намного удобнее, когда начисление можно разобрать до исходных данных:

клиент → конкретный асик → расчётный период → тариф → данные работы → корректировки → сумма.

Если клиент спрашивает, почему за определённый асик начислена именно такая сумма, ответ находится в расчёте, а не собирается заново.

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

Иногда 66,7% uptime — отличный результат

Показатели тоже легко интерпретировать неправильно, если смотреть на них без контекста.

Возьмём асик, который по установленному графику должен работать 16 часов в сутки.

Он отработал ровно 16 часов. Не перегревался, не отключался и полностью выполнил план.

Если считать календарный uptime:

16 / 24 × 100 = 66,7%.

На первый взгляд показатель выглядит слабым.

Но выполнение рабочего графика составляет:

16 / 16 × 100 = 100%.

Оставшиеся восемь часов — не простой. Асик в это время и не должен был работать.

Поэтому для площадки, где используются расписания или управляемые режимы работы, имеет смысл отдельно считать:

календарный uptime — сколько оборудование работало относительно всего времени;

выполнение графика — сколько оно отработало из запланированного времени;

незапланированный простой — когда асик не работал тогда, когда должен был.

Иначе плановое отключение оборудования будет выглядеть в отчётах как техническая проблема.

Отчёт не должен собираться заново каждый раз

Если все предыдущие процессы ведутся последовательно, отчётность становится намного проще.

Руководителю нужна общая картина по площадке: оборудование, простои, инциденты, работа смен, начисления.

Клиенту — данные по его асикам, размещению, документам и расчётам.

Финансовой команде — начисления, счета и корректировки.

Для подготовки сведений для ФНС нужен уже другой набор данных.

Но большая часть исходной информации одна и та же.

Асик уже есть в реестре.

Его клиент известен.

Место установки известно.

Время работы зафиксировано.

Инциденты и простои сохранены.

Расчёт произведён.

Если перед каждым отчётом всё это приходится снова собирать из нескольких источников, значит информация хранится не там, где возникает.

Отдельный момент — обязательная отчётность по майнингу. Требования ФНС нужно проверять непосредственно на дату подготовки или публикации материала: нормативная база меняется. Но с организационной точки зрения задача всегда проще, когда сведения об оборудовании, клиентах и его работе уже ведутся системно.

Excel становится проблемой не из-за Excel

Сам по себе Excel здесь ни при чём.

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

Хороший сигнал, что система уже перестала справляться, звучит примерно так:

Какая из этих таблиц последняя?

Или:

Асик уже переставили, но я ещё не обновил реестр.

Или:

Я вроде писал про него вчера в чат.

Другие характерные признаки:

один и тот же асик имеет разные статусы в разных местах;

по старому ремонту сложно восстановить историю;

при передаче смены сотрудники повторяют уже выполненную диагностику;

данные по S/N и MAC постоянно копируются вручную;

перед выставлением счетов несколько сотрудников сверяют цифры между собой;

физическое перемещение асика происходит сразу, а информационное — когда кто-то позже вспомнит обновить таблицу.

Здесь уже бессмысленно просто создавать ещё одну «главную таблицу».

Нужно уменьшать количество мест, куда одни и те же данные вводятся повторно.

С чего начинать автоматизацию майнингового ЦОД

Переводить всю площадку на новую систему за один день необязательно.

Проще посмотреть, где сейчас теряется больше всего времени.

Если сотрудники долго ищут проблемное оборудование — начать с мониторинга асиков.

Если отклонения замечаются быстро, но потом теряются между исполнителями — связать мониторинг с задачами и инцидентами.

Если регулярно возникают вопросы, где находится конкретное устройство, — привести в порядок склад и размещение.

Если несколько дней каждого месяца уходят на сверку начислений — заняться биллингом.

Главное, чтобы каждый следующий процесс не создавал новую копию уже существующих данных.

В идеале связь выглядит так:

асик → мониторинг → событие → задача → действие → результат → начисление → отчётность.

Тогда любой процесс можно проследить назад.

Из начисления — до исходных данных.

Из инцидента — до конкретного оборудования.

Из карточки асика — до ремонта и перемещений.

Из отчёта — до фактических событий на площадке.

Как эта логика реализована в ROC

ROC построен вокруг связанных данных по площадке, оборудованию и клиентам.

Мониторинг асиков, склад, задачи и инциденты, биллинг и отчётность работают не как отдельные программы с собственными копиями информации, а как части одного процесса.

Если мониторинг фиксирует отклонение, его можно связать с конкретным асиком и задачей сотрудника. Выполненные действия сохраняются в истории. Данные о работе оборудования могут дальше использоваться при расчётах и формировании отчётности.

При этом площадке необязательно подключать все модули сразу.

Можно начать с базового мониторинга и добавлять остальные инструменты тогда, когда они действительно нужны.

Базовый мониторинг ROC — 0 ₽ за асик.

Посмотреть, как ROC будет работать на конкретной площадке, можно на демо.