Любой ИТ‑отдел рано или поздно приходит к таблице.

Сначала она выглядит безобидно: инвентарный номер, пользователь, кабинет, модель компьютера, серийный номер. Потом туда добавляются мониторы, принтеры, картриджи, счета, договоры, лицензии, гарантия, комментарии, история ремонтов, перемещения между отделами, списание, выдача, возврат, кто кому что передал и почему у нас опять «где‑то был такой же блок питания».

Через какое‑то время это уже не таблица, а маленькая самописная CMDB, только без связей, истории, прав доступа, нормального поиска и уверенности, что данным можно доверять.

В какой‑то момент я понял, что мне нужна не просто «ещё одна база компьютеров», а единая система для повседневной работы ИТ‑службы: техника, пользователи, документы, счета, лицензии, картриджи, удалённая поддержка, история изменений и автоматическая инвентаризация. Так появился Admin Desk.

Это не статья в стиле «я сделал идеальную систему». Скорее рассказ о том, почему простая задача учёта техники быстро превращается в продукт, где самое сложное — не CRUD, а связи между объектами, история, права, эксплуатация и удобство для реального администратора.

С чего всё началось

Типовая ситуация в ИТ‑отделе выглядит примерно так.

Есть парк компьютеров, ноутбуков, серверов, мониторов, принтеров и сетевого оборудования. Есть пользователи, отделы, помещения, склады, закупки, счета, договоры и лицензии. Есть расходники, например картриджи. Есть оборудование, которое переезжает от одного пользователя к другому. Есть техника, которую покупали по одному счёту, выдавали по акту, ремонтировали, потом вернули на склад, а через полгода поставили другому сотруднику.

И есть вопросы, на которые хочется отвечать за несколько секунд:

• у кого сейчас этот монитор;

• когда куплен этот ноутбук и есть ли гарантия;

• по какому счёту покупали эту партию техники;

• какие документы связаны с этим устройством;

• какие картриджи совместимы с этим принтером;

• сколько картриджей осталось на складе;

• какой софт установлен на конкретном ПК;

• какие компьютеры давно не обновляли инвентаризацию;

• что изменилось в карточке устройства и кто это сделал.

В Excel на всё это можно отвечать, пока парк маленький и всё держится в голове одного человека. Но как только появляется несколько филиалов, несколько администраторов, закупки, документы, перемещения и история — таблица перестаёт быть инструментом и становится источником хаоса.

Мне хотелось сделать систему, которая будет ближе не к абстрактному «enterprise asset management», а к ежедневной жизни ИТ‑отдела: открыть карточку компьютера и увидеть всё, что нужно для работы.

Что я хотел получить

Главная идея системы простая: объект учёта не должен жить отдельно от контекста.

Компьютер — это не только hostname и серийный номер. У него есть пользователь, отдел, расположение, ОС, компоненты, мониторы, документы, счета, история изменений, данные агента, установленное ПО и действия удалённой поддержки.

Принтер — это не только IP‑адрес. У него есть модель, технология печати, формат, цветность, счётчики, расходники, совместимые картриджи, складские остатки, документы, счета и история замен.

Документ — это не просто файл. Он может быть договором, актом, приложением, лицензией или внутренней запиской. Он связан с контрагентом, активами, счетами и сроками.

Счёт — это не просто PDF и сумма. Он должен быть связан с техникой, пользователями, документами, оплатой, поставщиком и отчётами по затратам.

Поэтому базовая цель была такой: сделать единую on‑prem систему, где ИТ‑активы, документы, финансы и поддержка связаны между собой, а не лежат в разных таблицах и папках.

Отдельные требования появились почти сразу:

1. Данные должны строго оставаться в инфраструктуре организации.

2. Система должна работать через браузер.

3. Инвентаризация должна быть автоматической, но ручной ввод тоже должен быть удобным.

4. Нужна нормальная история изменений.

5. Нужны роли и права.

6. Нужны документы, акты, счета и привязки к реальным активам.

7. Нужно автоматическое отслеживание оплаты счетов.

8. Нужна интеграция с LDAP/AD.

9. Нужен SNMP для принтеров и сетевых устройств.

10. Нужен быстрый удалённый доступ к рабочим станциям.

11. Нужна мобильная инвентаризация со сканированием штрихкодов и QR‑кодов.

Почему не готовая система

Готовые ITAM/CMDB‑системы существуют, но у меня было несколько причин писать своё.

Во‑первых, многие решения либо слишком тяжёлые, либо требуют долгого внедрения. А мне хотелось инструмент, который можно поставить, настроить и начать использовать без отдельного проекта на полгода.

Во‑вторых, мне нужна была связка именно под работу ИТ‑отдела: учёт техники, документы, счета, картриджи, инвентаризация, удалённая поддержка и ежедневные административные действия в одном интерфейсе.

