Почему интеграция с маркировкой не должна жить на офисном компьютере

MAATRIX

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

Почему интеграция вообще оказывается на офисном компьютере

Когда бизнес внедряет обмен с системой маркировки, решение «куда это поставить» почти никогда не принимается осознанно — оно происходит по инерции. Модуль обмена идёт в комплекте с учётной системой (обычно 1С), учётная система уже стоит на компьютере бухгалтера или товароведа, и сервис интеграции запускается там же — потому что это самый быстрый путь, требующий нуля дополнительных действий. Внедренец настроил, протестировал, показал, что коды принимаются и документы уходят — и на этом задача считается закрытой.

Проблема в том, что критерий «работает во время настройки» и критерий «работает постоянно, без участия человека» — это два разных требования, и второе никто не проверял. Компьютер сотрудника изначально не проектировался как сервис непрерывной работы: это рабочее место конкретного человека, с его личным графиком, его правом выключить машину, его периодическими обновлениями и его правом уйти в отпуск. Интеграция с маркировкой при этом обязана работать в фоне 24/7, независимо от того, сидит кто-то за этим компьютером или нет — а это требование к инфраструктуре, а не к рабочему месту.

Та же логика верна и для смежных обязательных систем — ЕГАИС, обмен с ФНС. О том, из каких компонентов на техническом уровне состоит такой сервис — очередь документов, обмен с оператором ЭДО, обработка ошибок — подробно разобрано в статье про серверную часть интеграции с Честным знаком. Здесь же речь о том, на какой физической площадке этим компонентам стоит жить.

Риск первый: компьютер живёт по графику сотрудника, а не по графику бизнеса

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

Что реально происходит на практике:

• Компьютер выключают на ночь. Даже если формально ничего критичного вечером не происходит, любое сообщение от оператора ЭДО — статус документа, запрос на подтверждение, уведомление об изменении регламента — просто не будет получено, пока машина не включится утром.
• На выходные технику выключают централизованно. В части офисов есть общая практика обесточивать компьютеры на выходные ради экономии или по требованиям безопасности — и тогда интеграция гарантированно не работает два дня в неделю, регулярно.
• Windows перезагружается сама. Плановые обновления Windows с автоматической перезагрузкой — стандартное поведение по умолчанию на рабочих станциях, которые не администрируются как серверы. Сервис обмена может быть настроен на автозапуск, но между перезагрузкой и повторным запуском проходит время, а иногда автозапуск ломается после обновления и требует ручного вмешательства.
• Компьютер уходит в спящий режим. Ноутбуки и многие настольные ПК по умолчанию засыпают после периода бездействия — для рабочей станции это разумная экономия энергии, для сервиса непрерывного обмена — гарантированный разрыв связи в самый неожиданный момент.

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

Риск второй: переустановка системы и смена техники ломают интеграцию незаметно

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

Типичные сценарии, которые встречаются регулярно:

• «Комп стал тормозить, я его переустановил». Сисадмин или сам сотрудник переустанавливает ОС, не зная, что на машине настроен обмен с маркировкой. Служба исчезает вместе с конфигурацией, сертификатами и накопленной очередью документов.
• Сотрудник увольняется, компьютер передают другому. Новый пользователь получает машину под свои задачи — про фоновый сервис интеграции ему никто не сказал, потому что она не была задокументирована как отдельная система.
• Плановая замена парка техники. Если единственным источником знания о настройках была голова конкретного специалиста, при замене техники интеграция обнаруживается только тогда, когда перестают проходить продажи.
• Сертификат теряется вместе с профилем пользователя. Если сертификат для подписи документов привязан к профилю Windows конкретного человека, при переустановке или смене учётки он может пропасть без предупреждения — обмен начинает падать с ошибками авторизации.

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

Риск третий: один компьютер — одна точка отказа без всякого резервирования

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

Что это означает практически:

• Аппаратный отказ останавливает обмен полностью. Сгоревший блок питания, вышедший из строя диск, залитая кофе клавиатура с материнской платой — любая бытовая поломка одновременно означает полную остановку интеграции, без запасного узла, на который можно переключиться.
• Нет UPS. Офисные компьютеры обычно не запитаны через источник бесперебойного питания — скачок или отключение электричества, которое для сервера означает штатный переход на резерв, для рабочей станции означает мгновенное выключение и потерю состояния очереди.
• Нет процедуры восстановления. Если интеграция настраивалась вручную несколько лет назад и с тех пор никто не трогал, при отказе машины восстановление превращается в археологию — вместо того чтобы поднять сервис из бэкапа конфигурации за считаные минуты.

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

