Управление конфигурацией — что это, как вести учёт и зачем нужна CMDB

Зачем управление конфигурациями

Управление конфигурацией — это практика, которая собирает и держит в порядке сведения о том, из чего состоит каждая ИТ-услуга и как её части связаны между собой. Части эти называются элементами конфигурации: сервер, программа, сегмент сети, договор с поставщиком, сама услуга — всё, чем нужно управлять, чтобы услуга работала 1. Записи об элементах и связях между ними лежат в базе данных управления конфигурациямиБаза данных управления конфигурациями (CMDB)База, где записано, из чего состоят ИТ-услуги и как связаны их части — и что остановится, если тронуть одну.ITIL 4: практическое руководство Service Configuration Management и книга ITIL Foundation; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.1, 3.2.2 и 8.2.6; FitSM-0, FitSM-1 (PR11) и FitSM-2; MOF 4.0, SMF «Изменение и конфигурация»; COBIT 5, процесс BAI10; DAMA-DMBOK, глава 12; Брукс, «Метрики для управления ИТ-услугами»; itSMF, «Введение в ИТ Сервис-менеджмент», 2003 — CMDB, в разговоре просто базе конфигураций. Что это такое и как устроено, разобрано на странице термина в глоссарии.

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

Имён у практики несколько. В ITIL 4 она называется service configuration management — управление конфигурацией услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation 1. ГОСТ Р ИСО/МЭК 20000-1-2021 называет её менеджментом конфигураций (пункт 8.2.6) 3. FitSM, лёгкий стандарт управления ИТ-услугами 4, и COBIT, свод по руководству ИТ 5, пишут «управление конфигурациями». MOF 4.0 описывает её вместе с изменениями, в одной функции «Изменение и конфигурация» 2. В справочнике мы пишем «управление конфигурациями», во множественном числе, как в русском издании COBIT 5 5. В поиске чаще набирают «управление конфигурацией», в единственном, — это та же практика. Есть и однофамилец — управление конфигурацией в разработке изделий и программ; о нём в разделе «Что с чем путают».

ITIL 4 формулирует цель так: точные и надёжные сведения о составе услуг и об элементах, на которых услуги держатся, доступны в нужном месте и в нужное время, вместе со сведениями о связях 1. ГОСТ Р ИСО/МЭК 20000-1-2021 цель не формулирует, а сразу требует: типы элементов определены, услуги тоже считаются элементами, а по каждому элементу известны идентификатор, тип, описание, связи и состояние 3.

ЦенностьЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation практики целиком в чужой работе. Сведения о составе нужны, чтобы оценить влияние изменения, найти причину сбоя, взвесить риск, распределить затраты между услугами и подразделениями, спланировать доступность — чтобы услуга не встала из-за одной детали 1. Книга ITIL 4 Foundation так и пишет: ценность управления конфигурацией косвенная — благодаря ей другие практики работают быстрее и точнее 10. В отчётах этой ценности не видно, поэтому при экономии работу по учёту легко сократить: потери проявятся позже и у соседей.

Практика меряется не полнотой базы, а числом решений, которые по ней приняли и о которых потом не пожалели.

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

Когда практика работает

Учёт бывает живым, а бывает бумажным: записи есть, но описывают прошлое. Отличить помогают три признака, и все три видны в системе, а не в положении об учёте.

По услуге видно, из чего она состоит. Как проверить: за пять минут можно назвать серверы, программы и договоры, от которых зависит конкретная услуга, — по записям, а не по памяти дежурного инженера.

Сведения совпадают с действительностью. Как проверить: последняя сверка записей с тем, что стоит и работает на самом деле, завершена, её результаты записаны, а расхождения разобраны или поставлены в работу. ГОСТ Р ИСО/МЭК 20000-1 требует через запланированные промежутки времени проверять, верны ли сведения, и разбираться с найденными расхождениями 3.

Записи обновляются от изменений, а не от разовой инвентаризации — обхода всего хозяйства раз в год. Как проверить: после изменения, которое затронуло состав или связи услуги, сведения обновили — этого требует стандарт 3; иначе учёт начинает отставать с первого же неучтённого изменения.

Что входит и что рядом

Конфигурации и активы: где проходит граница

Две практики смотрят на одни и те же серверы, программы и лицензии разными глазами, и это не дублирование.

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

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

ГОСТ Р ИСО/МЭК 20000-1 держит их в соседних пунктах, 8.2.5 и 8.2.6, и отдельно оговаривает случай, когда один и тот же актив попадает в оба учёта 3. Практический признак смешения: в базе завели монитор и мышь, потому что они стоят денег, — учёт активов заполз в учёт конфигураций и утопил его в мелочах.

Что на входе и что на выходе

Главное в этой картине — направление. Практика питается изменениями: каждое проведённое изменение обязано оставлять след в сведениях о составе 3. Организация, где записи обновляют раз в квартал руками, работает с картой прошлого квартала.

И на выходе то же: практика ничего не производит для себя. Всё, что она собрала, ценно ровно настолько, насколько этим пользуются соседи — при разборе инцидентаИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами, оценке изменения, расчёте доступности.

Из чего состоит учёт

Элемент конфигурацииЭлемент конфигурацииЛюбой объект, которым надо управлять, чтобы предоставлять услугу: сервер, приложение, лицензия, документ.ITIL — любой компонент, которым нужно управлять ради предоставления услуги 1. Под учёт обычно попадают: техника и устройства; программы и системы вместе с лицензиями и исходным кодом; виртуальная инфраструктура; базы и данные; услуги и договоры поставщиков; подразделения, места, люди и роли; описанные процессы 1.

Модель элемента — правила для целого типа: кто владелец, как называем и маркируем, какие атрибуты и связи ведём, какие стадии жизни проходит элемент, как проверяем и кто за это отвечает 1. Модель пишется один раз на тип и избавляет от спора по каждому новому серверу или программе.

Базовая конфигурация — состояние, которое формально проверено и согласовано и служит опорой для дальнейшей работы 1. У MOF 4.0 похожее понятие называется базовыми показателями конфигурации: это снимок среды с её структурой и зависимостями, который сохраняют перед изменением, чтобы было куда вернуться 2.

База и система. Сведения хранятся в базе конфигураций — CMDB, а система управления конфигурациями (CMS) — это база вместе со средствами сбора, связывания и показа 1. MOF 4.0 добавляет отрезвляющее: такой системой может быть и электронная таблица, и сложный набор средств 2. Расшифровка CMDB, её отличие от CMS и пример записи об элементе — на странице термина CMDB в глоссарии; здесь не повторяем.

Как начать, если описать всё сразу невозможно

MOF 4.0 признаёт прямо: описать конфигурацию всей рабочей среды — задача сложная, — и предлагает выход: снимать базовые показатели конфигурации при каждом изменении — со временем полная картина соберётся сама 2.

Логика простая. Сплошная инвентаризация даёт снимок, который начинает устаревать в день окончания. Учёт, растущий от изменений, описывает ровно то, что живёт и меняется, и обновляется тем же действием, которым меняется среда.

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

Как это работает

ITIL 4 выделяет три процесса 1.

Цвет шага: приём, учёт, работа с обращением техническая работа проверка, разбор, улучшение работа с людьми и сторонами

На схеме шаги 1 и 2 — первый процесс, 3 и 4 — второй, 5 и 6 — третий; стрелка «нет» возвращает работу к учёту.

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

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

Третий разберём отдельно: именно в нём выясняется, совпадает ли база с действительностью.

Как начать управление конфигурацией

Порядок внедрения у каждого свода свой. Самый короткий по числу шагов — у FitSM: стандарт задуман лёгким, с минимумом требований, и подготовка у него укладывается в пять действий. Но первое, что нужно решить, — три вопроса 8. Какие части ваших услуг считать элементами конфигурации, а какие нет? Какие сведения вести по каждому элементу? Как обеспечить, чтобы сведения в базе были верными и свежими — точными и обновлёнными после изменений? Ответы на них и есть замысел учёта; его продумывают до выбора программы, а не после.

Затем FitSM-2 — часть стандарта с описанием действий по каждому процессу — перечисляет пять подготовительных шагов 8:

• определить область учёта и саму базу конфигураций;
• договориться, насколько подробно вести сведения;
• описать типы элементов с их атрибутами — например владельцем, версией, местом — и типы связей между ними;
• найти источники сведений о конфигурации, которые в организации уже есть;
• решить, как эти источники объединить, чем дополнить и какими средствами это делать.

После подготовки начинаются две постоянные работы: вести записи — заводить новые и обновлять существующие — и проверять их: планировать сверку и проводить её 8.

Два совета из других сводов удерживают учёт от разрастания. MOF 4.0: начните с минимально возможного набора данных и добавляйте новые только тогда, когда у них есть цель, — на обновление данных уходит время людей 2. ITIL 4 предлагает пять вопросов перед тем, как добавить в базу ещё что-то 1. Нет ли этих сведений в другом источнике? Нужны ли они для решений или без них можно обойтись? Сколько стоит их собрать и поддерживать? Как часто они нужны? Как быстро? Иногда, добавляет руководство, дешевле получать сведения по запросу, чем держать их наготове постоянно 1.

Сверка базы с действительностью

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

Инвентаризация — сбор сведений о том, что есть на самом деле. База говорит, что должно быть; инвентаризация показывает, что найдено 1.

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

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

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

Что с чем путают

Конфигурации и активы. Это разобрано выше, под катом «Конфигурации и активы: где проходит граница».

База конфигураций и мониторинг. Система мониторинга знает, что сейчас работает; база — что должно работать и как эти элементы связаны. Расхождение между ними — одно из тех, что ищет верификация.

Полнота и подробность. Полнота отвечает на вопрос «обо всех ли элементах этого типа есть записи», подробность — «сколько атрибутов заполняем по каждому элементу». ГОСТ Р ИСО/МЭК 20000-1 требует выбирать подробность в зависимости от критичности и типа услуги 3, а не от возможностей системы.

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

Управление конфигурацией услуг и управление конфигурацией изделия. Слово одно, предметы разные. В системной инженерии и разработке программ управление конфигурацией — это учёт состава, версий и изменений того, что проект производит, — документов, кода, самих изделий, — чтобы результат оставался целым и согласованным. ГОСТ Р ИСО/МЭК 15288-2005 описывает такой процесс через стратегию, перечень элементов, базовую линию и контроль их изменений 9. Там элемент — версия чертежа или файла, здесь — работающая часть услуги; там базовая линия — утверждённое состояние результата, точка отсчёта для изменений, здесь базовая конфигурация — согласованное состояние работающей услуги. Если вы искали хранилище версий кода или управление составом изделия — это не та страница.

Кто участвует

Ключевая пара — ответственный за практику и владельцы типов элементов 1. Практика, у которой есть менеджер и нет владельцев типов, держится на одном человеке и рассыпается вместе с его отпуском.

Что должно быть в записи элемента

Обязательный минимум задан стандартом 3:

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

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

Чем автоматизируется

Без автоматизации практика не живёт. ITIL 4 прямо называет её сильно автоматизированной: она держится на сборе и связывании больших объёмов данных 1.

Отдельно: часть сведений автоматизировать трудно или невозможно — данные о людях, оргструктуре, договорах с поставщиками 1. Их ведут руками, и это надо закладывать в стоимость практики заранее.

Как измерять

Показатели строятся вокруг двух факторов успехаФактор успеха практикиТо, что должно быть верно, чтобы практика выполняла своё назначение.ITIL Service Operation, раздел 4.2.8: сведения полезны и стоимость их получения не выходит из берегов 1. Отсюда правило чтения: показатель полноты базы сам по себе не значит ничего, пока рядом не стоит число решений, которые эта база помогла принять.

