Как мы создали Telegram-бот и увеличили эффективность осмотра вагонов

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Хабр! Меня зовут Сергей Корнеев, я руководитель направления аналитики отдела прототипирования в ПГК Диджитал. Мы занимаемся разработкой пилотных цифровых решений (Proof of concept, MVP), которые упрощают жизнь нашим коллегам и способствуют повышению эффективности бизнеса.

В этой статье расскажу, как мы задумались над процессом осмотра вагонов, как IT-решения помогают бизнесу и почему мы выбрали Telegram-бот, а не другие варианты.

В чём была проблема?

Раньше сотрудники, проводящие осмотр вагонов, использовали бумажные распечатки или ноутбуки. Это было неудобно в полевых условиях, особенно в плохую погоду. Гораздо удобнее просто ввести номер вагона в смартфоне и сразу получить нужную информацию в соответствии со своей ролью.

Другой сценарий: осмотрщики звонили коллегам по телефону, просили проверить данные по вагону в системе, что отвлекало их от работы. Ошибок при передаче информации было мало, но, например, можно было неверно расслышать номер вагона. Самым сложным была именно подготовка и затрачиваемое на неё время: печать материалов или формирование выгрузок из разных систем, а также необходимость носить с собой ноутбук.

Путь решения

Заказчиками проекта выступили коллеги из отдела нормативно-технического регулирования и инноваций нашей материнской компании – Первой грузовой компании (ПГК), они занимаются повышением эффективности эксплуатации вагонов компании.

Для проверки гипотезы о востребованности такого инструмента был выбран формат рабочего прототипа: базовая сборка функционала с возможностью “боевого” тестирования на реальных пользователях и данных. Команда прототипирования рассмотрела несколько вариантов и остановилась на разработке Telegram-бота.

Почему Telegram-бот?

Мы рассматривали разные варианты: мобильное приложение, веб-интерфейс. Но:

Мобильное приложение — долго и дорого, у нас не было свободных разработчиков под мобильную платформу.

Веб-интерфейс — медленнее, чем Telegram-бот.

Telegram-бот — идеальный баланс: по результатам custdev мессенджер уже установлен у всех сотрудников, он удобный и быстрый.

Внедрение прошло легко: анонсы на внутреннем портале, корпоративное ТВ, демонстрация. Уже через короткое время после успешного завершения прототипа у нас было более 90% всех сотрудников, участвующих в бизнес-процессе.

Процесс разработки и технологический стек

По рекомендации наших сотрудников информационной безопасности (ИБ) команда разработки спроектировала многоуровневую архитектуру с реализацией полноценной демилитаризованной зоной  (ДМЗ).

Вполне прогнозируемым видится и стек используемых технологий. Так, два backend-а написаны с использованием микросервисной архитектуры в парадигме FastAPI (Python). Почему два? Ответ прост: Часть данных находится во внутреннем контуре ИС ПГК. Здесь работает основной backend, отвечающий за аутентификацию, авторизацию (PostgreSQL), обработку запросов пользователей с использованием данных из различных витрин данных (Oracle, MsSQL), средства администрирования и т.д. Стоит упомянуть, что для поддержания актуальности доступов к данным, реализован scheduler-механизм (автоматически запускается по расписанию), который сравнивает перечень активных пользователей с учетными записями в ActiveDirectory и деактивирует тех, кто ушёл из компании и не имеет более учётки AD. Также, система использует Email-Service для подтверждения прав пользователей при регистрации/периодической реактивации.

Второй backend архитектурно планировался к размещению в ДМЗ. Он отвечает за интерфейсную часть, реализованную через Telegram-Service. Между собой backend-ы общаются через Kafka (брокер сообщений).

Считаю, плох тот проект, в котором не возникло “нештатной” ситуации, удивившей фантомной ошибкой, требующей приложения усилий в тестах. Не буду утомлять подробностями, но есть некоторые нюансы при разборе с помощью Listner (consumer) сообщений от Kafka. Если разбор очередного сообщения несколько затянулся, брокер считает его ошибочно “не разобранным” и отправляет вновь. Поэтому все полученные сообщения сразу оборачиваются в обёртку и запускаются в отдельном автономном процессе. Так ответы на некоторые запросы в Telegram пользователь видит в не том порядке, в каком отправил.

Источник: https://habr.com/ru/companies/pgk/articles/885616/


Интересные статьи

Интересные статьи

Приветствую всех неравнодушных! Я являюсь руководителем разработки в компании DD Planet, и сегодня, наконец-то, дошли руки написать продолжение статьи
Создадим прототип SPA в Bitrix без использования популярных JS фреймворков и библиотек, все будет сделано средставами Bitrix.И самое главное без потери серверного рендеринга и SEO страниц.ПогналиВсего...
Автор: DevOps компании Hostkey Никита ЗубаревИнфраструктура нашей компании поддерживается на высоких уровнях SLA, что требует от нас измерять, наблюдать и отправлять отчеты, которые фиксируют метрики ...
Пропорция золотого сечения известна людям уже несколько тысяч лет и всё это время не теряет популярности как в чисто математической среде, так и среди художников, скульпторов, философов, биологов. Зол...
Привет, это Дима, бэкенд-разработчик из Hawking Bros. Сегодня я расскажу о решении задачи, с которой мы столкнулись при реализации нестандартной логики инфоблоков на проекте с битриксовой многосайтово...