Поводом вернуться к обсуждению процесса управления изменениями в инфраструктуре стала совокупность двух фактов. Первым стал неожиданный, но приятный, положительный отклик на запись “Место для процесса управления изменениями”. Вторым – новость от коллег о близости к завершению очередной итерации по развитию продукта CleverENGINE, где кардинальной переработке подвергся модуль управления активами и конфигурациями.
“Какая связь между обновлением модуля конфигураций в продукте и процессом управления изменениями?” – может спросить наш читатель.
Чтобы я мог ответить на этот вопрос, мне нужно поделиться опытом и собственными соображениями о ценности, вносимой этим процессом в результаты работы ИТ-подразделения.
Значимость роли изменений в деятельности ИТ-подразделения
ИТ-специалист, создающий своим трудом в производстве непосредственную ценность, может заниматься четырьмя видами работ (укрупнённо):
- Поддержка потребления ИТ-услуги (управление сервисными запросами, Request fulfillment);
- Регулярные регламентные работы (планово-предупредительное обслуживание, поддержка, не связанная с запросами);
- Устранение ошибок (Incident и Problem);
- Внесение изменений в ИТ-инфраструктуру (Change).
Силы и средства, затрачиваемые на устранение ошибок – это прямые потери ИТ-подразделения, вызванные низким качеством принятых решений разного характера. Минимизация этих потерь за счет системного повышения надежности и устойчивости ИТ-инфраструктуры почти всегда является приоритетной задачей.
Привлечение ресурсов на выполнение работ по регламентному обслуживанию точно также подлежит минимизации, но уже за счёт вклада в автоматизацию рутинных задач везде, где это технически возможно.
Для действительного потребителя услуги прямую (измеримую) пользу приносят:
- Непосредственное потребление услуги, эксплуатация продуктивной ИТ- инфраструктуры (приложений, устройств);
- Способствование наилучшему для пользователя способу/характеру потребления ИТ-услуги через выполнение сервисных запросов;
- Своевременное преобразование ИТ-услуги следующее (или предвосхищающее) за изменением действительных потребностей пользователя.
За первый пункт из этого списка отвечает пользователь (предполагая, что ИТ-ресурс был ему предоставлен). За второй отвечаем мы, поставщики, но для выполнения сервисных запросов зачастую не требуется существенная квалификация, а в ряде случаев эта работа автоматизируется в значительном объёме или полностью.
Самым важным, сложным и ответственным процессом ИТ-подразделения является процесс управления изменениями. Именно он в современном мире несёт основную ответственность сразу за два фронта: за своевременность и качество преобразований и за надежность инфраструктуры (минимизация ошибок и сбоев, связанных с изменениями). Мы все знаем и ожидаем, что в процессе изменения услуги не будут деградировать, а их пользователи страдать.
Игнорировать ли изменения в опорной ИТ-инфраструктуре?
Возможно мой опыт и наблюдения не являются самыми репрезентативными, но заметно, что даже в компаниях, тотально поглощённых драконом DevOps, периодически сохраняются функциональные подразделения, отвечающие за такие “привычные обычные вещи” (commodity) (с точки зрения разработчиков приложений), как поддержка сети (сетевые инженеры), информационная безопасность, ЦОД (инженерные сооружения, вычислительные ресурсы, виртуализация). Эти зрелые области обладают колоссальной сверхнадежностью сами по себе, но, с другой стороны, мы помним многочасовые сбои приложений (в т.ч. публичные у общемировых гигантов) из-за изменений правил маршрутизации в транспортной сети или изменений правил безопасности на отдельных узлах.
Те, кто не могут мириться с передачей этого риска на аутсорс (недавние события показали, что идея “все наши серверы на AWS: с ними ничего не случится, по крайней мере сразу и одновременно” наталкивается на то, что РосКомНадзор так не считает), вынуждены управлять этими рисками, организуя управляемый процесс изменений этих важных, но не очень интересных снаружи вещей.
Теперь, обладая пониманием, что комплексно управлять рисками требуется во всей ИТ-инфрастуктуре, а не только в области развития и доставки приложений, рассмотрим этот процесс чуть более подробно.
Изюминка процесса
Процесс управления изменениями почти всегда делится на два блока:
- изменения с гарантированно низким влиянием, стандартные изменения;
- все прочие изменения, включая “сложные” комплексные/взаимосвязанные изменения.
Запуская процесс, легко свалиться в ловушку, что внедрение и автоматизация задач из первого блока является важной быстрой победой. Это, к сожалению, не так. Точка принятия решения по реализации таких изменений или замкнута в этой же области ответственности/компетенций, или находится где-то неподалеку. При этом ощутимого влияния на услуги эти изменения не оказывают, влияние в лучшем случае сильно локализовано. Дальнейшее движение в сторону формализации стандартных изменений точно не воспринимается ответственными специалистами с энтузиазмом, т.к. процесс вводит определенную бюрократическую обёртку их рутинной (по их же ощущению) работе. Заниматься сокращением трудозатрат на рутину через формализацию и автоматизацию можно и нужно, но акцент на этой области будет ошибкой. Формализация не является назначением процесса, она лишь его побочный эффект.
Если посмотреть на сложные изменения, взаимосвязанные изменения, иногда даже их “программы”, то нам важно относиться к изменениям не с формализмом, как к заявкам поддержки, а со всем вниманием. От того, насколько мы ответственно подойдём к такому внешне не заметному этапу обработки изменения, как его оценка, будет зависеть очень многое. Именно тут мы прикладываем существенные усилия и всю доступную нам экспертизу, чтобы оценить возможность и способы реализации изменения, его пользу для заказчика, влияние изменения на наши инфраструктуру, услуги и персонал.
Мы должны научиться управлять рисками на всех этапах выполнения изменения, выявлять их на этапе оценки (и на последующих этапах), обрабатывать, планировать и реализовывать решения в ходе подготовки и проведения преобразования. Оценка изменения – это, по моему личному мнению, самый важный этап жизненного цикла изменения: реализовывать изменения получается у многих (мы же специалисты в своей предметной области), проводить их хорошо (без разрушений и в срок) – далеко не у всех.
Задача оценки изменения – это очень энергоёмкое мероприятие, т.к. для анализа, планирования, конструирования и принятия решений требуется актуальная информация, а также усилия по её обработке. Требуется анализ данных о заинтересованных сторонах и участниках, контексте выполнения изменения (расписания изменений/релизов/этапов проектов), информации о влиянии изменения на зависимую ИТ-инфраструктуру и далее на услуги и пользователей, данных об архитектурных и физических ограничениях изменяемых и зависимых компонент. Проводится оценка влияния на пользователей, профиль потребления/нагрузки. Для кого-то важна финансовая оценка или, в упрощенном варианте, оценка целесообразности: баланс выгоды/ущерба и затрат.
CMDB и ответы на вопросы
Библиотеки лучших практик рекомендуют использовать конфигурационную информацию для получения ответов на вопросы, связанные с изменением, что звучит логично. Обычно конфигурационная база содержит информацию о конфигурационных единицах, храня значимые технические параметры (идентификационные и мощностные), информацию об ответственных за эксплуатацию, владельцах. Кроме самих конфигурационных единиц там есть связи конфигурационных единиц между собой, между ИТ-инфраструктурными конфигурационными единицами и услугами. Связи несут семантику и связанный с ними набор параметров или весов.
Если смотреть на универсальные механизмы работы с этим массивом данных в форме наборов записей, списков, визуализации структуры связей, то работа с ними существенно затрудняется, когда инфраструктура становится многослойной и сложной (т.е. всегда 🙂 ). Анализу подлежит большое количество связанных объектов, навигация по которым осуществляется большей частью последовательно. Поиск информации по этому информационному массиву начинает требовать существенного времени и усилий. Отсюда возникает желание нагрузить эту машину отдельными механизмами получения данных, которые будут отвечать только на некоторые строго определенные вопросы, а не просто представлять универсальный (и от того слишком громоздкий) стандартный способ получения информации. При этом ответы на эти важные для нас вопросы мы хотим получить быстро, без ручного “майнинга” информации в CMDB.
Примерами таких запросов по изменению (затрагивающему одну или несколько конфигурационных единиц) могут быть:
- На работоспособность каких КЕ категорий “ИТ-система”, “Инфраструктурный сервис” повлияет изменение? Какие из них будут затронуты, но не должны деградировать?
- Какие услуги будут недоступны (в т.ч. когда и для каких потребителей) с учётом запланированного графика недоступности отдельных конфигурационных единиц?
- Согласование каких лиц необходимо для авторизации Go\NoGo, подтверждения плана реализации, старта работ, подтверждения результата?
Ответы на эти вопросы редко удается корректно завернуть в статичные шаблоны обработки, т.к. ответы изменяются в зависимости от набора изменяемых конфигурационных единиц.
Сразу скажу, что ответить на эти вопросы можно только с учётом некоторых условностей/договоренностей: например, строгого определения связи “влияет”, связи “входит в состав”; есть ли у связи влияния градации и какие они, как обеспечена достоверность этой информации по истечению времени, как мы учитываем эти связи в кластерах, шкафах, полках, корзинах.
Коллеги, которые занимаются поддержкой и развитием опорной ИТ-инфраструктуры (виртуализация, кластеризация, сети) всегда любят свою работу (я никогда не видел, чтобы было иначе в этой специфичной области), но некоторым из них решение коммуникационных и организационных вопросов, связанных с изменениями, без вспомогательных инструментов дается не просто в силу личного склада характера или иных факторов. Любые информационные инструменты, способствующие упрощению коммуникаций и автоматизации организационных мероприятий (на основании списков заинтересованных лиц, наборов обязательных критериев/этапов приемки и тому подобные), имеют наибольший эффект именно в этой области, препятствуя естественному желанию замкнуть общий риск в рамках профильного подразделения.
Если вы из своего опыта сможете поделиться описанием подобных инструментов-подсказчиков “над CMDB”, которые хорошо помогали вам и вашим коллегам выполнять свою работу и отвечали на предметные вопросы, то не держите это золотое знание в себе, расширьте или уточните приведенный выше список. Что по вашему мнению сегодня обязательно должно быть реализовано в ITSM системе, чтобы оценка изменения могла быть проведена с требуемым качеством?