В‑третьих, важным требованием было локальное размещение. Для части организаций история оборудования, документы, счета, пользователи и внутренние комментарии — это данные, которые не хочется отправлять в чужое облако.

В‑четвёртых, мне было интересно сделать продукт, который решает мою собственную боль. Это сильно меняет подход: ты не проектируешь «универсальный справочник сущностей», а постоянно задаёшь себе вопрос: «а как этим будет пользоваться админ в понедельник утром?».

Архитектура

Серверная часть Admin Desk — веб‑приложение на ASP.NET Core с Razor Pages. В качестве базы используется MariaDB. Перед приложением стоит Nginx, который принимает HTTP/HTTPS и проксирует запросы на локальный Kestrel.

Упрощённо схема выглядит так:

Браузер пользователя
        |
      HTTPS
        |
      Nginx
        |
  локальный Kestrel
        |
 Admin Desk Server
        |
      MariaDB                
        |
 файлы, документы, журналы, настройки

Отдельно есть дополнительные модули:

AdminDeskAgent       -> сбор инвентаризации
AdminDeskRemote      -> удалённый доступ
LDAP/AD              -> пользователи и группы
SNMP                 -> принтеры и сетевые устройства
SMTP/IMAP            -> уведомления и почтовые сценарии
1C                   -> отслеживание факта оплаты счетов
Мобильное приложение -> инвентаризация, поиск активов и уведомления

Я сознательно не стал делать SPA на React/Vue. Для этого проекта Razor Pages оказались хорошим компромиссом: серверный рендеринг, понятная структура страниц, простая работа с формами, модалками, валидацией и правами. Там, где нужно обновлять таблицы без полной перезагрузки страницы, можно использовать htmx и частичные представления.

Для административной системы это оказалось удобнее, чем тащить отдельный фронтенд, отдельную сборку, отдельный слой API для каждой формы и потом синхронизировать всё это с серверной авторизацией.

Модель данных: самое сложное не таблицы, а связи

На первый взгляд кажется, что ITAM — это просто таблица assets.

На практике очень быстро появляются разные типы объектов:

• компьютеры;

• мониторы;

• компоненты;

• принтеры;

• картриджи;

• сетевые устройства;

• документы;

• счета;

• пользователи;

• отделы;

• расположения;

• склады;

• справочники моделей, производителей, типов и статусов.

А потом выясняется, что все они должны быть связаны между собой.

Компьютер может иметь компоненты и мониторы. Компонент может лежать на складе, быть установлен в ПК или быть закреплён за пользователем. Принтер имеет модель, а модель связана с совместимыми картриджами. Счёт может относиться к нескольким компьютерам, принтерам, компонентам и документам. Документ может быть связан с другим документом, например договор с приложением или актом.

То есть вместо одной таблицы получается граф связей.

Именно поэтому в Admin Desk важны не только карточки объектов, но и панели связей: открыть счёт и увидеть, какие активы к нему относятся; открыть документ и увидеть связанные устройства; открыть компьютер и увидеть документы, счета, компоненты, историю и действия.

История изменений

Отдельная боль — история.

В обычной таблице часто невозможно понять, что произошло: кто поменял пользователя у ноутбука, когда монитор переехал в другой кабинет, почему компонент отвязали от ПК, кто прикрепил счёт или удалил документ.

Поэтому в моей системе изменения пишутся в историю объектов. Для компьютеров, компонентов, принтеров, счетов и моделей есть отдельные журналы. В историю попадает действие, пользователь, дата и JSON с деталями изменения.

Например, если компонент отвязали от компьютера, это событие должно быть видно и в истории компонента, и в истории компьютера. Иначе через месяц никто не поймёт, куда он делся.

История — одна из тех функций, которые сначала кажутся необязательными, а потом становятся основой доверия к системе. Если в базе есть история, с ней можно разбираться. Если истории нет, остаются только догадки и переписки в мессенджере.

Автоматическая инвентаризация

Ручной учёт хорош до первого десятка компьютеров. Дальше хочется, чтобы данные собирались сами.

Для этого есть AdminDeskAgent. Он устанавливается на устройства и отправляет данные на сервер: железо, ОС, накопители, мониторы, сетевые параметры, установленное ПО и другие сведения.

Важный момент: агент — вспомогательный модуль. Система должна оставаться полезной и без него, потому что в реальной инфраструктуре всегда есть устройства, куда агент поставить нельзя или нецелесообразно.

Для принтеров и сетевых устройств используется SNMP. Это отдельный пласт проблем: разные производители, разные OID, разные уровни поддержки, странные ответы устройств, таймауты, старые прошивки. Но результат того стоит: можно автоматически подтягивать принтеры, счётчики страниц, статусы и параметры устройств.

Документы и счета

