Приёмка партии асиков на майнинг-хостинге: как сократить процесс с 8 часов до часа

Российский майнинг-хостинг 2026 года - это индустрия с реестром ФНС, регулярной отчётностью и обязанностями оператора майнинговой инфраструктуры. Каждый асик клиента должен быть в учёте площадки с серийным номером, моделью, MAC-адресом и привязкой к конкретному владельцу. Любая ошибка в этих данных при первой приёмке всплывает потом - при гарантийном случае, перемещении, споре или налоговой проверке.

Мы как оператор майнинговой инфраструктуры прошли путь от ручной приёмки в Excel до автоматизированного процесса через мобильное приложение. Расскажем, как у нас сейчас принимается партия из 30 асиков за час и за счёт чего получилось сократить время в 6-8 раз.

Сразу обозначим позицию: главная ценность хорошо настроенной приёмки - не сэкономленные часы команды в день поступления партии, а отсутствие проблем с учётом на годы вперёд. Это фундаментальная разница между «учёт ради учёта» и «учёт как операционная основа площадки». Аргументируем дальше.

Приёмка партии - не «расставить асики по контейнерам». Это полноценный процесс с обязательными этапами: регистрация каждого устройства в учёте площадки с серийником и MAC-адресом, привязка к клиенту, постановка на склад с документом приёмки, расстановка по локациям, подключение в сеть и пул.

В контексте российской регуляторики 2026 года точность этих данных критична. После введения реестра операторов майнинговой инфраструктуры ФНС в ноябре 2024 года каждый асик клиента должен корректно идентифицироваться в системе оператора - именно эти данные потом попадают в XML-отчёт, который мы как оператор обязаны подавать. Опечатка в серийнике, допущенная при приёмке, превращается в расхождение между нашей отчётностью и физическим оборудованием.

В первые годы работы у нас на площадке всё шло вручную через Excel. Стандартный сценарий - партия из 30 асиков от клиента, и команда из двух-трёх человек тратила на приёмку 6-8 рабочих часов.

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

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

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

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

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

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

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

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

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

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

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

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

В приложении менеджер идёт по пути: Склад → Операции → Добавить документ. Заполняет шапку приёмки: хостинг, площадка, на которую приехала партия, и клиент. Если клиент новый, его можно создать прямо в этой же форме - имя, контакты, основные данные.

Дальше открывается сканер прямо в приложении. Менеджер указывает количество устройств в партии, подходит к каждому асику и наводит камеру телефона на наклейку производителя. Сканер считывает серийный номер и MAC-адрес. После сканирования каждое устройство сразу попадает в реестр склада с серийником, MAC, датой приёмки и привязкой к клиенту, выбранному в шапке. Документ приёмки формируется автоматически из этих данных.

15-20 минут на сканирование 30 устройств. Дальше идёт физическая работа: расстановка по контейнерам и подключение в сеть, которую система не заменяет. Но сам учётный процесс - закрыт.

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

Когда при приёмке мы зафиксировали MAC-адрес каждого асика, мы фактически «представили» эти устройства системе заранее - до их физического подключения. Дальше инженер расставляет асики по контейнерам и подключает их в сеть. И система автоматически их видит и идентифицирует - именно по MAC-адресу, который уже есть в реестре склада.

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

За полгода работы на новом процессе мы провели десятки приёмок партий разных размеров. Сравнение со старым ручным режимом по типовой партии 30 асиков:

Сбор данных по серийникам и MAC раньше занимал около часа в идеальных условиях. Сейчас - 15-20 минут на сканирование. Привязка к клиенту в старом режиме была отдельным шагом после ввода всех устройств. Сейчас - выбирается один раз в шапке документа и применяется ко всей партии. Документ приёмки раньше заполнялся вручную из шаблона. Сейчас - формируется автоматически из заполненной шапки.

Итого: вместо 6-8 рабочих часов команды из двух-трёх человек - 40-60 минут работы одного-двух человек. Сокращение времени примерно в 6-8 раз. Принципиально важно другое: количество ошибок в серийниках и MAC практически сведено к нулю, потому что нет ручного ввода. За год работы на новой системе у нас не было ни одного случая, когда устройство «потерялось» в учёте или попало не к тому клиенту.

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

Физический осмотр каждого асика на дефекты - наш инженер делает руками, оценивает состояние корпуса, проверяет наличие повреждений. Расстановка по контейнерам, укладка кабелей, подключение в сеть и настройка пула - это физическая работа, которая занимает основное время. Сверка с клиентом обязательна: даже если 30 серийников зафиксированы корректно, мы проходим по списку с клиентом и подтверждаем приёмку. Подписание акта приёма-передачи зависит от документооборота клиента и не входит в нашу систему.

И главное ограничение по самой системе: внедрение специализированной платформы требует ресурсов. Для хостинга на 5-10 клиентах с редкими приёмками экономика не складывается - ручной режим в Excel ещё дешевле. Точка перелома обычно проходит на 30-40 клиентах с регулярными новыми партиями.

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

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

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

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

Если вы оператор майнинг-площадки и узнаёте у себя похожие операционные вводные, команда ROC проводит демо и отвечает на вопросы по специфике майнинг-хостинга. Контакт - https://t.me/Roc_support

Функциональность платформы ROC может отличаться от описанной в статье - система развивается, набор возможностей меняется. Требования ФНС к отчётности операторов майнинговой инфраструктуры также могут обновляться - актуальную редакцию имеет смысл сверять на nalog.gov.ru.