Первая часть - первые 180 дней

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

Несмотря на то, что я обладаю практическим опытом создания технических команд с нуля, внедрения CMDB и разработки корпоративных регламентов, ранее эти процессы не были формализованы в виде единого стратегического плана. За 6,5 лет работы в холдинге FIBA Group, я глубоко изучил все этапы развития ИТ-команд и проектов изнутри. Данное тестовое задание стало для меня отличной возможностью систематизировать накопленные знания и представить их в виде структурированного документа.

Открыв свою любимую библиотеку ITIL 4, я начал обдумывать проект. У каждого проекта должны быть цели, а значит, и мне нужно их определить. Какими они могут быть для новой службы ИТ-поддержки? В первую очередь - достижение ключевых показателей эффективности (KPI).

Я решил сфокусироваться на следующих метриках:

SLA Compliance Rate (соблюдение уровня обслуживания);
Customer Satisfaction (уровень удовлетворённости пользователей);
First Contact Resolution (решение обращений при первом контакте);
L3 Workload Reduction (снижение нагрузки на L3, ведь кто-то же решает инциденты, пока нас нет).

Чтобы эти KPI достигались, нам нужны люди - сотрудники, готовые к обучению и способные проявлять эмпатию. Следовательно, необходимо продумать структуру команды, которой пока не существует. Для старта я решил взять за основу соотношение 2:1:1 (L1:L2:L3). Неплохое начало, правда? Всегда хотел иметь двух толковых специалистов L1, которые будут наперегонки обжимать патч-корды.

На этапе формирования команды от менеджера требуется описать SLA, установив конкретные временные рамки. По сути, мы «продаём» нашу услугу внутреннему заказчику в обмен на ресурсы (зарплату). Чтобы эти цифры были обоснованными, для начала нужно составить простую матрицу «Влияние/Срочность» (Impact/Urgency).

Приоритет определяется по матрице Impact/Urgency (Влияние/Срочность).

Приоритет определяется по матрице Impact/Urgency (Влияние/Срочность).

Используя эту матрицу для определения приоритетов, мы можем сформировать как внутренние KPI для каждого сотрудника, так и общие KPI для всего отдела. На основе этих показателей мы и напишем наш внутренний SLA. До полноценного, клиентского SLA нам ещё далеко, но это первый важный шаг.

С такой командой можно сразу же разработать и политику эскалации (о том, как это делается, расскажу как-нибудь потом). В итоге этих шагов мы будем готовы управлять инцидентами в разумных рамках. База знаний начнёт наполняться сама собой, по мере накопления опыта и решения кейсов, а процесс управления проблемами мы опишем в будущем. Такой подход близок к KCS Lite, где создание знаний - это не отдельный проект, а неотъемлемая часть ежедневной работы поддержки. Процесс управления проблемами оставим на будущее, это следующий этап зрелости.

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

Итак, у нас есть команда, есть обязательства (внутренний SLA) и есть поток инцидентов. Но мы же хотим смотреть в светлое будущее, а не только тушить пожары, верно? А это значит, нам нужен мониторинг.

Вместе с другими командами - DevOps, Разработка, Продажи - мы определим наш список «королевских драгоценностей»: ключевую инфраструктуру, бизнес-критичные приложения и важные каналы связи. Покрываем всё это связкой Zabbix, Prometheus + Grafana и становимся проактивными. И да, не забываем про грамотную настройку пороговых значений, иначе наш сон превратится в мечту под шквал ночных алертов.

Когда у нас пойдут данные из ITSM-системы и систем мониторинга, можно проявить свой гений в визуализации. Ведь как нас будут хвалить, если нам нечем похвалиться? Лично я предпочитаю два типа дашбордов:

Технический дашборд для ИТ-отдела: с графиками загрузки серверов, статусом ключевых сервисов и другими важными метриками. Это наш рабочий инструмент.
Общий дашборд для бизнеса: простая и понятная панель со статусами основных сервисов в виде светофора (зелёный/жёлтый/красный). Это отличный способ наглядно показать нашу работу и её влияние на бизнес.

Таким образом, мы становимся «всевидящим оком», которое не только видит проблемы, но и автоматически регистрирует инфраструктурные инциденты, имея полное визуальное представление о здоровье всей системы. На пути к стабилизации всё должно быть освещено - в нашем случае, светом дашбордов.

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

И это не проявление «звёздной болезни», а реальная возможность для пользователя решить свою проблему гораздо быстрее, чем через стандартную заявку. Ведь даже при самом жёстком SLA, одно только создание тикета отнимает драгоценное время, которое можно было бы потратить на чашку кофе. Мы же начнём собирать "лайки" через обратную связь, повышая показатели всего отдела. Тем самым мы приближаемся к первоначальным целям - достижению метрик.

