Управление конфигурациями - 4

Записаться

Контроль КБД и управление изменениями

Контроль — это деятельность, при которой сначала должен появиться первичный документ, и только затем можно изменять что-либо в конфигурационной базе данных (КБД; Configuration Management Database, CMDB).

Изменять характеристики конфигурационной единицы (Configuration Item, CI) можно только через изменения, авторизованные процессом управления изменениями. Нельзя просто взять и поменять конфигурационную единицу.

Процесс управления изменениями должен:

• оценить, опасное изменение или нет;
• определить, что ещё нужно поменять вслед за этим;
• указать, какие документы подготовить;
• определить, чьи подписи получить и с кем согласовать.

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

Требования к процессу управления изменениями

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

Когда мы ссылаемся на другой процесс как на заведомо правильный, мы предполагаем, что он:

• укоренённый;
• стабильный;
• понятный;
• одинаково понимаемый всеми;
• формально точно определённый.

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

Если процесс хаотический, в одном случае исполняется так, в другом — иначе, по непонятным причинам, то его наличие почти ничего не меняет. Поэтому неявно присутствует допущение, что корпоративный процесс управления изменениями нормальный, стабильный и зрелый.

Зрелость процесса

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

Когда создавались основные процессы в референтных моделях, теории зрелости ещё не было. Поэтому про это явно ничего не написано. Сейчас это уже известная область знаний.

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

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

Контроль за КБД

В рамках контроля за КБД нужно выполнять некоторые работы:

• отслеживать с момента добавления новых конфигурационных единиц все изменения статусов;
• отслеживать изменения владельцев;
• отслеживать изменения взаимоотношений;
• хранить всю информацию, которая есть в КБД.

Какими средствами это делать? Ясно, что организационными: с помощью специальных документов, процессов, согласования, авторизации и прочего. Но в источнике про это ничего не сказано. Это отдельная история — как в организации должно быть устроено управление конфигурациями.

Аудит и инвентаризация

Про верификацию, аудит и инвентаризацию сказаны самые общие слова. Когда возможен аудит после внедрения новой КБД?

• Спустя полгода с момента внедрения, когда уже много чего произошло, добавилось и изменилось.
• Перед серьёзными изменениями и после них, чтобы можно было откатиться к более-менее корректной версии КБД.
• После чрезвычайных обстоятельств, потому что предсказать их последствия невозможно.
• В любое другое удобное время. Это значит, что аудит можно проводить хоть каждый день, хуже не будет, но будет дороже.

Нужно искать баланс между затратами и полезностью аудита.

Что именно рассматривается в ходе аудита? Тоже только примеры, достаточно очевидные вещи. Например, регистрируются ли в КБД данные всех запросов на изменение на всех этапах их реализации. Ничего выходящего за рамки здравого смысла здесь нет.

Показатели эффективности и качество процесса

Опять встречаются ключевые показатели эффективности (Key Performance Indicators, KPI). Здесь их меньше, и это тоже только примеры. Как и в случае управления инцидентами, сначала нужно понять, для чего нужны те или иные метрики. Что мы собираемся проверить? Какие решения собираемся принять? Когда это станет понятно, можно говорить о том, какие метрики нужны.

Если написанных метрик достаточно для практических задач — хорошо. Если недостаточно — надо придумывать своё.

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

Как эти требования выражаются и в чём состоят — отдельная задача. Это станет понятно, когда мы точно определим, что есть в КБД и что нужно каждому из процессов. Как часто ему это нужно, каковы его требования к информации — тогда можно будет сказать, что именно в процессе можно улучшить и как повысить его качество.

Когда мы говорим о качестве процесса, мы говорим только о работах, производимых людьми неформально, а не сервером базы данных и не техническими средствами. Отсюда возникают требования не только к процессу управления конфигурациями, но и к отдельным работам: верификации, контролю, планированию и другим.

Роли и функции

Первым номером идёт руководитель процесса, то есть его владелец. Обычно владелец процесса делает следующее:

• определяет сферу действия;
• определяет уровень детализации процесса;
• доводит информацию о процессе до всех заинтересованных лиц;
• обеспечивает процесс персоналом;
• разрабатывает систему идентификации, иначе говоря, модель данных;
• разрабатывает интерфейсы с другими процессами, отчёты, запросы к КБД;
• оценивает существующие системы и внедряет новые системы автоматизации;
• планирует и внедряет систему наполнения КБД информацией;
• организует аудиторские проверки;
• формирует отчёты.

Планирование и внедрение системы наполнения КБД — сложная вещь. Она включает функции контроля, согласования и подготовки необходимых документов. Организация аудиторских проверок и формирование отчётов — это фактически подпроцессы основного процесса.

Затраты и проблемы

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

Некоторые затраты можно примерно оценить. Например, поддержка и сопровождение базы данных — более-менее понятная работа. Затраты на другие работы, такие как аудиторские проверки, заранее оценить сложно. Может быть, когда пройдёт несколько проверок, наберётся статистика.

Конкретики в источнике нет.

Краткие итоги

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

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

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

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

Роли и затраты показывают, что управление конфигурациями требует организационной зрелости. Владелец процесса отвечает за модель данных, интерфейсы, отчётность, автоматизацию и наполнение КБД. Автоматизация ускоряет и упрощает работу, но увеличивает расходы. Часть затрат поддаётся оценке, часть — только по накопленной статистике. Практический вывод: устойчивое управление конфигурациями возможно лишь при сочетании формальных правил, зрелых процессов, реалистичных метрик и осознанного баланса между затратами и полезностью.