Простой ASIC в майнинг-хостинге обычно начинается с короткого сообщения от клиента: «У меня асик офлайн, что случилось?» Для него причина не всегда видна. Есть оборудование, оно должно работать, но хешрейта нет.
Хешрейт - это вычислительная мощность, которую выдает асик. Если она падает или пропадает полностью, клиент быстро замечает проблему. Дальше появляются вопросы: когда устройство отключилось, почему это произошло и сколько времени оно реально стояло?
Мы на своей площадке к этому пришли не сразу. Сначала казалось, что достаточно мониторинга и чата с инженерами. Но со временем стало понятно: спор по простою начинается не из-за самого отключения, а из-за того, что хостинг не может быстро показать всю историю события.
Почему простой ASIC превращается в спор
Асик может уйти в офлайн по разным причинам. Устройство могло отключиться само по себе. На нем могла появиться ошибка. Мог зависнуть контроллер, пропасть сеть, отвалиться пул или возникнуть проблема с питанием.
Пул - это сервер объединенного майнинга, к которому подключается оборудование. Если с ним что-то не так, асик может быть физически включен, но нормальной работы клиент не увидит.
Для инженера все эти ситуации разные. Для клиента результат один - устройство не дает хешрейт.
И вот здесь начинается самое сложное. Клиент спрашивает, что произошло. Менеджер идет к инженеру. Инженер вспоминает смену. Кто-то поднимает переписку. Кто-то открывает мониторинг и пытается понять по графикам, когда именно началась проблема.
Иногда команда отработала быстро. Но если нет нормальной фиксации, доказать это трудно.
Почему одного мониторинга мало для SLA
Мониторинг показывает, что устройство работает или ушло в офлайн. Это полезно, но для SLA этого недостаточно.
SLA - это договоренность о качестве обслуживания: как быстро хостинг реагирует на проблему, как фиксирует простой и как потом объясняет ситуацию клиенту. Если у вас есть только красный статус в мониторинге, это еще не история инцидента.
Для нормального разбора нужно понимать всю цепочку:
- какой асик отключился;
- кому он принадлежит;
- где он стоит;
- когда началась проблема;
- кто получил уведомление;
- кто взял задачу;
- что сделал инженер;
- когда устройство вернулось в работу;
- какой итог показали клиенту.
Без этой цепочки SLA остается обещанием. С ней уже можно спокойно разговаривать фактами.
Что должно фиксироваться при простое
Мы для себя вывели простое правило: если событие нельзя восстановить через неделю, значит, оно зафиксировано плохо.
При простое нужно сохранять не только сам факт отключения. Нужна привязка к конкретному устройству, клиенту, контейнеру и действиям команды.
У нас эта логика закрывается через ROC: событие по устройству связывается с клиентом, оборудованием, контейнером и историей действий.
На маленькой площадке многое еще держится на памяти сотрудников. Один инженер помнит, что менял блок питания. Другой помнит, что в контейнере были проблемы с сетью. Менеджер помнит, что клиент уже писал по этому поводу.
Но память команды - плохая база для спора с клиентом. Нужна не устная версия, а понятная хронология.
Как это было у нас раньше
Раньше часть информации была в мониторинге. Часть оставалась в Telegram. Часть вообще жила в голове инженера.
Если клиент писал сразу, ответ можно было собрать быстро. Если вопрос прилетал через день или через неделю, начинались ручные поиски.
Например, клиент смотрит статистику и пишет: «Почему мой асик стоял?» Менеджер уточняет дату, контейнер, устройство. Потом спрашивает инженеров, кто был на смене. Потом ищет, не было ли работ по сети, питанию или пулу.
Формально ответ найти можно. Но это долго.
И самое неприятное - иногда команда действительно реагировала быстро, а объяснение все равно выглядело слабым. Не потому что кто-то плохо работал. Просто факты были разбросаны по разным местам.
Что мы поменяли в работе
Мы поняли, что нам нужен не только мониторинг. Нужна операционная история по каждому событию.
Поэтому мы начали вести инциденты через ROC. Для нас это рабочий контур, где связаны клиенты, оборудование, задачи, инциденты и действия команды.
В ROC инцидент не висит отдельно от устройства. Он относится к конкретному асику. Асик привязан к клиенту. Клиент привязан к своему парку и месту размещения.
Менеджеру не нужно собирать цепочку вручную. Он видит, что произошло, по какому устройству, кто реагировал и чем все закончилось.
Для руководителя это тоже полезно. Видно не только то, что был простой, но и как команда с ним работала.
Кейс с площадки: пропала группа устройств в контейнере
Был у нас случай, который хорошо показал ценность такой фиксации.
В одном из контейнеров возникла проблема с коммутатором. Коммутатор - это сетевое оборудование, через которое асики подключаются к сети. Из-за сбоя из сети пропала сразу группа устройств одного клиента.
Снаружи это выглядело неприятно. Был рабочий парк, потом несколько устройств почти одновременно ушли в офлайн.
В ROC сразу появились уведомления, что оборудование недоступно. По характеру события стало понятно, что проблема не в одном конкретном асике. Когда разом пропадает несколько устройств в одном контейнере, первым делом проверяют сеть, питание и общую инфраструктуру.
Инженеры быстро пошли в контейнер, проверили сетевую часть и нашли проблему на стороне коммутатора. Связь восстановили оперативно. По времени потери получились минимальными, потому что команда увидела проблему по событию, а не после звонка клиента.
После восстановления менеджер открыл историю инцидента в ROC и объяснил клиенту, что произошло.
Не в формате «там что-то с сетью было». А нормально: когда устройства ушли в офлайн, когда команда увидела событие, что проверили, что восстановили и когда оборудование снова появилось в сети.
Такой разговор проходит спокойнее. Клиент видит, что ситуацию не замалчивали. Видит, что команда не ждала его сообщения. Видит хронологию, а не объяснение задним числом.
Почему это важно для SLA
SLA работает только тогда, когда его можно подтвердить.
Если в договоре написано, что хостинг быстро реагирует на проблемы, но внутри нет истории инцидентов, доказать качество работы сложно. Любой спор превращается в обмен мнениями.
Клиент говорит: «Мой асик стоял долго».
Хостинг отвечает: «Мы быстро отреагировали».
Дальше все упирается в доверие.
Доверие нужно. Но в операционной работе лучше, когда есть факты.
Ценность ROC для нас именно в этом: мы видим не только простой, но и цепочку реакции по нему. Это снижает количество спорных ситуаций и помогает менеджеру разговаривать с клиентом спокойно.
Не оправдываться. Не вспоминать. Не собирать все по кускам. А открыть событие и показать, как оно было отработано.
Когда хостингу пора менять подход к простоям
Есть несколько признаков, что старый подход уже не справляется.
Первый - клиенты часто спрашивают, почему их асики стояли. Это не всегда значит, что площадка плохо работает. Иногда клиенту просто не хватает прозрачности.
Второй - менеджеры ищут информацию по чатам. Если для ответа клиенту нужно опросить инженеров, поднять переписку и открыть несколько таблиц, процесс уже держится на ручном труде.
Третий - инженеры закрывают задачи устно. На небольшой площадке это может работать, но при росте быстро начинаются потери информации.
Четвертый - владелец хостинга не видит скорость реакции команды. Он видит общий результат, но не видит путь: когда событие началось, кто отработал, где была задержка.
Пятый - отчеты по простоям собираются вручную. Это один из самых заметных сигналов. Если отчет каждый раз приходится собирать заново, значит, данные не живут в одном рабочем контуре.
Простои нельзя исключить полностью
Полностью убрать простои невозможно. Асики ломаются. Сеть иногда дает сбои. Оборудование зависает. Пулы работают нестабильно. Контейнерная инфраструктура тоже требует обслуживания.
Вопрос не в том, можно ли построить площадку без единого инцидента. Нельзя.
Вопрос в другом: насколько быстро команда видит проблему, как реагирует и может ли потом показать клиенту понятную историю.
Для майнинг-хостинга это часть доверия. Клиент не всегда ждет идеальной работы без единого сбоя. Но он ждет честности, скорости и прозрачности.
Если простой зафиксирован, объяснен и закрыт, конфликт чаще всего не развивается. Если простой есть, а истории нет, даже небольшая проблема может стать долгим спором.
SLA держится на фактах
SLA в майнинг-хостинге - это не красивая строка в договоре. Это дисциплина внутри команды.
Нужно фиксировать простои, действия инженеров, причины инцидентов и время восстановления. Тогда хостинг разговаривает с клиентом не на эмоциях, а на фактах.
Если хотите посмотреть, как у нас в ROC устроена фиксация простоев, инцидентов и реакции команды - напишите в Telegram: @platform_roc. Покажем на демо и ответим на вопросы.
Функциональность платформы может отличаться от описанной в статье - система активно развивается, и набор возможностей меняется. Для актуальной конфигурации лучше уточнить у команды.