Как внедрить процессы управления конфигурацией

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

^[1]Изображение Kenny Louie ^[2] CC ^[3]

С чего начать

Прежде чем начинать внедрение, необходимо объяснить смысл CMS-системы всем участникам экосистемы: членам команды, клиентам и др. Это важно, поскольку в дальнейшем каждая сторона будет принимать ^[4] участие в управлении конфигурацией — члены команды CMS должны предоставлять точную информацию своим коллегам, ответственным за инциденты и изменения, а действия, производимые IT-специалистами должны отображаться в базе данных управления конфигурацией (CMDB).

Для организации CM был разработан эффективный метод. В целом внедрение CMS можно разделить на четыре части: планирование и определение, контроль, учет состояния, аудит.

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

Составление плана

Мы рекомендуем ^[5] начать планирование управления конфигурацией с наиболее критичных бизнес-процессов — обработки инцидентов и проблем. Служба технической поддержки всегда загружена заявками от пользователей, поэтому важно обеспечить их своевременное исполнение. Реализация проекта с этого класса услуг позволит оптимизировать работу технической поддержки, что непременно скажется на эффективности других отделов компании.

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

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

Активы, на диаграмме выше, — это персональная техника и другие устройства, находящиеся на финансовом контроле и требующие управления. А материально-технические ресурсы представляют собой периферию (клавиатуры, мыши, флешки и др.).

При планировании важно учитывать такие мелкие детали, как, скажем, описание способа формирования имен конфигурационных единиц. Имя для каждой CMDB должно быть уникально и содержать ключевую информацию для идентификации. Например, обозначение MSserver-Moscow-Level3 говорит оператору сервисного центра, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме и назначить тикет ответственной группе специалистов.

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

Определение исходного состояния

Этап определения исходного состояния — это следующий шаг после планирования, который нужен, чтобы понять из каких элементов состоит инфраструктура компании в настоящий момент. Такой снимок в будущем может быть использован для сравнения ^[6] состояний, например, «в этом году объем имущества увеличился на 20%, что привело к появлению 2 тыс. новых изменений».

Как только исходное состояние определено, следует убедиться, что ему соответствуют соглашения об уровне услуг (SLAs), операционные соглашения (OLAs), внешние договоры (UCs), связанные с IT-инфраструктурой и сервисами организации.

Определение исходного состояния стоит начинать с какого-либо одного сервиса, расписав все его компоненты. При этом полученная информация должна заноситься в базу данных ITSM-платформы, например ServiceNow, или простую базу данных CMDB — это может быть таблица в Excel или Access.

Что касается платформы ServiceNow, то она предоставляет удобные инструменты для создания и ведения системы управления конфигурацией. Пользователю доступны двести типов конфигурационных единиц, таких как компьютеры, ноутбуки, серверы, оргтехника, программное обеспечение, интернет-ресурсы и др. Импортом в базу данных CMDB занимается приложение ServiceNow Discovery, которое автоматически сканирует сеть и добавляет найденные единицы.

Также отметим, что важно определить ^[7] ответственное лицо за внесение информации в базы данных.

Контроль

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

• Тесно сотрудничать с работниками, осуществляющими контроль изменений, дабы работа управления конфигурациями следовала корпоративным политикам об изменениях. Без контроля изменений CMS/CMDB быстро устареет.
• Конфигурационные единицы, участвующие в процессе оказания услуги, должны быть с ней связаны. Это даст пользователю возможность быстро выбрать требуемый сервис. В этом случае все CI добавятся автоматически.
• ИТ-специалисты, отвечающие за систему управления конфигурацией, должны участвовать в консультативных советах по изменениям (CAB), чтобы отображать в CMS и CMDB производимые с инфраструктурой изменения. При этом все вносимые изменения должны проверяться, перед закрытием тикета как успешного.

Учет состояния

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

Аудит

Заключительный этап внедрения CMS называется проверка и аудит. Его задача — гарантировать достоверность данных, представленных в CMDB: все рабочие CI должны соответствовать тому, что указано в CMS/CMDB, а документация поддержки должна точно описывать все CI. Чтобы удовлетворить эти требования, важно составить и утвердить план проверок, содержащий ответы на следующие вопросы:

• Имеются ли специальные инструменты для проведения проверок?
• Требуется ли физическая проверка?
• Каковы нормативные требования?
• Есть ли сертификация по стандарту ISO 20000 ^[8] и должны ли выполняться IL3, BASEL 3 или NGN224, требующие вмешательства третьей стороны?

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

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

P.S. Другие материалы из нашего блога «ИТ-Гильдия»:

• Интервью с техническим директором ServiceNow об инновациях, приоритетах и развитии ИТ ^[9]
• Как сделать ITIL более клиентоориентированной ^[10]
• Financial Management — бюджетирование и оценка затрат на предоставляемые услуги в ServiceNow ^[11]
• 4 мифа об управлении услугами, в которые вы не должны верить ^[12]
• Лучшие бесплатные ресурсы для специалиста ServiceNow ^[13]

P.P.S. И пара материалов из нашего блога на Хабре:

• Немного о ServiceNow, ITSM и ServiceDesk в формате подборки полезных материалов ^[14]
• «Управление в ИТ»: что такое ITSM и платформа ServiceNow ^[15]

Автор: it-guild

Источник ^[16]