Привет, Хабр! Наш проект "Пятерочки #налету", описанный в статье "Как тебе такое, Джефф Безос?"продолжает развиваться - надеемся, что вскоре дадим по нему апдейт. Ну а пока расскажем о еще более масштабном проекте, в ходе которого удалось обновить систему мониторинга автотранспорта на 15 000 машин.
Зачем она нужна? Представьте, что у вас есть магазин с постоянными клиентами, которые каждый день приходят за нужными им товарами. И есть грузовик, который каждое утро привозит эти товары. И вдруг в одно прекрасное утро грузовик не приезжает, или приезжает, но гораздо позже обычного, либо приезжает, но привозит испорченные товары. Хаос и разочарование на лицах покупателей неминуемы. А ведь это только один магазин и один грузовик. А что, если магазинов и грузовиков - много тысяч? В этом случае нужна сверх -надежная система мониторинга транспорта, которая поможет навести порядок с доставкой товаров. Под катом - описание системы, рассказ о том, как однажды все (ну, почти) поломалось и о том, как мы все поправили, переделав систему.
Как все начиналось
Вот уже много лет подряд сеть магазинов X5 постоянно растет, расширяется и автопарк, предназначенный для обслуживания магазинов. В 2015 году X5 Retail Group запустила систему оперативного мониторинга автотранспорта, которая значительно упростила работу логистам.
Эта система используется для того, чтобы контролировать качество сервиса доставки, а именно: своевременность прибытия по точкам маршрута, соблюдение температурного режима при перевозке и многое другое. Онлайн-табло у сотрудника магазина позволяет видеть местоположение грузовика, контакты его водителя и прогноз прибытия машины. Если что не так - узнать об этом можно в считанные секунды, что позволяет оперативно исправить ситуацию, не допустив того самого хаоса, о котором говорилось выше.
На практике персонал магазина всегда знает, когда прибывает товар, какой товар и в каком объеме. Соответственно, разгрузку/раскладку товара можно планировать заранее, сводя к минимуму временные затраты.
За чем именно следит система?
Рассказывает Вячеслав Мулюков – Начальник отдела по мониторингу перевозок X5 Logistics:
«Она ведет мониторинг критически важных показателей рейса каждого транспортного средства:
● Своевременность доставки и прогноз прибытия;
● Состояние температурного режима в кузове;
● Объем топлива + расход (в т.ч. газ и дизель);
● Количество паллет в кузове;
● Состояние дверей (открытие, закрытие);
● Скорость автомобиля, моточасы, пробег и другие данные с CAN-шины;
● Состояние холодильно-отопительного оборудования.
Мониторинг начинается после того, как машина, загруженная на складе, отправляется в путь. В систему загружается информация о начале рейса, перечень магазинов или складов, куда машина поехала, состав заказа и количество паллет, что также имеет значение для контроля рейса.
Магазины при этом видят "свои" автомобили с расчетом плановых доставок. Задерживается автомобиль или, наоборот, ожидается более быстрая доставка - все это можно узнать. Сотрудники складов в свою очередь, видят прогнозное время возвращения машины из рейса. И, к слову, на основе этих данных происходит расчет премий и надбавок водителям.
Если что-то идет не так, сотрудники торговых точек могут загрузить в систему информацию о проблеме, приложив фотографии - например, груза с повреждениями.»
И все бы хорошо, но с 2015 года объем автопарка значительно вырос, как следствие – количество данных и функциональность изначальной системы масштабировались. Появилась нужда в отслеживании большего, чем первоначально, количества технических параметров, которые считываются с транспорта. А это здорово увеличило нагрузку на систему. Мы стали задумываться об апгрейде или замене системы. В итоге систему решили не менять, т.к. она справляется со своими функциями, но решили кардинально ее проапгрейдить. Почему?<o:p>
Недостатки старой архитектуры
К 2019 году ее проблемы стали очень заметными:
● Запас производительности системы отсутствовал, поскольку масштабируемость была ограничена архитектурой. То есть уже во второй половине 2019 года ресурс системы был бы полностью исчерпан.
Тяжелые пользовательские отчеты формировались длительное время.
Время недоступности системы при сбоях инфраструктуры не отвечало общим требованиям к бизнес-критичным системам.
Потребность в ресурсах хранения данных превышала возможности системы.
Данные телеметрии собственных автомобилей передавались через внешнего провайдера. Проблемы с его оборудованием были причиной сбоев в системе.
Использование устаревшей и не поддерживаемой вендором версии Oracle. Изначально система была построена на СУБД 11 версии.
Дальше так нельзя
Проблемы с системой мониторинга транспорта могли привести к отсутствию должного контроля за условиями перевозки и невозможности оперативно реагировать на отклонения в рейсе, что в свою очередь может привести к финансовым потерям.
В 2019 году компания приняла твердое решение – оптимизировать работу системы. Дело в том, что именно в этом году произошла цепочка технических проблем с мониторингом, что привело к "белым пятнам" в транспорте – процесс доставки был непрозрачным, местоположение автомобилей и время доставки оставалось загадкой для сотрудников компании.
Проблемы были серьезными, и мы решили не дожидаться момента, когда нужно хвататься за голову и грустно повторять: "Шеф, все пропало!". Оперативно был запущен проект по апгрейду системы, и работа пошла.
Собрали команду из специалистов по инфраструктуре, базам данных, консультантов, плюс воспользовались помощью подрядчика для создания новой архитектуры.
Рассказывает Дмитрий Шушман – начальник отдела бизнес-приложений управления транспортом X5 Технологии:
«Вот основные моменты, которые мы изменили:
● В дополнение к Oracle подключили СУБД PostgreSQL. Организовав хранение в гибридном виде.Использовали даже не чистый PostgreSQL, а TimescaleDB, расширение для хранения временных рядов. Попутно обновили СУБД Oracle с 11 версии до Oracle 19с, с нормальной поддержкой от вендора и рядом новых фич для улучшения производительности.
● Оптимизировали хранение телематических данных, сделали партицирование ряда «тяжелых» таблиц и «научили» отчеты с ними работать.
● Сократили суммарный размер базы данных с 25 ТБ до, примерно, 10 ТБ. Перевели всю БД на SSDрешение.
● Актуализировали инфраструктурный ландшафт продуктива (создали дополнительные стендбай ноды для серверов БД. Внедрили балансировщик нагрузки для хаб-серверов).
● Не забыли и про ландшафт сред разработки и тестирования, теперь их ресурсы позволяют выполнить полноценное нагрузочное тестирование и без проблем работать нескольким командам разработки.
● Замкнули трафик телематики собственных ТС внутри инфраструктуры Х5, теперь за него полностью отвечаем мы. Постараемся не подвести наших коллег из бизнес подразделений.»
Что это дало:
Система наконец-то «задышала полной грудью». Теперь это решение, которое легко справляется со своими задачами и процесс его поддержки и развития сильно упростился.
Конечно, сейчас возможности системы тоже имеют границы. Лимиты будут исчерпаны еще не скоро - есть минимум 2 года, ну а в случае достижения критических показателей система мониторинга может быть оперативно масштабирована.
О сложностях внедрения изменений и результатах рассказал Никита Семин, руководитель направления проектов X5 Технологии:
«Мы подошли к реализации поставленной бизнесом задачи как к масштабному инфраструктурному проекту. Особенность реализации заключалась в том, что большинство компонентов системы находилось на стороне компании-разработчика, в результате чего нам пришлось буквально создать дубль системы, но уже на инфраструктуре Х5. Помимо инфраструктурных работ, о которых выше рассказал Дмитрий, было выполнено множество улучшений для удобства работы пользователей, например выросла скорость работы с отчетностью и данными, повысилось удобство работы с отчетами по большим периодам и доработан интерфейс. Также немаловажным для нас было создать фундамент для поддержки и развития системы собственными силами, что и было сделано – в рамках проекта мы наняли необходимый штат специалистов, который позволил нам снизить зависимость от вендора, ранее внедрившего решение».
Кстати, еще несколько интересных возможностей, которыми обладает система:
автоматический процесс приемки машины из рейса в части передачи информации в учетную систему SAP, которая ранее собирались вручную дежурными механиками, позволяет экономить значительный объем трудозатрат;
система позволяет устанавливать случаи недолива топлива при заправке, автоматически анализируя информацию по чекам с АЗС и сопоставляя ее с данными датчиков уровня топлива из системы;
процесс контроля уровня сервиса, предоставляемого наёмными транспортными компаниями, позволяет формировать рейтинги и на их основе управлять распределением рейсов между партнерами.
Что дальше?
Нужно провести масштабную ревизию легаси-кода, переписать его и сделать быстрее и эффективнее. Об этой проблеме на Хабре писали много раз, поэтому повторяться не будем.
Кроме того, планируется добавить несколько важных для партнеров Х5 функций. Одна из них - транслирование телематических данных. Пример – перевозку груза с использованием транспорта нашей компании заказывает некая компания "Х". В начале рейса данные с нашего автомобиля автоматически транслируется в систему мониторинга партнера, трансляция прекращается вместе с завершением работы машины. Таким образом, система перестает работать сугубо в интересах внутренних подразделений Х5, а становится связующим звеном во взаимодействии с нашими партнерами.
Еще одной важной фичей, на которой сосредоточится команда, будет набор инструментов по выявлению фрода в телематических показателях, что позволит компании снизить потери от хищений товара или вторсырья.
