Эксплуатация Snipe-IT: обновления, бэкапы и безопасность

Почему «поставил и забыл» не работает

В первых статьях серии мы развернули Snipe-IT в Docker и подключили его к Active Directory, Excel-наследию и API-автоматизациям. Внедрить — полдела. Сегодня — про вторую половину, о которой обзоры молчат: как эта система живёт у наших клиентов годами и что входит в регламент её сопровождения. Спойлер: немного, но регулярно — и в этом вся суть.

Главная особенность Snipe-IT как объекта эксплуатации — темп разработки. Релизы выходят каждые несколько недель: ветка v8 стартовала в феврале 2025-го, и к августу 2026-го актуальной стала v8.6.3. Для пользователя это прекрасно — баги чинятся быстро, функции приезжают постоянно. Для того, кто сопровождает, это обязательство: отстать на год — значит копить риск. Во-первых, security-фиксы: та же v8.6.3 от 15 июня 2026 года — именно security-релиз, закрывающий проблемы в SCIM и LDAP, то есть ровно в тех интеграционных механизмах, которые торчат в сторону домена. Во-вторых, чем больше пропущено релизов, тем страшнее становится догоняющий прыжок: обновляться с версии годичной давности через мажорный рубеж — совсем не то же самое, что накатить очередной минорный релиз за десять минут.

Поэтому в нашем SLA для Snipe-IT зафиксированы два ритма: минорные обновления — раз в месяц, плановым окном, с прочтением changelog; security-фиксы — в течение недели после выхода, вне очереди. Следим за релизами просто: подписка на GitHub-репозиторий (Watch → Releases) — уведомление о новом релизе падает на дежурный ящик само, без ручных проверок.

Регламент обновления Docker-инсталляции

Docker превращает обновление Snipe-IT в короткую предсказуемую процедуру — при одном условии: версия образа в docker-compose.yml прибита явно (snipe/snipe-it:v8.6.3), а не latest. Тогда обновление — это осознанная правка одной строки, а не лотерея при случайном pull. Наш регламент по шагам:

1. Читаем changelog релиза. Две минуты на GitHub Releases: что за релиз (фиксы или новые функции), нет ли пометок о несовместимостях и изменениях требований. Для минорных релизов это формальность, но именно она однажды спасает.
2. Бэкап перед обновлением — обязательно. Свежий архив snipeit:backup (о нём ниже) плюс, на виртуалках наших клиентов, снапшот VM. Правило простое: не бывает «слишком маленького» обновления, перед которым не нужен бэкап.
3. Меняем тег и накатываем:

   sed -i 's/v8.6.2/v8.6.3/' docker-compose.yml
   docker compose pull
   docker compose up -d
   

   Миграции базы выполняются автоматически при старте нового контейнера — руками ничего накатывать не нужно, через минуту-две система поднимается уже на новой версии.
4. Smoke-тест: пять минут руками. Логин, открыть карточку актива, сделать тестовый checkout/checkin, проверить печать этикетки и что ушло письмо. Список короткий, но фиксированный — по нему видно, что живы все ключевые подсистемы: база, сессии, генератор этикеток, почта.
5. Откат, если что-то пошло не так: возвращаем прежний тег образа и docker compose up -d. Именно поэтому тег в compose — явный: «предыдущая версия» — это конкретная строка в git-истории конфига, а не воспоминание. Если новый релиз успел мигрировать схему базы несовместимым образом — восстанавливаемся из бэкапа шага 2; за годы нам это понадобилось ровно один раз.

Отдельно про мажорные апгрейды — там регламент строже. Переезд v7→v8 мы проходили у всех клиентов: ветка сменила требования к окружению (v8 требует PHP не ниже 8.2, а с релиза v8.5 движок переехал на Laravel 12) — в Docker-варианте это скрыто внутри образа, но означает, что образ меняется капитально. Поэтому мажор мы сначала прогоняем на копии: разворачиваем рядом контейнер новой версии, подкладываем восстановленный из бэкапа дамп, прогоняем smoke-тест и только потом трогаем прод. Час дополнительной возни — зато ни один клиент перехода не заметил.

И мелочь, которую замечают пользователи, а не админы: после обновления свежедобавленные строки интерфейса могут быть на английском — перевод на Crowdin догоняет новые функции через релиз-другой. Мы предупреждаем об этом клиентов заранее (и это честно снимает 100% тикетов «у нас что-то сломалось с языком»).

Бэкапы: три уровня защиты

