Как поднять мониторинг на новый уровень: опыт Банка ДОМ.РФ

Привет! Сегодняшняя статья про то, как мы настраивали мониторинг работоспособности отдела поддержки проектного финансирования Банка ДОМ.РФ.

«Ох уж это ПФ»

Банк ДОМ.РФ входит в тройку лидеров рынка по объёмам проектного финансирования. Это механизм, когда застройщик строит дом не на деньги дольщиков, а на кредит в банке. Для того, чтобы давать такие кредиты застройщикам, в Банке ДОМ.РФ существует огромная система, включающая в себя 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 и формировать в поддержке непрерывную оптимизацию процессов.

Если коротко — ещё есть над чем работать. Продолжение следует.

Автор: Денис Харьков, ИТ лидер направления поддержки систем проектного финансирования Банка ДОМ.РФ