ROC Platform - Мониторинг майнеров и управление майнинговым ЦОД.

[ROC Platform]

ROC — платформа для мониторинга ASIC и управления майнинговым ЦОД.

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

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

ROC объединяет основные процессы майнингового ЦОД в одной системе — от контроля оборудования до работы сотрудников и расчётов с клиентами.

ROC — мониторинг майнеров и система управления майнинговым ЦОД
Коллеги, привет!

Хотим рассказать о ROC — платформе для мониторинга майнеров и управления майнинговым ЦОД.

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

При этом мониторинг можно использовать отдельно от остальных возможностей платформы — базовый мониторинг ROC доступен бесплатно.

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

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

Мониторинг майнеров
Мониторинг — одна из основных функций ROC.

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

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

 

 

В ROC можно отслеживать:

• текущий статус майнера

• хешрейт и его отклонения;
• температуру;
• uptime;
• reject;
• потерю связи;
• нарушения заданного режима работы;
• плановые и незапланированные простои.

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

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

Базовый мониторинг — 0 ₽ в месяц.

А что происходит после того, как нашли проблему?
Сам по себе мониторинг отвечает на важный вопрос: что сейчас происходит с оборудованием?

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

Где он находится?
Кому принадлежит?
Что именно с ним произошло?
Кто должен заняться проблемой?
Что с ним уже делали раньше?
Сколько времени он находится в простое?
Нужно ли учитывать этот простой при расчётах с клиентом?

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

Поэтому помимо мониторинга в ROC есть инструменты для управления другими процессами майнингового ЦОД.

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

ROC это фиксирует.

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

Если майнер нужно снять, заменить, отправить в ремонт или переместить в другое место — это можно отразить в учёте оборудования.

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

А накопленные данные — при формировании внутренних, клиентских и регламентированных отчётов.

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

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

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

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

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

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

Ссылки и контакты
Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: @roc_support

[ROC Platform]

Модули ROC — что входит и для чего они нужны

В прошлом посте мы уже рассказывали про ROC в целом. Здесь хотим отдельно пройтись по модулям — что есть сейчас и за что каждый отвечает.

ROC модульный, поэтому не обязательно сразу подключать всё.

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

Сейчас в ROC есть:

Мониторинг майнеров
Инфраструктура и управление майнерами
Склад и история оборудования
Задачи и инциденты
Биллинг
Отчёты

Начнём с самого базового.

---

Мониторинг майнеров

Это основа ROC.

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

В базовом мониторинге есть основные показатели майнеров, поиск, фильтрация и сортировка.

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

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

Подключение и базовый мониторинг ROC бесплатны.

---

Инфраструктура и управление майнерами

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

Нужно понимать, где именно стоит конкретный аппарат.

В ROC для этого есть структура:

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

Каждый майнер можно привязать к своему месту.

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

То есть здесь уже можно не только смотреть на состояние оборудования, но и работать с тем, где оно находится и как должно работать.

---

Склад и история оборудования

Со складом, думаю, многим ситуация знакома.

Майнер приехал, его приняли, потом установили. Через какое-то время перенесли, потом отправили в ремонт, потом вернули обратно.

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

В ROC для каждого майнера сохраняются S/N, MAC-адрес, место установки, связанные документы, перемещения и история операций.

Оборудование можно принять, выдать, переместить или отправить в ремонт.

Если нужно быстро найти конкретный майнер, можно отсканировать S/N или MAC-адрес и сразу открыть его карточку.

В истории остаётся информация о том, где находилось оборудование, кто выполнял операцию и когда это было.

На основе складских данных формируются акты приёмки, перемещения, ремонта и выдачи.

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

---

Задачи и инциденты

Мониторинг увидел проблему. Дальше с ней кто-то должен что-то сделать.

Для этого в ROC есть задачи и инциденты.

Событие из мониторинга можно зафиксировать как инцидент. Обращения клиентов и обычные рабочие задачи тоже можно вести в общей очереди.

Для задачи назначается ответственный, приоритет и срок SLA.

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

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

Есть передача задач между сменами.

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

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

---

Биллинг

Здесь всё строится вокруг фактической работы оборудования.

В ROC майнер связывается с клиентом, тарифом и расчётным периодом.

Сейчас есть четыре варианта расчёта.

По формуле

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

По телеметрии

Расчёт строится по фактическим данным телеметрии поддерживаемых моделей майнеров.

По ручным показаниям

Сотрудник вручную вносит показания счётчика для контейнера или выбранной зоны.

Счётчик + ROC

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

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

Кроме расчёта, в модуле есть начисления, корректировки, история расчётов и формирование счетов.

Счёт можно выставить в личном кабинете или сформировать в PDF.

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

Там будут видны S/N, период, тариф, время работы, мощность, простои, корректировки и итоговая сумма.

---

Отчёты

Раз данные уже есть в системе, дальше их можно использовать и для отчётности.

В ROC доступны календарный uptime, выполнение графика работы оборудования, внутренние отчёты, отчёты для клиентов и подготовка данных для ФНС.

Календарный uptime и выполнение графика считаются отдельно.

Например, майнер должен работать 16 часов из 24 и все эти 16 часов он отработал.

Календарный uptime будет 66,7%, а выполнение графика — 100%.

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

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

Используются форматы PDF, XLSX и XML. Часть данных можно смотреть прямо в ROC и в личном кабинете.

Также ROC поддерживает подготовку данных квартального отчёта оператора майнинговой инфраструктуры КНД 1111664 в формате ФНС 4.02 с выгрузкой ZIP с XML.

Перед формированием можно проверить полноту данных, расхождения и ошибки.

Здесь важный момент: ROC подготавливает данные для отчёта. Юридическую проверку и отправку в ФНС выполняет сама организация.

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

---

В целом логика ROC простая.

Если нужен только мониторинг — используете только мониторинг.

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

Не обязательно сразу внедрять всё.

---

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram для связи и поддержки: @roc_support

[ROC Platform]

Как ROC помогает быстрее находить проблемы с майнерами

В прошлом посте мы подробно разобрали модули ROC. Теперь хотим отдельно остановиться на мониторинге - это основа системы и то, с чего обычно начинается работа оператора.

Главная задача мониторинга простая - не заставлять человека вручную просматривать большое количество оборудования в поисках проблемного майнера.

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

Что можно увидеть в мониторинге

По каждому майнеру в ROC отображаются основные рабочие параметры.

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

