Крупному бизнесу с разнородной ИТ-инфраструктурой, более 20 000 устройств в парке и строгими требования ИБ, не так просто выбрать систему для инвентаризации. В статье директор продукта «Инферит ИТМен» Василий Гурьев собрал реальный опыт по внедрению такого ПО в больших компаниях и рассмотрел 7 основных критериев, которые помогут бизнеса уровня Enterprise избежать серьезных ошибок и лишних расходов.
Общие рекомендации
Выбирайте российский софт
Это связано не только с законодательными инициативами, предписывающими государственному сектору переходить на импортозамещенный софт, но и с массовым уходом зарубежных вендоров. Даже если на данный момент нужное поставщик ПО продолжает продавать лицензии и оказывать техническую поддержку, в любой момент вендор может прекратить сотрудничество и остановить продажу. Также нет уверенности, что в ближайшие годы не появится закон о запрете использования зарубежного софта для частных компаний.
Выбирайте проприетарное ПО
Предпочтительнее проприетарное ПО, а не Open Source. Это связано с требованиями информационной безопасности, а также с более сложными эксплуатационными характеристиками Open Source-решений в нише системного инфраструктурного ПО, то есть бизнесу нужно будет вносить серьезные доработки. Однако если ресурсы компании позволяют задействовать ИТ-специалистов для «кастомизации» ПО или требования ИБ не столь категоричны, подойдет и Open Source.
7 технических критериев софта для инвентаризации
Инвентаризация ― регулярный процесс по сбору данных с ИТ-инфраструктуры, идентификации устройств, ПО, пользователей и последующей поставкой собранной информации в CMDB и BPMS-системы. Это ключ к контролю инфраструктуры. Рассмотрим критерии, которые ИТ-специалисты должны учитывать при анализе ПО для инвентаризации.
1. Полная картина данных
Софт должен работать на больших объемах и с высокой скоростью собирать данные даже с парка в 200 000 устройств и больше. Лучше выбирать ПО, которое собирает данные скриптами, а не «пакетным» методом без возможности внесения изменений. Скрипты могут достать максимальное количество информации об устройстве, установленном на нем ПО и связать с пользователем. Это более гибкая и мощная технология, которая не ломается на сверхбольших объемах.
Также не менее важно, чтобы софт поставлял данные об ИТ-инфраструктуре для разных типов потребителей в структуре компании. Не только системные администраторы и специалисты техподдержки в крупном бизнесе будут запрашивать актуальную информацию об устройствах для решения рутинных задач. Данные понадобятся другим командам: ITSM-менеджменту, ИТ-инженерам, бухгалтерии, менеджерам и руководителям. На основании собранных данных разные подразделения получат единую информацию, поэтому необходим софт, который умеет не только быстро собирать данные, но при этом связывать объекты инвентаризации без искажения и дублирования.
2. Гибкая архитектура
Бывают ситуации, когда компания не имеет реального представления о своей ИТ-инфраструктуре. Многие предполагают, что у них простая клиент-серверная инфраструктура, которая подразумевает прямое взаимодействие клиента с сервером и базами данных. Простое ПО для инвентаризации обойдет такую инфраструктуру и соберет информацию со всех конфигурационных единиц.
![Схема клиент-серверной инфраструктуры](https://www.computerra.ru/wp-content/uploads/2024/04/image3.png)
Но потом при внедрении закупленного софта для инвентаризации выясняется, что в компании есть не только клиент-серверная инфраструктура, но и сложная закрытая хабовая модель. В этом случае далеко не каждое ПО справится. Именно поэтому крупному бизнесу с разветвленной инфраструктурой, разнотипными устройствами и гео-распределением по разным городам и странам нужно ориентироваться на систему инвентаризации с гибкой гибридной (конвергентной) архитектурой.
![Схема закрытой хабовой инфраструктуры](https://www.computerra.ru/wp-content/uploads/2024/04/image2.png)
При этом важно не забывать про требования ИБ ― софт должен быть безопасным и обходить закрытые участки без «взлома».
![Конвергентная архитектура в системе для инвентаризации и сбора данных](https://www.computerra.ru/wp-content/uploads/2024/04/image5.png)
3. Идентификация устройств
На старте проекта по внедрению нужно учесть, что система инвентаризации должна уметь идентифицировать устройство как единый объект независимо от того, из каких источников информации о нем поступили данные.
Если софт для инвентаризации не умеет идентифицировать устройства, в системе появляются десятки дублей, что искажает картину об ИТ-инфраструктуре. Например, если переводят сервер на zabbix или SolarWinds, софт должен «соединить» информацию о нем и показать в системе как одно устройство.
Это важно для отдела, который занимается учетом ИТ-активов и выдачей оборудования, чтобы видеть корректную историю изменения устройств. Специалистам информационной безопасности нужно отслеживать «мертвые души», то есть уволенных сотрудников компании, которые до сих пор привязаны к ПК.
4. Пригодность данных для поставки в CMDB
Если система инвентаризации не может нормализовать и адаптировать собранные данные, то в CMDB возникает хаос. В этом случае есть пару нюансов:
- Софт должен устранять дубли при поставке в CMDB.
- Софт должен иметь большое количество атрибутов данных, таких как классы устройств, категории, типы, версии ПО, линейки принтеров и другие.
![Компоненты CMDB](https://www.computerra.ru/wp-content/uploads/2024/04/image4.png)
Для этого в ПО для инвентаризации должен быть конвейер обработки данных, который включает их сбор, идентификацию в системе, нормализацию и обогащению с помощью собственной библиотеки ПО.
5. Сетевая инвентаризация по SNMP-стандартам и собственным скриптам
Софт для инвентаризации должен проводить сетевую инвентаризацию и сетевой дискаверинг, то есть собирать данные по устройствам с SNMP-протоколом, идентифицировать по типу и находить устройства в сети. К типам устройств относятся принтеры, коммутаторы, телефоны, бесперебойники и т.д.
В сетевой инвентаризации есть два класса решений:
- Только стандарт: ПО пользуется рекомендованными стандартами на подключение к устройству. Однако если производитель принтера шифрует какие-либо данные об устройстве или добавляет нестандартные параметры, то такой класс решений не сможет собрать информацию.
- Стандарт и скрипты: ПО дает возможность компаниям добавить собственные скрипты, которые соберут любые нужные данные о сетевом устройстве — от количества тонера до зашифрованного серийного номера.
6. Сбор данных с Windows и всех типов Linux
Крупные компании постепенно переходят с Windows на экосистему Linux. В Windows было единое хранение данных, стандартизированные списки и дистрибутивы, поэтому собрать информацию и идентифицировать разные версии ОС в системе инвентаризации было легко. В Linux путь к стандартизации данных только начался. Нужен софт, который может собрать все параметры: версии, пользователи, дистрибутивы. Стандартные инструменты инвентаризации не могут идентифицировать разные версии, например, защищенной ОС Astra Linux и RedHat.
7. Инвентаризация виртуальных сред
Софт для инвентаризации должен собирать данные не только с физических устройств и установленного на них ПО, но и со средств виртуализации, машин и контейнеров. Наиболее распространенные системы виртуализации (гипервизоры) — Hyper-v, VMWare, Xen, KVM, zVirt.
Такой осознанный и осмысленный подход к инвентаризации поможет масштабироваться и расти без сбоев в процессах. Знать свою ИТ-инфраструктуру ― первый шаг к полному контролю.