Инфраструктура для CRM/ERP: сервер в офисе или размещение в ЦОД

С чего начинается выбор: что вы на самом деле сравниваете

Вы выбираете не просто место, где будет стоять «железо». Вы выбираете, как CRM/ERP будет работать каждый день: насколько часто будут сбои, как быстро система восстановится, кто отвечает за безопасность и во сколько все это обойдется на практике.

Когда говорят «сервер в офисе или ЦОД», обычно сравнивают три подхода:

• Сервер в офисе (в серверной или даже в отдельном кабинете).
• Размещение серверов в ЦОД (колокация): ваше оборудование, но площадка и инженерия дата-центра.
• Гибрид: часть систем в офисе, часть в ЦОД (например, база и резервные копии в ЦОД, а локальные сервисы - на месте).

Одна и та же CRM/ERP может быть «нормальной» в офисе и «отличной» в ЦОД, или наоборот. Часто дело не в самой программе, а в простых вещах: питание, охлаждение, связь, физический доступ к оборудованию и то, кто дежурит ночью, если что-то сломалось.

До сравнения цен стоит прояснить базовые требования. Они быстро отсекают неподходящие варианты:

• Сколько пользователей работает одновременно и есть ли пики (утро, конец месяца, сезон).
• Есть ли филиалы, удаленные сотрудники и мобильный доступ, где они находятся.
• Что для вас считается простоем: 10 минут терпимо или уже критично.
• Какие данные хранятся в системе (персональные, финансовые, медицинские) и какие требования по безопасности.
• Кто будет отвечать за инциденты и как быстро люди могут физически добраться до сервера.

Пример: головной офис в Алматы и два филиала в регионах. Если CRM «тормозит» из филиалов, проблема часто не в сервере, а в связи и маршрутизации. Тогда перенос оборудования в ЦОД ближе к магистральным узлам может дать заметный эффект, даже без замены самого сервера.

Если вы планируете закупку серверов или рабочих станций, обсудите не только характеристики, но и сценарий эксплуатации: где будет стоять оборудование, кто обслуживает, как восстанавливает после аварий. У интеграторов и производителей уровня GSE.kz такие вопросы обычно входят в предпроектное обследование.

Минимальные требования CRM/ERP простыми словами

Чтобы спорить о площадке, нужно сначала понять, что системе нужно каждый день. Требования зависят не от названия CRM/ERP, а от нагрузки, объема данных и внутренних правил.

Что важно уточнить в цифрах

Начните с пользователей: сколько людей работает одновременно и когда бывают пики (закрытие месяца, массовые отчеты, начисления, инвентаризация). В такие дни нагрузка легко вырастает в 2-3 раза, и это влияет на процессор и память.

Дальше - база данных: текущий объем, скорость роста и ожидаемое время отклика (карточки, отчеты, поиск). Часто «тормоза» упираются в хранение: для CRM/ERP обычно важнее быстрые накопители и грамотная конфигурация дисков, чем максимально мощный процессор.

Интеграции добавляют фоновые задачи и риски: телефония, почта, 1С, BI-отчеты, обмен с гос-сервисами или ЭДО. Уточните, что должно работать в реальном времени, а что может обновляться по расписанию.

И еще один вопрос, который решает многое: сколько простоя допустимо. Если 2-3 часа остановки в месяц приемлемы - это один уровень. Если нельзя терять даже 30 минут в рабочее время - нужен другой уровень резервирования и восстановления.

Перед выбором площадки зафиксируйте хотя бы это:

• число одновременных пользователей и характер пиков;
• объем базы сейчас и прогноз роста на 12-24 месяца;
• критичные интеграции и допустимые окна обслуживания;
• допустимый простой и потери данных при сбое (RTO/RPO);
• правила компании: где можно хранить данные, нужен ли аудит и кто утверждает регламенты.

Небольшой пример

Компания на 60 сотрудников использует CRM и учет. В обычный день одновременно работает 25-30 человек, а в конце месяца - 50, и все строят отчеты. База выросла до 400 ГБ и прибавляет по 30-40 ГБ в месяц. Параллельно идут интеграции с телефонией и обменом документами.

В такой ситуации «средний» сервер может справляться в спокойные дни, но на пиках система начнет тормозить, а любой сбой дисков или сети сразу остановит работу продаж и бухгалтерии. Поэтому требования лучше записать заранее, а уже потом сравнивать офисный сервер и ЦОД.