Дальше начинается время рутины: созвоны, встречи, митинги — всё то, что так «любят» и трудоголики, и те, кто ими притворяется. На этом этапе мы полноценно внедряем управление проблемами и проводим первые разборы корневых причин (RCA).

Хотя мы и снижаем нагрузку на L3 (метрика L3 Workload Reduction улучшается), наше взаимодействие с ними, наоборот, становится более тесным и продуктивным. Мы активно пополняем базу знаний, запускаем опросы удовлетворённости, регулярно анализируем статистику по инцидентам. В общем, становимся опытными, бородатыми и брутальными.

На последний месяц из этих 180 дней, я бы оставил застенчивые шаги в сторону процесса управления изменениями (Change Management). Ведь нам уже нужно планировать вторую половину года: готовить отчёты по накопленной статистике, корректировать план расширения команды, а ещё так хочется внедрить систему обучения и новые инструменты... Всё что угодно, лишь бы не возвращаться в этот мир бесконечных собеседований.

Вторая часть. Еще 180 дней

Пришло время вернуться к тем самым «застенчивым шагам» в сторону управления изменениями (Change Management). За плечами - полгода успешной работы и отчеты, подтверждающие нашу эффективность. Мы продуктивны, проактивны, и нам дали зеленый свет на расширение: в команде появится еще один специалист L2, а ряды L1 пополнит сотрудник, нацеленный на написание статей для базы знаний и поддержку VIP - пользователей. Параллельно с процессами, мы запустили систему внутреннего обучения и грейдов, чтобы у лучших сотрудников была мотивация расти вместе с командой, а не искать счастья на стороне. Тем более у нас самые красивые дашборды на Диком Западе. Они не просто радовали глаз, а наглядно демонстрировали бизнесу, как снижение времени простоя напрямую экономит деньги. А что у нас дальше?

А дальше - построение масштабируемого фундамента. Процесс управления проблемами уже запущен: всё фиксируется, регистрируется и эскалируется. Гора обходных решений растет, но это лишь временные меры. Настало время это менять. Мы хотим больше влияния - хотя бы горсть, - чтобы не просто обходить проблемы, а устранять их корневые причины. Для этого мы вводим Change Request.

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

Стандартные (Standard Change): Низкорисковые, повторяемые и заранее утвержденные операции. Создание учетной записи по шаблону или замена картриджа в принтере. Согласование каждый раз не требуется.
Нормальные (Normal Change): Ядро процесса. Обновление ПО, миграция сервиса, изменение конфигурации брандмауэра. Каждое такое изменение требует оценки рисков, плана работ, плана отката и согласования с CAB (Change Advisory Board) — консультативным советом по изменениям.
Аварийные (Emergency Change): Когда всё горит и нужно срочно исправить критический сбой (например, закрыть уязвимость). Проводятся немедленно, но с обязательным разбором на CAB постфактум, чтобы извлечь уроки.

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

Возможно, этот шаг стоило планировать в самом начале, но в условиях первоначального хаоса и постоянного роста команд и продуктов - это было бы неэффективно. Теперь, когда процессы стабилизировались, мы готовы. Наша цель - найти всё: от каждого сервера до каждой установленной копии ПО. В ход идут discovery tools, сканеры сети и возможности наших систем безопасности вроде SentinelOne или Kaspersky.

Все результаты мы заносим не в Excel-таблицу, а в CMDB (Configuration Management Database) в нашей ITSM-системе. Ведь CMDB — это не просто список железок, а база данных, где каждый актив (CI, Configuration Item) имеет свои атрибуты, статус и, что самое главное, связи с другими активами.

Кратко, для чего все эти усилия? Мы можем связать CIs между собой и с бизнес-услугами. Например:

Бизнес-сервис «Корпоративная почта» зависит от приложения «Microsoft Exchange», которое установлено на виртуальном сервере EXCH-01, работающем на хосте VMHOST-A, подключенном к коммутатору SWITCH-CORE-1.

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

Идеальная картина мира выглядит так:

Инцидент + CMDB: При сбое на сервере EXCH-01 система автоматически показывает, что затронут сервис «Корпоративная почта», и повышает приоритет.
Изменение + CMDB: Планируя обновление на VMHOST-A, Change Manager видит, что это затронет не только почту, но и CRM-систему. Оценка рисков становится на порядок точнее.
Проблема + CMDB: Анализируя сбои почты, мы видим, что все они связаны с одним и тем же хостом, что помогает быстрее найти корневую причину.

По итогам этих 180 дней мы вырастем из команды «2:1:1, которая хочет кушать» в настоящий центр управления ИТ-услугами. Мы будем не только быстро решать проблемы, но и предотвращать их, опираясь на точные данные и контролируемые процессы. А на таком уровне уже можно всерьез обсуждать Return on Investment (ROI), ведь мы — прямая инвестиция в стабильность и производительность бизнеса.

Как я планировал Тех Под с 0