Отдельно учитываются плановые и незапланированные простои.

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

Для нас это важный момент, потому что просто видеть "майнер не работает" недостаточно. Нужно понимать, должен ли он вообще работать в этот момент.

Не искать проблему вручную

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

В ROC можно использовать поиск, фильтрацию и сортировку.

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

Если известен конкретный майнер, его можно найти по серийному номеру.

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

Сначала смотрим общую картину, потом идём глубже

Обычно работа начинается не с карточки конкретного устройства, а с общей картины.

Оператор видит, что часть оборудования работает нормально, а часть требует внимания.

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

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

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

Мониторинг - это только первый шаг

Сам по себе мониторинг отвечает на вопрос: что сейчас происходит с оборудованием?

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

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

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

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

Подключение и базовый мониторинг ROC доступны бесплатно.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Что происходит после того, как мониторинг нашёл проблему: задачи и инциденты в ROC

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

Но увидеть проблему - это только начало.

Дальше нужно понять, кто будет с ней разбираться, что уже проверили, чем закончилась работа и не потеряется ли всё это при передаче следующей смене.

Для этого в ROC есть задачи и инциденты.

От мониторинга к конкретной работе

Допустим, оператор увидел майнер с отклонением.

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

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

В ROC для этого можно создать задачу или инцидент.

Внутри указывается ответственный, приоритет и срок SLA.

Дальше вся работа по проблеме остаётся в одной карточке.

Что сохраняется внутри задачи

По ходу работы сотрудник может добавлять информацию о том, что уже было сделано.

В карточке сохраняются:

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

То есть через какое-то время не приходится вспоминать, кто именно смотрел этот майнер и что с ним делали.

Можно открыть задачу и посмотреть историю.

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

Если проблема затронула сразу несколько майнеров

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

Например, мониторинг показывает похожее отклонение сразу у группы майнеров.

Разбирать каждое событие отдельно в такой ситуации не всегда удобно.

В ROC связанные проблемы можно объединить в один инцидент.

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

Внутри можно вести диагностику и фиксировать, что происходит.

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

Передача между сменами

Ещё одна обычная ситуация - сотрудник начал разбираться с проблемой, но до конца смены закончить не успел.

Если просто передать следующей смене словами "посмотрите этот майнер", часть информации легко потеряется.

Что уже проверяли?

Какие действия выполняли?

Что осталось сделать?

В ROC задача может быть передана следующей смене вместе со всей накопленной информацией.

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

Не приходится каждый раз начинать всё заново.

Задачи бывают не только из мониторинга

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

В общей очереди можно вести обычные рабочие задачи и обращения клиентов.

То есть сотрудник видит не только технические инциденты по майнерам, но и другую работу, которую нужно выполнить в течение смены.

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

Так проще понимать, что нужно делать сейчас, а что может подождать.

Что видит руководитель

Для руководителя важен уже немного другой уровень.

Нужно понимать не только, что задача существует, но и как сотрудники с ней работают.

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

То есть задачи становятся не просто списком "что надо сделать", а ещё и историей того, как отрабатываются проблемы на площадке.

Почему мы связали задачи с мониторингом

Логика здесь достаточно простая.

Мониторинг отвечает на вопрос:

что произошло с оборудованием?

Задачи и инциденты отвечают на следующий:

что мы с этим сделали?

Если эти вещи существуют отдельно друг от друга, часть информации приходится передавать вручную - в чатах, таблицах или просто между сменами.

В ROC мы стараемся оставить весь рабочий контекст рядом с самой проблемой.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

Edited 11 Sep 2026, 09:06 by ROC Platform

[ROC Platform]

Что происходит с майнером после снятия с площадки: склад и история оборудования в ROC

В прошлом посте рассказывали про задачи и инциденты - что происходит после того, как мониторинг заметил проблему и ей уже занимается конкретный сотрудник.

Но иногда на этом работа с асиком не заканчивается.

Его могут снять с места, перенести, отправить в ремонт, потом вернуть обратно. Через какое-то время уже важно не просто знать, что майнер сейчас находится на складе или снова работает, а понимать, что с ним происходило до этого.

Для этого в ROC есть склад и история оборудования.

У каждого майнера своя история

В ROC майнер можно найти по S/N или MAC-адресу и открыть его карточку.

Там сохраняется история операций с ним.

Если асик приняли, установили, потом переместили или отправили в ремонт - эти действия не пропадают после того, как его статус поменялся.

Можно посмотреть, где он находился раньше, когда его перемещали и кто выполнял операцию.

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

Если майнер сняли

Допустим, сотрудник разбирался с проблемой и стало понятно, что асик нужно снять.

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

Его можно переместить на склад или дальше отправить в ремонт.

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

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

Поиск по S/N и MAC

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

В ROC для этого можно использовать S/N или MAC-адрес.

Их можно отсканировать и сразу открыть нужный майнер.

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

Из карточки уже видно, что это за майнер и какие операции с ним проводились раньше.

Приёмка, перемещение, ремонт, выдача

Со складом мы старались не делать отдельный список, где просто написано, сколько майнеров сейчас лежит.

В работе важнее сами операции.

Майнер можно принять, выдать, переместить или отправить в ремонт.

По этим действиям сохраняется история.

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

На основе складских операций также можно формировать документы по приёмке, перемещению, ремонту и выдаче.

С ремонтом история особенно полезна

Когда асик один раз съездил в ремонт, обычно всё понятно и без сложного учёта.

Но со временем один и тот же майнер может проходить через ремонт несколько раз.

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

В ROC также можно учитывать стоимость ремонта и транспортировки.

Получается, что по майнеру остаётся не только факт того, что он когда-то был в ремонте, но и сама история связанных с ним операций.

Зачем связывать это с остальной системой

Склад у нас не существует отдельно от мониторинга и работы сотрудников.

Сначала майнер работает на своём месте.

Если с ним появляется проблема, это видно в мониторинге и инцидентах.

Сотрудник получает задачу и разбирается.

Если асик нужно снять, дальше уже начинается работа со складом или ремонтом.

А когда он возвращается, история никуда не пропадает.

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

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Биллинг майнинга: как считать работу майнеров и начисления клиентам в ROC

В прошлом посте рассказывали про склад и историю оборудования. Майнер может работать на площадке, потом его снимают, перемещают или отправляют в ремонт, а все эти операции остаются связаны с конкретным асиком.

Теперь хотим отдельно рассказать про биллинг.

