1С в медсети на 30+ филиалах: как не потерять контроль над базой

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

Симптом, с которого всё началось

В сентябре сеть из 34 клиник в Москве и области получила жалобу от главного врача: расписание приёма зависает у половины филиалов одновременно, примерно в 8:40, когда администраторы регистрируют первых пациентов. В IT-отделе — три человека на всю сеть, и у каждого свой список серверов, потому что филиалы открывались в разное время и оборудование закупалось разными подрядчиками.

Стали смотреть логи. Оказалось, что 12 филиалов работают на локальных мини-серверах возрастом четыре-пять лет, ещё 15 — через терминальный доступ к серверу в головном офисе, а оставшиеся семь — вообще на обычных офисных ПК с установленной 1С без выделенной серверной части. Три топологии одновременно, три разных набора проблем, и ни одного человека, который видел бы картину целиком.

Почему в медсети это не «ещё один ИТ-вопрос», а риск для пациентов

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

Цена бездействия здесь считается не в абстрактных «рисках», а в конкретных потерях. Простой регистратуры на 20 минут в филиале с потоком 40 пациентов в день — это минимум 10-15 сорванных или перенесённых записей. Умножьте на 30+ филиалов и на то, что зависания повторяются не раз в квартал, а еженедельно в пиковые часы. Отдельная статья расходов — время администраторов сети, которые вместо развития процессов тушат пожары на разрозненном железе.

Три варианта, которые рассматривала сеть

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

Как выглядел перенос по шагам

Инвентаризация и приоритизация

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

Расчёт мощности под пиковую нагрузку

Пиковая нагрузка — это не среднее число пользователей, а момент 8:30-9:00, когда одновременно подключаются регистратуры всех филиалов плюс врачи открывают карты пациентов. Для сети на 30+ баз и суммарно около 200 одновременных сессий подобрали выделенный сервер в аренду с запасом по ядрам и оперативной памяти, а не по минимальным системным требованиям 1С — иначе тот же затор просто переехал бы с локального железа на арендованное.

Перенос по волнам, не одним махом

Переносили не все 34 базы разом, а группами по 5-6 филиалов за выходные, с полным откатом на случай проблем. Это заняло полтора месяца вместо теоретических двух недель, зато ни один филиал не остался без 1С в рабочий день.

Настройка терминального доступа и разграничение прав

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

Обучение администраторов и мониторинг первых недель

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

Что изменилось для головного офиса

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

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

Сколько это стоит и когда окупается

Базовая аренда сервера 1С у UKVED начинается от 1 100 ₽/мес за пользователя за площадку; для сети на 30+ баз конфигурация под пиковую нагрузку считается индивидуально, исходя из числа одновременных сессий и объёма данных. Сопровождение и разовые работы по настройке — 3800 руб/час: перенос 34 баз с разбивкой по волнам занял штат из двух специалистов на полтора месяца, что для сети оказалось дешевле одного нового сервера с резервированием в головном офисе, который пришлось бы обслуживать своими силами следующие пять лет.

Окупаемость здесь считается не через абстрактный ROI, а через простой вопрос: сколько стоит час простоя регистратуры в 30 филиалах одновременно против ежемесячного платежа за инфраструктуру, которая не падает по частям.

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

Можно ли переносить базы филиалов на арендованный сервер по частям, а не всю сеть сразу?

Да, и это безопаснее: перенос волнами по 5-6 филиалов за выходные с возможностью отката снижает риск простоя в рабочий день. Полный перенос сети на 30+ баз занимает обычно полтора-два месяца.

Что произойдёт с работой филиалов, если откажет арендованный сервер?

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

Как настроить доступ, чтобы один филиал не видел данные другого?

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

Сколько стоит сопровождение сети из 30+ баз 1С на арендованном сервере?

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

Стоит ли переходить на 1С:ERP при таком масштабе сети?

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