Вариант 1: сервер в офисе - реальные расходы и ограничения

Офисный сервер выглядит простым решением: поставили, подключили, и CRM/ERP работает. Но фактически вы берете на себя всю среду вокруг него: питание, охлаждение, хранение, резервные копии и поддержку.

Из чего складываются затраты

Разовая покупка сервера - только начало. Чтобы система не падала и данные не терялись, обычно нужны:

• быстрые диски/контроллеры или система хранения под базу данных;
• резервные копии (отдельный носитель/второй сервер и место для хранения);
• лицензии и обновления (ОС, СУБД, средства резервного копирования);
• ИБП и базовая электрика (защита от скачков и корректное выключение);
• кондиционирование и нормальная вентиляция помещения.

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

Плюсы офисного сервера

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

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

Ограничения и риски

Самые частые слабые места - электричество и интернет. Один скачок напряжения может повредить диски, а несколько часов без связи превращают CRM в «неработающий телефон». Настоящая отказоустойчивость тоже сложнее, чем кажется: резервировать нужно не только сервер, но и сеть, питание, место для бэкапов и сам процесс восстановления.

Пример: в офисе на 30 человек CRM работает на одном сервере. После отключения света база поднимается, но часть данных повреждена, а последний рабочий бэкап сделан неделю назад. Сервер физически на месте, но бизнес теряет время и доверие.

Офисный сервер обычно подходит, если:

• офис небольшой и нет жесткого требования 24/7;
• простои на несколько часов допустимы и есть понятный план на этот случай;
• есть внутренняя ИТ-команда, которая отвечает за бэкапы и восстановление;
• условия в офисе позволяют обеспечить питание и охлаждение хотя бы на базовом уровне.

Если вы выбираете этот путь, заранее закрепите, кто отвечает за резервные копии, тест восстановления и реагирование при инцидентах. Это экономит больше денег, чем любая «удачная покупка» сервера.

Вариант 2: размещение в ЦОД - за что платите и что получаете

Размещение сервера в ЦОД часто воспринимают как «аренду места». На деле вы покупаете условия, которые трудно повторить в офисе: стабильное питание, охлаждение, физическую безопасность и регламент обслуживания. Для CRM/ERP это важно, потому что сбои чаще происходят из-за среды вокруг «железа», а не из-за самого сервера.

Обычно в базовый тариф входят место в стойке (юниты или стойка), выделенная мощность, климат-контроль и охрана доступа. Дальше начинаются детали, которые и формируют итоговый счет.

Чаще всего встречаются такие платежи:

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

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

Минусы тоже есть. Вы сильнее зависите от каналов связи: если проблемы у оператора или узкое место в сети, пользователи почувствуют «тормоза», даже если сервер в порядке. Доступ к оборудованию идет по правилам ЦОД: визиты и работы нужно согласовывать. И важно заранее определить границы ответственности: кто отвечает за сеть, кто за резервные копии, кто реагирует ночью.

ЦОД чаще подходит компаниям с филиалами, критичными продажами/обслуживанием и требованиями по доступности. Если CRM/ERP должна работать «всегда», ЦОД обычно ближе к этой цели, но только при нормально организованной связи и понятном распределении ролей.

Каналы связи: почему CRM может тормозить даже на хорошем сервере

Ощущение скорости CRM/ERP часто зависит не от мощности сервера, а от сети. Если есть филиалы, удаленка и мобильные сотрудники, система может работать отлично «в серверной», но задумываться на рабочих местах.

Типичная картина: в головном офисе все быстро, а в филиале открытие карточки клиента занимает 10-15 секунд. Причина может быть в задержке и потерях пакетов на маршруте, а не в самой CRM.

Что важно проверить в канале связи

Сделайте простые замеры в рабочее время, особенно в часы пик. Важна не только «скорость по тарифу», а качество соединения:

• задержка (ping) и ее стабильность;
• потери пакетов (даже 1-2% заметно портят работу форм и отчетов);
• качество связи вечером и в конце месяца;
• путь трафика (иногда провайдер ведет его длинным маршрутом);
• наличие основного и резервного интернета.

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

Если сервер в ЦОД, площадка обычно дает предсказуемую доступность внешних каналов, но офисам и филиалам все равно нужен качественный доступ до дата-центра. Иначе «узкое место» просто переместится на последнюю милю.

