Много лет назад работал я системным администратором в одной не очень большой, но хорошей компании. Все стандартно: несколько серверов, простенький документооборот, почта, интернет, бухгалтерия, файловые ресурсы, рабочие места пользователей. Да, ох уж эти рабочие места. Поддержка пользователей всегда занимает особое место в сердце любого системного (да и не системного тоже) администратора.

В одно прекрасное утро я получил довольно внушительный «втык» от руководства за неожиданно ставший неработоспособным компьютер главного бухгалтера. Ничего экзотического – неожиданно закончилось место на системном диске. ОС «упала» и отказалась подниматься самостоятельно. Быстренько устранив инцидент, я подумал, неплохо бы было получать информацию о том, что тот или иной пользователь заполонил своими фотками весь диск 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 процессов МТС.