АВТОМАТИЗАЦИЯ УЧЕТА АКТИВОВ ИТ-ИНФРАСТРУКТУРЫ: ОТ КОНЦЕПЦИИ ДО ВНЕДРЕНИЯ В АО МТУ «КРИСТАЛЛ»

Шарафутдинов А.Г., к.э.н., доцент,

Климов В.А., бакалавр,

Дубровин А.А., бакалавр,

ФГБОУ ВО Башкирский ГАУ, г. Уфа, Россия

Аннотация. Статья посвящена этапу проектирования реляционной базы данных для информационной системы учета сетевого и компьютерного оборудования предприятия. В качестве примера рассматривается АО МТУ «Кристалл», для которого выполняется разработка структуры хранения данных, обеспечивающей централизованный учет ИТ-активов. Описываются этапы сбора требований, построения концептуальной, логической и физической моделей данных, а также особенности реализации структуры базы данных в PostgreSQL.

Ключевые слова: проектирование базы данных, реляционная модель, PostgreSQL, учет ИТ-оборудования, логическая модель, физическая модель, нормализация, схема данных

Сейчас сложно представить бизнес, где всё оборудование учитывается на бумагах или в разрозненных Excel-таблицах. Любая средняя ИТ-инфраструктура — это не пара десятков ноутбуков, а сложная экосистема, состоящая из серверов, сетевого железа, рабочих станций и большое количество соединений между всеми устройствами. Удерживать контроль над таким сложным процессом без продуманной информационной системы учета — задача из разряда невозможных. Более того: такая система учета должна начинаться не с разработки пользовательского интерфейса или отдельных элементов управления, а с проектирования базы данных [1]. Расскажем на примере нашего опыта для АО МТУ «Кристалл», где мы делали первую часть большого проекта: создавали именно схему базы данных — ту самую опору, от которой строится всё остальное.

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

- Каждое устройство должно иметь уникальные «имя» (инвентарный номер), паспортные данные (серийный номер), а ещё быть привязанным к модели и производителю.

- Необходимо чётко видеть его жизненный путь: хранится ли оно на складе или уже установлено и эксплуатируется? Где гарантия началась и где закончилась? Когда его переместили? Всё это обязательно фиксировать.

- Описывать порядок расстановки: филиал → этаж → кабинет → стойка → юнит

- Персональная ответственность: кто главный за эту машину/свитч? Какие комплектующие входят в состав сервера и какие соединения он образует с другими компонентами инфраструктуры?

- Минимум лишних повторов и максимум надёжности.

Проектирование ER-диаграммы так, чтобы отражать действительную модель работы. В центре этой модели — сущность «Оборудование» (Device). Чтобы не множить одинаковую информацию (например, имя производителя или тип свитча/роутера), добавили отдельные справочники для моделей, производителей и типов устройств.

Особо важно оказалось движение техники по офису: описание местоположения сделали рекурсивным (родитель-потомок) через сущность «Локация» (Location). Благодаря этому можно отразить любую вложенность, хоть серверное помещение внутри офиса на третьем этаже филиала в Уфе.

Представим карту всех сетевых соединений между железом. Отдельно завели сущность «Порт» (Port) и описываем связи через «Соединение» (Connection) — две строки в табличке могут описывать целиком всю смену сети за ночь.

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

Индексы завели там же, где обязательно будет поиск требуемой информации: номера устройств, серийные номера, ID местоположений... Автоматизация мелких проверок пошла через триггеры БД: нельзя соединить проводом уже занятый порт; все смены статуса оборудования немедленно сбрасываются в историю движений устройства [1].

Рисунок 1 – Построенная ER-диаграмма

Результатом этапа проектирования стал пакет документации, включающий:

- Исчерпывающее описание всех таблиц, их атрибутов, типов данных и

ограничений.

- Диаграмму физической модели (сгенерированную средствами pgAdmin или аналогичными).

- SQL-скрипт schema.sql для развертывания пустой базы данных со всеми таблицами, индексами и триггерами.

- Скрипт sample_data.sql с тестовыми данными для верификации структуры и демонстрации.

После изучения и проектирования документ был передан разработчику клиентского веб-интерфейса, который, используя описанную схему как контракт, смог независимо проектировать логику приложения, методы API (REST/GraphQL) и пользовательские формы, четко понимая структуру и правила хранения данных на сервере.

Проектирование базы данных для системы учета ИТ-активов — это фундаментальная задача, от качества решения которой зависит успех всего проекта. Надёжная учетная система формируется только из хорошо спроектированной структуры хранения данных [1]. Когда этапы распределения ответственности строго разграничены («проектируем БД → реализуем интерфейс»), повышается согласованность разработки и снижается риск ошибок интеграции.

Литература

1. Дейт К. Дж. Введение в системы баз данных : пер. с англ. — 8-е изд. — М. : Вильямс, 2019. — 1328 с. — ISBN 978-5-8459-0788-2.