Ми у GMhost ставимо сервери під BAS, M.E.Doc, Вчасно та IT-Enterprise клієнтам мало не щотижня. Конфігурацію підбираємо за кількістю бухгалтерів і характером навантаження, а не за маркетинговими тарифами «преміум / бізнес». У цьому гайді розберемо, як це зробити самостійно — або принаймні зрозуміти контекст, перш ніж замовляти.
Чому офісний комп — це лотерея
Типова картина: BAS живе на старенькому HP ProDesk у кутку серверної. Працює років п'ять, ніхто не пам'ятає, де лежить пароль адміна. Під закриття місяця десять бухгалтерок одночасно формують звіти, диск повзе по нулях, BAS зависає на півгодини. Якщо у цей самий день вилітає блок живлення — далі тиждень переходу на резерв і ризик втратити день роботи.
Сервер у дата-центрі вирішує одразу кілька проблем: окреме обладнання з ECC-пам'яттю і резервним живленням, регулярний контрольований бекап, локація в Україні з правильним юридичним статусом обробки персональних даних платників.
Що насправді треба BAS
BAS — форк 1С Підприємства, тому профіль навантаження схожий: багато дрібних транзакцій до бази даних, CPU-bound на перерахунках (закриття, консолідація, зведені звіти), чутливий до затримок диску. Плюс одночасна робота десятків користувачів через RDP — потрібні ядра і RAM із запасом.
Конфіги, які ми ставимо у наших ДЦ:
Команда | CPU | RAM | Диск |
|---|---|---|---|
5-10 бухгалтерів | 2 × Intel Xeon Gold 6138 (20 ядер) | 64 GB DDR4 ECC | NVMe 1 TB |
15-30 бухгалтерів | 2 × Intel Xeon Gold 6230 (Cascade Lake, 20 ядер) | 128 GB DDR4 ECC | NVMe 2×1 TB у дзеркалі |
50+ з важкими звітами | 2 × Xeon Platinum 8163 (48 ядер сумарно) | 256 GB DDR4 ECC | NVMe RAID-10 |
BAS любить RAM більше, ніж очікують замовники. MS SQL (або PostgreSQL у нових релізах) кешує робочі таблиці — дайте йому 128 GB, і закриття місяця з 40 хвилин перетворюється на 7. RAM окупається за один цикл звітності.
NVMe замість SATA SSD — критично для random IOPS. На SATA SSD теж працює, але закриття буде у півтора-два рази повільніше. ECC-пам'ять — обов'язкова: бухгалтерська база, яка отримала single-bit error у пам'яті і записала його на диск, виявляється не одразу, а відновлення з бекапу за два тижні може коштувати днів роботи.
M.E.Doc, Вчасно, IT-Enterprise — на одному сервері з BAS?
Так, цілком нормальний сценарій. M.E.Doc легший — йому вистачить 2-4 GB RAM і пари ядер, Вчасно та IT-Enterprise приблизно те саме. Коли все стоїть на одному сервері, головне — закласти запас RAM з урахуванням, що під час пікових перерахунків BAS може забрати майже все. Окремо тримати їх варто тільки коли у вас 50+ користувачів і важкий модуль M.E.Doc-агрегатора, який молотить ЕЦП по 8 годин на день.
RDP-термінальний сервер — стандартна архітектура
Більшість клієнтів хочуть одне: бухгалтерки заходять через віддалений робочий стіл, не тягають локальні копії бази, працюють у спільному середовищі. Це термінальний сервер — Windows Server з ліцензіями CAL на кожного користувача, профілі винесені на окремий диск, доступ через корпоративний VPN.
Кілька деталей, які часто пропускають:
-Ліцензії Windows Server + CAL — офіційно, через Volume Licensing у партнера. Ніяких «тимчасових ключів активації»: податкова перевірка з претензією до неліцензійного ПЗ виглядає невесело.
-Корпоративний VPN до сервера — щоб RDP не висів у відкритому інтернеті. WireGuard на тому самому сервері або окремий VPS-вузол. Захищає від брутфорсу і L7-атак.
-Профілі користувачів — на окремому диску від системного. Полегшує бекапи, прискорює вхід.
Український ДЦ — обов'язково чи бажано?
Усі сервери для бухгалтерського стеку у нас стоять в українських ДЦ GMhost. Це важливо не з патріотичних міркувань, а з трьох цілком практичних:
-Дані платника податків — в Україні. Менше питань від контролюючих, простіше відповідати на запити Держслужби із захисту персональних даних.
-Латентність. З Києва до нашого ДЦ — 2-5 мс, зі Львова — 4-6 мс. У європейському ДЦ було б 30-50 мс — і ви це помітите на кожному кліку у RDP-сесії.
-Підтримка українською у робочий день. Інженер на дзвінку розуміє контекст «у нас закриття, BAS виліз за дозволену пам'ять» без перекладу.
Резервне копіювання — те, про що думають коли вже пізно
Стандартна схема, яку ми ставимо:
-Щоденний автоматичний бекап BAS-папок + SQL-дамп.
-Версіонування 14-30 днів — можна відновити документ за минулу п'ятницю, якщо бухгалтер випадково його видалив.
-Off-site копія в інший наш ДЦ (Естонія / Німеччина / Португалія) — щоб втрата майданчика не означала втрату даних.
-Перевірка відновлення раз на квартал — на реальній копії, не «на око».
Як ми переходимо з офісного компа на сервер у ДЦ
Стандартна процедура без даунтайму:
- Підготовка. Ставимо сервер, налаштовуємо Windows Server, ліцензії, профілі, спільний доступ — 1-2 робочі дні.
- Тестова міграція. Копіюємо актуальний BAS-дамп і базу, піднімаємо паралельну робочу копію. Один-два бухгалтери тестують паралельно з продуктивом.
- Переключення. У вихідний — фінальний дамп, перенос, перевірка контрольних звітів. У робочий день команда заходить уже на новий сервер.
- Підстраховка. Старий сервер залишається у read-only режимі ще тиждень — якщо щось не так, повертаємось швидко.
Загалом тиждень від «зателефонували» до повної робочої системи.
Скільки це коштує
Ціна залежить від кількості користувачів і запасу під майбутнє зростання. Орієнтовно:
-VPS під BAS на 5-10 бухгалтерів — від базового NVMe-тарифу.
-Dedicated сервер на 15-30 бухгалтерів — від стартового dedicated.
-Dedicated на 50+ з важкими звітами — від heavy-тарифу.
У всі тарифи входить ліцензія Windows Server + CAL, налаштування RDP, корпоративний VPN до сервера, щоденні бекапи з версіонуванням, off-site копія, моніторинг 24/7 і підтримка українською.
FAQ
Скільки часу займає міграція з офісного сервера?
Підготовка нового сервера — 1-2 години.
А якщо у нас все ще 1С, не BAS?
Працюємо. Допомагаємо мігрувати на BAS, якщо ви плануєте перехід; або хостимо існуючу 1С-конфігурацію, поки ви визначаєтесь. Обидва сценарії технічно близькі.
Можна без RDP, просто щоб клієнти підключалися до бази напряму?
Можна — варіант для тих, у кого є власний «товстий клієнт» BAS на робочих машинах. Тоді сервер віддає тільки SQL і файли, CAL-ліцензії на RDP не потрібні.
Хто буде адмініструвати?
Базове адміністрування — наша підтримка цілодобово. Бухгалтерські оновлення BAS і M.E.Doc — або ваш приходящий ITшник, або ми за окремим договором.
Чи є гарантія, що дані не пропадуть?
Триярусна схема (RAID + локальний бекап + off-site у інший ДЦ) і SLA 99,9% з компенсацією простою. Це той максимум, який реально пропонують серйозні провайдери.
Хочеш конфігурацію під вашу команду?
Напиши на [email protected] або в бот @gmhost_support_bot — поставимо запитання, подивимось вашу теперішню структуру і повернемось із пропозицією у той самий день. Якщо є цейтнот — мігруємо за одні вихідні.
