Управління Сервісними Активами та конфігурації (Service Asset and Configuration Management), як даний процес правильно називається в ITIL® v3, - один з найважчих для розуміння і впровадження процесів ITIL®, у всякому разі, така оцінка випливає з опитувань наших слухачів.
Спробуємо зрозуміти ці труднощі, розібравши деякі ризики, які супроводжують практикам даного процесу.
Для початку (як завжди) розберемося з основними поняттями даного процесу. В процесі Управління Сервісними Активами та конфігурації з'явилися нові поняття, яких не було в ITIL® другої версії. Коротко заглибимося в основні поняття, використовуючи визначення з Глосарію.
- Система управління конфігураціями (Configuration Management System, CMS) - набір інструментів і баз даних, які використовуються для управління даними про установки постачальника ІТ послуг.
- CMS також містить інформацію про інциденти, проблеми, відомих помилках, зміни і релізах. Може містити дані про співробітників, постачальників, місцях розташування, бізнес-одиницях, замовників і користувачів
- CMS включає в себе інструменти для збору, зберігання, управління, оновлення та подання інформації про всіх CI та їхні взаємини
- База даних управління конфігураціями (Configuration Management Database, CMDB) - база даних, яка використовується для зберігання записів про зміни на всьому протязі їх життєвого циклу. Система управління конфігураціями (Configuration Management System, CMS) управляє однією і більш CMDB і кожна CMDB містить атрибути CI і їх зв'язку іншими CI.
- Запис про CI (сonfiguration Record) - запис, що містить детальну інформацію про CI. Кожен запис документує життєвий цикл єдиною CI. Запис про конфігурацію зберігаються в CMDB.
- Конфігураційна одиниця (configuration item, CI) - актив, компонент сервісу або інший елемент, який знаходиться або буде знаходитися під контролем процесу управління конфігураціями. Можуть бути:
- CI життєвого циклу сервісу
- Сервісні CI
- організаційні CI
- внутрішні CI
- зовнішні CI
- інтерфейсні CI
Проілюструємо ці положення невеликою схемою, взятої з книги Service Transition:
Зі схеми і визначень ми бачимо, що:
CMS - більш широке поняття, ніж CMDB і може містити в собі об'єкти, які не є CI.
Мова вже йде не тільки про базу даних, але про цілу систему взаємопов'язаних між собою баз даних, інструментарію, сайтів і інтерфейсів, що мають різні рівні зберігання, уявлення і відображення.
Перелік того, що може бути CI, значно розширено і в нього можуть входити як фізичні, так і логичеких CI, як IT, так і бізнес об'єкти.
Звичайно ж, далеко не всі компанії мають таку грандіозну систему управління конфігураціями навіть в мріях, але бачення ITIL® вражає. Отже, які ж труднощі і ризики очікують людей, які вирішили втілити в життя цей процес, які помилки вони найчастіше здійснюють? Розберемо деякі з них:
Невірно або нечітко визначені цілі і завдання процесу
З самого початку, ще на етапі планування, потрібно чітко розставити акценти, оскільки сам процес, структура CMS і організація взаємодії з іншими процесами або підрозділами драматично залежать від того, які завдання повинні бути вирішені. Можливі варіанти:
Встановлення контролю над основними елементами ІТ інфраструктури, визначення зв'язків як між частинами ІТ інфраструктури, так і між ними та основними бізнес сервісами для проведення критичних для бізнесу змін
Облік цінних активів, контроль збереження, підтримка вимог з безпеки, інтеграція з системами моніторингу
Оперативна і точна інвентаризація ІТ активів за запитами бухгалтерії
Ліцензійний контроль ПО
Але уявімо собі, що ми розібралися з необхідними завданнями. Тоді нас чекає перший підводний камінь:
Підхід: «збираємо всі дані, які можливо», що веде до перевантаження процесу, а також до неможливості його підтримувати
Типова помилка на початку будівництва даного процесу: все зачаровані можливістю зібрати в CMDB максимально можливу кількість інформації. Як наслідок, жахливо напружуються всі сили, проводиться тотальна інвентаризація, в базу забивається все аж до останньої дохлої миші і - ось воно, щастя! Але немає, щастя, як завжди, немає, тому що мало все зібрати один раз, треба все це багатство підтримувати в актуальному стані, відображаючи в CMDB всі зміни, реально відбуваються з численними CI. Оскільки про це заздалегідь ніхто не подумав і сил на підтримку не запасати, настає швидка деактуалізація частини (а якщо не пощастить, то і більшої частини) даних в CMDB і як наслідок - жахливе розчарування і зневіра в могутність ITIL®. А ось і другий підводний камінь, тісно пов'язаний з першим:
Втрата актуальності конфігураційної інформації з часом, що викликає помилки, а також труднощі і надлишкові витрати при виправленні
Управління конфігураціями - особливий процес, метафорично нагадує виховання маленької дитини: мало його народити, треба про нього постійно піклуватися і це вже назавжди. Трохи не вдавитися великим шматком на старті, треба ще підтримувати всі актуальним в ході процесу. На практиці зустрічаються ситуації, коли з тих чи інших причин відбувається втрата актуальності даних в CMDB, тому важливо визначити факт настання такого стану і продумати раціональні заходи по його виправленню. Найдієвішою мірою виявлення є аудит, тобто звірка даних CMDB і реальних CI. На жаль, проведення аудиту є дорогим задоволенням, вимагає залучення додаткових ресурсів і, як мінімум, правильного визначення охоплення аудиту. На практиці найчастіше проводиться вибірковий аудит.
Підтримка даних в CMDB в актуальному стані настільки ж важлива, як і інформативність самої бази. Вимоги до даних в CMDB:
Вони повинні бути актуальними (чітко відображати стан справ в реальній інфраструктурі на поточний момент)
Вони повинні бути достовірними (відсутність помилок в самих даних)
Вони повинні бути затребуваними (потрібними споживачам CMDB)
І тут доречно розглянути таке положення, яке також вимагає акуратного і продуманого підходу. це:
Встановлення обґрунтованого рівня точності, тобто кореляції між моделлю і реальною конфігурацією
Вирішити це завдання нелегко, тому що тут треба чітко вирішити рівняння з кількома невідомими:
Визначити рівень деталізації - наприклад, які атрибути будуть у CI, що буде тільки атрибутом, а що - гідно бути справжньою CI?
Визначити необхідні зв'язки як між CI, так і між CI і сутностями - наприклад, між CI і сервісами, між CI і інцидентами, проблемами, RFC, релізами.
Оскільки з першого разу вирішити всі правильно буде непросто, завдання вирішується в декілька ітерацій. При наступних ітераціях можуть вирішуватися такі завдання:
Додавання в CMDB даних, які були потрібні споживачам, але яких не виявилося в CMDB
Видалення з CMDB даних, які не були затребувані споживачами бази
При всіх ітераціях необхідно визначати ресурси, необхідні для підтримки даних CMDB в актуальному стані. Наявність (відсутність) таких ресурсів є критично важливим.
Таким чином, ми бачимо, що рекомендації ITIL дозволяють нам вберегтися від типових помилок, і дають нам вірні підходи для вирішення навіть такого складного завдання, як побудова правильного процесу управління сервісними активами і конфігураціями.
Детальніше ця тема обговорюється на наступних курсах:
Схожі питання порушувалися в наступних проектах:
- Організація процесу управління конфігураціями в банку BSGV
- Реалізація процесу управління конфігураціями в Керуючої компанії ВАТ «УК ГидроОГК» РАО ЄЕС Росії
- Впровадження процесу управління конфігураціями в банку ВТБ24
- Побудова та впровадження процесу управління конфігураціями в Групі СУАЛ
ITIL® і PRINCE2® - зареєстровані торгові марки компанії AXELOS Limited.
Swirl logo ™ - торгова марка компанії AXELOS Limited.