Більшість ваших функцій реального часу в логістиці не є реальним часом

Кожна логістична платформа продає реальний час. Відстеження в реальному часі. Видимість в реальному часі. Сповіщення в реальному часі. На демо іконка вантажівки плавно ковзає по карті, і інженер у залі схвально киває.

У виробництві іконка вантажівки оновлюється кожні тридцять секунд, і позиція, яку вона показує, відстає на сорок секунд. Маршрут на карті — інтерпольований. Подія "доставлено" надходить у звичайний день між двома і п'ятнадцятьма хвилинами після фактичної доставки. Нічого з цього не є неправильним. Все це "реальний час" у тому сенсі, в якому індустрія використовує це слово. Але клієнт думає, що реальний час означає те саме, що у відеодзвінку, і прірва між цими двома визначеннями спричиняє приблизно половину ескалацій клієнтів у цій сфері.

Скільки коштує реальний час

Реальний час у строгому сенсі коштує грошей. Конкретно — трьох речей, що масштабуються лінійно зі строгістю визначення.

Пропускна здатність телематики. Вантажівка, що звітує GPS-позицію раз на секунду, використовує приблизно в шістдесят разів більше даних, ніж та, що звітує кожну хвилину. Помножте на флот з десяти тисяч транспортних засобів, на вартість тарифних планів, на мертві зони стільникового зв'язку, де буферизовані дані врешті надсилаються пакетами при відновленні покриття. Рахунок за пропускну здатність реальний, а ROI від п'ятисекундного інтервалу проти тридцятисекундного є у майже кожному бізнес-кейсі нульовим.

Інфраструктура для обробки потоку. Щойно позиції надходять з однієї секунди роздільної здатності, кожна downstream-система має обробляти таку пропускну здатність. Сховище. Потокові процесори. Рушії геозон. Push-сповіщення до застосунків водіїв. У кожного з них свій профіль масштабування, і вони не всі масштабуються лінійно. Односекундний інтервал оновлення легко може означати вдесятеро більші витрати на інфраструктуру проти тридцятисекундного — майже без операційного поліпшення.

Інженерні години назавжди. Строгість стає властивістю архітектури, а архітектура стає властивістю компанії. Кожна нова функція має її поважати. Кожна нова вендорська інтеграція має її поважати. Загальна вартість — не збірка; це наступні п'ять років, коли кожен інженер думає про латентність, яка бізнесу ніколи не була потрібна.

Що клієнтам насправді потрібно

Цікаво, що майже жодному логістичному клієнту насправді не потрібні позиції посекундно. Їм потрібна одна з трьох конкретних речей.

Точний ETA. "Коли приїде моя вантажівка?" Щоб відповісти добре, потрібна відстань маршруту, трафік, історичний темп водія і позиція достатньо свіжа для старту. Позиція тридцятисекундної давнини — цілком достатня. Позиція однієї секунди не дасть кращого ETA.

Події геозон. "Повідом мене, коли моя вантажівка в'їде на склад." Це вимагає гарантованої доставки події (складніша проблема), а не частішого опитування. Правильна подія, що надійшла через сорок секунд, цінніша за потік, який міг або не міг її зловити.

Сповіщення про виключення. "Повідом мене, коли щось іде не так." Пізній від'їзд, відхилення від маршруту, несподівана зупинка. Це виявлення патернів у вікні. Тут не потрібен реальний час — потрібна коректність.

У всіх трьох випадках архітектура, що перемагає, — подієво-орієнтована з відносно грубим опитуванням під нею, а не високочастотний стрімінг. Виняток — справжня пряма карта: клієнт, що буквально дивиться на рух вантажівки в реальному часі, для наглядових цілей. Такий кейс існує, і він — один або два екрани в бізнесі, а не вся платформа.

Що реально робити

Схема, яка працює, на нашому досвіді:

Визначте контракт свіжості даних для кожної функції. ETA: позиція не старша дев'яноста секунд. Події геозон: гарантована доставка протягом п'яти хвилин від виникнення. Жива карта: best-effort тридцять секунд, без SLA. Запишіть це. Покажіть клієнтам. Клієнти вважають це заспокійливим, а не розчаровуючим — вони були обпечені розпливчатими обіцянками "реального часу" і цінують чесність.

Спочатку будуйте хребет подій, потім опитування. "Geofence-entered", "route-deviated", "delivery-completed". Це події, на яких тримається бізнес. Будуйте їх як надійні, впорядковані, "exactly-once" події. Потім накладайте опитування позицій поверх — з частотою, яку вимагає контракт свіжості.

Проєктуйте з урахуванням поганої мережі. Водії їдуть крізь тунелі. Склади всередині сталевих будівель. Модем вантажівки перезавантажується. Телефон розряджається. Логістична система, що вдає надійність з'єднання, — це система, що виробляє неправильні дані більшість днів. Буферизуйте локально, узгоджуйте при повторному підключенні, проєктуйте кожну подію відтвореною.

Чесна пропозиція

Ми збудували чимало таких систем. Версія, що виходить у реліз і залишається в релізі, майже ніколи не та з найагресивнішими показниками реального часу. Це та, де контракт між системою і клієнтом чесний щодо того, що означає "реальний час", а архітектура оптимізована під те, що бізнесу реально потрібно: точні ETA, гарантовані події та стійкість до мережі, яка іноді намагається зіпсувати ваш день.