Inventory Monitoring System или CMDB на коленке
Много лет назад работал я системным администратором в одной не очень большой, но хорошей компании. Все стандартно: несколько серверов, простенький документооборот, почта, интернет, бухгалтерия, файловые ресурсы, рабочие места пользователей. Да, ох уж эти рабочие места. Поддержка пользователей всегда занимает особое место в сердце любого системного (да и не системного тоже) администратора.
В одно прекрасное утро я получил довольно внушительный «втык» от руководства за неожиданно ставший неработоспособным компьютер главного бухгалтера. Ничего экзотического — неожиданно закончилось место на системном диске. ОС «упала» и отказалась подниматься самостоятельно. Быстренько устранив инцидент, я подумал, неплохо бы было получать информацию о том, что тот или иной пользователь заполонил своими фотками весь диск C немного раньше, чем откажет его компьютер.
Я написал и запустил с помощью Task Sheduler-а на одном из серверов несколько простеньких скриптов на VBS, которые регулярно подключались к рабочим станциям пользователей по WMI и собирали информацию о томах на всех доступных рабочих станций в домене (ActiveDirectory).
Получилось прикольно. Аппетит разгорелся . Через пару месяцев в базе данных (MS SQL Server) новорожденной Inventory Monitoring System (IMS) было вполне приличное описание практического всего ИТ-оборудования компании, а на внутреннем сайте (IIS + ASP) можно было эту информацию в удобном виде посмотреть или выгрузить в MS Excel.
Кроме сбора информации о конфигурации и состоянии различного оборудования было настроено сканирование и контроль внутренних IP-сетей, сбор данных производительности серверов (загрузка CPU, использование памяти, производительность сети и дисков) и доступности различных ИТ-ресурсов (страничек внутреннего и внешнего сайтов, доступа в интернет и т.п).
Что удивило — вроде делалось это, чтобы освободить побольше времени для творчества и отдыха , а на самом деле автоматизированный сбор данных об ИТ-ресурсах обнаружил большое количество скрытых мелких проблем, которые мне же и пришлось решать.
МТС
В компанию МТС я пришел в подразделение, которое занималось серверами Windows. Только сервера — никаких рабочих станций, принтеров, пользователей. Красота! Только серверов этих было несколько сотен, и каждые полгода их количество удваивалось.
Через пару дней после выхода на работу я понял, что без IMS мне и моим коллегам здесь придется трудновато. Выпросил старенький сервер и поднял IMS.
На сегодня этой платформе уже 14 лет. Это система полностью разработана сотрудниками компании (у нас специально для таких продуктов есть название СИТР — система собственной ИТ -Разработки). IMS рос и менялся вместе с процессами в компании. 10 лет назад он содержал информацию только о серверах МТС Москвы — сейчас содержит информацию практически обо всем ИТ-оборудовании МТС и ее дочерних компаний по всей России.
Сбор данных с оборудования происходит преимущественно удаленно. На серверах платформы запускается множество отдельных процессов, подключающихся к серверам и оборудованию (WMI, SSH, SNMP, SOAP), которые собирают и отправляют в базу платформы полученную информацию. Процессы запускаются с помощью штатного планировщика TashSheduler. Весь процесс добавления/удаления задач в TashSheduler тоже автоматизирован. План сбора метрик, указанный в карточке объекта, автоматически реализуется в конкретные задачи в TashSheduler на конкретных серверах платформы.
План метрик может быть назначен объекту с помощью набора профилей вручную или автоматически (в зависимости от типа оборудования, местоположения и т.п.) и дополнен собственным персональным набором «штатных» метрик.
Кроме этого, можно подготовить и назначить к сбору комплект своих, особенных метрик, характерных только для конкретного объекта. Для этого нужно воспользоваться специальным конструктором и создать метрики для получения данных одним из стандартных предопределенных методов, например, через WMI, SNMP, командой SSH и т.п. (всего полтора десятка разных методов получения данных).
Результатами работы процессов являются параметры сервера. В карточке объекта (веб-интерфейс) можно посмотреть их в виде списка последних собранных значения или проанализировать исторические значения в виде графиков и таблиц (с возможностью выгрузки в Excel).
Кроме динамических параметров собирается различная инвентаризационная информация: сведения об оборудовании, ОС, локальных пользователях, дисковых томах, интерфейсах, установленных приложениях, сессиях RDP и SSH, установленных системных обновления и т.п.
Происходящие с объектом изменения фиксируются в журналах: сообщения от систем мониторинга можно увидеть в журнале сообщений, информация о плановых и аварийных работах — в журнале событий, изменения, вносимые в карточку объекта — в журнале изменений.
Жизненный цикл оборудования можно довольно подробно описать на специальной вкладке «Эксплуатация». Можно распечатать и наклеить на оборудование этикетку c QR-ссылкой на карточку в IMS.
IMS имеет развитую систему поиска и отображения информации об объектах, хранящихся в системе. Позволяет искать нужный набор объектов по большому количеству критериев, составным условиям и по списку значений. Для отображения полученного набора объектов можно воспользоваться стадартными формами с определенным набором характеристик объектов или собственной формой с произволным наборм характеристик. Есть также возможность подготовки динамических отчетoв (dashboard).
Преимущества текущей реализации
Сразу было понятно, что система будет полезна и окупит потраченные на нее силы только если будет содержать нужные и актуальные сведения. Если за актуальность данных, которые собираются автоматически, можно было, в принципе, не беспокоиться, то обеспечение актуальности информации, вносимой пользователями вручную (системными администраторами), организовать было гораздо сложнее. Их необходимо было заинтересовать и мотивировать использовать IMS как инструмент для оперативной повседневной работы.
Исходя из этого, определилось несколько ключевых целей:
- принципы работы и процессы в системе должны быть максимально открыты, просты и интуитивно понятны;
- интерфейс должен быть максимально прост, быстр и интуитивно понятен;
- сотрудники — источники «ручной информации» — должны постоянно работать в системе, активно используя ее для решения своих оперативных задач, получая нужную для себя информацию, — тогда они будут максимально заинтересованы в поддержании актуальности «ручных» сведений.
И, по-моему, это удалось. Это и объясняет успешную и такую продолжительную эксплуатацию платформы, несмотря на устаревшие технологии, использованные для ее разработки. Напомню: ПО платформы изначально было написано на Microsoft ASP + VBScript, и большая часть кода до сих пор сохранилась на этом диалекте и в этой парадигме. Хотя, конечно, доработка и разработка нового функционала, по возможности, ведется на современных продуктах платформы .NET.
Как показал опыт, простая открытая архитектура ASP и VBScript, возможность быстрого и наглядного исправления ошибок и внесения правок позволяла быстро и эффективно дополнять и перестраивать процессы получения, управления и отображения данных с учетом текущих потребностей и пожеланий коллег. Это и дало возможность создать этот удобный и практичный (как мне кажется) инструмент для системного администратора.
Вендерных CMDB-продуктов много. Каждый имеет свои плюсы и минусы. И основной минус — это стоимость решения, лицензий и кастомизация. IMS же позволять легко интегрироваться с любыми решениями и выступать в роли поставщика инвентаризационных данных.
Владимир Наумов (v_naumov), старший эксперт-куратор отдела автоматизации ITSM процессов МТС.