Бэкап реестра активов — это защита не столько данных, сколько дисциплины: восстановить-то можно и вручную, но повторную инвентаризацию на 300 позиций с наклейками и подписанными актами вам никто не простит. Наша схема — классическое правило 3-2-1, разложенное на три уровня.

Уровень 1: встроенный snipeit:backup

У Snipe-IT есть штатный механизм: команда php artisan snipeit:backup собирает в один архив с меткой времени SQL-дамп базы и все загруженные файлы — фотографии активов, сканы, подписанные акты. Запускается по расписанию, свежие архивы видны прямо в админке (Admin → Backups), откуда их можно скачать. Это уровень «быстро откатиться»: перед обновлением, перед массовым импортом, перед экспериментами.

Уровень 2: копия за пределами сервера

Архив, лежащий на том же диске, что и система, — это не бэкап, а самообман: умирает диск — умирает всё вместе. Поэтому ночной cron на хосте забирает свежий архив и уносит его на независимое хранилище — у нас это FTP-хранилище в другом дата-центре, физически и административно отдельное от площадки со Snipe-IT. Глубина хранения — 30 суточных копий плюс 12 месячных: «удалили актив в прошлом квартале и заметили только сейчас» — реальный сценарий из практики, суточной глубины для него мало.

Уровень 3: APP_KEY — без него архив неполноценен

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

Учебное восстановление — прогон на реальном кейсе

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

1. Поднимаем на тестовой машине чистый стек из того же docker-compose.yml (он лежит в git — инфраструктура как код спасает и тут) с тем же тегом версии.
2. Вписываем в .env сохранённый APP_KEY из парольного менеджера — не свежесгенерированный!
3. Забираем архив с FTP, восстанавливаем: дамп — в базу, загруженные файлы — на место. У Snipe-IT есть и штатная команда восстановления из архива, и «ручной» путь; структура архива прозрачная — SQL-файл плюс каталоги загрузок, так что восстановление не зависит от магии.
4. Прогоняем чек-лист: логин работает; число активов совпадает с продом на момент архива; фотографии в карточках открываются; подписанные акты на месте и открываются (это главная проверка — именно вложения теряют чаще всего); значения зашифрованных полей читаются (проверка APP_KEY); тестовый checkout проходит.

Наш норматив на полное восстановление — 40 минут от «архив скачан» до «чек-лист пройден». Цифра важна не сама по себе, а как обещание клиенту: мы знаем время простоя при худшем сценарии, потому что регулярно его измеряем. Кстати, восстановление на живой системе разлогинивает всех пользователей — поэтому и боевые восстановления, если они когда-то понадобятся, мы планируем на вечер.

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

Безопасность инсталляции

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

Учётки: 2FA и права по ролям

Двухфакторка в Snipe-IT встроенная, по TOTP — работает с любым приложением-аутентификатором. Для учёток с админскими правами она у нас обязательна без исключений, включается принудительно. Дальше — принцип минимальных прав через группы: система позволяет нарезать права очень мелко, и мы этим пользуемся. Типовая пирамида для клиента до 50 РМ:

• Админ (мы или ИТ-ответственный клиента) — полные права, 2FA, единственный, кто правит справочники и настройки;
• Офис-менеджер — выдача и приём техники, создание активов; без доступа к настройкам и удалению;
• Бухгалтер — только просмотр и отчёты: вся амортизационная фактура доступна на чтение, руками ничего не испортить;
• Сотрудники — видят только свою технику и подписывают акты. Им вообще не нужен вход в основной интерфейс.

Периметр: не светить панель в интернет

Идеальная схема — Snipe-IT доступен только из офисной сети и по VPN. Она же и типовая у наших клиентов: реестром пользуются три-пять человек, всем им VPN и так выдан. Если внешний доступ всё же нужен (подпись актов удалёнщиками с личных устройств — самый частый повод), то минимум: только HTTPS, allowlist по IP там, где он возможен, и fail2ban на nginx против перебора паролей — благо неудачные попытки входа видны в логах. И в любом случае порт приложения наружу не публикуется — только через reverse-proxy, как мы настраивали в статье про установку.

Секреты: .env вне git, ротация токенов

Файл .env — это все пароли инсталляции разом: база, SMTP, ключ шифрования. В git-репозиторий с конфигурацией он не попадает никогда (в .gitignore — с первого коммита), права на файл — 600. API-токены живут у пользователей-роботов с минимальными правами, а не у живых админов, и ревизуются дважды в год: скрипт умер или переехал — токен отзывается. Скучно? Скучно. Утечка реестра техники — гораздо веселее, но мы предпочитаем скуку.

