Учёт оборудования - один из ключевых процессов на любом майнинг-хостинге. К нему всегда относятся серьёзно: серийники, локации, привязка к клиентам, история перемещений - всё это нужно вести точно и постоянно держать в актуальном состоянии. Вопрос только в том, как сделать этот процесс удобнее и быстрее, особенно когда асиков становится больше сотни, а клиентов - десятки. Расскажем, как у нас на площадке устроен учёт оборудования и как нам в этом помогает ROC.
Что входит в учёт оборудования на майнинг-хостинге
Полноценный учёт - это не просто список асиков с моделями. По каждому устройству нужно вести серийный номер, MAC-адрес, модель, локацию в контейнере, привязку к клиенту и так далее - всё, что в любой момент может понадобиться для работы.
Эти данные нужны не для красоты в системе, а для повседневных задач: ответить на вопрос клиента, найти асик при инциденте, оформить гарантийный случай и так далее. Если что-то из этого ведётся в отдельном файле или хранится в голове конкретного человека, при росте хостинга это становится узким местом.
Почему мы хотели заменить Excel
Учёт у нас изначально вёлся в Excel. Это рабочий вариант, через который проходят почти все хостинги. Но мы всегда думали, как этот процесс заменить или хотя бы упростить - потому что вести учёт в таблицах не всегда удобно, и очень легко в них запутаться.
Поиск нужного асика через стандартный поиск по таблице работает не всегда удобно: нужно помнить, как именно записан серийник, в какой колонке искать, какой файл открыть. При записи нового устройства легко допустить ошибку - 12-18 знаков серийника мелкой печатью на наклейке, и достаточно перепутать одну цифру или букву, чтобы потом этот асик не находился в системе. А при смене менеджера часть данных нередко остаётся в его собственных файлах или переписке - передать всё это аккуратно тоже отдельная задача.
Каждая такая мелочь сама по себе не критична. Но при росте площадки они складываются и начинают съедать рабочее время команды.
Как мы попали на ROC
В какой-то момент один из наших клиентов предложил попробовать ROC - сказал, что работает с этой системой на другой площадке и видит, как она закрывает наши задачи. Согласились на короткий демо-период, и после нескольких недель использования возвращаться к Excel уже не захотели.
ROC - это операционная платформа для майнинг-хостинга, в которой учёт оборудования живёт в единой системе с клиентами, контейнерами, биллингом и инцидентами. Не отдельная база данных асиков, а полноценный учёт, где всё связано между собой. Дальше расскажем, как у нас это устроено и что это даёт в повседневной работе.
Как мы заводим оборудование в систему
На практике у нас два типовых сценария занесения асиков в учёт. Способ под каждый сценарий свой - в зависимости от того, в каком состоянии оборудование на момент занесения.
Сценарий 1: сканер для новой партии
Самый частый случай - новые асики только приехали на площадку, ещё не подключены к сети. Здесь удобнее всего работать через мобильную версию ROC прямо рядом с оборудованием.
Менеджер открывает приложение, заходит в раздел склада и приёмки. В шапке документа выбирает клиента - того, чьё это оборудование. Если клиента ещё нет в системе, его можно создать прямо в этой же форме, не прерывая процесс. Дальше открывается сканер в приложении, и менеджер проходит по асикам, наводя камеру на наклейку производителя на каждом устройстве. Сканер считывает серийный номер и MAC-адрес.
После сканирования каждое устройство сразу попадает в систему: с серийником, MAC, привязкой к клиенту и датой приёма. Никакого ручного ввода 12-18 знаков, никакой возможности ошибиться. Партия из 30 асиков заводится в учёт за 15-20 минут.
Сценарий 2: CSV для оборудования, которое уже работает
Бывает наоборот: асики уже подключены и работают, нужно завести их в систему. Самый частый повод - миграция учёта со старой системы или из Excel.
Здесь логично использовать импорт через CSV-файл, в котором перечислены все устройства. Но есть важный технический нюанс: серийники в CSV нужно вписать вручную. Серийный номер - это физический параметр устройства, считать его можно только с самой наклейки на корпусе. По сети серийник не передаётся, в отличие от MAC-адреса.
На практике это означает, что для миграции учёта оператору один раз придётся пройти по всем работающим асикам и переписать серийники в файл. После этого загрузка CSV в ROC происходит за минуты - все устройства попадают в учёт сразу, с серийниками и привязкой к клиентам, как они были оформлены в файле. Если CSV у оператора уже есть готовый, например, его вёл предыдущий сотрудник в Excel, импорт занимает минуты.
Это разовая процедура, после которой дальнейший учёт работает уже без ручных операций - все новые асики приезжают и ставятся в учёт через сканер, а старая партия уже в системе.
Что видно по каждому асику в учёте
В ROC по каждому устройству хранится полный набор данных: серийный номер, MAC-адрес, модель и паспортное потребление, текущая локация в контейнере, привязка к клиенту с датой начала размещения, история перемещений с датами и причинами, история инцидентов и работы команды по этому устройству, текущий статус (работает, в простое, на обслуживании). Это не строка в таблице, а карточка с историей, которая ведётся автоматически по ходу работы.
Как это работает на практике: пример с клиентом
Самый понятный пример - повседневная ситуация, когда клиент пишет нам с вопросом по своему оборудованию. Скажем, приходит сообщение: «проверьте, пожалуйста, S21, почему-то не отображается у меня на пуле».
Что делает наш менеджер. Открывает карточку клиента и сразу видит полный список его оборудования у нас на площадке. Если у клиента несколько S21, видит все по серийникам - можно уточнить у клиента, о каком именно идёт речь, или сразу проверить все. Заходит в карточку нужного устройства и видит текущий статус, время последнего ответа от устройства, температуру, подключение к пулу, недавние инциденты.
Если асик показывает оффлайн, сразу видно, когда упал и что происходило перед этим. Если есть инцидент, видно, кто из команды уже занимается, на каком этапе. Менеджер даёт клиенту осмысленный ответ: «по вашему S21 с серийником таким-то связь потеряна вчера в 14:30, инженер уже выехал к асику, сообщим как разберёмся».
На всё это уходит меньше минуты вместо длинной цепочки звонков между менеджером, инженером и тем, кто помнит, чьё это оборудование. Клиент получает не «сейчас разберёмся, перезвоним», а конкретику и понимание, что его вопросом занимаются.
Перемещения и смена владельца
Учёт - это не «занесли и забыли». Оборудование живёт: переезжает между контейнерами при сортировке, меняет владельцев при продаже между клиентами на площадке. Если эти изменения не отражаются в системе, актуальность учёта быстро теряется.
В ROC любое перемещение асика между локациями фиксируется как событие - с датой и причиной. История сохраняется в карточке устройства целиком: где стоял, когда переехал, куда переехал, почему. Это особенно важно при больших перестановках - например, когда мы реорганизуем контейнер и переставляем десятки асиков. Каждое перемещение фиксируется, и через месяц мы можем поднять историю любого устройства.
Если клиент продаёт асик другому клиенту на нашей же площадке, оформляем смену владельца. Устройство привязывается к новому клиенту, но вся его предыдущая история остаётся в карточке - она не теряется при смене владельца. Это особенно важно для гарантийных случаев: производитель смотрит на серийник, а не на то, кому асик принадлежит сейчас. Полная история работы и инцидентов всегда под рукой.
Что осталось ручной работой
Чтобы картина не выглядела рекламной, важно проговорить ограничения. Не всё в учёте оборудования автоматизировано, и часть нагрузки на команду остаётся.
Серийники физически считываются только с самих устройств. Если асик уже в работе и нужно завести его в систему - либо снимать его на минуту для сканирования, либо иметь записанный серийник заранее в CSV. Расстановка по контейнерам и физическое подключение - это всегда руки инженера, систему здесь не заменит. Сверка с клиентом при приёме партии остаётся обязательной частью процесса, даже если все 30 серийников аккуратно зафиксированы. Внесение исторических данных при первой миграции - разовая, но довольно объёмная работа: нужно переписать серийники с уже работающих асиков, подготовить CSV, проверить корректность.
Когда стоит менять подход к учёту
Если вы пока ведёте учёт в Excel и думаете, нужна ли смена подхода, есть несколько ориентиров. На площадке больше 50 асиков. Появилось 2 и более контейнеров с оборудованием разных клиентов. Регулярно случаются ситуации, когда сложно быстро найти конкретный асик. При вопросе клиента «что с моим оборудованием» уходит больше 10 минут на ответ. Был хотя бы один случай, когда асик не нашёлся в учёте или попал не к тому клиенту.
Если 2-3 пункта совпадают, ручной режим уже стоит дороже автоматизации. Excel при росте превращается в источник скрытых издержек: команда тратит время на поддержание актуальности данных вместо реальной работы с клиентами и оборудованием.
Итог
Хороший учёт оборудования - это не про красивую таблицу. Это про возможность за минуту ответить на любой вопрос про любой асик на площадке: где стоит, чей, в каком состоянии, что с ним было за последний месяц. Когда учёт устроен так, это видно по скорости работы команды и по тому, насколько быстро мы можем дать клиенту понятный ответ.
Главная ценность системного подхода к учёту - не сам учёт, а то, что он делает возможным в повседневной работе: спокойную приёмку новых партий, быстрые ответы клиентам, корректные отчёты в ФНС, аккуратные перемещения и переоформления. Всё это - результат того, что данные ведутся в одном месте и поддерживаются в актуальном состоянии без ручного труда.
Если хотите увидеть, как устроен учёт оборудования в ROC, напишите команде в Telegram: https://t.me/Roc_support. Они проведут демо и ответят на все вопросы.
Функциональность платформы ROC может отличаться от описанной в статье - система развивается, набор возможностей меняется.