Здесь уже другая задача. Нужно связать конкретный асик с клиентом, тарифом и расчётным периодом, а потом получить начисление на основе тех данных, которые используются на площадке. В ROC для этого сейчас есть четыре варианта расчёта.

Первый вариант - расчёт по формуле

В этом случае используется время работы асика из мониторинга и мощность с учётом модели и прошивки.

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

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

Второй вариант - телеметрия

Для поддерживаемых моделей асиков расчёт можно строить по фактическим данным телеметрии.

Это отдельный вариант расчёта, а не дополнение к формуле выше.

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

Если показания счётчика вносятся вручную

Третий вариант - ручной ввод показаний.

Сотрудник вносит показания счётчика по контейнеру или выбранной зоне, после чего эти данные используются для расчёта.

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

Счётчик + ROC

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

В этом случае ROC автоматически получает показания счётчика, проверяет их и распределяет данные по клиентам.

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

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

При этом модель можно выбирать под данные конкретной площадки, контейнера или зоны. 

Что можно проверить в самом начислении

Для нас здесь важна не только итоговая сумма.

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

В ROC расчёт можно открыть до конкретного асика. В детализации видны S/N, расчётный период, тариф, время работы, мощность, простои, корректировки и итоговая сумма. 

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

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

ROC также хранит версии расчёта, корректировки и историю изменений.

Простои тоже попадают в расчёт

Мы уже писали про простои в постах о мониторинге.

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

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

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

При этом сам факт инцидента ещё не означает какой-то конкретный перерасчёт. Для начисления нужно смотреть используемую модель расчёта, тариф и применимые условия. На сайте ROC это отдельно оговаривается при описании проверки начислений. 

После расчёта можно сформировать счёт

Когда начисления проверены, в ROC можно сформировать счёт.

Счета и детализация доступны в личном кабинете клиента, также предусмотрено формирование документов в PDF. История расчётов при этом сохраняется. 

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

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

Как биллинг связан с тем, о чём мы писали раньше

В предыдущих постах мы постепенно проходили путь одного майнера внутри ROC.

Сначала он работает на площадке, и его состояние видно в мониторинге. Если появляется проблема, она переходит в работу через инциденты и задачи. Если асик снимают, перемещают или отправляют в ремонт, это остаётся в истории оборудования.

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

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

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

Edited 18 Sep 2026, 08:30 by ROC Platform

[ROC Platform]

Отчёты в ROC: uptime, выполнение графика и подготовка отчётности для ФНС

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

Теперь перейдём к отчётам.

Большая часть нужной информации уже есть в ROC: майнеры, их работа, простои, размещение, клиенты, задачи и расчёты. Поэтому для отчёта не нужно каждый раз заново собирать всё по разным местам.

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

Календарный uptime и выполнение графика - не одно и то же

Здесь легко получить неправильную картину, если смотреть только на обычный uptime.

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

За сутки он отработал все запланированные 16 часов без незапланированных остановок.

Если считать uptime относительно всех 24 часов, получится 66,7%.

Но свой график майнер выполнил полностью - 100%.

Для ROC это два разных показателя.

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

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

Отчёт не обязательно делать по всей площадке

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

В ROC можно выбрать период и нужную часть оборудования.

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

Отчёты для клиентов и внутренней работы

У руководителя площадки и у клиента обычно разные вопросы.

Внутри ЦОД могут смотреть uptime, выполнение графика и другие данные по работе оборудования. Клиенту чаще нужна информация именно по его майнерам.

Поэтому отчёты можно собирать под конкретную задачу.

Часть информации доступна прямо в ROC и в личном кабинете. Для разных отчётов предусмотрены выгрузки в PDF, XLSX и XML.

Регулярные отчёты

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

Можно настроить периодичность и получателей.

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

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

Отдельно есть подготовка отчётности для ФНС

В ROC также можно подготовить квартальный отчёт оператора майнинговой инфраструктуры для ФНС.

Здесь речь именно об операторе, который предоставляет майнерам инфраструктуру.

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

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

После проверки ROC формирует XML-файл для дальнейшей подачи отчётности.

Сам ROC отчёт в ФНС не отправляет.

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

Сначала данные, потом файл

Здесь нам кажется важным сам порядок работы.

Можно сделать кнопку, которая сразу формирует XML. Но если внутри не хватает нужных данных, от этого пользы немного.

Поэтому сначала идёт проверка.

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

Если к отчёту потом пришлось вернуться и что-то исправить, история изменений остаётся в системе.

Отчёты стали продолжением того, что уже есть в ROC

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

Сначала мониторинг показывает, что происходит с майнерами.

Если появляется проблема, она переходит в инциденты и задачи.

Если асик снимают, перемещают или отправляют в ремонт, это остаётся в истории оборудования.

Биллинг использует данные работы для начислений.

А отчёты уже собирают нужную информацию за выбранный период.

Поэтому нам не хотелось делать отчётность отдельным процессом, который начинается только тогда, когда кому-то понадобился файл.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Управление майнерами в ЦОД: размещение, группы, пулы и графики работы в ROC

В прошлом посте рассказывали про отчёты в ROC - uptime, выполнение графика, отчёты для клиентов и подготовку данных для ФНС.

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

Когда оборудования немного, многое ещё можно держать в голове. Примерно знаешь, где стоит нужный асик, какие майнеры относятся к конкретному клиенту и как они должны работать.

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

Сначала нужно нормально разложить оборудование по площадке

В ROC для этого есть структура размещения:

площадка -> контейнер -> ряд -> ячейка

К конкретному месту можно привязать майнер.

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

Если место уже указано в ROC, оператор сразу видит, куда идти.

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

История размещения при этом сохраняется. Если асик раньше стоял в одном месте, а потом его переставили, старое размещение не просто исчезает.

Размещение со временем меняется

На работающей площадке оборудование не стоит годами в одной и той же ячейке.

Асик могут снять из-за ремонта, временно переставить, вернуть обратно или поставить уже в другое место.

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

В ROC перемещения остаются в истории оборудования.

Это пересекается со складом, про который мы уже писали раньше. Майнер можно проследить не только пока он работает в контейнере, но и после снятия.

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

Когда майнеров много, удобнее работать с группами

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

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

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

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

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

Работа с пулами

В ROC можно задавать разрешённые пулы и использовать автоматическое переключение.

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

Если на площадке действуют определённые правила по пулам, их можно учитывать в ROC.

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

