ИТ-поддержка держится на одном инженере: что случилось, когда сисадмин ушёл в отпуск и 60% заявок перешли на четверых

Инженер, который знает всех пользователей по именам, помнит, у кого какой ноутбук и кто не любит писать в HelpDesk, — лучший сотрудник ИТ-поддержки и одновременно главный риск. Пока он на месте, всё работает быстро. Когда он уходит в отпуск, руководитель компании узнаёт, что поддержка держалась на одном человеке.

Мы разобрали 1 297 заявок группы компаний за семь месяцев — и увидели этот сюжет в цифрах. Первые шесть месяцев 60,1% заявок и 60,8% часов держал один инженер первой линии. В июле он ушёл в отпуск. Ниже — что произошло, сколько это стоило и как проверить, что будет с вашей поддержкой в августе.

Что такое bus factor в ИТ-поддержке. Bus factor — число людей, после выпадения которых сервис останавливается. Если один инженер закрывает больше половины заявок и один знает пароли, bus factor ИТ-поддержки равен единице: его отпуск, болезнь или увольнение заказчик замечает сразу. Снижают его не документами, а практикой перераспределения потока и передачи знаний — и именно это проверяет сезон отпусков.

Почему поток заявок в ИТ-поддержку концентрируется на одном инженере

Это не ошибка планирования. Инженер первой линии, который дольше всех работает с клиентом, закрывает типовые заявки за 24 минуты: он знает, где лежит база, кто координатор в подразделении и что «опять слетел офис» означает конкретный ноутбук на втором этаже. Пользователи тоже это знают — и пишут ему напрямую.

В результате поток сам стягивается к самому быстрому. За полгода до июля инженер A закрывал 79–156 заявок в месяц. Остальные шесть постоянных инженеров — от 2 до 35. Служба выглядела устойчивой: 81,5% заявок закрывались в пределах суток, просрочено было 2,3%. Только устойчивость эта была устойчивостью одного человека.

Июль: 60% потока за неделю перешли на четверых

В июле инженер A закрыл 47 заявок вместо обычных 128–156. Поток при этом не просел: 179 заявок за месяц против 183 в июне. Его приняли четыре инженера:

Доля просроченных заявок не выросла. Активных заявок на конец месяца — 25, норма для такого объёма. Заказчик не почувствовал разницы, и это главный результат: знание клиента не оказалось заперто в одном человеке.

Важная оговорка: перераспределение прошло без предварительной передачи дел. Четыре инженера приняли поток, потому что работали с этим клиентом раньше — по своим темам, в меньшем объёме, но работали. Это и есть разница между штатом и «своим админом».

Цена перераспределения — и почему она ожидаема

Было бы нечестно показать только красивую половину. У инженеров, принявших поток, доля долгих заявок — дольше трёх дней — выше: 20% у инженера E и 16,7% у инженера G против 5,9% у инженера A.

Причин две. Первая — характер работы: E и G ведут инфраструктурные и проектные задачи, которые по природе не закрываются за час. Вторая — меньшее знание конкретных пользователей: на выяснение, где стоит станция и кто владелец базы, уходит время, которого у инженера A не уходило. Обе причины ожидаемы, обе устраняются практикой. Поэтому перераспределение мы закрепили как постоянную меру с программой передачи знаний, а не как аварийный режим на время отпуска.

Чем штат отличается от «своего админа»

Ситуация с отпуском повторяется в трёх вариантах, и только первый из них плановый.

Отпуск. Известен заранее, длится две-четыре недели. Штатному сотруднику замену обычно не ищут — «потерпим». В подрядчике с одним выделенным инженером это тот же сценарий под другим названием.

Болезнь. Неизвестна заранее, длится от трёх дней до двух недель. Заявки копятся, пользователи пишут в мессенджеры, руководитель сам звонит поставщику интернета.

Увольнение. Длится навсегда. С человеком уходят пароли, схема сети и знание, что «сервер 1С нельзя перезагружать до восьми утра». Что с этим делать, мы разбирали в материале «Сотрудник ушёл, пароль от сервера остался у него».

Механизм, который делает все три сценария незаметными для заказчика, один: за клиентом стоит не человек, а служба. В нашей — 20 штатных инженеров, без фриланса и ИТ-субподряда. Это не про размер, а про то, что у каждого клиента есть несколько инженеров, которые его знают, и у каждого инженера есть кто-то, кто знает его клиентов.

Правило 35% и передача знаний

По итогам разбора мы закрепили правило: ни один инженер не несёт более 35% потока одного клиента. Не потому, что 60% — плохо для качества, а потому, что 60% — плохо для устойчивости.

Правило держится на трёх практиках:

• Ротация типовых заявок. Часть потока первой линии распределяется на второго и третьего инженера принудительно, даже если ведущий закрыл бы быстрее.
• Документированный контекст клиента. Кто координатор в каждом подразделении, какие системы критичны, что нельзя трогать в рабочее время, — записано, а не хранится в голове.
• Ежемесячный контроль концентрации. Доля потока на одном инженере — строка в отчёте, а не открытие в июле.

Цена правила — те самые лишние минуты на заявку у инженеров, которые знают клиента хуже. Мы считаем это платой за то, что отпуск ведущего инженера перестаёт быть событием.

Что именно записано в контексте клиента

«Передача знаний» звучит абстрактно, поэтому вот состав документа, который есть у каждого нашего клиента и который читает инженер, принимающий чужой поток. Пять разделов, каждый — на страницу.

• Люди. Координаторы по подразделениям, кто имеет право ставить заявки от имени коллег, кому звонить, если координатор в отпуске.
• Критичные сервисы. Системы, остановка которых стоит денег, и допустимый простой для каждой — в минутах, согласованный с руководителем.
• Ограничения. Что нельзя делать в рабочее время: перезагружать сервер 1С, обновлять антивирус на кассах, менять правила на шлюзе без предупреждения.
• Типовые операции. Как разворачивается копия базы, где лежат дистрибутивы, как выглядит стандартное рабочее место — с шагами, а не с именем того, кто «знает».
• Открытые серии. Проблемы, которые возвращаются, и их текущий статус — чтобы принимающий инженер не закрывал по одной то, что коллега уже разбирает как причину.

Документ обновляется при каждом изменении, и это входит в сопровождение. Инженер, который знает всё это по памяти, — по-прежнему самый быстрый. Но теперь он не единственный.

Три вопроса, чтобы проверить свою поддержку

Ответьте на них честно — цифрами, не ощущениями.

1. Кто закрывает больше половины ваших заявок? Если один человек — у вас bus factor, равный единице. Посмотрите в HelpDesk распределение по исполнителям за последние полгода. Если HelpDesk нет, это уже ответ.
2. Что будет в его отпуск? Не «справимся», а конкретно: кто примет заявки, знает ли он ваших пользователей, где записано, что нельзя перезагружать сервер до восьми утра. Проверить это можно до отпуска — десятью вопросами системному администратору.
3. Сколько людей знают пароли? Если один — вернитесь ко второму вопросу и добавьте к нему увольнение.

Если хотя бы на один вопрос ответ — «один человек», отпуск этого человека покажет, что вы обслуживаетесь не службой, а везением. В разборе кейса есть полная картина потока, включая то, что мы нашли на массиве заявок помимо сезона отпусков, и почему на приёме заявок нужны люди, а не один дежурный.

Сопровождение, которое не зависит от одного инженера, — это ИТ-аутсорсинг с несколькими инженерами на каждого клиента: поток распределён, контекст записан, отпуск ведущего инженера не становится событием для заказчика.