Привет, Хабр! Меня зовут Сергей Корнеев, я руководитель направления аналитики отдела прототипирования в ПГК Диджитал. Мы занимаемся разработкой пилотных цифровых решений (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 пользователь видит в не том порядке, в каком отправил.
