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

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

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

Что же происходит, когда мы начинаем использовать в своей работе системы построенные на микросервисной архитектуре, виртуальные машины и контейнеры, системы контроля версий, наиболее эффективные методологии разработки и поддержки приложений?

"Agile way" говорит нам о том, что нет никакой базовой версии – мы всегда храним рабочую версию приложения-услуги. "Код всегда работает". Этот постулат фактически говорит нам о том, что вся информация о приложении, вычислительной инфраструктуре, средах, настройках всегда хранится в системе контроля версия и изменяется "on demand".

Какова же роль процесса управления конфигурациями в таком случае? Осталось ли для него место?

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

Видится, что место и ответственность SACM остаются в следующем:

1. Вспомним, что сервисные активы – это и возможности и ресурсы: Процессы, ноу-хау, компетенции, контракты, информация об услуги (от бизнес-планов и оценок до технической архитектуры), взаимоотношения с поставщиками, документация. Информацией об этих сервисных активах (составляющих услуги) важно владеть и вполне понятно как её использовать для решения задач ИТ-организации.
2. Чаще всего какая-то часть информации о приложениях и инфраструктуре все же должна подпадать под процесс управления изменениями, а значит, мы должны обеспечить целостность, доступность и достоверность информации о ключевых управляемых объектах до и после изменения. Ответственность за это берет на себя SACM.
3. Процесс управления конфигурациями отвечает за предоставление информации для всех участников и никто не снимает с него эту задачу. Выявление и удовлетворение потребностей в информационном обмене и предоставление информации для решения производственных, финансовых или технологических задач требует усилий на создание инструментов, человеческих и финансовых ресурсов. Процесс должен решать поставленные перед ним задачи, используя все имеющиеся инструменты, в т.ч. систему контроля версий (версий всего:.серверов, настроек, документов, тестов, версий приложений, и т.д.).

С учетом того, что прямо сейчас работаю про в проекте посвященном этому процессу – тема очень интересная.  

Коллеги, если вам есть, что высказать, добавить или оспорить – welcome! 

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации