Snipe-IT нужен не всем: на каком количестве техники таблица сдаётся

MAATRIX

Рано или поздно в компании появляется файл «Учёт техники.xlsx», куда вносят серийники ноутбуков, кому что выдали и когда истекает гарантия. Какое-то время он работает. Потом кто-то увольняется, забыв сдать монитор, две строки конфликтуют после правки в Google Sheets с телефона, а лицензия на софт молча продлевается платно, потому что напоминание никто не поставил. Дальше вопрос не «нужна ли система учёта вообще», а «на каком масштабе таблица перестаёт быть рабочим инструментом» — и здесь честный ответ важнее хайпа вокруг self-hosted ITAM.

Что такое Snipe-IT и что он умеет

Snipe-IT — открытая система учёта IT-активов (IT Asset Management, ITAM): написана на PHP поверх Laravel, хранит данные в MySQL/MariaDB, распространяется под открытой лицензией и разворачивается на своём сервере (есть и платный облачный вариант от разработчиков для тех, кто не хочет админить сам). Задача одна: знать, какая техника есть, у кого она сейчас, и что с ней происходило.

Внутри — несколько типов сущностей, и это первое отличие от плоской таблицы:

• Assets (активы) — техника с уникальным asset tag: ноутбуки, мониторы, телефоны, сетевое оборудование. У каждого — модель, серийный номер, статус, привязка к сотруднику или локации.
• Licenses (лицензии) — софт с количеством посадочных мест (seats), датой покупки и датой истечения подписки/поддержки.
• Accessories (аксессуары) — то, что выдаётся без индивидуального номера: мыши, кабели, гарнитуры, но с учётом остатка на складе.
• Consumables (расходники) — тонер, батарейки, флешки — то, что расходуется и убывает.
• Components (компоненты) — комплектующие вроде оперативной памяти или дисков, которые можно переставлять между активами.

У каждого актива есть статус (например, «готов к выдаче», «выдан», «в ремонте», «списан»), кастомные поля под конкретные нужды (инвентарный номер по внутреннему регламенту, MAC-адрес, дата последней проверки) и история: кто, когда и на каком основании его получил и вернул. Есть импорт из CSV, интеграция с LDAP/Active Directory для синхронизации сотрудников, REST API, генерация QR/штрихкодов для наклеек на технику и email-уведомления об истекающих гарантиях и лицензиях.

Если это описание звучит как «Excel с дополнительными полями» — отчасти так и есть. Разница не в наборе колонок, а в том, что перечислено дальше.

Где обычно перестаёт справляться таблица

Спредшит не ломается резко — он деградирует постепенно, и обычно по одним и тем же пунктам:

• Нет истории выдачи. В таблице есть текущее состояние («у кого сейчас»), но не «кто держал этот ноутбук до Иванова и когда он его сдал». Когда актив теряется или ломается, восстановить цепочку владения по правкам ячеек почти невозможно.
• Кто что вернул — на честном слове. Сотрудник ушёл, написал в чат «сдал», HR закрыл доступ — а строка в таблице осталась не обновлённой, потому что обновлять её должен был кто-то другой, и это «кто-то» не произошло.
• Нет напоминаний. Гарантия истекает тихо. Подписка на софт продлевается автоматически, потому что дата в ячейке E47 никому не прилетела на почту. Таблица не умеет напоминать — умеет только хранить дату, если её туда вписали и потом туда же посмотрели.
• Конфликты редактирования. Несколько человек одновременно правят один файл — Google Sheets более-менее справляется через одновременное редактирование, Excel на сетевой папке справляется хуже: перезаписанные правки, дублирующиеся строки, разные версии файла в переписке.
• Нет разграничения доступа. Таблица либо открыта всем, кто может её найти, либо закрыта — но выборочно («HR видит зарплатное поле, IT видит серийники, менеджер видит только своё подразделение») в спредшите настроить неудобно и ненадёжно.
• Аудит превращается в археологию. Когда нужно ответить «сколько у нас лицензий Х активно оплачено и сколько реально используется» — приходится вручную сверять несколько источников, потому что таблица не считает это сама.

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

На каком количестве техники есть смысл переходить на систему

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

Таблицы обычно хватает, если:

• техники немного (условно до полутора-двух десятков единиц) и один человек ведёт учёт лично, без делегирования;
• команда стабильная, текучка низкая, оборудование почти не переезжает между людьми;
• лицензий немного и они на виду — их можно перечислить по памяти;
• нет требований к формальному аудиту (внешний due diligence, ISO-сертификация, корпоративный комплаенс).

Систему стоит разворачивать раньше, чем «когда табличка совсем развалится», если совпадает несколько условий:

• учёт ведёт не один человек, а несколько (IT, HR, офис-менеджер) — и им нужен общий источник правды, а не пересылка файла;
• команда распределённая или есть удалённые сотрудники — выдача и возврат техники физически не под одним столом, где можно «на глаз» проверить;
• много лицензий с разными датами продления — здесь автоматическое напоминание окупает себя одним предотвращённым автопродлением;
• есть текучка кадров — каждый уход сотрудника означает обязательный чек-лист возврата техники, и без истории выдачи он держится на памяти конкретного человека;
• нужен аудиторский след — кто, когда и почему поменял статус актива, а не только «текущее состояние».

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

Установка Snipe-IT на VPS: Docker Compose

Если решили, что таблицы уже недостаточно, разворачивать удобнее всего через официальный Docker-образ — не нужно вручную ставить PHP, Composer и настраивать веб-сервер под Laravel-приложение.

Структура каталога:

snipe-it/
├── docker-compose.yml
└── .env

.env — переменные для контейнера БД и самого приложения:

# База данных
MYSQL_ROOT_PASSWORD=замените_на_свой_пароль
MYSQL_DATABASE=snipeit
MYSQL_USER=snipeit
MYSQL_PASSWORD=замените_на_свой_пароль

# Приложение
APP_URL=https://assets.example.com
APP_TIMEZONE=Europe/Moscow
APP_LOCALE=ru
MAIL_MAILER=smtp
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=notify@example.com
MAIL_PASSWORD=замените_на_свой_пароль
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDR=notify@example.com

docker-compose.yml:

services:
  snipeit:
    image: snipe/snipe-it
    restart: unless-stopped
    ports:
      - "8080:80"
    depends_on:
      - db
    env_file:
      - .env
    environment:
      DB_CONNECTION: mysql
      DB_HOST: db
      DB_DATABASE: ${MYSQL_DATABASE}
      DB_USERNAME: ${MYSQL_USER}
      DB_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - snipeit_data:/var/lib/snipeit

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - snipeit_db:/var/lib/mysql

volumes:
  snipeit_data:
  snipeit_db:

Запуск:

docker compose up -d

При первом старте контейнер сам накатывает миграции и генерирует ключ приложения. Если что-то пошло не так и веб-мастер настройки не показывается — команды можно выполнить вручную внутри контейнера:

docker compose exec snipeit php artisan key:generate
docker compose exec snipeit php artisan migrate --force

Дальше открываете http://ваш_домен:8080 (или сразу настраиваете обратный прокси с HTTPS перед контейнером — публиковать систему учёта техники по голому HTTP наружу не стоит) и проходите мастер первичной настройки: название компании, часовой пояс, учётная запись администратора.

Порт 8080 в примере — временный, пока нет прокси. На проде разумно поставить перед приложением nginx или Caddy с выпуском сертификата и закрыть прямой доступ к порту контейнера через firewall.

Для бэкапов у Snipe-IT есть встроенная artisan-команда, которая архивирует и дамп базы, и загруженные файлы (фото активов, вложения):

docker compose exec snipeit php artisan snipeit:backup

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

