Как рассчитать сервер с запасом роста, но без лишней переплаты

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

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

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

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

Содержание

• Почему компании переплачивают за серверы
• Какие исходные данные собрать до расчёта
• Как оценить реальную нагрузку, а не абстрактные желания
• Как выбирать процессор без переплаты за лишние ядра
• Как рассчитать объём оперативной памяти
• Дисковая подсистема: где бизнес чаще всего ошибается
• Сетевые интерфейсы, резервирование и пропускная способность
• Как правильно заложить запас на рост
• Сервер под виртуализацию, базу данных, файлы и приложения: в чём разница
• Когда выгоднее мощнее сервер, а когда лучше думать про архитектуру
• Типовые ошибки при расчёте сервера
• Пошаговый алгоритм расчёта
• Итог
• ЧЗВ по выбору сервера

Почему компании переплачивают за серверы

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

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

Есть и психологический фактор. Руководитель или ИТ-специалист часто предпочитает купить сервер с большим запасом, потому что цена ошибки кажется выше цены лишней мощности. Но на практике избыточная конфигурация тоже является ошибкой. Деньги замораживаются в железе, которое простаивает. Возраст оборудования идёт одинаково быстро и для полезного ресурса, и для неиспользуемого. Через несколько лет компания обнаруживает, что переплатила не за рост, а за красивые цифры в спецификации.

Какие исходные данные собрать до расчёта

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

Следующий важный параметр — количество одновременно активных пользователей, а не просто общее число сотрудников в штате. Компания может насчитывать 200 человек, но одновременно тяжёлую нагрузку на сервер создают только 35–40 сотрудников бухгалтерии, логистики и операторов. Или наоборот: предприятие небольшое, но почти все работают в единой базе и активно обращаются к данным в течение дня. Без разделения общего количества пользователей и фактической конкурентной нагрузки нельзя адекватно оценить ни процессор, ни память, ни дисковую подсистему.

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

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

• список сервисов и их приоритетность;
• число одновременно активных пользователей;
• объём данных и темп их роста;
• пиковые периоды нагрузки;
• критичность простоя для бизнеса;
• планируемый срок эксплуатации сервера;
• возможность дальнейшего расширения.

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

Как оценить реальную нагрузку, а не абстрактные желания

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

Чтобы оценить нагрузку правильно, полезно разделить её на три слоя. Первый слой — постоянная фоновая нагрузка: службы каталогов, служебные сервисы, файловые обращения, базовые внутренние процессы. Второй слой — регулярная рабочая нагрузка в обычные часы: работа учётной системы, приложения, базы данных, совместный доступ к файлам, отчёты. Третий слой — пики: закрытие месяца, массовые выгрузки, резервное копирование, пересменка, одновременный запуск отчётов, синхронизация филиалов, обработка массивов данных или всплеск обращений к базе.

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

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

Как выбирать процессор без переплаты за лишние ядра

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

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

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

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

Как рассчитать объём оперативной памяти

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

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

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

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

Дисковая подсистема: где бизнес чаще всего ошибается

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

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

Нередко компании смешивают в одном дисковом наборе системные файлы, базы, активные рабочие данные и архив. Это упрощает старт, но ухудшает производительность и делает развитие неудобным. Гораздо полезнее заранее определить, какие данные будут самыми активными, что требует быстрого отклика, что относится к холодному хранению и как быстро будет расти объём. В некоторых случаях выгоднее сразу предусмотреть отдельный массив под систему и приложения, отдельный — под активные данные, а архивы и большие файловые объёмы вынести в более подходящую подсистему.

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

Сетевые интерфейсы, резервирование и пропускная способность

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

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

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

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

Как правильно заложить запас на рост

Самый частый вопрос при покупке сервера звучит так: а какой запас брать на будущее. Ответ почти никогда не выражается одним числом. Нельзя просто сказать взять на 30 процентов больше и считать задачу решённой. Рост бывает разным. У одной компании увеличивается число пользователей. У другой — объём базы. У третьей появляются новые виртуальные машины. У четвёртой растёт архив видеоданных. У пятой — расширяется филиальная сеть и нагрузка по обмену.

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

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

Именно в этом различие между запасом и переплатой. Запас — это когда у бизнеса есть куда расти. Переплата — это когда ресурсы уже куплены, но в реальности не используются и, возможно, так и не будут востребованы до морального устаревания сервера.

Сервер под виртуализацию, базу данных, файлы и приложения: в чём разница

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

Сервер под виртуализацию

Здесь важен баланс. Обычно одновременно требуется достаточно ядер, заметный объём памяти, быстрая дисковая подсистема и понятная сетевая схема. Виртуализация плохо переносит перекосы, когда одного ресурса много, а другого мало. Если планируется размещать несколько рабочих сервисов, лучше сразу закладывать удобство расширения и разумный запас по памяти и дискам.

Сервер под базу данных

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

Файловый сервер

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

Сервер приложений

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

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

Когда выгоднее мощнее сервер, а когда лучше думать про архитектуру

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

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

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

Типовые ошибки при расчёте сервера

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

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

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

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

Пятая ошибка — не учитывать стоимость простоя. Иногда компания стремится сэкономить на резервировании, а потом платит гораздо больше из-за остановки учёта, отгрузок, доступа к документам или простоев сотрудников.

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

Пошаговый алгоритм расчёта

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

1. Определить роль сервера

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

2. Зафиксировать рабочие сервисы и пользователей

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

3. Посчитать данные и рост

Нужно оценить текущий объём, годовой прирост, структуру активных и архивных данных, а также требования к скорости доступа.

4. Выделить пиковые сценарии

Полезно понять, когда нагрузка максимальна: отчёты, закрытие месяца, резервное копирование, массовые входы пользователей, обмен с филиалами.

5. Определить требования к простоям и резервированию

Если остановка сервера критична, это нужно учитывать на уровне блоков питания, дисков, сетевых интерфейсов и общей архитектуры.

6. Сбалансировать процессор, память и диски

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

7. Выбрать платформу с понятным путём роста

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

8. Проверить бюджет не только на покупку, но и на владение

Сюда входят не только железо, но и резервирование, обслуживание, запас по дискам, модернизация и риски простоя.

Итог

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

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

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

ЧЗВ по выбору сервера

Нужно ли сразу покупать сервер с большим запасом на пять лет вперёд?

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

Что важнее для сервера: процессор или память?

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

Почему сервер может работать медленно даже с хорошим процессором?

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

Когда стоит думать об отдельной системе хранения, а не только о дисках в сервере?

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

Можно ли рассчитать сервер только по числу сотрудников компании?

Нет. Количество сотрудников само по себе почти ничего не говорит. Важнее, какие системы они используют, сколько пользователей активны одновременно и какие операции создают основную нагрузку.

Что чаще всего приводит к переплате при покупке сервера?

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