Добрый вечер, сообщники и случайные гости!
Не так давно один из наших участников в личной переписке попросил меня рассказать о том, как мы с коллегами проектировали и внедряли базу управления конфигурациями (она же CMDB) в своей организации. Не потому что наша CMDB такая хорошая и правильная (хотя, безусловно, она такая))), а просто потому что реальных пользователей iTop в рунете катастрофически мало, а тех, кто может и отвечает на вопросы, еще меньше. В общем, на его вопросы я ответил и забыл, а сегодня подумал, что этот ответ может стать хорошим материалом для поста. Так что с небольшими правками публикую свой ответ ниже.
Вместо дисклеймера: всё нижеописанное – мой личный опыт и моё личное мнение.
Почему iTop?
Когда я подбирал систему, основными требованиями были:
- Helpdesk, Service Desk, CMDB;
- бесплатно и на базе open source;
- свобода и простота доработки;
- основано на принципах ITIL/ITSM;
- активная поддержка и продолжение разработки.
Я близко смотрел OTRS ITSM, но так и не понял, как туда что-то добавить. Написано на непонятном мне perl c непонятной структурой базы данных. Мельком смотрел glpi, idoit и что-то ещё, уже не помню, но они тогда ещё не добрались до стабильного релиза.
iTop на тот момент был в версии 1.0.2, не особо функциональной, но стабильной и активно разрабатываемой. А главное – были все мануалы по доработке. Я добавил в него новые типы конфигурационных элементов, многие из которых потом появились в версии 2.0, что ещё раз убедило меня в правильности выбора.
Зачем нам понадобилась CMDB?
Я работаю в телеком компании (телефония) с маленьким штатом, но большой географией (от Калининграда до Южно-Сахалинска). В обслуживании у нас было больше 60-ти телефонных узлов в разных городах, на каждом 1-2 стойки, от 1 до 4 серверов, АТС в разных конфигурациях, маршрутизаторы, коммутаторы и электропитание для всего этого дела. Между узлами Eth через E1 на чужом транспорте.
Мой отдел (3 человека) занимался первичной настройкой, ремонтом, заменой и плановым обслуживанием железа. Всё это хозяйство свалилось на нас без сколь-нибудь внятной документации, поэтому периодически доходило до смешного. Прилетает специалист в Новосибирск, его задача заменить вышедшую из строя плату на аналогичную, которую он взял с собой из Москвы, а платы с одинаковой номенклатурой оказываются не взаимозаменяемы из-за различных производителей микросхемы памяти! В результате получаем 48 часов простоя вместо 12 обещанных. И таких неожиданных “особенностей” нашего оборудования, которые можно выяснить только на месте, было очень много.
После пары таких поездок стало понятно, что нужно как-то полученную информацию систематизировать, хранить и использовать в дальнейшем. Причем количество информации обещало быть внушительным, так что экселем было не отделаться. Кроме этого, налегала бухгалтерия, которой нужно было знать “что-откуда-куда-когда” мы переместили. Зачастую запросы бухгалтерии были связаны с перемещениями годовой давности, значит нужно хранить историю. Так мы дошли до создания базы конфигураций и активов, в ней была необходимость.
Что и как мы там храним?
Примерно в то же время меня отправили на обучение основам ITIL. Отправили случайно, по остаточному принципу (остальные отказались), и без особых перспектив применения полученных знаний на практике. После этого курса, я понял, как на самом деле может и должна работать наша служба (помимо моего, было еще два отдела: первый занимался сетью и серверами, второй – телефонией и поддержкой абонентов).
Мы решили строить CMDB, стараясь сделать её максимально полезной для всех отделов, и планировали хранить там актуальные версии программного обеспечения на серверах, дампы конфигураций АТС и сетевого оборудования, связи между сетевыми устройствами, зависимости между сервисами и много другой очень полезной информации. Но оказалось, что прежде чем эту информацию хранить, её нужно собрать. А на это нужно потратить огромное количество времени и сил. Поскольку на тот момент руководство наш энтузиазм не особо разделяло, каких-то ресурсов на создание CMDB выделено не было.
В итоге было было принято эгоистичное решение – хранить в CMDB только то, что было полезно нашему отделу, что мы ежедневно использовали в работе и что могли бы собрать сами. Так определился список того, что мы храним: расположения, стойки, все устройства и их отличительные особенности, серийники, история перемещений, схемы кабельных соединений и электропитания. Не густо, но пусть лучше наша база будет небольшой, зато достоверной и легко поддерживаемой, чем огромной, но с ошибочной информацией.
Существующая структура CMDB iTop нам примерно подходила. Пришлось добавить специфические типы КЕ (АТС и др.), немного поправить типы электропитания и разделить Расположение на Узел связи и Офис. К последнему мы относим наш офис и представительства контрагентов, куда периодически катается наше оборудование.
Всё первичное наполнение CMDB производилось через импорт из CSV. У iTop для этого есть удобнейший инструмент. Собираете всё в экселе, а потом одним махом вносите в базу! Ошиблись? Не беда! iTop добрый, он покажет, где и что сделано неверно. Этот же механизм экспорта/импорта мы использовали, когда переходили с версии 1.2 на 2.0.
Для базы мы разработали систему внутренней нумерации конфигурационных единиц. Уникальные номера КЕ мы указываем в поле Номер актива, которе сделали обязательным для заполнения. Вот так это выглядит:
10100001 - 10100999 - Стойки
10101001 - 10101999 - Крейты и шасси
10110001 - 10119999 - АТС
10120001 - 10139999 - Платы и модули АТС
10140001 - 10149999 - Серверы
… и так далее.
Поначалу мы знали о большинстве устройств только физическое месторасположение и придуманный нами же номер актива. Приезжая на узел или получая устройство по почте (например в случае ремонта), мы заполняли недостающие сведения.
Отдельно хочу сказать про связи между элементами в iTop. Это очень удобный функционал, когда вам нужно оценить влияние выхода из строя одной КЕ на другие. Но насколько он удобный, настолько же и трудно поддерживаемый. Изначально мы всё электропитание и кабельные соединения переносили в связи между элементами. Через некоторое время мы поняли, что это была ошибка. Во-первых, поддержание актуальности достаточно затратно, во-вторых, никто не отменял бумажные схемы, которые тоже нужно актуализировать и периодически отправлять партнерам и подрядчикам на согласования и т.п. Таким образом, одна и та же информация хранилась в разных местах, в разном виде и её актуализация требовала в два раза больше нашего времени. Как мы решили этот вопрос, описано ниже.
Постепенно наша база наполнялась информацией, и ответы на вопросы типа “какая прошивка на плате в Хабаровске” или “сколько свободных юнитов в стойке в Архангельске” стали находиться очень быстро. Мы начали “приучать” пользоваться базой своих коллег из других отделов. Расписали им, что и где конкретно в этой базе можно найти и раздали учётки. Бухгалтерия подгоняла свою систему инвентаризации под нашу CMDB, поскольку последняя в итоге является самым достоверным источником информации.
Преимущества использования CMDB стали очевидны, и когда возник вопрос о переходе с самописного хелпдеска на что-то более продвинутое, руководство приняло решение об использовании iTop. В настоящее время в нашем iTop сделаны все необходимые доработки и устранены замечания опытной эксплуатации его в качестве хелпдеска. Дальше – учёт инцидентов и проблем и интеграция с системой мониторинга. Но это уже другая история.
Не iTop’ом единым
Изначально у нас возникло труднопреодолимое желание уложить в iTop всё до последнего патч-корда. Для каждой даже самой незначительной детали хотелось сделать отдельный тип КЕ, а потом всё связать между собой. Но мы смогли во время остановиться и осознать, что если так пойдет и дальше, то всё наше время будет уходить на поддержку базы.
Я настоятельно рекомендую не пытаться всё уложить в iTop. Он для этого и не создавался. Используйте его как основу, специфические задачи решайте более подходящими инструментами, а затем связывайте результаты.
Как я писал выше, изначально мы напридумывали кучу связей, отражающих физические соединения (как схемы кабельных соединений, электропитание). Поскольку на тот момент никакой оценки влияния КЕ не требовалось, мы все связи удалили, оставив только бумажные схемы (pdf). Эти схемы лежат в централизованном хранилище (ftp-ресурс), а в iTop для каждой схемы создан Документ, который привязан к нужным КЕ. Используйте связи, если вам нужно отследить влияние падения сервера MySQL на приложения, и не используйте для отображения физических соединений. И не дублируйте информацию!
Ещё пример. В нашем iTop есть КЕ Узел связи, отдельно есть галерея фотографий этих узлов (веб-приложение). Фотографии в галерею добавляются по событиям, следствием которых они являются (т.е. сломался сервер, поехал менять, пофоткали, добавили в галерею). В описании Узла связи есть поле со ссылкой на страницу этого узла в галерее, а на страницах узлов в галерее – обратная ссылки на соответствующие КЕ узлов в CMBD. После введения учета работ будем связывать такими ссылками отдельные события и тикеты этих работ.
Безусловно, всё это можно сделать и в iTop, но насколько это будет рационально с точки зрения трудозатрат? Если вам не наняли команду IT-консультантов и разработчиков для создания вашей CMDB, то скорее всего вы будете действовать своими силами, причем параллельно (или вместо) с выполнением основных трудовых обязанностей.
Ну же, ещё чуть-чуть
Небольшая очевидная рекомендация по объёму доработок – чем их меньше, тем лучше. Старайтесь изменять базовый функционал только когда это действительно необходимо. Если не уверены, пробуйте работать с тем, что есть. Добавить всегда успеете, а вот удалить неиспользуемые функции будет сложнее.
iTop – очень мощная и гибкая система. Научитесь пользоваться запросами OQL, вы сможете мгновенно получать доступ к любой выборке информации и формировать любые отчеты. Используйте инструмент Аудит для контроля за состоянием CMDB, и жестоко карайте тех, кто нарушает её достоверность.
И ещё, попробуйте делать меньше ограничений в интерфейсе и больше чётких инструкций. Можно “настрогать” и раздать всем разные роли, права, области видимости и т.п., а потом долго ломать голову, почему ничего не работает, и заниматься постоянными правками кода. А можно разрешить всем всё и написать бумажную инструкцию по основным операциям под роспись. Во втором случае будет гораздо проще корректировать процедуры. Но, наверно, это актуально для небольших компаний, где внедрение системы типа iTop и описание процессов идет параллельно.
P.S. А где взять информацию?
Да, с бесплатной информацией на русском туго. Общее представление об ITIL можно получить из курса на intuit.ru. Я свои начальные теоретические знания в области ITIL получил за деньги на курсе “Основы ITILv3”, который вел тренер компании IT Expert.
По CMDB очень помогли материалы компании Cleverics. У них периодически проводятся открытые вебинары. Рекомендую найти и посмотреть записи “Как спроектировать полезную CMDB” и “Проводим идентификацию конфигурационных единиц”, причем второй не менее важный! Кроме этого, различные статьи и темы можно поискать на специализированных (обязательно!) сайтах и форумах по ITSM.
Другие источники добавляйте в комментариях.