Сообщение «на складе плохо работает Wi-Fi» не даёт инженеру точки отсчёта. Неясно, какой терминал, в какой зоне и на какой операции столкнулся с проблемой. К моменту проверки смена закончилась, устройство перезапустили, а условия изменились.
Для начала диагностики нужны время, место, номер ТСД, выполняемая операция, видимый симптом и способ восстановления. Эти сведения позволяют сопоставить жалобу с журналами. Сотруднику склада не нужно определять причину: ниже приведены поля карточки и пример заполнения.
1. Запишите время, место и устройство
Укажите дату и время события с понятным часовым поясом. Вместо «утром» полезнее «около 10:24 МСК, повторилось через несколько минут». Если часы терминала, сервера и системы управления отличаются, сообщите об этом: несовпадение времени мешает сопоставлению событий.
Место лучше описывать рабочим обозначением: зона, ряд, уровень мезонина или маршрут. Инвентарный номер позволяет найти конкретный ТСД. Модель и версия ПО полезны для сравнения с другими устройствами; собирать их можно силами ИТ-службы, не перекладывая это на комплектовщика.
В диагностических платформах события устройств и подключения рассматриваются во времени. Например, руководство Cisco Catalyst Center связывает состояние контроллера, точек и клиентов с временной шкалой и отдельно разбирает сетевые службы доступа. Это иллюстрирует, зачем жалобе нужны точные координаты события; набор доступной диагностики зависит от платформы и её настройки. Cisco: Troubleshoot Wireless Issues with Catalyst Center.
2. Опишите операцию и видимый симптом
«Завис» может означать разные ситуации: приложение не отвечает на нажатие, долго ждёт подтверждения, показывает ошибку соединения или просит войти заново. Запишите, что сотрудник делал перед событием и что увидел на экране. Текст ошибки лучше сохранить точно.
Важна последовательность: сотрудник перешёл в соседний ряд, разбудил ТСД после паузы, отсканировал код, дождался или не дождался ответа. Не подменяйте наблюдение выводом «оборвался роуминг», если это ещё не подтверждено.
Если допустимо снять экран, исключите из пересылаемого изображения персональные данные и содержимое заказов, которые не нужны для диагностики. Сами технические логи собирают и передают через согласованный канал ответственные специалисты.
3. Отметьте масштаб и повторяемость
Один терминал, несколько устройств одной модели или вся зона — разные отправные точки. Важно узнать, наблюдается ли тот же симптом на другом устройстве при сопоставимой операции. Это помогает сузить круг гипотез, но не доказывает причину само по себе.
Проверьте, связан ли сбой с местом, движением, временем смены, определённой операцией или выходом из сна. Не нужно специально останавливать рабочий процесс ради эксперимента. Повторные проверки планируют с руководителем смены и ИТ-командой, когда понятны условия и последствия.
Отдельно запишите, что помогло продолжить работу: ожидание, переход в другую зону, повторный вход, перезапуск приложения или терминала. Такая запись не превращает временный обход в исправление причины.
4. Карточка сбоя Wi-Fi или WMS: пример заполнения
Карточка должна быть достаточно простой, чтобы её действительно заполнили. Неизвестные поля можно оставить для уточнения. Пример ниже условный и не описывает реальный проект.
| Поле | Пример записи |
|---|---|
| Время | 10:24 МСК, повторно около 10:29 |
| Место | Зона комплектации, ряд B, после перехода из ряда A |
| Устройство | Инвентарный номер ТСД-027; модель уточнит ИТ |
| Операция | Подтверждение отбора после сканирования |
| Симптом | Экран ожидания, затем сообщение об ошибке соединения |
| Масштаб | На этом устройстве дважды; по другим пока данных нет |
| Продолжение работы | После повторного входа операция стала доступна |
| Изменения | В этот день обновления пользователю неизвестны |
Для обращения достаточно скопировать поля: дата и время; место; устройство; операция; видимый симптом; масштаб; способ продолжить работу; известные изменения. Если данные неизвестны, так и напишите. Этих наблюдений достаточно, чтобы начать поиск нужного интервала журналов; диагноз от сотрудника склада не требуется.
5. Собирайте диагностику под гипотезу
Инженер сопоставляет наблюдения с событиями радиосети, устройства, служб доступа и приложения. Возможные проверки включают подключение и переключение между точками, выдачу адреса, доступ к нужному узлу и время ответа приложения. Программа зависит от симптома и доступных инструментов.
Утилита на терминале тоже имеет режимы и ограничения. В документации Zebra Roaming Analysis указано, что режим нужно выбирать под задачу; есть ограничения на одновременную работу других функций анализа и приложений, создающих интенсивный трафик, в активном режиме. Поэтому запуск всех тестов сразу может изменить условия наблюдения. Zebra: Roaming Analysis.
Успешный ping до одного адреса не доказывает готовность всей цепочки WMS. И наоборот, ошибка приложения сама по себе не доказывает неисправность радиосети. Полезно заранее определить, на какой вопрос отвечает каждый тест и чего по нему заключить нельзя.
6. Закрывайте инцидент вместе с проверкой
После изменения настройки или замены компонента повторите согласованный сценарий. Зафиксируйте условия, устройства и период наблюдения. Если редкий симптом не повторился, это ещё не всегда означает доказанное устранение причины; в итоговой записи нужно различать исправление подтверждённой проблемы и продолжающееся наблюдение.
История инцидентов помогает увидеть повторяемость: одни модели ТСД, одно место или одинаковая операция. Она также показывает, каких данных систематически не хватает. На этой основе можно изменить порядок обращений или запланировать обследование, вместо того чтобы каждый раз начинать с общей жалобы.
Для регулярных проблем важны согласованные роли: кто принимает сообщение, кто собирает диагностику и кто отвечает за Wi-Fi, ЛВС, терминалы и WMS. Обсудить такой порядок можно в рамках сопровождения сети. Если причины пока неизвестны, поможет аудит Wi-Fi. Когда сбой связан с перемещением, полезен также разбор роуминга ТСД.