Режимы и графики работы

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

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

В ROC можно задавать режимы и графики работы оборудования.

Эта часть потом связана и с отчётами.

В прошлом посте мы приводили пример: майнер должен работать 16 часов в сутки и все эти 16 часов отработал. Календарный uptime у него будет 66,7%, но выполнение установленного графика - 100%.

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

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

Клиентское оборудование тоже нужно отделять

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

В ROC для этого есть клиентские кабинеты и связь оборудования с клиентами.

Дальше эта же информация используется в других частях системы.

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

То есть принадлежность майнера не приходится отдельно восстанавливать перед каждым расчётом или отчётом.

Почему мы вообще выделяем инфраструктуру в отдельную часть ROC

Мониторинг сам по себе отвечает в основном на вопрос: что сейчас происходит с майнером?

Но для работы ЦОД этого мало.

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

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

Особенно это чувствуется, когда оборудования уже много.

Строка с S/N говорит, какой именно асик перед нами. Но площадка -> контейнер -> ряд -> ячейка говорит, где его искать.

И это уже совсем другой уровень информации.

В итоге мониторинг и управление работают рядом

В ROC мониторинг можно использовать отдельно - подключение и базовый мониторинг бесплатны.

Если этого достаточно, остальные функции подключать необязательно.

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

Так оператор видит не просто список асиков, а понимает, где они находятся и как должны работать.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Майнер не отображается в сети: причины, что делать и как найти проблему с помощью ROC

В прошлом посте рассказывали про управление майнерами в ROC - размещение по площадке, группы, пулы, режимы и графики работы.

Теперь разберём более конкретную ситуацию: майнер перестал отображаться в сети.

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

В ROC это можно сделать через мониторинг, размещение оборудования и инциденты.

Почему майнер может перестать отображаться в сети

Причины могут быть разными.

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

Поэтому сам статус offline ещё не говорит, что именно произошло.

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

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

Сначала смотрим, один майнер пропал или несколько

В мониторинге ROC видно состояние асиков и потерю связи.

Если offline только один майнер, можно открыть его и дальше разбираться именно с ним.

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

Это уже даёт первое понимание ситуации.

Один offline и двадцать offline одновременно - это совершенно разные случаи, даже если внешне в мониторинге они выглядят одинаково.

Проверяем, где находятся проблемные ASIC

Следующий шаг - посмотреть размещение.

В ROC используется структура:

площадка -> контейнер -> ряд -> ячейка

К каждому месту можно привязать конкретный майнер.

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

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

Если они находятся в разных частях площадки, ситуация выглядит иначе.

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

Почему размещение здесь важно

Когда асик просто отображается в списке по S/N, этого хватает, пока всё работает нормально.

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

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

Он видит контейнер, ряд и ячейку прямо в системе.

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

Если пропала группа майнеров

Когда offline уходит сразу несколько асиков, важно проверить, что их объединяет.

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

При этом не стоит автоматически считать, что причина у всех одна.

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

Поэтому задача мониторинга на этом этапе - помочь собрать картину. А уже после этого сотрудник проверяет оборудование на месте.

Что происходит после того, как проблема найдена в мониторинге

Если с асиком что-то происходит, это отображается в инцидентах ROC.

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

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

Получается, что проблема не остаётся просто строкой offline в мониторинге.

Появляется понятная история: какой майнер перестал отвечать, кто взял задачу и что с ним происходило дальше.

Если проблема затронула сразу несколько ASIC

Связанные проблемы можно объединять.

Это удобно, когда одновременно пропало несколько майнеров и сотрудник работает с одной общей ситуацией.

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

При этом конкретные майнеры всё равно остаются видны отдельно.

Можно посмотреть, какие асики были затронуты и что происходило с каждым из них.

Что получает сотрудник

Когда задача назначена, сотрудник видит конкретный майнер и его размещение.

То есть вместо сообщения вроде «несколько асиков не работают, посмотри» у него уже есть список оборудования и понимание, где его искать.

Дальше начинается обычная диагностика на площадке.

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

На небольшом ЦОД часть таких вещей можно держать в голове.

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

Можно посмотреть историю майнера

Если асик раньше уже перемещали, это остаётся в его истории.

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

При разборе текущей проблемы эту историю можно открыть и посмотреть.

Она не обязательно объяснит причину текущего offline, но информация не теряется.

Не приходится заново восстанавливать, где раньше находился асик и что с ним происходило.

Передача проблемы между сменами

Не каждая проблема решается сразу.

Иногда сотрудник начал диагностику, но его смена закончилась. Тогда работу продолжает другой человек.

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

В ROC история остаётся внутри инцидента и задачи.

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

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

Что делать после восстановления связи

После устранения проблемы майнер снова появляется в мониторинге.

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

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

Так можно понять, восстановилась ли работа полностью.

Результат диагностики и выполненные действия при этом остаются в истории инцидента.

Если майнер снова пропадёт из сети

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

Когда история по майнеру сохраняется, можно посмотреть предыдущие инциденты и выполненные действия.

Это не означает, что причина обязательно будет той же.

Но сотруднику уже доступен контекст: происходило ли подобное раньше и что тогда проверяли.

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

Как выглядит весь процесс в ROC

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

Мониторинг показывает, что майнер перестал отвечать. Если offline несколько асиков, оператор смотрит их вместе и проверяет размещение.

После этого проблема попадает в инциденты, назначается сотрудник и начинается диагностика.

В процессе сохраняются комментарии, фотографии и результат.

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

То есть offline в мониторинге - это только начало работы с проблемой.

Что важно проверить, если майнер не отображается в сети

В первую очередь стоит понять, пропал один асик или сразу несколько.

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

После этого уже можно назначать сотрудника и переходить к проверке на месте.

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

В следующем посте разберём другую ситуацию - майнер остаётся online, но у него падает хешрейт, растёт температура или появляются другие отклонения. Там подход уже немного другой, потому что связь с асиком есть, но работает он не так, как должен.

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Падает хешрейт ASIC: причины, что проверить и как найти проблему с помощью ROC

В прошлом посте разбирали ситуацию, когда майнер вообще перестал отображаться в сети. С offline всё достаточно понятно: связи с асиком нет, оператор видит проблему и дальше начинает разбираться, что произошло.

Но бывает другая ситуация.

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

Здесь одного статуса online уже недостаточно. Нужно смотреть на сами показатели майнера и понимать, насколько его текущая работа отличается от нормальной.

