Бухгалтер на аутсорсе ведёт 30 фирм: 1С и базы на своём сервере

MAATRIX

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

Почему одна машина на тридцать клиентов — это риск, а не удобство

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

Дело не в том, что стало "больше работы". Дело в том, что у всех клиентов теперь общая точка отказа — ваш компьютер. Слетела Windows, отказал SSD, ноутбук залили кофе, украли сумку в поезде — и под ударом не одна база, а все тридцать одновременно. Для клиента, у которого горит отчётность или требование от налоговой, аргумент "у меня комп сломался" звучит одинаково плохо независимо от того, была у вас одна база или тридцать. Просто при тридцати вероятность, что именно на этой неделе что-то случится хотя бы с одной срочной задачей, гораздо выше.

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

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

Сервер вместо личного компьютера: что меняется по сути

Идея простая: вместо того чтобы держать все информационные базы на диске личной машины, вы размещаете их на отдельном сервере — арендованном VPS или выделенном сервере, который работает 24/7 в дата-центре, а не в сумке рядом с кофе. Ваш компьютер (и компьютеры помощников) при этом превращаются в терминалы для подключения к серверу — либо через терминальный доступ (RDP-сессия, где 1С физически работает на сервере, а вы видите только экран), либо через клиент-серверный режим 1С, где базы данных лежат на сервере, а толстый или тонкий клиент подключается к ним по сети.

Что это даёт на практике:

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

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

Какой сервер нужен: локация, характеристики, режим работы 1С

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

Второе решение — какой режим работы 1С вы выбираете:

• Файловый режим на сервере через RDP. Самый простой путь миграции: базы физически лежат на сервере, вы подключаетесь по RDP (удалённый рабочий стол), а 1С в файловом режиме работает локально относительно самого сервера — то есть быстро, без задержек по сети между клиентом и базой. Это решение хорошо масштабируется на несколько пользователей, но требует правильно настроенного терминального доступа с раздельными учётками.
• Клиент-серверный режим (1С:Предприятие в связке с SQL Server или PostgreSQL). Более "правильный" с точки зрения архитектуры вариант для действительно большого числа баз и параллельных пользователей — но и более требовательный к настройке: нужен сервер 1С:Предприятия, СУБД, лицензии на сервер приложений. Для тридцати файловых баз одного бухгалтера с парой помощников это часто избыточно; такой режим больше оправдан, когда одна база растёт и её файловый режим уже не тянет нагрузку.

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

По конфигурации сервера точную цифру дать без ваших реальных данных нельзя — многое зависит от объёма баз (файловая база маленького ООО может весить сотни мегабайт, база компании с большим документооборотом — уже несколько гигабайт), числа одновременных пользователей и того, насколько интенсивно вы формируете тяжёлые отчёты. Как самый общий ориентир для тридцати файловых баз с одним-тремя одновременными пользователями обычно рассматривают конфигурации порядка 4-8 vCPU и 16-32 ГБ оперативной памяти — но это именно ориентир для старта, а не расчёт под ваш случай: конкретную конфигурацию стоит подбирать по факту после переноса первых баз и наблюдения за нагрузкой, с возможностью нарастить ресурсы, если станет тесно. Отдельно закладывайте место под диск — базы плюс их резервные копии за разумный срок хранения съедают больше места, чем кажется на первый взгляд. Подробнее про подбор конфигурации под 1С — в обзоре лучших VPS для 1С в России.

Перенос баз: как это делается технически

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

Порядок действий на верхнем уровне выглядит так:

