Количество рабочих мест для расчёта серверной мощности полезно рассматривать как верхнюю границу потенциальной нагрузки. Реальное потребление ресурсов зависит от числа одновременно работающих сотрудников, используемых приложений, графика присутствия в офисе и удалённого доступа.
Штатное расписание само по себе не позволяет выбрать подходящий сервер. Если в компании работают 100 человек, специалисты 1С, бухгалтеры и менеджеры могут создавать разную нагрузку, причём она редко распределяется равномерно в течение дня.
Специалисты IT Doc в Алматы помогают компаниям сопоставить данные о сотрудниках, лицензиях и приложениях с фактической загрузкой инфраструктуры. Такой подход снижает риск переплаты за избыточные ресурсы и предотвращает дефицит производительности в рабочие часы.
Начните с разграниченияния штатных сотрудников, удалённых работников, подрядчиков и автоматизированных сервисных учётных записей. Каждая категория требует отдельного подхода: человек может использовать несколько устройств, а одна сервисная запись способна выполнять тысячи операций.
Полезно сопоставить несколько источников: кадровый учёт, доменную систему, лицензии 1С, корпоративную почту, VPN и приложения для учёта рабочего времени. После этого одинаковые учётные записи и неактивные сотрудники исключаются, а реальный круг пользователей уточняется.
Пример: в штате числится 120 человек, но одновременно с бизнес-системами работают около 45 сотрудников. Именно 45 пользователей следует учитывать при моделировании пиковой нагрузки, если каждый из них регулярно открывает приложения и сохраняет документы.
Пользователи могут находиться в офисе не одновременно. Сдвижные производства, круглосуточная поддержка и клиентские подразделения создают пересечения рабочих смен, когда количество активных сессий превышает среднее значение.
Удалённый доступ не всегда снижает нагрузку. Сотрудники в других часовых поясах могут подключаться вечером, а мобильные пользователи — открывать почту и CRM на короткие интервалы в течение всего дня.
Для расчёта нужны не только общие счётчики входов, но и показатели пиковой одновременной работы, продолжительности сессий и времени отклика приложений. При отсутствии мониторинга разумно использовать несколько сценариев, проверив их позже на серверных журналах.
Рабочие места следует распределить по профилям. Оператор ввода данных создаёт много коротких запросов, бухгалтер работает с тяжёлыми отчётами в 1С, а руководитель чаще просматривает небольшие документы и аналитику.
Один пользователь 1С способен потреблять значительно больше процессорного времени и оперативной памяти, чем менеджер, работающий с почтой и CRM. Для проектных команд важны компиляция, контейнеры и тестирование, для дизайнеров — графические приложения, а для удалённых сотрудников дополнительное значение имеют VPN-соединения.
Поэтому число сотрудников нужно преобразовывать в технические показатели: пиковое число процессов, объём оперативной памяти, интенсивность дисковых операций и сетевой трафик. Прямой пересчёт «один сотрудник — одна единица мощности» обычно даёт неточный результат.
Перед расчётом необходимо понять, где выполняются приложения. Если 1С развёрнут локально, его требования к серверу следует оценивать отдельно. При использовании облачной версии локальный сервер обычно нужен для файлов, почты, VPN, корпоративных интеграций и резервного копирования.
До окончательного выбора инфраструктуры нагрузочный тест можно провести с помощью хостинга для тестовой среды. Это позволяет сравнить конфигурации, проверить сценарии нагрузки и выявить узкие места без закупки оборудования до завершения расчётов.
Хранилище планируется отдельно от числа пользователей. Объём растёт из-за почты, документов, журналов, резервных копий, баз 1С и файлов проектов. Для системы с активным редактированием важны не только гигабайты, но и скорость дисковых операций.
Краткосрочный расчёт без резерва быстро устаревает. Для компании на 50 сотрудников можно предусмотреть текущий штат, прирост за год и отдельный сценарий при расширении филиала или запуске нового направления. Такой подход описан в материале о бесперебойной работе серверов.
Круглосуточные сервисы требуют резервирования компонентов и проверки восстановления. Для каждого сценария следует задать допустимое время простоя, объём потерянных данных и порядок переключения на резервную площадку.
Запас производительности полезно распределять между процессорами, памятью и хранилищем. Вместо равномерных 50% резерва практичнее выделять больше там, где профилирование выявило нестабильность. Регулярный мониторинг позволяет вовремя пересчитывать параметры без полной замены оборудования.
При выборе между покупкой и арендой серверов учитываются не только цена оборудования, но и электричество, место в стойке, лицензии, ремонт, запасные части и работа администраторов.
Аренда снижает первоначальные расходы и упрощает расширение, но требует заранее определить условия выхода, стоимость хранения данных и доступность переноса. Собственная инфраструктура даёт больший контроль, особенно когда важны локальное размещение в Алматы и предсказуемое время реакции поддержки.
Гибридная схема часто оказывается рациональной: критичные и нагруженные компоненты размещаются в собственной инфраструктуре, а тестовые среды, сайты и резервные копии передаются внешнему провайдеру. IT Doc также подбирает и администрирует серверное оборудование и предоставляет круглосуточную техническую помощь.
Итоговый расчёт удобно представить в трёх сценариях: базовом, расширенном и сценарии роста. Значения должны отражать предполагаемое число активных пользователей, структуру их workloads, требуемые резервы и параметры восстановления.
Сравнение выглядит так:
| Показатель | Базовый сценарий | Расширенный сценарий | Сценарий роста |
|---|---|---|---|
| Одновременно активные пользователи | 40 | 60 | 85 |
| Доля тяжёлых профилей | 20% | 30% | 40% |
| Запас по процессорной мощности | 30% | 40% | 50% |
| Запас по оперативной памяти | 25% | 35% | 45% |
| Рост хранилища за год | 25% | 40% | 70% |
| Время восстановления после сбоя | 4 часа | 2 часа | 1 час |
Это ориентиры для согласования расчёта, а не универсальные нормативы. Их следует наполнить реальными показателями компании, проверить тестированием и пересматривать при изменении штата или архитектуры.
Практические рекомендации:
Оставьте заявку на аудит инфраструктуры IT Doc: специалисты уточнят реальную нагрузку, рассчитают подходящую конфигурацию и подготовят обоснованную схема серверного решения для вашей компании.