Одна из главных причин, почему Excel перестаёт работать, — документы и закупки.

Техника редко существует сама по себе. У неё есть счёт, поставщик, дата покупки, гарантия, договор, акт, лицензия или внутренний документ. Если это не связать с активом, через год начинается классическое: «а где документ на этот сервер?» или «по какому счёту покупали эти мониторы?».

В Admin Desk документы и счета — это не отдельный архив файлов, а часть модели данных.

Счёт можно связать с компьютерами, принтерами и компонентами. Документ можно связать с активами и другими документами. Лицензии можно вести как документы с датами, контрагентами и привязками к оборудованию. Для счетов можно хранить статусы оплаты и доставки, даты, суммы и файлы.

В такой модели инвентаризация перестаёт быть отдельной таблицей с устройствами и начинает пересекаться с закупками, документами, гарантиями и отчётностью.

Картриджи и склады

Картриджи — это маленькая отдельная вселенная.

С одной стороны, это расходники. С другой — их нужно учитывать: какие модели есть на складе, с какими принтерами они совместимы, сколько осталось, куда что установили, когда менять, что закупать.

В системе я разделил принтеры, модели принтеров, модели картриджей, совместимость и складские остатки. Это позволяет не привязывать картридж «на глаз», а работать через модель совместимости.

Например, у принтера есть модель, у модели есть список совместимых картриджей. При инвентаризации или выдаче система может показывать не все картриджи подряд, а только подходящие.

Удалённая поддержка

Учёт — это хорошо, но администратору часто нужно не просто посмотреть карточку компьютера, а сразу выполнить действие.

Поэтому в карточку ПК постепенно попали инструменты удалённой поддержки: быстрый доступ, команды, действия через WinRM, VNC и отдельный модуль AdminDeskRemote.

Идея простая: если я уже открыл компьютер в системе, я должен из этой же карточки увидеть его данные и при необходимости подключиться, отправить команду или обновить инвентаризацию.

AdminDeskRemote — отдельный опциональный модуль для удалённого просмотра и управления рабочим столом. Для простых сценариев можно использовать VNC, для более сложных — модуль с несколькими мониторами, буфером обмена, настройками качества и блокировкой ввода пользователя.

Права, безопасность и on‑prem

Так как система хранит не только «железки», но и документы, счета, пользователей и историю, права доступа важны с самого начала.

В Admin Desk есть пользователи, группы безопасности, роли, 2FA и политика паролей. Доступ к функциям интерфейса зависит от прав. Защищённые файлы не должны просто лежать в публичной директории и отдаваться всем подряд — доступ к ним должен контролироваться приложением.

Отдельный принцип — локальное размещение. Сервер ставится в инфраструктуре организации, данные живут в её MariaDB и файловой системе. Агент отправляет инвентаризацию на сервер, который указал администратор.

С эксплуатационной точки зрения это тоже важно: приложение работает как отдельная служба, за Nginx, с локальным Kestrel, отдельным системным пользователем и обычной Linux‑логикой обслуживания.

Установка и обновления

Один из выводов, к которому я пришёл: продукт для администраторов должен устанавливаться как нормальный пакет, а не как набор команд из README на три страницы.

Поэтому сервер поставляется как DEB‑пакет через APT‑репозиторий. Внутри — приложение, systemd unit, зависимости, скрипты установки и обновления. Обновление можно делать через веб‑панель или обычным apt update && apt upgrade.

Это не самая романтичная часть разработки, но для реального продукта она критична. Пока проект живёт только у тебя на сервере, можно обновлять его как угодно. Как только его должен поставить другой администратор, нужны предсказуемая установка, обновление, откат, документация и понятные системные требования.

Интерфейс: почему важны мелочи

Административные интерфейсы часто страдают от одной проблемы: формально функция есть, но пользоваться ей неприятно.

В системе много внимания ушло на мелочи:

• быстрый поиск;

• фильтры;

• сортировка таблиц;

• сохранение контекста при возврате;

• модальные окна;

• массовые операции;

• smart‑select для больших справочников;

• отдельные мобильные представления;

• история прямо в карточке объекта;

• привязки документов и счетов без перехода через пять страниц.

Например, если пользователь открыл список мониторов, применил фильтр, перешёл в карточку, прикрепил документ и вернулся назад, он ожидает попасть в тот же контекст, а не на первую страницу без фильтров. Такие вещи не выглядят как «большая фича», но именно они определяют, будет ли системой удобно пользоваться каждый день.

Что оказалось сложнее всего

1. Не CRUD, а жизненный цикл

Добавить карточку компьютера просто. Сложно описать его жизненный цикл: купили, приняли, выдали, переместили, заменили компонент, подключили монитор, отвязали монитор, отправили в ремонт, вернули, списали.

То же самое с документами, счетами, картриджами и лицензиями.

2. История и связи

