В любой большой компании существуют десятки цифровых систем и сервисов — они автоматизируют, информируют и помогают улучшать процессы на самых разных уровнях. У нас в НЛМК есть «Банк Идей» — платформа, где любой сотрудник может предложить, как сделать производство эффективнее или безопаснее. Инициатива держится не на чистом энтузиазме — за внедренные идеи предусмотрено и реальное вознаграждение. Ежегодно на платформе подается более 30 тысяч идей, а количество вовлеченных в процесс авторов — более 45 тысяч человек.
Сервис выстроен как полноценный бизнес-процесс: стек разработки — .NET 5, база данных — MSSQL, у идеи меняются статусы, автоматически считается экономический эффект, отслеживаются расходы, корректируются премии. И поскольку система широко используется, вопросы пользователей не заставляют себя ждать. Почему премия такая? Кто добавил автора в идею? Когда премия была пересчитана и почему? Нам нужно видеть каждый шаг в изменениях — быстро, прозрачно и без «ручных» расследований с привлечением разработчиков.
Зачем мы дали бизнесу self-service
Раньше любые разбирательства с историей изменений выглядели одинаково: вопрос «кто поменял?» попадал к техподдержке, а оттуда — к разработчикам. Разработчик открывал лог, писал запрос к базе данных, сам собирал данные. Это было долго, неудобно и, прямо скажем, дорого.
Мы захотели сделать иначе: передать расследование истории изменений самим бизнес-пользователям, освободить разработчиков для более ценных и интересных задач. А главное — не тратить время на разработку и поддержку отдельного интерфейса под журнал изменений.
Как мы нашли решение
Существует масса готовых enterprise-интерфейсов для истории изменений.
Например, ApexSQL Audit и Idera SQL Compliance. Но они часто тяжеловесны, а их внедрение выливается в месяцы и приличные бюджеты, при этом поддержка всегда висит где-то на последнем месте в плане. К тому же любой внедренный enterprise-интерфейс живет по принципу «вход — рубль, выход — сто».
Тогда мы задумались: «А можно ли не писать отдельный UI вовсе?» Оказалось, можно!
Почему мы выбрали MongoDB для хранения гибких данных
У нашего выбора MongoDB было сразу несколько причин. Во-первых, вся история изменений хранится в одной коллекции MongoDB. Более того, можно хранить разные типы событий и данных, сохраняя сквозной поиск по ним.
Во-вторых, для просмотра истории отлично подходит бесплатное приложение MongoDB Compass. Это, по сути, интуитивно понятный визуальный клиент с фильтрами, сортировкой и поиском по любому полю.
Наконец, в-третьих, у MongoDB минимальный порог вхождения: пара инструкций, несколько готовых шаблонов фильтров — и люди из бизнеса в большинстве случаев разбираются без нас.
Как шла разработка
Мы за пару недель силами одного разработчика реализовали трассировку изменений в сервисе, а также установили Compass на рабочие места бизнес-администраторов.
Теперь все изменения по запрошенному бизнесом списку идут в журнал. Для бизнес-пользователей мы расписали фильтры по частым сценариям: «все изменения по идее», «кто менял статусы», «когда изменились бонусы» и т. д.
Запуск прошел волнительно, но все наши ожидания оправдались. С момента запуска никто ни разу не обращался к разработчикам по вопросам изменений данных: специалисты сами смотрят историю и отвечают на вопросы сотрудников.
С момента запуска прошло уже больше года — доработки были копеечные, например добавили к журналу несколько точек сбора данных. Причем добавление новой точки журналирования занимает от силы пару часов, нет никаких очередей из тикетов «посмотри, кто поменял». И самое важное: бизнес полностью перешел на self-service, а вопросы решаются за минуты, а не за часы или дни.
Почему плюсы open source не ограничиваются экономией
MongoDB и Compass в базовой версии бесплатны. Но их главное преимущество в нашем случае — не цена (хотя это тоже большой плюс), а выверенное удобство и минимальная нагрузка на разработку. Мы не писали лишний интерфейс: уже готовый GUI от сообщества выглядит симпатично и дружелюбно — не появилось еще одной унаследованной системы, которую надо вечно чинить. Поддержка на стороне бизнеса, а не в IT — значит, все выигрывают. Лицензия MongoDB (Server SSPL) запрещает продавать MongoDB как сервис, но для внутренних нужд можно использовать спокойно.
Результаты в цифрах
Доработка заняла 14 дней труда одного разработчика.
Раньше было около десяти обращений в месяц по вопросам изменения данных, сейчас таких обращений ноль. Таким образом, разработчики получили больше времени для работы над новыми задачами.
Разбор обращения по поиску истории изменений занимал около 1–2 часов. Получается, сейчас мы можем за сэкономленный бюджет запилить небольшую фичу. Большую часть изменений мы раньше вообще не сохраняли, приходилось заниматься гаданием по косвенным признакам или по картам Таро. Причем карты Таро были информативнее.
Какие выводы мы смогли сделать из разработки и запуска:
- Не всегда взаимодействие между IT и бизнесом требует сложных кастомных систем или платных коробок. Иногда готовые open source инструменты отлично решают поставленную задачу, попутно экономя время всей команды.
- Выбирайте такие решения, где бизнес может быть самостоятельным пользователем, а не постоянным просителем поддержки.
- Читать и разбираться в своем прошлом должно быть просто — и разработчики не должны быть для этого посредниками!