Если майнер online, это ещё не значит, что с ним всё нормально

В ROC по асикам видны статус, хешрейт, температура, uptime, reject и другие данные мониторинга.

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

Если асик остаётся online, но хешрейт начал снижаться, это уже отклонение, которое можно проверить дальше.

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

Сначала смотрим сам хешрейт

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

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

Если похожее отклонение появилось сразу у группы, уже имеет смысл посмотреть их вместе.

В ROC для этого есть поиск, фильтры и сортировка. Можно быстро выделить нужные майнеры и понять масштаб ситуации.

Это тот же принцип, что и с offline: сначала общая картина, потом уже конкретный асик.

Проверяем температуру

Следующий показатель, который имеет смысл посмотреть рядом с хешрейтом, - температура.

Если производительность майнера изменилась, а вместе с этим видно отклонение по температуре, у оператора появляется дополнительная информация для диагностики.

Сам ROC не определяет техническую причину вместо сотрудника.

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

Для мониторинга здесь важно другое - проблема становится заметна ещё до того, как майнер полностью пропал из сети.

Смотрим reject

Ещё один показатель - reject.

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

Поэтому смотреть только на статус или только на одну цифру хешрейта недостаточно.

В ROC reject находится в том же мониторинге вместе с остальными данными по асикам.

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

Один ASIC или сразу группа

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

Например, где они находятся физически.

В ROC используется структура:

площадка -> контейнер -> ряд -> ячейка

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

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

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

После мониторинга проблема переходит в работу

Когда оператор видит отклонение, дальше с ним должен кто-то работать.

Если с асиком что-то происходит, это отображается в инцидентах ROC.

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

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

То есть падение хешрейта не остаётся просто строкой в мониторинге.

Появляется конкретная проблема, ответственный сотрудник и история того, что с майнером делали.

Если проблема касается нескольких майнеров

Связанные инциденты можно группировать.

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

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

При этом каждый конкретный асик всё равно остаётся виден отдельно.

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

Сотрудник сразу понимает, где искать майнер

После назначения задачи сотруднику нужно физически найти асик.

Если размещение ведётся в ROC, для этого не приходится отдельно искать оборудование по таблицам.

У майнера уже указаны площадка, контейнер, ряд и ячейка.

Оператор увидел отклонение в мониторинге, передал задачу, сотрудник открыл асик и понимает, куда ему идти.

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

Особенно когда оборудование периодически переставляют.

Если подобное уже происходило раньше

Бывает, что проблема повторяется.

В таком случае полезно посмотреть историю конкретного майнера и предыдущие инциденты.

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

Это не значит, что новая проблема обязательно имеет ту же причину.

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

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

Если за одну смену проблему не решили

Не каждое отклонение удаётся закрыть сразу.

Иногда сотрудник уже провёл часть диагностики, но задача переходит следующей смене.

В ROC комментарии, фотографии и результаты проверки остаются внутри инцидента.

Следующий сотрудник видит, что уже было сделано.

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

Без истории такая задача легко превращается в повторение одних и тех же действий каждой новой сменой.

Что проверить после работы с ASIC

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

Проверить хешрейт, температуру, reject и остальные показатели.

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

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

Если асик пришлось снять и отправить в ремонт, дальше его история продолжается уже через склад и перемещения в ROC.

Не стоит ждать, пока ASIC полностью уйдёт в offline

В этом и есть главное отличие от ситуации из прошлого поста.

Когда майнер перестал отвечать, проблема уже очевидна.

При снижении хешрейта асик может продолжать отображаться в сети. Если смотреть только на online/offline, его легко пропустить.

Поэтому мониторинг в ROC строится не только вокруг статуса соединения.

Оператор видит хешрейт, температуру, reject и другие показатели и может заметить отклонение раньше.

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

Что в итоге

Если у ASIC падает хешрейт, сначала стоит посмотреть не только на сам хешрейт, но и на остальные показатели.

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

В ROC мониторинг помогает собрать эту информацию в одном месте.

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

Так можно работать не только с полностью пропавшими из сети майнерами, но и с асиками, которые остаются online, но уже работают не так, как должны.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

Edited 24 Sep 2026, 06:23 by ROC Platform

[ROC Platform]

Перегрев ASIC: причины, что проверить при высокой температуре майнера и как работать с проблемой в ROC

В прошлом посте разбирали ситуацию, когда майнер остаётся online, но у него начинает падать хешрейт.

Теперь отдельно поговорим про температуру.

Асик может продолжать работать и отображаться в мониторинге, но температура уже начинает расти. Если смотреть только на статус online/offline, такую проблему легко пропустить. Поэтому в ROC температура отображается вместе с другими показателями майнера.

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

Высокая температура ASIC - сначала смотрим общую картину

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

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

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

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

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

По тому, где растёт температура, уже можно понять, куда смотреть

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

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

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

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

Другая ситуация - перегреваются асики только на определённой полке или в одной части контейнера.

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

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

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

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

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

То есть уже по масштабу проблемы можно примерно понять направление проверки.

Если перегревается весь контейнер - смотрим общую систему отвода тепла и воздушный поток.

Если перегревается конкретная полка или группа асиков - проверяем вентиляцию именно в этой зоне.

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

ROC здесь помогает увидеть эту картину ещё до того, как сотрудник пойдёт к оборудованию.

Температуру лучше смотреть вместе с хешрейтом

Одна цифра сама по себе даёт не так много информации.

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

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

В ROC эти данные находятся рядом, поэтому оператору не нужно сначала замечать температуру в одном месте, а потом искать остальные показатели где-то ещё.

Так проще понять, что происходит с майнером в целом.

Проверяем reject и остальные показатели

Помимо температуры и хешрейта, в мониторинге ROC можно посмотреть reject, uptime, состояние связи и другие данные по майнеру.

Это не значит, что по набору цифр система автоматически определит техническую причину перегрева.

Задача мониторинга здесь другая - показать отклонение и дать сотруднику данные, с которыми он дальше будет работать.

Например, температура выросла, но майнер всё ещё online. Оператор видит это до того, как асик полностью перестал отвечать.

Где находится проблемный майнер

После того как конкретный асик найден в мониторинге, его ещё нужно найти физически.

В ROC майнер связан со структурой площадки:

площадка -> контейнер -> ряд -> ячейка

Поэтому сотрудник может сразу посмотреть, где стоит нужный майнер.

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

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

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

