Привет, Хабр! В 2022 году я пришёл в Ozon Tech на позицию специалиста технической поддержки склада и начал разбираться, как настраивать и поддерживать оборудование на ФФ (фулфилмент), огромном складе площадью 70 000 м², где проходят операции от приёмки и хранения товаров до их подготовки к отправке на сортировочные центры. В тот момент всё работало стабильно. На складах использовались терминалы Zebra (ТСД — терминал сбора данных), вендор был на рынке, поддержка оставалась доступной, и никто особенно не задумывался, как всё устроено внутри.
После изменения условий работы с вендором нам пришлось глубже разобраться в процессе настройки и поддержки устройств, чтобы сохранить стабильную работу терминалов на объектах. Оказалось, что поддерживать работу десятков тысяч терминалов по всей стране стало задачей с множеством неизвестных. Притом именно через них проходит большая часть складских операций, от приёмки и размещения товара до сборки и отгрузки заказов. Впереди нас ждали несколько лет разборов, ошибок, временных решений и постепенной перестройки всей системы. В какой-то момент казалось, что мы зашли в тупик. Но в итоге справились. Сейчас мы сократили время настройки терминала с 30 до 6 минут, управляем тысячами устройств удалённо и имеем единый лаунчер. В этой статье расскажу, как мы заново выстроили процесс настройки и управления терминалами на складах. Поехали!
О каком масштабе идёт речь
По всей стране у Ozon работает много складских объектов. Это фулфилменты, сортировочные центры и дарксторы Ozon fresh — небольшие склады для быстрой доставки товаров. По специфике они различаются как размерами, так и рабочими процессами, а также количеством людей, которые работают на сменах. Фулфилмент — это полный цикл приёма товара, хранение, сортировка и отгрузка. На смену выходит около тысячи человек. На приёмке задействована рабочая станция, но остальные операции используют терминал сбора данных. Положить товар в корзину, из корзины на полку, взять с полки — каждое действие фиксируется с помощью терминала, чтобы мы чётко знали, где и что лежит, могли это быстро найти и передать в доставку.
Ежедневно в операционных процессах Ozon задействованы тысячи терминалов сбора данных. Масштаб отличается в зависимости от типа объекта. На фулфилментах — от 500 до 5000 устройств, в сортировочных центрах 50–200 терминалов, а в сервисах быстрой доставки используют 5–20 терминалов. Сложность в том, что всё это работает в разных уголках страны. Кроме этого, терминалы используют разные системы (WMS — система управления складскими операциями и т. п.), поэтому нам нужно поддерживать консистентность данных и единые принципы обработки на всех устройствах.
Наша задача как технической поддержки заключалась и до сих пор заключается в первичной настройке устройств и поддержании их стабильной работы на складах.
С чего мы начали
Перед нами стояла задача оптимизировать подготовку терминалов к работе. Сети Wi-Fi, в которых работают наши ТСД, требуют аутентификации по EAP-TLS, поэтому главными задачами на первом этапе были:
Установка сертификатов.
Подключение к Wi-Fi.
Установка приложений.
При запуске терминала нас приветствует первичный экран настройки. По инструкции нужно было считать QR-код, чтобы начать настройку по сценарию.
Для нас это был готовый сценарий, который нужно было описать и сделать поддерживаемым. В начале было неизвестно, какие профили применяются, откуда скачиваются файлы, какие скрипты запускаются и какие параметры меняются на устройстве. Отправная точка у нас была в виде действующей инструкции, доступных конфигураций и уже используемого сценария настройки. Процесс работал, но его нужно было описать, структурировать и сделать поддерживаемым для команды. Постепенно мы восстановили логику штатного процесса по доступным инструкциям, конфигурациям и поведению сценария настройки.
ТСД подключался к промежуточной сети WPA-PSK, для этого использовалась временная схема с раздачей Wi-Fi с компьютера техподдержки. Такое решение было неудобно в масштабировании и создавало дополнительные риски, поэтому мы начали искать более безопасный и централизованный подход. Далее устройство синхронизировало время, прописывало NTP-сервер, скачивало архив с сервера техподдержки и запускало скрипт. В этом скрипте выполнялась последовательность действий: установка приложений, выдача прав, установка сертификата и подключение к сети.
Главный вызов заключался в том, как поддерживать актуальность архива: приложения, сертификаты и конфигурации должны были обновляться централизованно и без ручных операций на каждом устройстве. С этого момента нам нужно было описать и перенести рабочий процесс в управляемый сценарий, подготовить профиль для раскатки, научиться следить за состоянием архива, а также всё это оптимизировать и упростить.
Подключение к сети
Первый шаг — нужно подключить устройства к корпоративной сети для ТСД. У нас используется отдельная сеть, предназначенная только для терминалов, выстроенная с аутентификацией по связке EAP-TLS + RADIUS. Это сразу добавило сложности, потому что для подключения требуется сертификат. Его нужно сначала доставить на устройство, установить в систему и затем указать в настройках Wi-Fi. Если всё это делать вручную, на это потребуется очень много времени.
Открытым вопросом также был сброс времени. При полном разряде аккумулятора устройство могло откатиться далеко в прошлое — условно в 1970 год. Из-за этого сертификат для подключения к сети считался ещё недействительным: дата начала его действия была «в будущем» относительно времени на терминале. Получался замкнутый круг: без корректного времени не работает сертификат, без сертификата терминал не входит в сеть, а без сети он не может синхронизировать время. GPS на складах не работает, поэтому рассчитывать на него не приходилось.
При разборе действующего сценария настройки мы увидели, что в процессе используются два приложения: одно выпускает сертификат, другое устанавливает его в систему. Такая схема работала только из внутренней сети, в которую терминал как раз должен был попасть с сертификатом. На текущий момент в инструкциях это решалось только раздачей Wi-Fi с соседнего устройства. Мы отложили эту задачу в бэклог с первым приоритетом, а пока занялись первичной настройкой.
Первое рабочее решение
Следующим шагом мы решили упростить вход. Мы создали QR-код для подключения к сети, также с промежуточным доступом к отдельному серверу техподдержки. Скачиваем приложение для установки сертификата, получаем сертификат через него, а дальше настраиваем сеть, благо в StageNow такая возможность была.
StageNow — решение компании Zebra, которое позволяет подготовить к работе от нескольких штук до нескольких тысяч устройств на базе Android благодаря возможности быстрого сканирования штрихкода или считывания NFC-метки. |
Примерно в одном случае из двадцати сертификат не выпускался. Иногда такие сбои повторялись сразу на нескольких устройствах подряд. Дополнительно ситуацию усложняла высокая нагрузка на центр сертификации.
Мы зафиксировали это и передали в разработку, а сами продолжили настройку по доступному сценарию. Несмотря на сбои с выпуском части сертификатов, базовое подключение к сети удалось настроить — для нас это уже было важным промежуточным результатом. Пока команда разбиралась с ошибкой, мы перешли к следующим этапам настройки терминалов.
Настройка системных параметров
На этом этапе нужно было ограничить права пользователя в режиме киоска. Это позволит заблокировать доступ к настройкам, убрать браузер, ограничить список приложений, используемых пользователем, чтобы минимизировать риски несанкционированных действий на терминале. Тут на помощь пришёл стандартный софт, который предоставляет вендор Zebra Enterprise Home Screen.
Zebra Enterprise Home Screen (EHS) — это приложение, не требующее навыков разработки или программирования. С его помощью можно создать однозадачное устройство для работы в режиме киоска, управлять доступными приложениями и функциями устройства, а также защитить среду рабочего пространства. |
Тут обошлось без приключений. По конфигу вывели на рабочий стол наши приложения, задаём админский пароль, ставим автоматический выход из админского режима по времени и блокируем набор приложений, чтобы они не открывались при вызове другими приложениями. Время показало, что данного приложения для ограничения возможностей пользователей недостаточно и они находят пути обхода ограничений.
Напомню, что всё это настраивается через QR-код, а управлять удалённо конфигами киоска мы ещё не научились — значит, не могли поменять что-либо на терминалах по всей стране одновременно. Приходилось неоднократно менять конфиг на терминалах вручную, используя ресурсы технической поддержки.
Дальше дело за малым: настроить параметры экрана (яркость, время блокировки, режим экрана блокировки), сменить NTP-сервер на тот, что используется внутри сети, настроить громкость, редактирование каналов Wi-Fi 2.4 и 5 ГГц (часть каналов по умолчанию не соответствовала требованиям сетевых инженеров), roaming и delta для корректного роуминга на складе. О тонкой настройке сети и о том, с какими проблемами боролись сетевые инженеры, возможно, расскажу в следующей части. Вроде всё просто: создали скрипт сценария в StageNow и закинули на сервер техподдержки. Основные настройки завершены, дальше оставалось установить рабочие приложения.
Установка приложений на терминалы
На ТСД в Ozon используется несколько основных приложений:
Складское приложение.
Логистическое приложение.
Приложения для дарксторов Ozon fresh.
Для этого мы создали виртуальную машину в ЦОД и подняли сервер с дистрибутивами приложений и конфигов, собрали приложения в один архив, сделали скрипт на скачивание и установку. Схема оказалась рабочей, но потребовала доработки: когда каждое приложение скачивалось по отдельности, периодически одно из них не устанавливалось из-за ошибок передачи, а это приводило к регулярным обращениям в поддержку. Упаковка всех приложений в единый архив решила проблему — архив грузился стабильно, и установка проходила без сбоев. Так мы повысили надёжность процесса и избавились от ошибок передачи.
На этом этапе мы не строили новую систему с нуля, а привели уже работающий процесс к более понятному и поддерживаемому виду.
Как мы настраивали новые терминалы
Что могло испортить такое прекрасное начало и работающее решение?
К нам поступила партия из нескольких десятков тысяч терминалов от трёх разных вендоров. Нужно было в короткие сроки распределить и отправить в регионы. Сложность состояла в том, что мы ещё не разработали и не реализовали стороннее к тому моменту MDM-решение.
MDM (Mobile Device Management) — это программные решения для централизованного управления, настройки, обновления ПО и контроля безопасности устройств. |
С какими вызовами мы столкнулись?
Вызов 1. Вендоры либо не имели своих киосков (аналогов описанной ранее EHS), либо не умели делать то, что умеет StageNow. Проблем ещё добавили случайный MAC-адрес, который выбирался по умолчанию, и скачок Android с 8-й версии до 12-й.
Наша цель — чтобы вендоры обеспечили стабильный рабочий киоск и приложение для настройки. И всё это в самые сжатые сроки.
Некоторые вендоры справились с задачей довольно быстро: за 3–4 месяца реализовали киоски и предоставили софт для настройки. С другими мы работали почти год для достижения стабильности их решений. Мы получали новые версии приложений, тестировали их на складах и отправляли баги вендорам для исправлений. Не всё шло гладко: где-то вылетал киоск, где-то пользователи на складах находили лазейки входа в настройки и открытия полноценного доступа в интернет. Всего мы протестировали примерно 50 версий прошивок для разных терминалов, чтобы добиться стабильной работы в наших сценариях.
Вызов 2. Если при подключении к Wi-Fi не выбрать опцию «Больше не спрашивать для этой сети», терминал после перезагрузки не подключится к сети.
Вызов 3. Настройка ТСД у одного из вендоров состояла из 12 последовательных QR-кодов с частью ручных операций.
Вызов 4. Во время тестирования был выявлен ещё один недочёт использования неконтролируемых терминалов — это их ОС. ТСД Zebra уже были обновлены до актуального состояния, а новые устройства были распределены по стране тысячами на одной прошивке. Для них спустя пару месяцев мы получали от вендоров версии с учётом наших требований и замечаний. Обновлять девайсы, конечно, приходилось руками или через QR-код. Но если раньше мы скачивали только 100 МБ приложений при настройке, то тут шли уже пакеты с обновлениями весом до 2 ГБ. Так мы пришли к временной версии локальной распределённой инфраструктуры серверов с дистрибутивами ПО и конфигов на объектах.
В начале 2024 года мы частично дописали адаптированные под текущие условия инструкции и смогли уменьшить ручные операции до минимума, насколько это было возможно. Организовали каналы технической поддержки с обновлением терминалов и полностью взяли на себя процесс настройки ТСД. Реализовали регламент тестирования нового оборудования, чтобы отсечь случаи закупки у вендоров, которые не имеют необходимого софта для настройки.
Фокус на безопасность и масштабирование
Как я упомянул в начале статьи, прежняя схема доставки сертификатов не полностью отвечала нашим требованиям к безопасности и масштабированию. Пришло время решить и эту задачу.
Первым делом нацелились на корректный выпуск сертификатов и подключение к сети. Самое проблемное место при настройке ТСД то, что ранее мы использовали отдельно приложение для скачивания сертификата, а потом отдельное приложение для его установки, ещё и к этому, иногда используя раздачу Wi-Fi с устройства подключённого к внутренней сети. Для команды мобильной разработки создали задачу на создание нового решения.
После нескольких месяцев разработки и тестирования группой мобильной разработки нам подготовили новый инструмент для выпуска сертификатов, назовём его условно Ozon Updater. Для установки других приложений на устройстве Ozon Updater имел специальные права, которые ему могла обеспечить роль Device Owner (особые права для пакета, целью которого является получение повышенных прав для приложения, что предоставляет почти максимальный контроль над устройством), а приложение с такой ролью на устройстве может быть только одно. Также выяснилось, что роль Device Owner нужна и для управления сертификатами на устройстве. По этой причине Ozon Updater стал основой будущего MDM-решения для ТСД.
Приложение предоставили, теперь нужно его установить и подготовить новые инструкции. Но снова столкнулись с новой проблемой: как выдать права Device Owner? Так и началась глобальная перенастройка ТСД в полуручном режиме. Благодаря тому, что дальше за сертификат и подключение к сети отвечает Ozon Updater, мы решили много проблем с девайсами, у которых сертификат отзывался по времени. После перенастройки мы пересмотрели старую схему работы с сертификатами и перешли к более контролируемой модели их выпуска и обслуживания.
Ещё одной важной задачей было наладить доставку обновлений на терминалы. Каналы были 50–100 Мбит/с, а терминалов — несколько тысяч на один фулфилмент. При обновлении приложений, даже частичном, канал оказывался полностью загружен, иногда даже случались зависания устройств. Для решения этой проблемы мы реализовали функционал локального сервера для обновлений на складе. Принцип работы: после выхода новой версии приложения пакет автоматически загружался на сервер. В административной панели развёртывания указывалось, что ТСД должен скачивать его оттуда, а не из ЦОД. Позже мы переработали функционал для автоопределения источника скачивания. Сейчас настроена автоматическая генерация ссылок для скачивания с ЦОД или с локального сервера.
Итого — дистрибуция обновлений с локального сервера на все терминалы ускорилась в несколько раз и никак не влияла на канал. В будущем мы задействовали эти машины для загрузки прошивок на ТСД.
В рамках тестирования мы сократили первичную настройку любого терминала на 4–5 шагов. Ранее настройка терминала занимала 30 минут, а теперь — 20 минут. Если посчитать каждое устройство отдельно, то это огромная экономия времени, это и заложило основной кирпичик в разработку MDM для терминалов. Как раз к этому моменту у нас началось тестирование новых терминалов.
В рамках техподдержки у нас была основная цель: уменьшение трудозатрат на настройку и поддержку терминалов. А в рамках тестирования мы подготовили техническое задание для вендоров. Основные шаги были заключены в том, чтобы пропустить первичную настройку: отключить GMS-пакет, убрать безопасный режим и возможность сделать скриншот из меню питания, предустановить приложение Ozon Updater (основной этап настройки), предоставить права Device Admin, Device Owner, по беспроводной сети настроить каналы, частоты, далее яркость экрана, громкость и т. д. С такими условиями мы уже с завода получаем почти настроенный терминал, нам остаётся установить сертификат и приложения.
Следующим шагом мы добавили в Ozon Updater требования по обновлению приложений. К этому моменту стало понятно, что одна из главных проблем разнородного парка терминалов — разные лаунчеры.
У каждого вендора было своё решение: с разным набором функций, разным поведением и разным качеством реализации режима киоска. Из-за этого периодически появлялись сценарии, через которые пользователь мог выйти за пределы рабочего интерфейса. Например, в одном из лаунчеров через список запущенных приложений можно было на несколько секунд открыть системное окно с информацией о приложении, а оттуда попасть в настройки.
Часть таких проблем удалось закрыть точечными доработками. Например, релиз нашего лаунчера для старых терминалов Zebra на Android 8 помог убрать кнопки управления в режиме киоска, через которые пользователи иногда пытались обойти ограничения. После этого количество сообщений о подобных случаях заметно снизилось.
Но точечные исправления не решали проблему полностью. Чтобы унифицировать поведение терминалов и снизить риск выхода за пределы рабочего интерфейса, нам был нужен единый лаунчер, который можно установить на весь парк устройств.
Лаунчером, соответственно, стал Ozon Updater, который к этому времени научился ставить приложения и выдавать все необходимые для их работы права. Совместно с вендорами удалось интегрировать его в поставляемый образ устройства, таким образом мы получили уже почти максимально готовый к работе ТСД. Остаётся выпустить этим приложением сертификат и дождаться в течение 6 минут — и оно полностью установит недостающие приложения и настроит терминал для работы.
Итог всей работы
После доработки лаунчера мы получили от большей части вендоров рабочие прошивки уже с интегрированным Ozon Updater. Была разработана панель администратора для управления девайсами, которая включает в себя:
управление версиями прошивок;
управление профилями для устройств;
общий список устройств для управления девайсами с набором фильтров;
поддержку первичного сценария для инициализации устройства.
В карточке устройства мы можем проверить конфигурацию устройства в текущем состоянии, выгрузить диагностические логи, заблокировать или разблокировать устройство. Теперь мы знаем версию прошивки на каждом терминале, можем гибко обновлять прошивки на одном устройстве или на всех разом, устанавливать различные профили и менять их для групп устройств под разные сценарии работы пользователей.
Мы получили и внедрили крайне гибкий инструмент для поддержки работы терминалов, который можно дорабатывать под наши запросы, а не коробочное решение с рынка. Благодаря интеграции с вендорами также максимально упростили ввод устройств в эксплуатацию, что помогает бизнесу при запусках. Полностью решили проблему с часовым поясом девайса и актуальностью времени на нём. Снизили время первичной настройки с 20 минут до 15 (с условием, что терминал необходимо прошить с интегрированным Ozon Updater), а повторной настройки — до 6 минут. На новой партии устройств уже будет актуальный Ozon Updater, и мы не будем тратить недели на настройку ТСД.
Далее хотелось бы раскрыть процесс разработки Ozon Updater и появившиеся проблемы, а также поделиться частью сетевых доработок — это будет в отдельных статьях.
Спасибо за внимание!