Мониторинг и типовые инциденты

Snipe-IT у нас стоит на мониторинге наравне с почтой и 1С — в Zabbix, который и так есть у каждого клиента. Набор проверок скромный, но закрывает всё, что реально ломается: HTTPS-проверка страницы логина (код ответа и срок сертификата), состояние контейнеров, свободное место на диске, и отдельно — уходят ли письма. Почему именно эти четыре — видно из статистики наших инцидентов. Вот три реальных, все пойманы мониторингом до жалобы клиента:

• Переполненный диск. Самый частый сценарий. Фотографии активов, сканы документов и — ирония — накопившиеся архивы бэкапов тихо съели том. Алерт на 80% заполнения сработал за недели до края; лечение — ротация старых архивов и перенос их на FTP, плюс пересмотр порога. Без мониторинга финал другой: место кончается в момент ночного бэкапа, архив создаётся битым, и об этом узнают при восстановлении.
• Слетевший SMTP-пароль. Клиент сменил пароль ящика уведомлений (плановая ротация на почтовом сервере), а про Snipe-IT забыл. Письма о выдачах перестали уходить молча — интерфейсу всё равно, а вот сотрудники перестали получать акты на подпись. Поймали проверкой почтовой очереди; починка — минута (и помним грабли из первой статьи: после правки .env — пересоздание контейнера, а не restart).
• Сломанный шаблон этикеток после обновления. После одного из апдейтов кастомный шаблон наклеек начал выдавать съехавшую разметку — размеры полей в новой версии генератора считались чуть иначе. Поймали на smoke-тесте (печать этикетки в нём не случайно), до боевой печати рулона дело не дошло. Починка — пять минут подгонки шаблона. С тех пор пункт «напечатать тестовую этикетку» из smoke-теста не выйдет никогда.

Общий вывод из всех трёх: инциденты Snipe-IT — не драмы, а мелочи, если их ловит автоматика. Каждая из этих мелочей, дозревшая до жалобы пользователей, стоила бы часов разбирательств и подорванного доверия к системе.

Гигиена данных как часть эксплуатации

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

• Ежеквартальный аудит статусов. Отчётом отбираем подвисшие состояния: техника «в ремонте» дольше месяца (ремонт забыли закрыть или ноутбук потерялся у подрядчика?), «готова к выдаче», но месяцами на складе (может, пора отдать её новичку вместо закупки?), выданное уволенным (офбординг прошёл мимо процедуры). Полчаса раз в квартал — и реестр не накапливает ложь.
• Списанное — архивировать, не удалять. Правило железное: удаление актива уничтожает историю его выдач, а она нужна бухгалтерии много лет — по спорам, актам и амортизации. Архивный статус убирает технику из рабочих списков, но сохраняет биографию. Кнопкой Delete в нашей практике пользуются только для явных ошибок ввода — дубль завели, опечатались.
• Сверка лицензий с фактом. Раз в квартал сверяем посадочные места лицензий с реальностью: сколько мест занято в Snipe-IT против того, сколько реально установлено. Расхождение в обе стороны стоит денег — либо платите за воздух, либо рискуете при проверке.
• Годовая инвентаризация — за один вечер. Кульминация всей затеи с QR-наклейками: обход офиса со смартфоном, сканирование каждой наклейки, отметка «на месте». Для 50 рабочих мест — вечер работы двух человек вместо недели с распечатками. Бухгалтерия получает сверку, директор — цифру расхождений (обычно ноль или около), а мы — подтверждение, что реестр совпадает с реальностью.

Сколько это стоит в часах

Финальная честность — смета. Вот во что реально обходится сопровождение Snipe-IT для компании до 50 рабочих мест при налаженных регламентах:

В сумме — 2–3 часа в месяц, включая квартальные работы, размазанные по году. Это и есть цена владения «бесплатной» системой: лицензия — ноль, дисциплина — пара часов ежемесячно. Для сравнения: у разработчиков есть официальный облачный хостинг, где обновления и бэкапы берут на себя они. Он оправдан, когда у компании нет вообще никого, кто готов тратить эти два часа, — но данные реестра при этом живут в чужом облаке, и по нашему опыту для российских компаний это чаще всего решающий аргумент в пользу self-hosted на своей или нашей площадке.

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