Почему компаниям на 50–200 сотрудников нужна своя «железная» инфраструктура
На старте облако кажется универсальным решением: быстро, без капитальных затрат, оплаты — по факту использования. Но по мере роста компании проявляются задержки в работе баз данных и 1С, счета за облако становятся непредсказуемыми, а вопросы безопасности и договорных ограничений — острее. Собственная серверная инфраструктура не отменяет облака, а дополняет его: берёт на себя критичные процессы, делает отклик стабильным и снижает стоимость владения на дистанции.
Когда облако перестаёт быть выгодным
Пока сотрудников десяток, любая задержка в приложении кажется терпимой, а размеры файлов — скромными. Когда людей становится пятьдесят и больше, нагрузка растёт ступенькой: одновременно открываются тяжёлые отчёты, пользователи гоняют по сети большие модели и чертежи, бухгалтерия каждое утро формирует регистры и отчёты. Облако в этот момент упирается в физику сети. Даже десятые доли секунды на каждый запрос к базе суммируются в минуты потерь рабочего времени. Локальный сервер с быстрым NVMe-хранилищем и правильной настройкой виртуализации возвращает системе ту самую «живость»: окно с отчётом открывается сейчас, а не «скоро».
Вторая проблема — предсказуемость затрат. Пока сервисов немного, счёт за облако радует гибкостью: выключили виртуалку — перестали платить. Но постоянные рабочие нагрузки, особенно базы данных, файловые сервисы, системы аналитики, живут 24×7. Вы платите не за пик, а за «фоновую инфузию», и летом, и зимой. Плюс трафик, плюс хранилище, плюс резервные копии. К моменту, когда в компании 100–150 человек, ежемесячный платёж за облако начинает конкурировать с амортизацией собственного сервера, который при этом обеспечивает более высокий отклик и лучше контролируется IT-отделом. На горизонте 3–5 лет локальное решение часто оказывается ощутимо дешевле.
Третья плоскость — риски и требования к данным. У некоторых заказчиков прямо прописано: информация должна обрабатываться и храниться в определённом юридическом периметре. Иногда требуется жёсткая сегментация доступа к проектным материалам, а иногда — внутренние аудиты журналов действий. Сделать это корректно можно и в облаке, но сложность настройки, зависимость от провайдера и стоимость быстро растут. Локальная инфраструктура даёт простой и проверяемый ответ: вот сервер, вот политика доступа, вот шифрование, вот процедура восстановления. Облако остаётся полезным для внешних интеграций и оффсайт-копий, но «ядро» сервисов живёт у вас.
Наконец, есть фактор управляемости. В критический момент вам важна не только поддержка провайдера, но и возможность самостоятельно открыть консоль, перезапустить нужную службу, быстро нарастить диск или вернуть виртуальную машину из свежего снапшота. Когда всё под рукой, простои короче, а решение проблем — прозрачно. Это особенно заметно в сезоны отчётности, активных продаж или внедрений — те самые дни, когда «всё должно работать».
Какие роли закрывает один–два сервера
Чаще всего бизнесу на 50–200 сотрудников хватает одного мощного сервера или пары узлов, чтобы закрыть основные потребности. На них живут четыре ключевые роли. Первая — файловый сервис. Это не просто «общая папка», а аккуратная структура с правами, версионированием и быстрым доступом к крупным проектам. Когда инженеру не приходится ждать, пока откроется многогигабайтный сборочный файл, он экономит часы за неделю — и это сразу видно в сроках.
Вторая роль — виртуализация прикладных сервисов. Контроллер домена, DNS, базы 1С, CRM, внутренняя wiki, система учёта заявок — всё это становится набором виртуальных машин, каждая со своей ответственностью и отдельными бэкапами. Такой подход избавляет от каскадных отказов, ускоряет обновления и делает переносы между узлами безболезненными. Падает одна служба — остальные продолжают работать, а администратор спокойно возвращает всё в строй из последнего снапшота.
Третья — резервное копирование и восстановление. На локальном сервере быстро делаются инкрементальные копии, а по расписанию — полные снепшоты машин и баз. Восстановление занимает минуты, а не часы, потому что трафик не уходит в интернет и не зависит от внешней пропускной способности. При этом оффсайт-копии всё равно есть: они уходят на внешнее хранилище или в облако по ночам, чтобы выдержать пожарные и юридические сценарии.
Четвёртая — специализированные нагрузки: системы видеонаблюдения, CAD/CAE-репозитории, сервисы аналитики, кэш-слои для внутренних приложений. Такие задачи требуют предсказуемых IOPS и широкой сети внутри офиса. Разместив их рядом с пользователями, вы получаете неизменно низкие задержки и честно высокую скорость. Даже если часть каналов наружу перегружена, внутренние сервисы продолжают работать как часы — и сотрудники это ощущают сразу.
Чтобы все эти роли тянулись без узких мест, нужен разумный набор «кирпичиков». Это не про «максимальные цифры в спецификациях», а про сбалансированную конфигурацию: процессоры с запасом потоков под виртуалки, много ECC-памяти для кэша и стабильности, быстрый слой NVMe для активных баз, надёжный зеркальный массив на жёстких дисках для архивов и проектных материалов, нормальная сетевая карта на 10GbE к ядру офиса. Такой набор и есть базовое серверное оборудование, на которое опирается инфраструктура: оно обеспечивает предсказуемость, скорость и возможность наращивать ресурсы по мере роста задач.
Минимальная «живая» конфигурация под 50–200 сотрудников
Базовый подход — не гнаться за «топом», а убрать узкие места. Один узел закрывает 1С/БД, файлы и вспомогательные сервисы. Два узла дают запас по отказоустойчивости и удобную миграцию.
Один мощный сервер. 12–24 ядер, 128–256 ГБ ECC, NVMe в зеркале под ВМ и БД, HDD RAID10 под файлы, 10GbE к ядру сети, два БП, ИБП с автозавершением. Подходит, если простои допустимы на время работ.
Два сервера. #1 — виртуалки и БД (больше RAM и NVMe). #2 — файловое хранилище (HDD + SSD-кэш). Плюсы: проще обновлять, меньше простоев, легче масштабировать.
Обязательно. IPMI/ILO/DRAC для удалёнки, мониторинг температур/SMART/IOPS, регулярный тест бэкапов.
Хранилище и сеть без узких мест
Для «горячих» данных — базы 1С, очереди, виртуальные диски — используйте слой на NVMe. Зеркало из двух NVMe даёт быстрый отклик и простое восстановление при отказе одного модуля. Общие папки и архивы разумнее держать на HDD в RAID10: он предсказуем по скорости смешанных операций и переживает отказ диска без драм. Если файлов много мелких, добавьте SSD под кэш чтения/записи — это сгладит «пилу» нагрузки. Важно разделить тома: ВМ и БД — на NVMe, «общак» и бэкапы — на отдельном массиве, чтобы копии не душили продуктив.
Базовый рубеж по сети — 10GbE от сервера к ядру. Он ускоряет бэкапы, копирование образов и работу с тяжёлыми файлами. При CAD/видеомонтаже или активной аналитике подумайте о 25GbE на критичных участках. Агрегация каналов (LACP) даёт суммарную пропускную, но один поток быстрее от этого не станет — под узкие задачи лучше один «жирный» порт, чем несколько по 1GbE. Разделите трафик по VLAN: управление, бэкапы, пользователи — так легче держать задержки под контролем. Jumbo Frames включайте только сквозняком и после тестов: выгода есть не всегда.
По инфраструктуре: два независимых БП в сервере, ИБП с корректным временем держания и автошифтовым завершением, приточно-вытяжное охлаждение без «горячих точек». Если сервер стоит не в стойке, следите за пылью и температурой — перегрев убивает IOPS так же надёжно, как узкий сетевой порт.
Сколько это стоит: считаем TCO «на пользователя в месяц»
Считайте не «цену сервера», а стоимость владения на 3–5 лет. Разделите разовый CapEx (железо + внедрение) на срок службы, добавьте электричество, поддержку и замену расходников. Получится стабильная сумма в месяц. Разделите её на число сотрудников — это и есть ориентир «за пользователя». У постоянных нагрузок локальная инфраструктура часто выходит дешевле облака уже на 12–18-м месяце: после окупаемости вы платите в основном за электричество и плановое обслуживание, а производительность — ваша.
Не забывайте про цену простоя. Час падения 1С или файлового сервиса стоит дороже любой оптимизации. В расчёт TCO включайте RPO/RTO: сколько данных готовы потерять и за сколько минут обязаны подняться. Система с быстрым локальным рестором и оффсайт-копией, как правило, снижает риски сильнее, чем попытки экономить на дисках и ИБП.
Как перейти без простоя: короткий план
Начните с инвентаризации: какие сервисы работают, где лежат базы и файлы, сколько занимают, какие RPO/RTO допустимы. На этой базе спроектируйте целевую схему: роли, ресурсы под них, отдельные тома для ВМ/БД и для файлов, сетевые требования (10GbE в ядре), схема бэкапов и оффсайта. Поднимите пилот на виртуализации: разверните копию 1С и пары внутренних сервисов, замерьте отклик и ночные бэкапы. Мигрируйте по окнам — сначала наименее критичные службы, затем базы и файлы, для каждого шага держите план отката и контрольный чек-лист. После переноса выполните тест восстановления «на чистом железе», проверьте права доступа, мониторинг и алерты, зафиксируйте регламент: кто обновляет, кто смотрит логи, когда тестируем бэкапы и как действуем при отказе.
Безопасность и соответствие требованиям
Начните с модели угроз: какие данные критичны, кто к ним обращается, какие сценарии утечки и простоя возможны. На этой основе задайте политику доступа: минимум прав по ролям и отделам, раздельные учётные записи админов, двухфакторная аутентификация для удалёнки, журналирование действий. Для баз и файлов — шифрование томов и резервных копий, отдельные ключи, хранение ключевого материала вне продуктивного контура.
Резервирование — правило «3-2-1»: три копии, на двух носителях, одна — вне площадки. Инкременты — ежедневно, полная — еженедельно, контрольные восстановление на «чистый» стенд — раз в квартал. Для соответствия внутренним и внешним требованиям фиксируйте регламенты: где лежат логи, кто и как их проверяет, как быстро восстанавливаемся (RTO) и какой объём данных допускаем потерять (RPO). Отдельно опишите порядок обновлений и патч-менеджмента: регулярные окна, тест перед выкладкой, откат.
Типовые ошибки и как их избежать
Экономия на памяти и NVMe. Узкое место почти всегда в RAM и IOPS, а не в процессоре. Если база «думает» на каждом отчёте, добавьте ECC-памяти и вынесите актив на зеркальный NVMe. Это дешевле, чем покупать «самый мощный» CPU и ждать чуда.
Один массив «для всего». Когда ВМ, базы, файлы и бэкапы живут на одном томе, любая копия «кладёт» продуктив. Разделяйте: NVMe под ВМ/БД, RAID10 на HDD под общий объём, отдельное хранилище под резервные копии.
1GbE в ядре. Гигабита хватает до первой ночи бэкапов или до первого большого проекта. Ставьте 10GbE сразу; LACP из нескольких 1GbE не заменяет один быстрый порт для одиночного потока.
Бэкапы без восстановления. Пока не развернули из копии — бэкапа нет. Делайте квартальные «учения»: поднимите ВМ на отдельном стенде, проверьте целостность баз и права.
Один БП и «домашний» ИБП. Падение питания превращается в простой. Дублируйте блоки питания, используйте ИБП с управляемым автозавершением, следите за батареями.
Нет мониторинга. Пользователи сообщают о проблеме раньше алертов — плохой признак. Настройте оповещения по температуре, SMART, заполнению томов, задержкам IO и пропускной.
Горячие точки и пыль. Перегрев снижает скорость так же надёжно, как узкий сетевой порт. Следите за притоком воздуха, выносите сервер из шумного офиса, регулярно чистите фильтры и проверяйте кривые вентиляторов.
Короткий кейс
Производственная компания, 120 сотрудников. До проекта — облачный VDS для 1С и файлов, средний отклик отчётов 15–25 секунд, ночные бэкапы шли 6–7 часов и мешали работе утром. Развернули один узел: 16 ядер, 192 ГБ ECC, NVMe 2×3.84 ТБ под ВМ и базы, HDD 4×12 ТБ RAID10 под файлы, 10GbE к ядру. Перенос делали по выходным, с тестовым восстановлением на «чистом» стенде.
После миграции отчёты открываются за 4–7 секунд, ночные копии укладываются в 1 час и не влияют на продуктив, восстановление ВМ из снапшота — 8–12 минут. Платёж за облако сократился до оффсайт-хранилища, точка окупаемости — около 14 месяцев.
Вывод
Локальная серверная инфраструктура даёт то, чего не хватает облаку при росте: быстрый отклик, предсказуемые расходы и управляемую безопасность. Для компании на 50–200 человек достаточно одного-двух узлов с NVMe под актив и RAID10 под общий объём, 10GbE в ядре и дисциплины бэкапов. Правильное разделение ролей (ВМ/БД отдельно от файлов и копий) убирает узкие места и сокращает простои. Мониторинг, резервирование питания и регулярный тест восстановления превращают «аварии» в плановые процедуры. В итоге вы платите меньше на горизонте 3–5 лет и получаете инфраструктуру, которая растёт вместе с задачами.
Редактор: AndreyEx