Если перегревается сразу несколько ASIC

Представим, что оператор видит повышение температуры сразу у нескольких майнеров.

Сначала он смотрит сами асики, потом их размещение.

Если они находятся в одной части площадки, сотрудник уже понимает, куда идти для проверки.

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

ROC помогает увидеть эту разницу до выхода сотрудника к оборудованию.

Что происходит после обнаружения проблемы

Если с асиком что-то происходит, это отображается в инцидентах ROC.

По проблеме можно назначить задачу конкретному сотруднику, указать приоритет и срок.

Дальше в задаче остаётся история работы: комментарии, фотографии, диагностика и результат.

То есть высокая температура не остаётся просто цифрой в мониторинге, которую кто-то заметил и потом забыл.

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

Если проблема касается группы майнеров

Связанные проблемы в ROC можно группировать.

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

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

При этом сами асики всё равно остаются видны отдельно.

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

Что фиксировать во время диагностики

Когда сотрудник приходит к оборудованию, дальше начинается обычная работа на площадке.

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

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

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

Это особенно важно, если проблема не решилась сразу.

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

Если задача переходит следующей смене

Перегрев не всегда заканчивается быстрым решением.

Сотрудник может провести часть проверки, но задача останется открытой.

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

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

Для круглосуточного ЦОД это обычная ситуация, поэтому история работы по проблеме иногда не менее важна, чем сам момент её обнаружения.

После работы снова проверяем температуру

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

Что происходит с температурой, изменился ли хешрейт, какой reject, остаётся ли асик online.

Если проблема касалась нескольких майнеров, проверяется уже вся группа.

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

Так видно, повлияли ли выполненные действия на проблему.

Если ASIC пришлось снять

Не каждую проблему удаётся решить на месте.

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

После снятия он не исчезает из ROC.

Сохраняются перемещения оборудования и дальнейшая история ремонта.

Получается связанная цепочка: мониторинг показал отклонение по температуре, появился инцидент, сотрудник провёл диагностику, после чего асик при необходимости сняли и отправили дальше.

Почему одного статуса online недостаточно

Статус отвечает на простой вопрос: есть ли сейчас связь с асиком.

Но он не показывает всей картины его работы.

Майнер может оставаться online, а температура уже растёт. Точно так же он может продолжать отвечать, но при этом терять хешрейт или показывать другие отклонения.

Поэтому в ROC мониторинг строится не только вокруг online/offline.

Оператор видит сами показатели и может начать работать с проблемой ещё до того, как асик полностью перестанет отвечать.

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

Один горячий асик, целая полка и весь контейнер - это три разные ситуации, и проверку в каждом случае логично начинать с разных мест.

Что в итоге

Если у ASIC растёт температура, сначала стоит понять масштаб проблемы.

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

Дальше можно посмотреть хешрейт, reject и остальные показатели, найти проблемные асики по размещению и передать ситуацию сотруднику.

В ROC проблема переходит в инцидент и задачу, а комментарии, фотографии, диагностика и результат остаются в истории.

Если майнер приходится снимать, его дальнейшее перемещение и ремонт продолжают учитываться в системе.

В следующем посте разберём ещё один показатель - высокий reject. Посмотрим, что оператор видит в ROC, почему reject лучше оценивать вместе с хешрейтом и что делать, если отклонение появилось сразу у группы майнеров.

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Как посчитать доходность майнера с учетом хешрейта, времени работы и потребления с помощью ROC

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

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

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

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

Почему текущего хешрейта недостаточно

Допустим, сейчас майнер показывает нормальный хешрейт.

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

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

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

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

Смотрим, сколько часов майнер реально работал

Второй важный показатель - время работы.

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

В ROC можно посмотреть фактическое время работы майнера за выбранный период.

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

Здесь уже не нужно исходить из стандартного расчета 24 часа × количество дней в месяце. Можно использовать реальные часы работы конкретного майнера.

Откуда брать доход от майнинга

ROC сам не получает данные о добытой монете и не рассчитывает итоговую доходность майнера.

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

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

Главное, чтобы все данные относились к одному периоду.

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

Как посчитать расходы на электричество

После дохода нужно понять, сколько за этот же период ушло на электроэнергию.

В ROC можно посмотреть потребление конкретного майнера за выбранный период.

Дальше расчет простой:

Потребление электроэнергии × стоимость 1 кВт⋅ч = расходы на электричество

Здесь тоже есть разница между расчетом по паспорту и фактическими данными.

Можно взять мощность майнера, умножить ее на 24 часа и на 30 дней. Но такой расчет предполагает, что асик весь месяц работал без остановок.

Если были простои, реальное потребление будет другим.

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

Как свести все данные вместе

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

В ROC смотрим:

• средний хешрейт;
• количество часов работы;
• потребление электроэнергии.

После этого берем фактическое начисление с пула или отдельно рассчитываем доход по среднему хешрейту.

Дальше считаем стоимость электричества по своему тарифу.

Получается:

Доход от майнинга - расходы на электроэнергию = результат за выбранный период

Здесь речь именно о результате с учетом электричества.

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

Зачем смотреть все три показателя вместе

По отдельности каждый показатель дает только часть картины.

Средний хешрейт показывает, с какой производительностью майнер в среднем работал за период.

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

Потребление позволяет понять расходы на электричество.

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

Когда эти данные собраны по одному майнеру и за один период, уже можно сделать нормальный расчет.

Это можно считать не только за месяц

Месяц - просто самый понятный пример.

Точно так же можно взять неделю, несколько дней или другой период.

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

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

Что в итоге дает ROC

ROC не заменяет пул и не считает финансовую доходность автоматически.

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

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

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Telegram для связи и поддержки: https://t.me/roc_support - @roc_support

[ROC Platform]

Удаленный мониторинг майнеров: как следить за ASIC и управлять ими через ROC

Если ASIC находится на удаленной площадке, в другом помещении или на хостинге, для проверки его состояния не обязательно постоянно подключаться к локальному интерфейсу самого майнера.

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

Это удобно как для владельца нескольких майнеров, так и для майнингового ЦОД, где одновременно работают десятки или сотни ASIC.

Какие данные по ASIC можно смотреть удаленно

После подключения майнера к ROC его состояние отображается в мониторинге.

По каждому ASIC можно проверить:

• статус подключения;
• текущий хешрейт;
• температуру;
• uptime;
• reject;
• потерю связи;
• другие отклонения в работе.

