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

Если у мобильных сотрудников по всей сети точек периодически «висит» загрузка отчётов из 1С, ищите проблему не только на сервере — часто дело в конкретной точке связи: слабом сигнале LTE, разрыве VPN-туннеля или перегруженном роутере на месте. Решение — модуль диагностики сети внутри самого приложения, который фиксирует, где именно рвётся соединение, а не гадает по звонкам от продавцов.

📱 Звонок в девять утра: «ничего не грузится»

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

Первая неделя: чинили роутер, тормозило приложение

Первая версия объяснения выглядела логично: раз жалуются разные точки в разные дни, значит дело либо в самом приложении, либо в сервере 1С. Перезагрузили роутер на точке, откуда пришла первая жалоба, — на следующий день сообщение пришло снова оттуда же. Переустановили приложение на телефонах трёх продавцов — не помогло. Проверили нагрузку сервера 1С в моменты жалоб: процессор загружен на треть, память в норме, тест Гилёва gilev.ru/tpc не выявил узких мест на стороне базы. Тогда решили, что дело в мобильном интернете, и здесь уткнулись в стену: у оператора связи нет инструмента, который показал бы, что происходило с конкретной SIM-картой в конкретную минуту на конкретной точке. Оператор видит агрегированную статистику по базовой станции, а не историю одного устройства.

Пробовали и более очевидный путь — поставить в офисе программу мониторинга сети, которая раз в минуту пингует несколько внешних адресов и записывает график. Она действительно ловит проблемы с офисным интернетом, но точки магазинов физически не подключены к этому каналу: у продавца на телефоне отдельная SIM-карта, отдельный оператор, отдельный маршрут до сервера 1С. График из офиса показывал ровную линию, пока на другом конце города у конкретного телефона пакеты терялись один за другим.

Что мы теряли, пока искали не там

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

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

🔧 Модуль диагностики внутри приложения: как построили

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

Что именно измеряет модуль

Список метрик получился короче, чем предполагали на старте обсуждения: уровень сигнала сотовой сети в dBm, тип активного подключения — LTE, 3G или Wi-Fi точки, время ответа сервера 1С на тестовый запрос, статус VPN-туннеля и доля потерянных пакетов при обмене с сервером. Всё это упаковывается в отчёт на несколько строк и прикладывается к обращению в поддержку автоматически: продавцу не нужно ничего измерять руками, он нажимает кнопку «пожаловаться», и отчёт с цифрами уходит вместе с сообщением. Раньше на этом месте в переписке было одно предложение — «ничего не грузится», теперь к нему прикладывается техническая картина конкретной минуты на конкретном телефоне.

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

Первые две недели данных

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

Отдельно всплыла точка, где сигнал LTE стабильно проседал каждый день с 12:00 до 13:00 — рядом с магазином неделей раньше началась стройка, и техника на площадке глушила сигнал соседней базовой станции оператора. Без отчёта из приложения на это совпадение по времени никто бы не обратил внимание неделями, а жалобы продолжали бы списывать на «глючное приложение».

Что изменилось: поддержка вместо угадывания

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

Тот же подход работает не только для сети магазинов: курьерская служба, выездные монтажники, торговые представители — везде, где мобильное приложение общается с 1С не по офисному Wi-Fi, а через сотовую сеть в произвольной точке города, разрыв связи выглядит одинаково — как молчаливое «ничего не грузится», за которым может стоять сервер, VPN, роутер или просто стройка у соседнего подъезда.

Для сети из полутора-двух десятков точек с мобильными сотрудниками, завязанными на 1С, это тот случай, когда диагностика окупает себя без сложных расчётов — достаточно сравнить время на разбор одного обращения до и после. Если приложение для точек продаж или склада уже работает или только планируется, модуль диагностики логичнее закладывать сразу в архитектуру, а не пристраивать потом — это тот же принцип, что при разработке B2B-приложения с 1С для распределённой сети точек. Отдельно стоит сверяться с системными требованиями 1С к сети: если задержка VPN стабильно выше того, что 1С считает приемлемым, чинить нужно канал, а не приложение. Стоимость разработки мобильного приложения с модулем диагностики в составе начинается от 500 000 рублей, точную оценку даёт аудит текущей интеграции с 1С — актуальные условия смотрите в тарифах.

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

Почему сервер 1С показывает норму, а сотрудники всё равно жалуются, что ничего не грузится?

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

Сколько стоит добавить модуль диагностики сети в мобильное приложение для 1С?

Зависит от того, как приложение уже подключено к 1С и какие метрики нужно собирать. Разработка мобильного приложения с таким модулем в составе начинается от 500 000 рублей, точную стоимость считают после аудита текущей интеграции и списка нужных метрик.

Можно ли обойтись без отдельного приложения и найти причину через сам 1С?

Частично: тест Гилёва и системные требования 1С покажут проблемы на сервере и в локальной сети офиса. Но они не видят, что происходит на удалённой точке с мобильным интернетом, поэтому для сети точек нужен модуль внутри самого мобильного приложения на телефоне сотрудника.

Что именно фиксирует модуль диагностики в приложении в момент сбоя?

Уровень сигнала сотовой сети, тип подключения — LTE или Wi-Fi, время ответа сервера 1С, статус VPN-туннеля и потерю пакетов. Данные попадают в короткий отчёт, который сотрудник прикладывает к обращению в поддержку вместо общей фразы «ничего не грузится».

Есть ли риск, что модуль диагностики соберёт лишние данные о сотруднике?

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