1. Подготовка сервера. Устанавливаете операционную систему (для файлового режима через RDP чаще всего это Windows Server — терминальный доступ на нём настраивается штатными средствами), настраиваете терминальные службы, ставите платформу 1С:Предприятие той же или совместимой версии, что используется сейчас.
2. Тестовый перенос одной базы. Не переносите сразу все тридцать — возьмите одну некритичную базу, скопируйте её каталог (или выгрузите в .dt и загрузите на сервере), подключитесь через RDP, проверьте, что база открывается, отчёты формируются, документы проводятся штатно. Это покажет проблемы конфигурации до того, как от них будут зависеть все клиенты разом.
3. Перенос остальных баз батчами. После успешного теста переносите базы группами, желательно в нерабочее время. У каждой базы стоит заодно проверить список пользователей и права доступа — удобный момент навести порядок, если за годы накопились лишние учётки.
4. Настройка списка баз для быстрого подключения. В 1С есть список информационных баз — настройте его так, чтобы вы и помощники видели понятные названия клиентов, а не путались в путях к файлам.
5. Проверка лицензий. Лицензирование 1С привязано к конкретным правилам платформы — свяжитесь с условиями вашей лицензии (клиентские, серверные при клиент-серверном режиме, лицензии на терминальный доступ Windows при нескольких пользователях через RDP), чтобы не нарушить условия из-за смены схемы работы.
6. Отключение старых копий с локального компьютера. После того как всё заработало на сервере и есть надёжный бэкап, старые локальные копии баз стоит архивировать отдельно и убрать с рабочего компьютера, либо удалить.

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

Совместный доступ: помощники, права и разграничение

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

На сервере эта задача решается штатными средствами:

• Отдельная учётная запись на каждого сотрудника. В терминальных службах Windows Server вы создаёте пользователя для каждого помощника с собственным паролем и настраиваете, к каким базам 1С у него есть доступ на уровне списка баз и прав внутри самой 1С.
• Права внутри 1С по ролям. Помимо доступа к самой базе, в 1С настраиваются роли — можно дать помощнику право вести первичку по конкретным клиентам, не открывая доступ к формированию отчётности или к банковским операциям, если это не входит в его задачи.
• Многопользовательский терминальный доступ требует отдельного лицензирования. Если планируете, что несколько человек будут одновременно подключаться к серверу через RDP, учтите: штатная Windows позволяет только одно активное удалённое подключение без специального лицензирования терминального доступа (RDS CAL). Для двух и более одновременных пользователей это нужно настроить и оплатить отдельно — про то, как это устроено и сколько стоит по факту, подробно разобрано в статье про лицензирование при нескольких пользователях RDP на Windows Server.
• Журнал того, кто и когда заходил. В отличие от локального компьютера, где сложно понять, кто и когда правил документ, на сервере с раздельными учётками у вас появляется реальная возможность отследить историю изменений — что полезно и для внутреннего контроля, и в случае вопроса от клиента "кто провёл эту накладную".

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

Резервное копирование: что должно происходить само, без вашего участия

Перенос на сервер снимает риск "уронил ноутбук", но создаёт новый вопрос: а что, если сломается сам сервер? Ответ один — регулярное автоматическое резервное копирование, настроенное так, чтобы вам не нужно было о нём помнить.

Минимальная разумная схема для бухгалтера на аутсорсе выглядит так:

• Ежедневное автоматическое копирование всех баз по расписанию — ночью, когда никто не работает.
• Хранение нескольких последних копий, а не только самой свежей — если проблема в данных обнаружится не сразу, нужна возможность откатиться дальше, чем на вчера.
• Копия за пределами самого сервера — если бэкапы лежат на том же диске, что и рабочие базы, при отказе диска вы теряете и то, и другое разом. Копии стоит выгружать на отдельное хранилище или в другой дата-центр.
• Периодическая проверка, что бэкап реально восстанавливается. Частая ошибка — настроить копирование один раз и никогда не проверять, что из архива можно поднять рабочую базу. Раз в квартал стоит попробовать восстановить одну базу в тестовое окружение.

Технически для баз 1С в файловом режиме резервное копирование сводится к копированию каталога базы (или созданию .dt-выгрузки) по расписанию; для клиент-серверного режима на PostgreSQL или MS SQL используются штатные средства резервного копирования СУБД. Пошаговая настройка процесса разобрана в статье про установку резервного копирования баз данных на VPS — она не заточена конкретно под 1С, но принцип регулярного автоматизированного бэкапа применим напрямую.

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

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