ASIC сам перезапускается: лог важнее догадки

Убедитесь, что произошёл именно перезапуск

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

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

Выгрузите данные до следующего вмешательства

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

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

Разделите возможные направления проверки

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

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

Исключите опасные повторные запуски

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

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

Проверьте изменения по одному

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

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

Передайте воспроизводимое описание

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

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

Шаблон журнала перезапусков

Укажите связь с изменениями конфигурации

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