Вторая линия ИТ-поддержки: когда штатным специалистам нужен внешний подрядчик

Главное – не дублировать работу штатного ИТ-отдела.

Условно первая линия занимается регулярными обращениями: создать учетную запись, настроить рабочее место, восстановить доступ сотруднику, подключить принтер или проверить стандартную проблему с корпоративным сервисом.

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

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

Количество сотрудников компании само по себе не определяет необходимость второй линии.

Гораздо важнее сложность инфраструктуры.

Представим компанию на 150 сотрудников. У нее есть виртуальная среда, несколько серверов, 1С, VPN, корпоративная почта, резервное копирование и два офиса.

Один системный администратор может нормально обслуживать такую инфраструктуру в штатном режиме. Но если одновременно возникает проблема с кластером виртуализации и необходимо восстановить критичную систему, специалист оказывается единственной точкой отказа.

Внешняя ИТ-поддержка в таком случае нужна не вместо администратора, а как резерв экспертизы и ресурсов.

Еще один сигнал – внутренний специалист регулярно откладывает плановые задачи из-за текущих обращений. Если обновления серверов, тестирование резервных копий и настройка мониторинга постоянно переносятся, проблема уже не только в количестве заявок. У ИТ-отдела не остается времени на работу с самой инфраструктурой.

Одна из главных причин привлекать подрядчика – задачи, для которых невыгодно держать отдельного сотрудника.

Компания может несколько раз в год сталкиваться с настройкой виртуализации, сложными сетевыми проблемами, миграцией серверов или восстановлением после серьезного сбоя.

Нанимать специалиста только ради этих эпизодов экономически не всегда оправданно.

Например, внутренний администратор обнаруживает проблему с производительностью виртуальной инфраструктуры. Вместо нескольких дней экспериментов он передает диагностику второй линии, специалисты которой регулярно работают с подобными системами.

В этом и состоит практическая ценность усиления ИТ-отдела: компания получает доступ к необходимой экспертизе тогда, когда она действительно требуется.

Есть еще одна проблема небольших ИТ-команд – зависимость от конкретных людей.
Если единственный системный администратор заболел, ушел в отпуск или уволился, поддерживать инфраструктуру становится некому.

Внешний системный администратор или команда второй линии могут использоваться как резерв.

Но такая схема работает только при одном условии: подрядчик должен знать инфраструктуру заранее.

Подключать новую компанию в момент аварии значительно сложнее. Специалистам сначала придется выяснять, где находятся серверы, какие существуют доступы, как устроена сеть и где хранятся резервные копии.

Поэтому резервная поддержка предполагает предварительную передачу схемы инфраструктуры, необходимых доступов и документации, а также периодическое знакомство подрядчика с изменениями.

Тогда отсутствие штатного сотрудника не превращается в экстренный поиск человека, который впервые видит инфраструктуру компании.

Внешней команде имеет смысл отдавать не все обращения подряд, а заранее определенный набор задач.

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

Главный принцип: внешний подрядчик должен закрывать дефицит экспертизы, а не повторять работу существующего ИТ-отдела.

Без четких правил первая и вторая линия могут начать перебрасывать задачи друг другу.

Поэтому необходимо определить, когда обращение передается подрядчику.

Например, критичный сервер недоступен. Внутренний администратор проводит первичную диагностику в течение 15 минут. Если стандартные действия не помогли, задача сразу передается второй линии.

Для менее критичных проблем допустимо больше времени на самостоятельное решение.

Особенно важно определить правила для инцидентов, которые останавливают бизнес. Если система продаж не работает, нет смысла три часа пытаться решить проблему своими силами только потому, что формально сначала должна разобраться первая линия.

В договоре с подрядчиком стоит отдельно закрепить время реакции именно на такие обращения.

У внешней поддержки есть и обратный риск.

Если все сложные задачи годами выполняет подрядчик, внутренний ИТ-отдел постепенно перестает понимать собственную инфраструктуру.

Поэтому результатом работы второй линии должно быть не только устранение проблемы, но и фиксация решения.

Например, подрядчик изменил конфигурацию сети – обновляется схема. Перенес виртуальную машину – корректируется документация. Устранил нестандартный сбой – причина и решение фиксируются в базе знаний.

Так экспертиза остается доступной компании, даже если подрядчик в будущем изменится.

Хорошая модель второй линии усиливает внутреннюю команду, а не делает ее зависимой от внешней.

Есть несколько практических признаков:

• сложные инциденты регулярно решаются методом проб и ошибок;
• критичные системы зависят от одного штатного специалиста;
• ИТ-команда постоянно откладывает профилактические работы из-за текущих заявок;
• компании периодически нужна экспертиза, ради которой невыгодно нанимать отдельного сотрудника;
• во время отпуска или болезни администратора некому принять инфраструктуру;
• восстановление после серьезного сбоя занимает слишком много времени;
• для отдельных технологий внутри компании фактически нет компетенций.

Если совпадает несколько пунктов, поддержка ИТ-отдела внешней второй линией может оказаться дешевле расширения штата и безопаснее работы без резерва.