Базовый набор мер почти одинаковый: VPN для защищенного доступа, разделение прав, мониторинг доступности. Мониторинг нужен не «для галочки»: он помогает быстро доказать, что проблема в канале, а не в сервере.

Как прикинуть стоимость связи: офис vs ЦОД

Считайте не один тариф, а набор, который дает приемлемую надежность.

Для офиса обычно получается: бизнес-интернет + резервный канал (второй провайдер или LTE) + оборудование (роутер/firewall) + обслуживание.

Для ЦОД: связь офиса до ЦОД (часто два провайдера) + защита доступа (VPN/firewall) + возможные платежи за подключение/порт.

Для филиалов: либо отдельные каналы до офиса/ЦОД, либо схема прямого подключения к ЦОД, если так проще по стабильности.

На практике выигрывает тот вариант, где легче обеспечить стабильный доступ для всех пользователей, а не только для одного здания.

Доступность и восстановление: что должно быть кроме самого сервера

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

Питание и «железо»: где чаще всего ломается

Ответьте на простой вопрос: что произойдет, если пропадет электричество или выйдет из строя один компонент.

На практике имеет смысл проверить:

• ИБП с запасом времени, чтобы корректно завершить работу или дождаться генератора;
• генератор или понятный сценарий, как переживаете отключение на 1-2 часа;
• два блока питания в сервере и раздельные линии питания (если возможно);
• RAID и запас по объему на рост хотя бы на 12-18 месяцев;
• мониторинг, который предупреждает о деградации дисков, перегреве и проблемах питания.

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

Резервные копии и план восстановления

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

Здесь удобно зафиксировать две метрики:

• RPO - сколько данных вы готовы потерять. Например, RPO 15 минут означает, что в худшем случае потеряются изменения за последние 15 минут.
• RTO - за сколько времени сервис должен вернуться в работу. Например, RTO 2 часа означает, что после серьезного сбоя CRM/ERP должна заработать не позже, чем через 2 часа.

Пример: у клиники запись пациентов идет весь день. При RPO 24 часа после сбоя можно потерять целый день записей. Обычно это неприемлемо, значит нужно уменьшать RPO (чаще копии или репликация) и ускорять запуск (резервный сервер, готовый образ, четкие шаги).

Отдельно закрепите ответственность: кто диагностирует проблему, кто меняет комплектующие, кто восстанавливает базу и кто принимает решение о переключении на резерв. Если вы привлекаете интегратора (в том числе GSE.kz), эти роли лучше согласовать до запуска.

Ответственность сторон: как не остаться крайним при инциденте

Когда CRM или ERP «упала», всем важно одно: кто поднимает сервис и в какие сроки. Если это не прописано, начинается переписка в стиле «это не наша зона».

Что именно делится между сторонами

Разделите систему на слои и назначьте владельца каждого:

• железо (сервер, диски);
• виртуализация (если есть);
• ОС;
• база данных;
• приложение CRM/ERP;
• резервные копии;
• безопасность (обновления, доступы, антивирус, журналы).

В офисе почти все ложится на вашу команду. В ЦОД площадка обычно закрывает «фундамент»: питание, охлаждение, физическую безопасность (иногда канал). Остальное остается у вас или у подрядчика.

Удобно зафиксировать это в простой таблице:

SLA: что должно быть написано черным по белому

SLA полезен только когда в нем понятно, что именно гарантируется. Проверьте, что прописаны:

• что входит в гарантию: питание, доступ в стойку, физическая охрана, канал;
• время реакции и время восстановления (это разные вещи);
• окна обслуживания и как предупреждают о работах;
• порядок аварийного доступа (ночью, в выходные);
• как фиксируются инциденты: тикет, звонок, журнал.

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

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

Хороший ориентир: назначьте одного владельца сервиса (не «железа»), который держит в одном месте все SLA, регламенты доступа и контакты.

Пошаговый план выбора: от требований к решению

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

1. Опишите 3-5 критичных процессов и допустимый простой. Например: оформление заказа - максимум 30 минут, печать накладных - 2 часа, отчеты для руководства - до конца дня.

2. Оцените нагрузку на 12-36 месяцев: пользователи, удаленные точки, рост базы и файлов (сканы, договоры), пики.

