Задача
Управлять большой фермой через web-интерфейсы отдельных майнеров невозможно. Инженер обходит IP-адреса по одному, руками сравнивает хешрейт, смотрит температуру, правит настройки пула и ведёт таблицу серийных номеров, а климат и электропитание живут отдельно от всего этого.
Когда помещений становится несколько, появляются вопросы, на которые таблица не отвечает: где физически стоит устройство и свободен ли слот; хватит ли мощности и холода на новую стойку; какая прошивка установлена; кто и когда обслуживал; что лежит на складе, а что в пути; почему конкретный майнер простаивает; какой пул он использует; как рост температуры в ряду отразился на эффективности.
Главная же проблема формулируется просто: «miner offline» — это не диагноз. Пока событие не связано с моделью, серийным номером, слотом, питанием, климатом, историей ошибок, нужной деталью и назначенным инженером, оно не говорит ничего.
Решение
Физическая модель фермы. Организация → площадка → здание или контейнер → комната → ряд → стойка → слот → майнер. У каждого уровня свои параметры: таймзона площадки, назначение помещения, лимиты мощности ряда, зона охлаждения комнаты, PDU стойки, позиция ASIC. Показатели агрегируются снизу вверх — от отдельной hashboard до всей организации.
Room planner. Помещение собирается как план: ряды, стойки, число слотов, ориентация горячего и холодного коридора, привязка стойки к PDU и автомату, зона HVAC. Перед размещением майнера система проверяет ограничения по мощности, охлаждению, габаритам, сетевому порту и совместимости — то есть отказывает раньше, чем устройство донесут до стойки. Слот можно зарезервировать под ещё не приехавшее оборудование.
Идентичность устройства. Шлюз на площадке сканирует разрешённые диапазоны сети, находит совместимые ASIC и сопоставляет их с реестром по MAC, серийному номеру и fingerprint. Устойчивой идентичностью остаётся серийник: IP, пул и физическое место меняются, он — нет. Неизвестное устройство попадает в очередь onboarding и не получает массовых команд, пока его не подтвердили.
Хешрейт в связке с энергией. Для каждого ASIC считаются эффективный хешрейт, отклонение от номинала, потребление, J/TH, аптайм, доля отклонённых шар, время троттлинга, простой, стоимость энергии и вклад в выручку пула. Сравнение с такими же моделями в той же комнате сразу отвечает, локальная это проблема или общая.
Массовые команды и прошивки. Перезапуск, ребут, безопасное выключение, power cycle через управляемый PDU, смена пула, профиль питания, locate LED — с предпросмотром списка целей, подтверждением, прогрессом и результатом по каждому устройству отдельно. Прошивки принимаются только из подписанного репозитория и раскатываются волнами: проверка совместимости, небольшая canary-группа, сравнение хешрейта, мощности, ошибок и температуры до и после, расширение или остановка. Повторная отправка команды не должна выполнить её дважды, а во время прошивки система не даёт снять питание и не запускает конфликтующие команды.
Тепло и питание как ограничение, а не отчёт. Платформа связывает майнер с PDU, автоматом, щитом и счётчиком: нагрузка по фазам, доступный резерв, лимиты. Тепловая карта накладывает температуру на реальный план помещения — это и отличает неисправность одного ASIC от проблемы стойки или всей зоны охлаждения. Правила реагируют на сочетание признаков — рост температуры на входе, несколько перегретых майнеров в одной стойке, отказ кондиционера, падение расхода воздуха — и могут поднять уставку вентиляторов, включить резерв, снизить профиль питания группы, остановить раскатку прошивки или создать критичный наряд. У автоматики есть гистерезис и пауза, чтобы оборудование не переключалось каждые пять минут.
Склад, закупка и монтаж — одна цепочка. ASIC проходит 12 состояний от заявки на закупку до списания. Когда диспетчер выбирает устройство и свободный слот, система разворачивает связанный план работ: проверить наличие или создать закупку, зарезервировать позицию, проверить запас мощности и холода, назначить инженера, подготовить кабель и порт, установить, сопоставить serial, MAC и IP, применить прошивку и профиль, настроить пул, прогнать burn-in и перевести в Active.
Результат
Ферма получила один цифровой контур вместо набора несвязанных инструментов. Владелец видит экономику и доступность флота, диспетчер — размещение и состояние площадок, инженер — конкретное оборудование и свои задачи, склад и закупки работают в связке с планом расширения и ремонта.
«Miner offline» перестало быть безымянным событием: система показывает модель, серийный номер, слот в стойке, питание, климат, пул, последнюю конфигурацию, историю ошибок, нужную деталь и назначенного специалиста.
Деградацию стало видно до отказа. История температуры, оборотов вентиляторов, ошибок чипов, мощности и хешрейта складывается в оценку состояния — постепенное падение производительности, рост ошибок платы, компенсация вентиляторами, частые перезагрузки, отличие от одноимённых устройств. Результатом остаётся рекомендация на осмотр, а не автоматическая замена оборудования.
Экономика перестала считаться отдельно от эксплуатации: доход пула, курс, сложность сети, хешрейт, потребление, тариф, простой, стоимость ремонта, закупочная цена и амортизация сходятся в одном отчёте, который можно построить по площадке, комнате, модели, партии, стойке или конкретному устройству.
Каждая площадка работает через собственный шлюз с локальными правилами и офлайн-буфером, а команды имеют жёсткую привязку к площадке — сбой или компрометация одной из них не расходится на остальные.