Первая настройка: активы, статусы, чекаут

После входа под администратором система пустая — структуру задаёте сами:

1. Категории активов (Asset Categories) — «Ноутбуки», «Мониторы», «Сетевое оборудование». К категории привязывается тип полей по умолчанию.
2. Модели (Models) — конкретная модель техники внутри категории, с производителем и, если нужно, картинкой для визуальной сверки.
3. Статусы (Status Labels) — из коробки есть базовые (готов к выдаче, в ремонте, архивирован), но их стоит донастроить под свой процесс: например, отдельный статус «на карантине после увольнения» для техники, которую приняли обратно, но ещё не проверили.
4. Кастомные поля (Custom Fields / Fieldsets) — если нужно хранить что-то специфичное (инвентарный номер по внутреннему регламенту, MAC-адрес, дата последней диагностики), поле создаётся один раз и привязывается к нужным категориям через fieldset.
5. Локации (Locations) — офисы, склады, «удалённо у сотрудника» как отдельная локация.
6. Импорт данных — не нужно вбивать всё руками: в разделе Import есть загрузка CSV с маппингом колонок на поля Snipe-IT, это стандартный путь перенести существующую таблицу без ручного ввода.

Дальше — рабочий цикл: Checkout привязывает актив к сотруднику, локации или другому активу (например, монитор — к рабочему месту, а не к человеку), Checkin возвращает его в пул со сменой статуса. Каждое действие попадает в лог актива — это и есть та самая история, которой не было в таблице. Для лицензий похожий принцип: посадочные места (seats) выдаются конкретным пользователям или привязываются к активам, и система видит, сколько мест ещё свободно.

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

Чего Snipe-IT не решает и когда таблицы всё ещё достаточно

Честный разбор не обходится без ограничений — иначе это не разбор, а реклама.

• Это не RMM и не система мониторинга. Snipe-IT не ставит агента на устройства и не узнаёт сама, что на ноутбуке кончилось место на диске или не установлено обновление. Данные вносятся вручную или через API — это реестр, а не система удалённого управления.
• Это не helpdesk. Заявки, тикеты, SLA — не сюда. Если параллельно нужна система обращений, это отдельный инструмент вроде osTicket — по опыту, попытки натянуть тикет-процесс на поля учёта активов быстро упираются в потолок.
• Это не IPAM/DCIM. Если основная боль — учёт IP-адресов, VLAN и стоек с оборудованием в серверной, ближе будет NetBox: у него другая модель данных, заточенная именно под сетевую инфраструктуру, а не под «кто держит ноутбук».
• Обслуживание — на вас. Это self-hosted приложение на PHP: обновления образа, бэкапы, мониторинг диска под MySQL, реакция на уязвимости — всё то же самое, что и с любым другим сервисом на своём сервере. Стоит заранее прикинуть, кто и как часто будет этим заниматься — вопрос разобран в общем виде в статье про экономику self-hosted: нагрузка небольшая, но она никуда не девается сама.
• Соответствие лицензионным условиям система не проверяет. Snipe-IT покажет, сколько посадочных мест вы завели и сколько выдали — но не узнает сама, что на самом деле установлено на компьютерах. Это по-прежнему требует периодической сверки руками; если такая сверка уже проводится хотя бы раз в год, разумно совместить её с внедрением системы, а не откладывать обе задачи на потом.
• Интерфейс утилитарный. Это рабочий инструмент для IT и офис-менеджера, а не витрина с современным UX — если ожидания на этот счёт завышены, лучше сразу посмотреть скриншоты в документации проекта, чтобы не разочароваться после разворачивания.

Если ни один из пунктов раздела «На каком количестве техники есть смысл переходить» не совпадает с вашей ситуацией — это нормальный повод не разворачивать систему прямо сейчас. Таблица с датой пересмотра раз в квартал — тоже рабочий процесс, если ей действительно кто-то следует.

Частые вопросы