3. Считайте полную стоимость владения, а не только цену сервера. Обычно в расчет входят покупка оборудования и лицензий, обслуживание, связь (основной и резервный каналы), резервирование (хранение копий и тест восстановления), а также люди (дежурства, замены на отпуск и ночные инциденты).

4. Проверьте связь и доступность на практике: замеры задержки до сервера, стабильность в часы пик, работа через VPN/тонкий клиент. Добавьте мониторинг, чтобы видеть проблемы, а не угадывать их по жалобам.

5. Зафиксируйте ответственность и регламенты: кто реагирует, кто обновляет, кто делает бэкапы, кто получает доступ на площадку, кто принимает решения при аварии.

После этого выбор между офисом, ЦОД или гибридом обычно становится очевидным.

Частые ошибки при выборе офисного сервера или ЦОД

Самая частая ошибка - начать с «сколько стоит железо», а закончить неожиданным простоем. Для CRM/ERP важны не только ресурсы сервера, но и интернет, питание, резервные копии и понятные правила, кто за что отвечает.

Чаще всего к лишним расходам приводят такие вещи:

• считают только цену сервера и забывают про ИБП, кондиционирование, стойку, лицензии, настройку и регулярное обслуживание;
• оставляют один канал интернета без резерва;
• не назначают владельца бэкапов и восстановления: копии вроде «делаются», но никто не знает где они и как быстро поднять систему;
• недооценивают сроки закупки, доставки, монтажа, согласований и тестов;
• запускают без проверки на реальных данных и типовых задачах пользователей.

Пример: компания переносит CRM на сервер в офисе, потому что «так дешевле». Через месяц в здании пропадает электричество на 2 часа. ИБП держит 10 минут, а резервная копия оказалась на том же диске, что и база. Сервер был нормальный, но к обычной аварии инфраструктура не готова.

Чтобы не попасть в такую ситуацию, заранее зафиксируйте три вещи: где лежат бэкапы и как часто проверяется восстановление, что делаете при отказе интернета и питания, и кто отвечает за каждый участок (офис, провайдер, ЦОД, интегратор).

Быстрый чеклист, пример и следующие шаги

Иногда нужно принять решение быстро. Тогда полезно на 10 минут отложить детали и проверить базовые вещи - они и определяют, будет ли CRM/ERP «просто работать».

Чеклист на 10 минут

Запишите ответы в одном файле:

• Доступность: сколько часов простоя в месяц вы готовы терпеть и кто это подтверждает (SLA или внутренняя договоренность).
• Связь: есть ли резервный интернет, что будет при обрыве, и как филиалы будут подключаться.
• Бэкапы и восстановление: как часто делаются копии, где они хранятся и сколько занимает восстановление.
• Безопасность: кто управляет доступами, обновлениями, антивирусом, журналами и что делаете при инциденте.
• Роли и регламенты: кто отвечает за сервер, сеть и сервис в целом, и какие действия выполняются по сценарию «если упало».

Пример: 80 пользователей и 2 филиала

У компании 80 сотрудников, CRM/ERP активно используют бухгалтерия, склад и продажи. Есть два филиала в других городах.

Если сервер стоит в офисе, филиалы зависят от канала до головного офиса. Авария у провайдера или отключение электричества - и «встает» сразу все. Чтобы выйти на приемлемую доступность, обычно приходится добавлять ИБП, резервный интернет, VPN, хранение бэкапов вне офиса и понятный план восстановления.

При размещении в ЦОД проще обеспечить питание, охлаждение, физическую охрану и стабильные подключения. Филиалы подключаются к одной точке в дата-центре, и меньше риск, что проблема в офисе парализует систему. Но роли нужно разделить заранее: ЦОД отвечает за площадку, а за ОС, приложения и политику доступа отвечает ваша ИТ-команда или подрядчик.

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

Следующие шаги:

• Составьте короткие требования: пользователи, филиалы, критичность, окна обслуживания, RPO/RTO.
• Опишите текущие затраты и риски, затем запросите расчет TCO на 3 года для вариантов «офис» и «ЦОД».
• Проверьте, как устроена поддержка: контакты, время реакции, эскалации.
• Согласуйте ответственность письменно (что именно входит в поддержку).

Если нужен практичный подбор «под задачу» и единая ответственность за железо и внедрение, GSE.kz как производитель и системный интегратор в Казахстане может закрыть поставку серверов (например, S200 Series) и сопровождение с круглосуточной технической поддержкой и сервисной сетью по стране.