В современных компаниях ИТ-инфраструктура находится на положении «младшего брата» информационных систем. Ее основные составляющие, бе­зусловно, нужны для работы предприятия. Но их бизнес-ценность очень невелика, тогда как основная ценность ИТ для бизнеса со­средоточена в прикладных информационных системах. Можно назвать ИТ-инфраструктуру «неизбежным злом», на которое ИТ-директора вынуждены отвлекать свое внимание.

Александр Козлов, независимый эксперт
Александр Козлов, независимый эксперт; a.a.kozlov99@gmail.com

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

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

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

Декомпозиция, или выделение «cервисов»

Прежде всего следует понять, где именно необходимо навести порядок. Для этого мы используем концепцию «инфраструктурных сервисов». Важно, что «инфраструктурные сервисы» не совпадают с ИТ-сервисами для конечных пользователей. Например, чтобы пользователь со своего компьютера получил доступ к корпоративной ERP-системе, должны работать сервер с базой данных, локальная сеть и система авторизации (домен). Таким образом, пользовательский ИТ-сервис «Доступ к ERP-системе» уже зависит как минимум от трех инфраструктурных сервисов. В отличие от пользовательских ИТ-сервисов, «инфраструктурные сервисы» — это, скорее, подсистемы, разные механизмы в сложной машине ИТ-инфраструктуры, которая обеспечивает пользовательские ИТ-сервисы (доступ к информационным системам) с максимальной ценностью для бизнеса.

Инфраструктурными сервисами могут быть оборудование (серверы и системы хранения), виртуализация (гипервизоры и системы управления ими), локальная сеть, служба каталогов, файловый сервис, офисная почта, прочие коммуникационные сервисы, СУБД, терминальные серверы, корпоративные средства информационной безопасности и т. д. Перечень индивидуален для каждой компании. При его составлении важно соблюдать несколько общих принципов.

Во-первых, необходимо учесть роль ИТ в бизнесе компании. Например, если в организации работает контакт-центр, то разумно выделить в сервисе «Офисная телефония» подсервис «IVR» — поскольку IVR представляет важную часть контакт-центра, интегрированную с основными информационными системами и регулярно подвергаемую изменениям. Однако это не имеет смысла для офиса небольшой организации, где механизм IVR используется только для донабора внутреннего номера сотрудника, настраивается один раз и работает автономно. В этом случае правильнее будет оставить один сервис «Офисная телефония», включающий в себя офисную IP-АТС со всеми встроенными модулями.

Во-вторых, надо помнить, что большие сервисы с широким охватом усложняют наведение порядка. Многое зависит от масштаба развернутой инфраструктуры. Если для организации локальной сети в офисах компании используются простые сетевые устройства, то сервис «Локальная сеть» допустимо рассматривать целиком. Но если сеть насчитывает сотни рабочих мест, включает беспроводные сегменты или сложное операторское оборудование, то разумно будет разбить его на подсервисы (например, DHCP, Wi-Fi, управление IP-адресами, коммутируемая сеть второго уровня, VPN). Такая детализация позволит сделать сложный сервис «Локальная сеть» прозрачным.

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

Теперь, когда мы определились, в чем именно собираемся наводить порядок, осталось решить, кто это сделает. У каждого сервиса должен быть «владелец» — сотрудник, который будет отвечать за эту часть инфраструктуры. Назначьте владельцев сервисов исходя из предпочтений сотрудников и их наиболее успешного опыта работы. Если за специалистом планируется закрепить более одного сервиса, учитывайте особенности его менталитета. Например, сервис «Оборудование»/«Виртуализация» требует схожих компетенций и может успешно обслуживаться одним специалистом, а вот сопровождение сервисов локальных сетей и СУБД требует разных навыков, редко сочетающихся у одного сотрудника.

Одиннадцать шагов к порядку

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

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

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

«Инсталляция» — это реализация сервиса в конкретном месте распределенной инфраструктуры. Например, инсталляцией сервиса «Локальная сеть» являются все его компоненты в филиале компании в Калуге. Централизованные сервисы имеют только одну инсталляцию.

В целом этап инвентаризации можно назвать наполнением конфигурационной базы данных (CMDB). Если у вас этой базы еще нет, то результат инвентаризации можно представить как таблицу, откуда можно автоматически получить уровни унификации по каждой компоненте и сервису в целом.

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

Этап № 2. Мониторинг. Ставим на мониторинг основные компоненты сервисов во всех инсталляциях, определяем основные показатели работы компонент (KPI) и их критические значения. Главное правило прежнее — никакого микроменеджмента сотрудников! На гипотетических примерах поясняем им, что подразумевается под мониторингом, тогда бездна человеческого таланта будет использоваться в нужном направлении. Хорошим упражнением может стать мини-семинар «Мониторинг автомобиля: основные компоненты, их KPI и мониторинг», у сильной половины ИТ-специалистов эта тема может вызвать позитивный отклик. Далее задаем эскалацию событий мониторинга: кто, когда и как узнает о прохождении критических значений и прочих событиях, или «триггерах» мониторинга. Для этого используем звонки, SMS, электронную почту — в ход идет весь инструментарий коммуникаций в зависимости от важности события.

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

