Интересным продолжением заметки Артёма Мукосеева от 03.12.2015 «CI or not CI» или размышления о картриджах» может служить пост «CMDB – Should I or Shouldn’t I?», опубликованный Ryan Ogilvie 09.12.2015.
Все тезисы логичны, перекликаются с тем, что написано в библиотеке ITIL, поэтому приведены ниже, – возможно, окажутся полезными для формирования подходов к построению процесса управления сервисными активами и конфигурациями (Service Assets and Configuration Management) .
- Определить решаемую задачу. Решение должно идти не от возможностей инструментария, с помощью которого собирает информация о конфигурационных единицах, а от задачи (например, определение архитектуры наиболее критичных сервисов, синхронизация управленческого учёта с финансовым и пр.).
- Желательно максимально упростить как структуру CMDB, так и сам процесс. Попытка охватить сразу всё существенно увеличивает риски неудачи, поскольку, во-первых, в более сложной структуре описания выше вероятность ошибиться и не учесть какие-то взаимосвязи. А, самое главное, более сложный процесс имеет меньше шансов «взлететь» (в т.ч. по причине более сильного противодействия со стороны исполнителей). И, наоборот, максимально упрощенная первая итерация, позволит получить более быструю победу, что, кроме всего прочего, мотивирует на дальнейшее движение.
- Определить взаимосвязи с другими уже существующими процессами по управлению сервисами.
- Определить регулярную процедуру (привет, CSI!) по аудиту накопленных данных и аудиту самого процесса (не возникает ли каких-либо затруднений с входом и выходом процесса, его взаимодействием с другими процессами (например, Change Management).
