5. Учебный вопрос 5. Разработка требований к cmdb и cms

Сформулируем рекомендации ИТ-менеджерам, планирующим внедрение или оптимизацию сервис-ориентированных подходов к управлению ИТ, а также предложим упрощенную методологию, направленную на снижение затрат на всех стадиях эксплуатации CMDB и CMS.

Общий принцип методики звучит так: «Движемся от требований бизнеса к выбору системы, а не наоборот», а сама методика состоит из пяти шагов.

Шаг 1. Определение основных услуг, предоставляемых бизнесу.

• На данном шаге перечисляются ИТ-системы, наиболее критичные для бизнеса (см. пример в графе 2 таблицы 2), и

• для каждой из них формулируется ответ на вопрос: «Что будет, если система прекратит работать на некоторое время?» Интервал времени можно задать исходя из статистики подобных сбоев (если она есть) или исходя из экспертной оценки максимального срока восстановления системы от ИТ-специалистов.

• Результат заносится в графу 3 таблицы 2 в виде названия процесса или услуги в терминологии, понятной бизнесу. Затем по каждой услуге определяется наиболее полный список ИТ-систем, которые также могут привести к сбою.

• Далее заполняется графа 4 таблицы 2, куда вносится стоимость остановки предоставления соответствующей услуги на максимальный из возможных интервалов времени. Такую оценку можно получить у бизнес-пользователей соответствующей услуги, например, это могут быть штрафные санкции за задержку отчета в налоговую инспекцию.

• В результате в графе 2 формируется заготовка каталога технических услуг, а в графе 3 – заготовка каталога бизнес-услуг, предоставляемых ИТ-службой (рис. 4).

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

Шаг 2. Определение процессов, подлежащих оптимизации средствами CMS (системы управления конфигурациями).

• На данном шаге перечисляются процессы, которые планируется оптимизировать за счет применения CMS, и цели, которых надо достичь по каждому процессу (таблица 3).

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

• Если мы затрудняемся указать куратора по процессу или не можем четко сформулировать цели реализации процесса, то с большой вероятностью он не будет работать на практике.

Шаг 3. Определение требований к CMDB.

• На данном шаге определяется «охват» CMDB: классы объектов, которые будут учитываться в рамках автоматизируемых процессов, и зона учета (площадки, ЦОД, подразделения и т.д., по которым будет производиться учет) (рис. 4).

• Охват CMDB может изменяться с течением времени, поэтому рекомендуется определить этапы расширения охвата.

• На первом этапе целесообразно включать в CMDB только те КЕ, информация по которым необходима для повышения качества (скорости обработки заявок, снижения количества сбоев после изменений) по наиболее критичным услугам, перечисленным в таблице 2.

• Результаты работы сводятся в «Классификатор конфигурационных единиц» (таблица 4) при дополнении каждого класса КЕ описанием принципа присвоения ему уникального имени. Это имя впоследствии будет использоваться для идентификации КЕ в CMDB и для маркировки физического объекта, связанного с КЕ (например, идентификатор ПК, проставляемый на его корпусе). Сведения о зоне охвата и этапе реализации заносятся в графу «Примечания» таблицы 4.

• Сформируем теперь требуемый набор связей между КЕ в виде логической модели данных CMDB, пример которой приведен на рис. 5.

• Модель должна содержать все классы CMDB, перечисленные в классификаторе (таблица 1), и

• все связи между КЕ.

• При формировании связей необходимо руководствоваться принципом «Замкнутая цепочка влияния»: двигаясь по цепочке связей, всегда нужно иметь возможность получить полный перечень КЕ, на которые повлияет изменение (остановка) текущего КЕ. В результате работы над логической моделью данных может быть изменен состав классов КЕ в таблице 4. Связи между КЕ могут иметь различные типы (например: «Содержит в составе», «Материально ответственный» и т.д.). Связи могут отражать влияние одной КЕ на работу другой КЕ, в этом случае их можно будет учитывать при анализе последствий изменений.

• Перечень полученных связей сводится в классификатор.

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

• Для каждого атрибута определим источник (источники) актуальных данных (например, LANDesk Inventory manager – для ПК и серверов, Cisco Works – для сетевого оборудования, MS Active Directory + Кадры – для пользователей и т.д.). Не следует дублировать всю информацию внешнего источника в CMDB. Набор атрибутов должен быть минимально необходимым для обеспечения оперативной обработки инцидентов и анализа изменений. Кроме того, обязательно должны быть атрибуты, однозначно идентифицирующие каждый КЕ во всех внешних источниках информации по нему и атрибуты-связи в соответствии с рис. 5.

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

• Следует учитывать, что чем больше атрибутов, поддерживаемых вручную, тем выше трудоемкость (и стоимость) эксплуатации системы, тем ниже актуальность данных в CMDB и тем меньше эффект от реализации CMS.

• В случае если нельзя определиться с источником данных по какому-либо атрибуту (или по целому классу КЕ), его следует исключить из CMDB, так как неактуальная информация дискредитирует систему в глазах пользователей на стадии эксплуатации.

Шаг 4. Составление перечня требований к системе.

• На этом шаге формулируются требования к системе, посредством которой планируется автоматизировать процессы управления ИТ в форме таблицы.

• Требования целесообразно группировать по автоматизируемым процессам.

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

Шаг 5. Формулировка критериев выбора системы.

• На предыдущих шагах мы получили подробный перечень требований к СMS и описание CMDB.

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

• В качестве дополнительных критериев отбора могут быть использованы:

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

  • цена (включая лицензии, внедрение, поддержку, обновление версий, обучение),

  • надежность регионального поставщика и разработчика системы.

На российском рынке представлены как комплексные системы (Service Desk + CMDB) наподобие Axious Systems assyst, BMC Remedy, LANDesk Service Desk, Naumen Service Desk, OmniNet Omnitracker, так и специализированные решения: HP Universal CMDB (CMS c гибкими интеграционными возможностями) и LANDesk Asset Lifecycle Manager (CMDB и средства реализации методологии IBPL).

Заключение — до 5 мин.

Содержание и методические рекомендации:

- обобщить наиболее важные, существенные вопросы лекции.

- сформулировать общие выводы.

- поставить задачи для самостоятельной работы.

- ответить на вопросы студентов.

Лекция разработана «___»________2011 г.

_______________________(Ежов С.М.)

(подпись, фамилия и инициалы автора)

1 Scope.

2 Service Request.

3 Варианты используются, если имеются несколько существующих одновременно форм Конфигурационной Единицы т. е если существуют параллельные отношения.

Версии появляются, например, если одновременно используется и новая, и старая версии Конфигурационной Единицы, т. е. когда существуют последовательные отношения. Использование этих двух концептуальных понятий помогает при планировании изменении.

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

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

4 Starting point