Этап № 3. Унификация. Приводим все компоненты всех сервисов к стандартному виду во всех инсталляциях. Этот этап займет больше времени, чем предыдущие два. Но он состоит из понятных задач с измеримым результатом. Эти задачи несложно решить самим, распараллелить по разным исполнителям или отдать подрядчику. Речь идет о несложных, но иногда трудозатратных ИТ-проектах: обновить прошивки на серверах, установить коммутаторы для стандартизации схемы сети, обновить версию операционной системы или системного ПО, установить обновления.

По завершении этапа «Унификация» у каждого сервиса во всех инсталляциях все компоненты одинаковы, то есть уровень унификации по всем компонентам сервиса достигает 100%. Тем самым серьезно снижается вероятность сбоев и увеличивается способность организации учиться после каждого инцидента.

Этап № 4. Резервное копирование. Цель этапа — убедиться, что регулярно создаются резервные копии для критичных данных по каждому сервису. Оптимальный инструментарий определяется по ситуации. Например, для большинства серверов можно снимать резервные копии на уровне виртуальных машин, а для критических данных, вроде сервиса каталогов или SQL-баз системы ERP, обеспечить дополнительное копирование. Самое главное на этапе резервного копирования — регулярный контроль процесса. Его разумно реализовать, добавив на этапе мониторинга регулярную проверку прохождения резервного копирования и уведомление ответственных лиц.

Необходимо помнить, что любое изменение должно затрагивать все ранее пройденные этапы. Например, мы закончили с этапом № 4, значит, стоит вернуться на первые три этапа и отразить изменения там: указать аспекты резервного копирования в инвентаризации сервиса (этап № 1), поставить копирование на мониторинг (этап № 2) и привести резервное копирование к одинаковому виду по всем инсталляциям (этап № 3). Только такое системное внесение изменений позволит обеспечить устойчивость и стабильность инфраструктуры.

Этап № 5. Непрерывность. После того как пройдены первые четыре этапа, пора задуматься о работе сервиса в чрезвычайных ситуациях. Этап «Непрерывность» подразумевает обеспечение отказоустойчивости сервиса и наличие планов действий по его восстановлению во всех возможных случаях. Важно, чтобы планы были рабочими, а значит, надо регулярно проводить тренировки. Существенно не только количество проведенных тренировок, но и их качество, поэтому процесс испытаний надо описать в измеримых показателях и тоже контро­лировать. Мы должны знать, что тренировка была и она успешно завершилась, — для этого нужно понимать, как и какие KPI сервиса меняются во время тренировки.

Непрерывность — очень увлекательный с технической точки зрения этап. Запустить шлюз выхода в Интернет или базу данных может и не очень опытный специалист — достаточно хорошей инструкции. Но чтобы обеспечить непрерывную работу этих сервисов при отказе оборудования, требуются широкий кругозор и куда более серьезная теоретическая подготовка. Поэтому нам снова требуется задействовать огромный творческий потенциал сотрудников. Лучше всего прибегнуть к открытым вопросам, например: что в вашем сервисе может сломаться? что сделать, чтобы в случае такой поломки сервис не останавливался? что сделать, чтобы в инсталляциях сервиса начала работать непрерывность? какие испытания надо проводить? какие параметры отслеживать? какие испытания считать успешными?

Не забываем вернуться к уже пройденным этапам! Например, на этапе «Мониторинг» проверяем, что мы постоянно отслеживаем готовность резервных систем и готовы подхватить нагрузку в случае отказа. На этапе «Унификация» проверяем, что мы обеспечиваем одинаковую реализацию непрерывности по всем инсталляциям сервиса. Работы по данному этапу заканчиваются, когда во всех инсталляциях сервиса обеспечен оговоренный уровень непрерывности, регулярно проверяемый испытаниями.

Этап № 6. Документация. Мы сознательно не занимались документированием раньше, поскольку из-за большого объема изменений документация быстро утратила бы актуальность, что снизило бы ценность работы и демотивировало специалиста. Сейчас, когда наши сервисы стабилизированы, можно заняться написанием более качественной и долгоживущей документации.

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

Этап № 7. Одинаковость. На этапе «Унификация» мы приводили сервисы к единому виду на уровне компонент — конфигурационных единиц в составе сервиса. Сейчас мы погружаемся в детали и приводим к единому виду подробные настройки компонент сервиса. Такими настройками могут быть параметры интерфейсов сетевого оборудования, файлы настроек системы и прикладного ПО, а также прочие параметры конфигурационной единицы, обычно не отражаемые в CMDB. Конечная цель — сделать настройки одинаковыми настолько, насколько это возможно.

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

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

Этап № 8. Планирование. Чтобы обеспечить устойчивую работу сервиса, необходимо понимать, какие нагрузки наш сервис обслуживает и как они будут меняться с течением времени. Нагрузка на многие сервисы зависит от количества компьютеров в офисе, и планирование такой нагрузки сводится к определению численности оснащенных компьютерами сотрудников. Соответствующую информацию можно получить у основных бизнес-подразделений компании. Горизонт планирования в первую очередь определяется масштабируемостью сервиса и сроками поставки оборудования для наращивания мощности. Для большинства случаев будет достаточно трех — шести месяцев.

Этапы № 9, 10, 11 («Анализ», «Обратная связь», «Постоянное улучшение») посвящены непрерывному оттачиванию работы сервиса путем реализации планов улучшения. Эти планы предлагается составлять на базе опросов пользователей и анализа поступающих заявок о работе сервиса. Постоянное улучшение — непрерывный процесс, и вряд ли эти три этапа улучшения можно выполнить единовременно и больше к ним не возвращаться.

Дело не только в технике

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

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

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

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

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