Любое действие с объектом может затрагивать другие объекты. Если компонент удалили, нужно корректно отразить это в истории всего с чем он был связан. Если документ отвязали от компьютера, это тоже событие.

3. Развитие схемы БД

Когда проект растёт, схема меняется постоянно. Появляются новые справочники, связи, индексы, таблицы истории, дополнительные поля. Очень важно не превращать миграции в хаос и не тащить вечную обратную совместимость, если продукт ещё активно развивается и можно аккуратно обновлять схему.

4. Агент

Сбор инвентаризации на разных системах — это много нюансов. Windows, Linux, macOS, мониторы, накопители, виртуальные машины, установленное ПО, сетевые адаптеры, разные источники данных и разные форматы. Агент должен быть достаточно лёгким, предсказуемым и не ломать машину, на которой работает.

5. Документация

Когда проект перестаёт быть «моей внутренней штукой», документация становится частью продукта. Нужно описывать установку, архитектуру, администрирование, эксплуатацию, обновление, безопасность, состав компонентов и ограничения. Это скучно только до момента, пока кто‑то другой не начинает ставить систему без тебя.

Какие подсистемы в итоге появились

По мере развития проекта стало понятно, что «учёт техники» — слишком общее название для задачи. На практике внутри такой системы постепенно появляются несколько самостоятельных подсистем.

• Первая — инвентарная модель: компьютеры, мониторы, компоненты, принтеры, сетевые устройства, пользователи, отделы, расположения и склады. Здесь важно не просто хранить карточки объектов, а поддерживать их состояние: где устройство находится, за кем закреплено, из чего состоит и с чем связано.

• Вторая — слой связей. Активы редко существуют сами по себе. Компьютер связан с компонентами, мониторами, документами и счетами. Принтер связан с моделью, расходниками и счётчиками. Документ может быть связан с другим документом, активом или счётом. В какой‑то момент становится очевидно, что система учёта — это не набор таблиц, а граф объектов.

• Третья — история изменений. Для меня это стало одним из ключевых элементов. Недостаточно знать текущее состояние объекта — нужно понимать, как он к нему пришёл. Кто поменял пользователя, когда устройство переместили, почему компонент отвязали от ПК, какой документ прикрепили и кто это сделал.

• Четвёртая — автоматический сбор данных. Ручной ввод остаётся необходимым, но часть информации лучше получать автоматически: характеристики компьютеров, ОС, накопители, мониторы, установленное ПО, данные принтеров и сетевых устройств. Для этого появились агент и SNMP‑сценарии.

• Пятая — документальная и финансовая часть. Счета, договоры, акты, лицензии и файлы должны быть не отдельным архивом, а частью общей модели. Тогда можно открыть устройство и сразу увидеть, по какому счёту оно куплено, какие документы к нему относятся и какие сроки важно контролировать.

• Шестая — эксплуатационный слой: права доступа, группы, двухфакторная аутентификация, LDAP/AD, уведомления, обновления, резервное копирование, журналы и установка через пакеты. Это не самые заметные функции, но без них система остаётся внутренней поделкой, а не инструментом, который можно передать другому администратору.

• Отдельно появились мобильные сценарии и удалённая поддержка. Они выросли уже не из задачи «вести базу», а из повседневной работы: быстро найти устройство по коду, провести инвентаризацию, открыть карточку компьютера и сразу выполнить нужное действие.

В итоге Admin Desk для меня стал не столько «справочником техники», сколько попыткой собрать в одной модели техническую, документальную и эксплуатационную сторону работы ИТ‑отдела.

Несколько выводов

Если бы я начинал заново, я бы ещё раньше заложил три вещи: историю, связи и нормальные справочники.

Пока проект маленький, кажется, что можно обойтись строковыми полями: «поставщик», «кабинет», «модель», «тип». Но потом появляются фильтры, отчёты, связи, права, импорт, массовые операции — и строковые поля превращаются в проблему.

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

Третий вывод: ITAM — это не про «завести список железа». Это про доверие к данным. Если администратор не уверен, что в системе актуальная информация, он снова вернётся к Excel, мессенджерам и памяти коллег.

Вместо заключения

Я не думаю, что Admin Desk должен заменить все существующие ITAM/CMDB‑системы. У больших продуктов есть свои сценарии, интеграции и аудитория.

Для меня этот проект стал способом разобраться, какой должна быть система учёта, если смотреть на неё глазами администратора, который каждый день работает с техникой, документами, пользователями, складами и удалённой поддержкой.

В итоге Admin Desk вырос из таблицы активов в попытку собрать в одной модели то, что обычно живёт в Excel, папках с документами, почте, мессенджерах и памяти коллег.

И если после внедрения на вопрос «где этот монитор и по какому счёту его покупали?» можно ответить за 10 секунд, значит подход оказался правильным.