Риск четвёртый: диагностика проблем вслепую и без доступа

Когда обмен с маркировкой не работает и надо разбираться, первое, что требуется — доступ к машине, на которой крутится сервис, и её логам. На выделенном сервере это тривиально: SSH или RDP-доступ, который работает независимо от того, где физически находится администратор и включен ли чей-то личный компьютер в офисе.

На рабочем компьютере сотрудника всё сложнее сразу по нескольким причинам:

• Компьютер может быть выключен или занят человеком, который решает свои рабочие задачи, и удалённое подключение к нему для диагностики мешает или требует согласования — в отличие от сервера, который создан именно для того, чтобы к нему подключались в любой момент.
• Удалённый доступ часто не настроен вовсе. Разворачивать RDP или SSH на рабочей станции постфактум, в момент, когда уже что-то сломалось, — плохой момент для этого учиться.
• Нет истории и мониторинга. На сервере логично настроить сбор логов и алерт при простое — на рабочей станции такое почти никогда не делают, и о проблеме узнают от кассира, у которого не пробивается товар.
• Диагностика конфликтует с обычной эксплуатацией. Антивирус, синхронизация файлов, обновления офисных приложений создают шум, из-за которого сложнее понять, в сервисе ли интеграции проблема или в чём-то ещё на той же машине.

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

Практическая альтернатива: выделенный сервер под интеграцию

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

• Небольшой VPS или выделенный сервер, на который переносится модуль интеграции — отдельно от рабочих компьютеров сотрудников. Для точки с несколькими кассами обычно достаточно скромной конфигурации: одно ядро CPU и пара гигабайт памяти, если сервис не делит ресурсы с тяжёлой учётной системой. Для сети из нескольких точек правильнее закладывать более мощный узел с запасом.
• Сервис как systemd-юнит с автозапуском и автоперезапуском, а не как приложение, которое кто-то должен вручную запускать после перезагрузки:

[Unit]
Description=Marking integration service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/marking-integration/daemon
Restart=always
RestartSec=5
User=marking-svc

[Install]
WantedBy=multi-user.target

• Постоянная доступность вместо графика конкретного человека. Сервер не выключают на ночь и выходные, не уносят домой, не переустанавливают между делом «раз затормозил». Его жизненный цикл управляется осознанно — плановые окна обслуживания согласуются заранее, а не происходят стихийно.
• Резервное питание и сетевая избыточность на уровне дата-центра — это уже забота хостинг-провайдера, а не офисного электрика. Скачки напряжения, локальные перебои с интернетом в конкретном здании — всё это перестаёт быть риском для сервиса обмена с маркировкой.
• Резервный канал связи до оператора ЭДО, отдельный от офисного интернета — второй провайдер или LTE-модем как fallback, если через сервер идёт обязательная по закону отправка документов.
• Мониторинг доступности сервиса с алертом, а не узнавание о простое от кассира. Простой периодический пинг эндпоинта или проверка, что процесс жив и очередь не растёт бесконтрольно, ловит проблему за минуты, а не за часы.
• Документированная процедура доступа и восстановления, не завязанная на память одного специалиста — данные для подключения, расположение конфигурации и сертификатов, порядок действий при переносе на новый сервер должны быть записаны, а не жить только в голове того, кто это когда-то настраивал.

Таблица ниже сводит разницу подходов по ключевым параметрам:

Оговорка: перенос на сервер не гарантирует нулевого простоя — сбои у оператора ЭДО или самой системы маркировки всё равно случаются и не зависят от того, где стоит ваш сервис. Речь о том, чтобы убрать из уравнения риски, которые вы полностью контролируете и которые к самой маркировке отношения не имеют — выключенный на ночь компьютер или переустановку системы кем-то, кто не знал, что на этой машине что-то критичное работает.

Похожий переход — от «поставили на рабочую станцию, потому что было проще» к «вынесли на сервер, потому что цена простоя оказалась выше цены аренды» — на конкретном примере розницы разобран в статье ЕГАИС и Честный знак: сервер, которому нельзя падать.

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