Если майнер перестал отвечать или его показатели изменились, это можно увидеть без физического доступа к площадке.

Например, ASIC продолжает быть online, но его хешрейт заметно снизился. В этом случае можно открыть данные по майнеру, посмотреть температуру, reject и другие показатели и уже по ним разбираться, что происходит.

Если связь с ASIC пропала полностью, в ROC это также будет видно.

Все майнеры в одном интерфейсе

При небольшом количестве ASIC еще можно по очереди открывать локальную панель каждого майнера. При росте парка такой способ становится неудобным.

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

Это позволяет быстрее найти ASIC с нужным S/N, посмотреть только майнеры с определенным статусом или выделить оборудование, у которого появились отклонения.

При необходимости майнеры можно объединять в группы и работать уже не с каждым ASIC отдельно.

Удаленное управление ASIC

ROC используется не только для просмотра показателей.

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

Также в системе предусмотрена работа с пулами, режимами и расписаниями работы майнеров.

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

Работа с пулами и режимами

В ROC можно задавать разрешенные пулы и использовать автоматическое переключение между ними.

Для майнеров также можно настраивать режимы и расписания работы.

Если ASIC должен работать по определенному графику, расписание позволяет учитывать это при дальнейшем контроле работы. Плановая остановка в таком случае отделяется от незапланированного простоя.

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

Что делать, если мониторинг показал проблему

Удаленный мониторинг помогает сначала понять масштаб проблемы.

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

При снижении хешрейта можно проверить температуру, reject и остальные доступные показатели.

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

Если нужна диагностика на месте, дальнейшую работу можно передать сотруднику.

Задачи и инциденты

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

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

Это особенно важно при посменной работе.

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

В результате мониторинг и работа с неисправностями находятся в одной системе: сначала фиксируется отклонение, затем по нему проводится диагностика и сохраняется результат.

Как найти конкретный ASIC на площадке

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

В ROC можно вести структуру размещения:

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

За счет этого по конкретному майнеру можно понять, где именно он установлен.

При большом количестве оборудования это сокращает время между обнаружением проблемы и началом работы с ASIC на месте.

Просмотр данных за период

Мониторинг нужен не только для просмотра текущего состояния.

В ROC можно использовать данные за выбранный период и оценивать, как ASIC фактически работал за неделю или месяц.

В частности, доступны данные по среднему хешрейту, фактическому времени работы и энергопотреблению.

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

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

Удаленный мониторинг для владельца нескольких ASIC

ROC можно использовать не только в крупном ЦОД.

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

Подключение и базовый мониторинг в ROC бесплатны.

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

ROC для майнингового ЦОД

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

В ROC для этого предусмотрены отдельные разделы:

• мониторинг майнеров;
• инфраструктура и управление майнерами;
• склад и история оборудования;
• задачи и инциденты;
• биллинг;
• отчеты.

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

Итог

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

Через ROC можно смотреть статус подключения, хешрейт, температуру, uptime, reject и другие показатели, выполнять удаленные команды, работать с пулами, режимами и расписаниями.

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

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Связь и поддержка: https://t.me/roc_support - @roc_support

[ROC Platform]

Как проверить, сколько времени ASIC реально работал за месяц: uptime, простои и данные ROC

Если ASIC находился на площадке весь месяц, это еще не означает, что он все это время действительно работал.

Майнер мог перезагружаться, терять связь, останавливаться по расписанию, находиться в ремонте или какое-то время простаивать из-за технической проблемы. Поэтому при оценке работы оборудования правильнее смотреть не на количество дней размещения, а на фактическое время работы за выбранный период.

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

Сколько часов ASIC может работать за месяц

Для начала можно определить максимальное количество часов.

Если в месяце 30 дней:

30 × 24 = 720 часов

При непрерывной работе ASIC теоретически может отработать все 720 часов.

Но фактическое значение может быть меньше. Причины бывают разными:

• потеря связи;
• перезагрузка майнера;
• неисправность;
• ремонт;
• обслуживание площадки;
• плановая остановка;
• работа по расписанию.

Поэтому количество дней, в течение которых ASIC числился на площадке, само по себе не показывает его фактическую работу.

Как посмотреть фактическое время работы в ROC

В ROC можно выбрать нужный период и посмотреть данные по конкретному майнеру.

Например, если нужно проверить сентябрь, выбирается соответствующий период и оценивается, сколько времени ASIC фактически находился в работе.

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

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

Пример расчета

Допустим, рассматривается месяц из 30 дней.

Максимально возможное время работы:

30 × 24 = 720 часов

По фактическим данным ASIC отработал:

682 часа

Тогда общее время, когда майнер не работал:

720 - 682 = 38 часов

Можно также определить долю фактического времени работы:

682 / 720 × 100 = 94,7%

Получается, что ASIC работал примерно 94,7% времени месяца.

Это уже дает больше информации, чем просто запись о том, что майнер находился на площадке 30 дней.

Почему фактические часы нужно смотреть вместе с хешрейтом

Большое количество часов работы еще не гарантирует нормальную производительность.

ASIC может оставаться online, но часть месяца работать с пониженным хешрейтом.

Например, два одинаковых майнера за месяц отработали по 700 часов. У первого средний хешрейт находился около обычного значения, а у второго был заметно ниже.

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

Поэтому при анализе месяца лучше смотреть минимум два показателя:

фактическое время работы + средний хешрейт

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

Плановая остановка и аварийный простой

Отдельно нужно учитывать причину остановки.

ASIC может не работать потому, что возникла проблема. Но он также может быть выключен заранее по установленному графику.

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

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

Так появляется разница между двумя ситуациями:

ASIC должен был работать, но простаивал

и

ASIC не должен был работать по расписанию

Для анализа работы площадки это важное различие.

Как понять, что происходило с ASIC в течение месяца

Допустим, майнер отработал 650 часов из 720.

Само число показывает, что 70 часов он не работал, но не объясняет причину.

Дальше уже нужно смотреть на работу ASIC в течение периода.

Часть времени могла приходиться на запланированную остановку. В другой день майнер мог потерять связь. Затем его могли перезагрузить или снять для диагностики.

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

Потребление электроэнергии и фактические часы

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

Допустим, ASIC потребляет 3,5 кВт и за месяц фактически отработал 682 часа.

Простой расчет:

3,5 × 682 = 2387 кВт·ч

Если условный тариф составляет 6 рублей за кВт·ч:

