Инфраструктура для ERP, SQL и удалённой работы

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

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

Express бесплатен и подходит небольшим установкам, но у него есть ограничения на размер базы, память и использование процессора, в которые растущая компания рано или поздно упирается, обычно в самый неподходящий момент. Standard эти ограничения снимает и поддерживает полноценные регламентные задания резервного копирования. Мы смотрим, что ваша система использует сейчас и насколько близко потолок, и прямо говорим, какую редакцию рекомендуем и сколько она стоит. Если Express всё ещё подходит, так и скажем.

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

Отдельно от файловых копий и по своему расписанию, потому что база, скопированная как файл во время работы, часто не восстанавливается. Используем собственный механизм копирования СУБД, храним копии вне той машины, что их сделала, и проверяем восстановление в отдельной среде, чтобы процедура была доказана, а не предположена. Как часто, зависит от того, сколько работы вы готовы переделать: для большинства бухгалтерских систем честный ответ это полная копия ночью плюс журналы транзакций в течение рабочего дня.

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