Брукс измеряет не саму базу, а последствия ошибок в ней — и этим подтверждает правило: считать надо решения, а не записи. Питер Брукс в справочнике itSMF «Метрики для управления ИТ-услугами» задаёт каждому показателю два порога: целевое значение и опасное, с которого надо разбираться 7. Показателя полноты среди его восьми нет. Запросы на изменение, сорванные из-за неверных данных, — цель 10, опасное значение 20. Инциденты из-за неправильно описанного элемента — цель 0, опасное 6. Нарушения соглашений об уровне услуг (SLAСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что даёт услуга, когда доступна и как быстро её восстановят.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами») по вине ошибок в базе — тоже 0, опасное 2 7. Каждый из них считается за пределами практики — запросы в CHNКонтроль изменений, инциденты в INCУправление инцидентами, нарушения SLA в SLMУправление уровнем услуг, — и именно поэтому их редко выводят на панель показателей практики.

Одно число стоит увидеть целиком. Доля некорректных элементов конфигурации — единственный у Брукса показатель качества самой базы: цель 40%, опасное значение 80% 7. Цель у него — не мечта, а допустимый уровень: две неверные записи из пяти терпимы, четыре из пяти — тревога. Эти пороги кажутся странными ровно до того момента, пока в организации не проведут первую честную сверку. Переносить их к себе не надо; стоит перенять другое — саму мысль, что у точности учёта есть достижимый уровень, и он ниже ста процентов.

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

Один показатель Брукса стоит особняком — число неиспользуемых лицензий: цель 50, опасное значение 80 7. Это единственное здесь число, которое показывает не убытки от плохого учёта, а деньги, которые хороший учёт возвращает, — если лишние лицензии не продлевать.

Зрелость управления конфигурациями

✕

Где ломается чаще всего

Шесть мест, где учёт ломается.

Учёт завели ради учёта. Никто не спросил, кому и для чего нужны сведения. База наполняется тем, что легко собрать, и не отвечает на вопросы разбора инцидентов и оценки изменений 1.

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

Связи не заводят. Элементы есть, связей между ними нет. Оценка влияния по такой базе невозможна, а именно ради неё практику и начинали.

Обновление отвязано от изменений. Записи правят по расписанию, а не по факту работ. Стандарт требует обратного: сведения актуализируются после внедрения изменений 3.

Сверку не проводят. Расхождения копятся молча, доверие к базе падает, и люди возвращаются к вопросу «а спросим-ка того, кто это настраивал». ГОСТ Р ИСО/МЭК 20000-1 требует проверять точность в заранее назначенные сроки 3.

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

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL 4 описывает практику подробнее всех: модели элементов, базовые конфигурации, три процесса, разбор инвентаризации, верификации и аудита, а границу учёта проводит по тому, окупается ли ведение записи 1.

ГОСТ Р ИСО/МЭК 20000-1 требует минимума, но требует жёстко: определённые типы элементов, услуги в числе элементов, пять обязательных сведений по каждому, прослеживаемость изменений, обновление после внедрения и периодическая верификация 3.

FitSM укладывается в пять требований: область учёта, достаточная подробность, база с элементами и связями, контроль изменений элементов, проверка через интервалы 4.

MOF 4.0 связывает конфигурации с изменениями в одну функцию и даёт практический вход через снимки перед изменениями 2.

COBIT держит управление конфигурациями отдельной целью рядом с изменениями и активами 5.

Расхождений по существу здесь нет — своды спорят только о глубине. Что действительно стоит знать: ни один из них не требует описать всё. ГОСТ Р ИСО/МЭК 20000-1 говорит о подробности по критичности 3, а практическое руководство ITIL 4 — о том, чтобы польза от сведений окупала их ведение 1.

Где описано

Что почитать дальше

Три соседние практики, ради которых этот учёт и ведётся: CHNКонтроль изменений — оценка последствий изменения, INCУправление инцидентами — поиск того, что сломалось, IAMУправление ИТ-активами — соседний учёт, про деньги и владение.