Обслуживание сети из 50 объектов: почему это не 50 отдельных проектов

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

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

Симптомы «50 проектов вместо одной сети»

Их легко проверить. Если ответ «да» хотя бы на три — у вас именно эта ситуация:

• На каждом объекте сидит свой подрядчик или «знающий человек», и никто не знает, кто настраивал маршрутизатор в точке номер 17.
• Открытие новой точки занимает 3–6 недель не из-за стен и оборудования, а из-за «настройки ИТ под новое место».
• Когда нужно поменять пароль администратора — это занимает не день, а спринт. И всё равно где-то остаётся старый.
• Инциденты случаются «вдруг»: о падении кассы или сети узнаёт не админ, а кассир, который позвонил в офис.
• Бэкапы есть, но никто не помнит, когда последний раз восстановление проверяли. На большинстве точек — никогда.
• Лицензии и оборудование закупаются повторно, потому что никто не отслеживает, что куда уехало при закрытии прошлой точки.
• Аудитор или служба безопасности задаёт вопрос про политики доступа — ответа нет.

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

Почему «50 проектов» рассыпается на масштабе

Дело не в количестве. Дело в трёх системных эффектах, которые проявляются именно после 15–20 точек.

1. Конфигурационный дрейф

Десять точек, открытых в разное время разными людьми, — это десять немного разных конфигураций. На одиннадцатой инженер уже не помнит, как было «правильно», и копирует с той, к которой ближе. Через два года вы имеете 50 уникальных снежинок: похожих, но не идентичных. Любая массовая операция — обновление антивируса, замена сертификата, ротация ключей VPN — становится отдельным микропроектом на каждой точке.

2. Отсутствие наблюдаемости

50 разрозненных объектов — это 50 чёрных ящиков. Вы не знаете, что у них внутри происходит, пока что-то не сломается до уровня жалобы пользователя. Без централизованного мониторинга невозможно увидеть тренды: что диск на точке 23 заполняется быстрее обычного, что VPN на точке 41 раз в неделю «моргает», что ИБП в точке 7 переходит на батарею каждый вторник в 14:00.

3. Размытая ответственность

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

Что должно жить в центре, а не на точке

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

В центре — без вариантов

• Учётные записи и права доступа. Один источник истины (Active Directory, Microsoft Entra ID или их аналог). Сотрудник уволился — отозвали один раз, и доступы пропали везде. Отдельные локальные администраторы на каждой точке — главный источник «вечных» учёток уволенных людей.
• Мониторинг и алертинг. Один Zabbix / Grafana / Prometheus, который видит каждую точку. Алерты не в чате с кассиром, а в дежурную смену.
• Резервное копирование и план восстановления. Бэкапы должны делаться по одной политике и складываться в одно проверяемое место. Восстановление — отрабатываться по графику, а не «когда сломается».
• Конфигурационные шаблоны. Образ рабочей станции, базовая настройка маршрутизатора, GPO, политика антивируса — всё это шаблонами, не «как помню».
• Логирование и аудит. Логи всех точек собираются в одно место. Без этого расследовать инцидент в точке 34, случившийся три недели назад, невозможно.
• Управление парком устройств. Один MDM / SCCM, который знает, где какой ноутбук, кто на нём работает, какие обновления установлены.
• Сетевые политики. Wi-Fi-контроллер, VPN-концентратор, межсетевые экраны управляются централизованно — иначе при инциденте безопасности вы будете правки катить руками 50 раз.

Локально — только то, что обязано работать в офлайне

• Кэш POS и торгового софта, чтобы можно было пробивать чеки при обрыве связи.
• Локальный DHCP/DNS — точка не должна вставать из-за того, что упал канал в офис.
• Видеорегистратор — пишет локально, метаданные и нарезки уезжают наверх.
• Резервный канал связи (LTE/4G) с автопереключением.

Как переехать со «100 проектов» на «одну сеть» без остановки бизнеса

Это не «переписать всё с нуля». Это поэтапный переход, обычно 4–9 месяцев на парк из 50 точек, в зависимости от состояния «как есть».

1. Инвентаризация. Прежде чем централизовывать — нужно знать, что у вас есть. Каждое устройство, каждый канал, каждая лицензия, каждый локальный «знающий человек». Это 2–4 недели полевой работы на 50 точек.
2. Выбор и поднятие центрального ядра. AD/Entra, мониторинг, бэкап-сервер, MDM, VPN-концентратор. Параллельно с эксплуатацией старого.
3. Эталонная конфигурация одной точки. Пилот на 1–2 точках: новый образ рабочих станций, новая сеть, подключение к центральному мониторингу и бэкапу. На пилоте отлаживаются 90% будущих проблем.
4. Миграция волнами. 5 точек в неделю — реалистичный темп. После каждой волны — короткий ретроспектив и правки эталона.
5. Декомиссия старого. Самый забываемый шаг. Старые VPN, старые учётки, старые арендованные сервисы выключаются, иначе они будут жить ещё годы и платить за них тоже будете годы.

Что меняется в цифрах

На реальных проектах (анонимно — цифры из нашего опыта в сетях ритейла, общественного питания и логистических объектов) переход к централизованной модели обычно даёт:

• Открытие новой точки сокращается с 4–6 недель до 3–7 дней по части ИТ.
• Время реакции на инцидент сокращается с «когда заметит пользователь» до 5–15 минут (пришёл алерт — взяли в работу).
• Расходы на ИТ-сопровождение снижаются на 25–40% за счёт устранения дублирующихся подрядчиков и лицензий.
• Восстановление с бэкапа из «никогда не пробовали» превращается в «делаем учения раз в квартал».
• Аудит безопасности и соответствие требованиям (Закон РМ 133, GDPR для зарубежных клиентов) перестаёт быть авральным и становится плановым.

Чек-лист: проверить, как у вас сейчас

Распечатайте и пройдитесь по своему парку точек. Если на любой пункт ответ «нет» больше чем для 10% точек — у вас работает модель «50 проектов».

• На точке нет локальных администраторских учёток вне корпоративного каталога.
• Сотрудника увольняли в прошлом квартале — доступы по всем точкам отозваны автоматически.
• Я могу за один запрос увидеть состояние всех точек: какие онлайн, какие в бэкапе сегодня, у кого свободного места меньше 20%.
• Бэкап последней точки восстанавливался на тестовый стенд за последние 90 дней.
• Открытие 51-й точки занимает не больше 5 рабочих дней по части ИТ.
• Любую сетевую политику (например, блокировку домена) я могу применить ко всему парку за один день.
• Если ИТ-инцидент случается в нерабочее время в одной точке, об этом узнаёт дежурный в офисе, а не сменщик в этой точке.

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

А если у нас точки в разных юрисдикциях — например, Молдова и Румыния?

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

Не дороже ли поднимать своё ядро, чем оставить «как есть»?

На горизонте 6–12 месяцев — да, требуется инвестиция. На горизонте 2 лет централизованная модель почти всегда дешевле за счёт прекращения дублирующихся контрактов, ускоренного открытия точек и сокращения ИТ-инцидентов, доходящих до клиента.

А что с данными, которые по закону должны храниться внутри страны?

Архитектурно это решается выбором площадки для данных и разделением «control plane / data plane»: управление можно держать централизованно, а сами данные — на нужной территории. В Молдове это особенно актуально для Закона РМ № 195/2024 и работы с персональными данными.

Мы небольшие — у нас всего 12 точек. Нам это рано?

Симптомы появляются примерно с 15–20 объектов. Но если вы планируете рост — закладывать модель «как сеть» дешевле всего на этапе 8–15 точек, пока это ещё реверсируется без больших миграций.