Как поднять мониторинг на новый уровень: опыт Банка ДОМ.РФ
Привет! Сегодняшняя статья про то, как мы настраивали мониторинг работоспособности отдела поддержки проектного финансирования Банка ДОМ.РФ.
«Ох уж это ПФ»
Банк ДОМ.РФ входит в тройку лидеров рынка по объёмам проектного финансирования. Это механизм, когда застройщик строит дом не на деньги дольщиков, а на кредит в банке. Для того, чтобы давать такие кредиты застройщикам, в Банке ДОМ.РФ существует огромная система, включающая в себя 5 подсистем.
От работоспособности и отказоустойчивости этой системы зависит, насколько быстро, удобно и бесшовно застройщики будут получать финансирование и начнут строить жильё. А значит, техподдержка и отработки инцидентов должны происходить если не молниеносно, то около того.
Проблема
Ежемесячно от пользователей системы проектного финансирования приходит порядка 2 тыс. обращений в техподдержку. Все эти обращения мы должны отрабатывать в регламентные сроки, обеспечивая следующие показатели эффективности: SLA — 95%, отказоустойчивость системы — 99,99%. Но, как выяснилось, над этим ещё предстояло поработать. Текущие показатели были далеки от идеальных: SLA решения было около 60%, а SLA реакции — 80%. Нам предстояло разобраться, почему система «не взлетает», и мы приступили к анализу.
Дело в технике
Специалисты техподдержки обрабатывают все обращения в ServseDesk Creatio, в которую заявки пользователей попадают через почту или через портал самообслуживания. «Под капотом» в Creatio есть услуги и сервисы, которым можно установить плановое время реакции и решения, согласно договору SLA — 8 часов. Также в Creatio есть возможность сформировать отчёт по обращениям за пользовательский период в формате Еxcel и после его обработки вычислить текущий SLA и посмотреть динамику. Ручная выгрузка отчёта, которая действовала в компании ранее, занимала около 4 часов. Так как мы не хотели делать ручные выгрузки, то средством агрегирования информации должна была стать система мониторинга. Она же, по нашей гипотезе, должна была показать, что не так с другими показателями.
Выяснилось много интересного:
1) Сотрудники поддержки не сразу замечают новую заявку, так как она легко теряется в почте. Они вынуждены в онлайне смотреть на экран линий Creatio и обновлять страницу, ибо разработчики не выпустили автообновление линии в нашей версии.
2) Сотрудники не всегда могли вовремя закрыть обращение, так как отвлекались на другие задачи, забывая про активное обращение.
3) У коллег не было четкого регламента работы с обращениями, из-за чего возникали различные другие причины просрочки.
Дашборд животворящий
Получив ограниченный доступ в Creatio, мы написали несколько SQL-скриптов по каждой группе поддержки подразделения. Благодаря скриптам выгрузки из системы начали формироваться автоматически и собираться в один дашборд. Доступ к дашборду мы дали всем сотрудникам техподдержки.
При создании item в Zabbix использовался стандартный database monitor, в теле которого был скрипт по подсчётам основных показателей мониторинга поддержки:
1) Сколько заявок заведено
2) Сколько заявок решено
3) Сколько просрочек по реакции и по решению
4) Сколько заявок находится в работе с разбивкой по статусам «На паузе» и «На инициаторе»
5) Какая текущая очередь заявок
6) Текущий SLA реакции и решения
Дополнительно был сформирован скрипт по потенциальным просрочкам обращений.
В zabbix были настроены оповещения по новым обращениям и просрочкам, которые приходили в группу Telegram. Сотрудникам поддержки так это понравилось, что они предложили дополнительно вывести таблицы с данными по заявкам в каждой категории, чтобы не переходить из системы в систему.
Спустя месяц работы мониторинга замеры по SLA были такими: SLA реакции — 98% и SLA решения — 97%
Крутые результаты, а что дальше?
1) Необходимо снизить количество времени статуса паузы, в которое заявка попадает в случае заведения бага в команду разработки. Это будем решать введением SLA решения багов в каждой команде и соответствующим контролем. «Смогли за час среагировать, а почему не сможете за минуту?»
2) Необходимо типизировать обращения и заводить их через портал самообслуживания в различных категориях с заполнением обязательных полей, что снизит время обработки обращений.
3) Необходимо после типизации обращений разработать инструмент автоматизации по решению типовых обращений.
4) Необходимо подконтрольно снижать время SLA и формировать в поддержке непрерывную оптимизацию процессов.
Если коротко — ещё есть над чем работать. Продолжение следует.
Автор: Денис Харьков, ИТ лидер направления поддержки систем проектного финансирования Банка ДОМ.РФ