2387 × 6 = 14 322 рубля

Это упрощенный пример расчета.

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

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

Проверка ASIC на удаленном хостинге

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

Например, на момент проверки ASIC находится online и работает нормально. Но это ничего не говорит о том, как он работал предыдущие четыре недели.

За месяц можно посмотреть:

• фактическое время работы;
• средний хешрейт;
• потребление;
• простои;
• отклонения в работе.

Так можно понять, насколько стабильно майнер отработал весь период.

Сравнение разных месяцев

Еще один вариант использования этих данных - сравнение одного ASIC в разные периоды.

Например:

Август - 704 часа работы

Сентябрь - 661 час работы

Разница составляет 43 часа.

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

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

Сравнение нескольких ASIC

Тот же подход можно использовать для сравнения разных майнеров.

Например, на площадке работают несколько ASIC одной модели. За одинаковый период у них можно сравнить фактические часы работы и средний хешрейт.

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

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

Почему 720 часов не стоит автоматически использовать в расчетах

При оценке месяца часто используется простой подход: майнер установлен на 30 дней, значит он работал 720 часов.

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

Если ASIC фактически работал 670 часов, использование 720 часов в расчетах завышает и время работы, и расчетное потребление.

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

Что в итоге стоит смотреть за месяц

Чтобы получить нормальное представление о работе ASIC, полезно смотреть несколько данных вместе:

• сколько часов майнер фактически работал;
• какой средний хешрейт он показывал;
• были ли плановые и незапланированные остановки;
• сколько электроэнергии было потреблено;
• какие отклонения происходили в течение периода.

ROC позволяет собирать эти данные по подключенным майнерам и использовать их для анализа работы оборудования за выбранный период.

Так можно проверить не только то, работает ли ASIC прямо сейчас, но и то, как он фактически отработал весь месяц.

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал: https://t.me/ROC_platform

Связь и поддержка: https://t.me/roc_support - @roc_support

[bakfor]

апну топик, начал пользоваться
вопросов нет, ребята красавчики 
быстро допиливают то что нужно конкретно под меня, оставляют максимальный респект !) 

[ROC Platform]

В 08.10.2026 в 12:17, bakfor сказал:

апну топик, начал пользоваться
вопросов нет, ребята красавчики 
быстро допиливают то что нужно конкретно под меня, оставляют максимальный респект !) 

Здравствуйте, спасибо за обратную связь! Наша команда старается постоянно улучшать ROC и прислушиваться к пожеланиям пользователей. Очень приятно, что вы это замечаете и цените. Будем и дальше развивать платформу!)

[ROC Platform]

ASIC постоянно online, но работает нестабильно: что проверить и как найти проблему в ROC

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

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

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

На что обращать внимание, если ASIC находится online

Статус online означает, что майнер доступен для мониторинга. Но для оценки его работы этого недостаточно.

Есть несколько признаков, по которым можно заметить нестабильность:

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

• Растет температура. Майнер нагревается сильнее, чем обычно при тех же условиях работы.

• Увеличивается reject. Пул начинает отклонять больше шар.

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

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

Небольшие колебания хешрейта сами по себе не означают неисправность. Важно, насколько сильно меняются показатели, как часто это происходит и сохраняется ли проблема в течение длительного времени.

Как проверить работу ASIC за неделю или месяц в ROC

Допустим, установлен ASIC с номинальным хешрейтом 200 TH/s. При проверке он показывает примерно 200 TH/s, температура в обычном диапазоне, соединение с мониторингом есть.

Но в ROC за последнюю неделю средний хешрейт составил 165 TH/s.

Разница с номинальным значением:

200 - 165 = 35 TH/s

Это на 17,5% ниже заявленной производительности.

Такая разница требует проверки, но не обязательно означает поломку. Сначала нужно посмотреть фактическое время работы ASIC, его режим и условия, в которых он работал.

Например, часть недели майнер мог работать в пониженном режиме. Если же он должен был постоянно выдавать около 200 TH/s, нужно искать причину снижения производительности.

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

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

Если хешрейт периодически снижается

Одна из первых вещей, которые стоит проверить, - температура.

При перегреве ASIC может снижать производительность или останавливаться. Но искать причину нужно с учетом того, где именно возникла проблема.

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

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

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

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

Что делать, если растет reject

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

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

Если reject заметно увеличился, сначала стоит проверить соединение с пулом и понять, затронут ли только один майнер.

Например, если reject вырос одновременно у нескольких ASIC, работающих с одним пулом, имеет смысл проверить общее соединение и настройки. Если проблема наблюдается только у одного асика, нужно разбираться с ним отдельно.

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

Почему частые перезагрузки тоже важны

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

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

В такой ситуации полезно проверить uptime и фактическое время работы за выбранный период.

Если ASIC постоянно перезапускается, очередная удаленная перезагрузка вряд ли решит проблему надолго. Нужно выяснить, из-за чего это происходит.

Как найти нестабильные ASIC на большой площадке

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

В ROC все подключенные асики находятся в одном интерфейсе. Поиск, фильтры и сортировка помогают быстрее находить майнеры, на которые стоит обратить внимание.

При этом полезно проверять не только показатели отдельных ASIC, но и их физическое расположение.

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

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

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

Если проблема повторяется после перезагрузки

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

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

В ROC для этого предусмотрены задачи и инциденты.

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

Если неисправность появится снова, будет видно, что с ASIC уже делали раньше. Не придется каждый раз разбираться с нуля.

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

Например, до ремонта средний хешрейт составлял 165 TH/s, а после него за сопоставимый период поднялся до 198 TH/s. Если при этом исчезли частые перезагрузки, а температура и reject находятся в нормальном диапазоне, значит, работа асика стала стабильнее.

Можно ли использовать ROC для одного ASIC

ROC подходит не только для майнинговых ЦОД.

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

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

Для больших площадок в ROC также предусмотрены:

• инфраструктура и управление майнерами;

• склад и история оборудования;

• задачи и инциденты;

• биллинг;

• отчеты.

Удаленный мониторинг помогает заметить отклонения в работе ASIC, а данные за период позволяют проверить, насколько стабильно он майнил. Если проблема повторяется, в ROC можно организовать ее диагностику и сохранить историю выполненных работ.

Подробнее о ROC:

Сайт: https://roc-platform.ru/

Telegram-канал ROC: https://t.me/ROC_platform

Связь и поддержка: https://t.me/roc_support - @roc_support