Малому бизнесу — свой сервер или облако: сравниваем TCO

Малые компании всё чаще упираются в ИТ-пределы: файлов много, 1С/CRM работают удалённо, отчёты считаются дольше, а выездные сотрудники требуют стабильного доступа к документам. На старте облако кажется «поставил и забыл», но счёт растёт — добавляются платные IOPS, платёж за хранение, почасовые ВМ и поддержка. «Железо» выглядит дороже на дне покупки, зато предсказуемо в расходах и задержках, когда в офисе появляются 10/25GbE и нормальные бэкапы.

Корректный способ выбрать — честно посчитать TCO на три года: CapEx и OpEx, электричество и охлаждение, простои и зарплаты, стоимость вывоза данных из облака (egress), рост объёмов и требования к восстановлению.

Методика расчёта TCO «на салфетке»

Сначала фиксируем входные данные: число сотрудников и активных сессий 1С/CRM, средний объём рабочих файлов, темп роста данных в месяц, требуемые RPO/RTO и допустимые окна обслуживания. Эти параметры превращаются в требования к CPU/RAM, дискам, сети и резервному копированию — отдельно для «облака» и «своего сервера».

Дальше раскладываем три года владения на понятные корзины. Для сервера это закупка «железа», ИБП и коммутатора, электричество и охлаждение, замены дисков, поддержка и время администратора, а также стоимость простоев при работах и сбоях. Для облака — аренда ВМ и дисков с нужным IOPS, плата за хранилище и трафик на выгрузку (egress), публичные IP, резервирование ресурсов, поддержка, плюс простои при инцидентах провайдера.

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

Профили SMB-нагрузок — от чего зависит счёт

В офисе «файлы+сканы» создают непрерывный фон: десятки мелких операций, чувствительных к задержкам диска и сети. Если к этому добавляется 1С/база, картина меняется: важнее становится объём оперативной памяти и быстрый «горячий» слой под БД и журналы, иначе отчёты ночами будут конкурировать с бэкапами. Когда часть сотрудников работает удалённо, к требованиям добавляются стабильный канал, VPN с MFA и предсказуемый отклик терминальных сессий; любые «просадки» сети превращаются в жалобы на «медленную программу». Веб-сервисы и интеграции добавляют пиковую нагрузку — короткие бурсты запросов к API и выгрузки в сторонние системы. Правильный расчёт начинается с аудита этих ролей: какие операции критичны к миллисекундам (базы, терминал), какие — к пропускной способности (файлы, резервное копирование), а какие можно вынести в фон, не влияя на рабочий день. Когда профиль ясен, становится понятно, что выгоднее: облако с гибкой подстройкой под пики или свой сервер с низкими и постоянными задержками для ежедневной рутины.

Свой сервер — где экономим, где рискуем

Он-прем даёт предсказуемые задержки и контроль над данными: файлы и 1С живут рядом с пользователями, 10/25GbE убирает «узкие места», а бэкапы не зависят от cчетчика egress. На горизонте трёх лет обычно выигрывает TCO при постоянной нагрузке и большом объёме файлов: вы платите за железо один раз, дальше — электричество, замену дисков и плановое обслуживание без сюрпризов в счёте за трафик. Режим «свой сервер» проще подчинить регламенту безопасности: роли и доступы, оффлайн-копии, иммутабельные бэкапы, аудит логов — всё в ваших руках и без пролетов между зонами. Но вместе с контролем приходит ответственность: нужна дисциплина обновлений, тесты восстановления «на чистый стенд», дежурные окна и мониторинг температур/питания. Ещё риск — единая точка отказа: если бюджет тянет только один узел, продумайте запас по питанию и дискам, а для критичных ролей — план ускоренного развёртывания на запасном корпусе или в облаке. Своё железо окупается там, где рабочий день дороже, чем почасовая гибкость, и где стабильные миллисекунды ценнее обещаний «эластичности» без гарантий отклика. Готовые конфигурации серверного «железа» удобно брать у kvan.tech — так вы сравниваете не абстрактные цифры, а реальные комплектации под ваш профиль.

Облако — гибкость и «скрытые» строки

Сильная сторона облака — эластичность. Можно стартовать за часы, менять размер ВМ под сезонные пики, быстро поднимать пилоты и выключать то, что не работает. Для распределённых команд это особенно удобно: терминальные сессии и веб-сервисы ближе к внешним клиентам, нет забот о железе, ИБП и температурных режимах. В счётах это выглядит прозрачно до тех пор, пока нагрузка действительно «дышит» и нет тяжёлых файловых потоков в офис.

Стабильные ежедневные задачи вскрывают обратную сторону. Диски с гарантированным IOPS стоят ощутимо дороже базовых, данные «разрастаются», а плата за хранение снапшотов и межзонный трафик добавляет непредсказуемость. Главное — egress: как только регулярные выгрузки и бэкапы идут в офис, счёт растёт быстрее ожиданий. Если же базы и файлы постоянно «живут» в облаке, латентность до рабочих мест становится ежедневным фактором: даже небольшие задержки на канале множатся на число операций и превращаются в «медленную программу». Облако выгодно, когда нужна скорость изменений, короткие проекты и редкие пики; в сценариях «каждый день, много файлов и предсказуемый рост» TCO за три года часто выходит выше, чем у своего сервера — не на старте, а на дистанции.

Пороговые эффекты: «тяжёлые» файлы, egress и задержки

Есть моменты, когда экономика «перещёлкивается». Первое — «тяжёлые» файлы в локальной работе: сотни мегабайт на документ и десятки мелких операций в минуту делают задержку важнее «количества vCPU». На своём сервере 10/25GbE даёт стабильные миллисекунды к файловому шару и базе; в облаке тот же путь проходит через интернет и маршрутизацию провайдера, поэтому даже редкие всплески RTT множатся на каждое обращение. Второе — egress: пока вы только загружаете в облако, счёт терпим, но как только ежедневно выгружаете бэкапы, отчёты BI или медиапулы обратно, строка «трафик на выход» начинает доминировать в бюджете. Третье — рост данных: когда объём удваивается за год, локальный массив масштабируется корзинами и дисками, а в облаке к плате за хранение добавляются снапшоты и репликации, которые трудно «сжимать» без пересборки контура. Эти пороги ловятся не презентациями, а профилированием: замерьте p95 задержек на типичных операциях и посчитайте ежедневный объём выгрузки — если оба показателя стабильно высокие, локальная архитектура с оффсайтом выйдет дешевле и предсказуемее на горизонте трёх лет.

Безопасность и соответствие

Требования к доступам и журналам одинаково строги и для облака, и для своего сервера, но реализуются по-разному. В он-прем сценарии проще принудительно разделить роли, ограничить периметр, вести учёт админских действий и изолировать бэкапы физически: оффлайн-копия и «неизменяемые» окна превращают резервирование в реальную страховку, а не галочку в интерфейсе. Каналы в офис защищаются VPN с MFA, доступ администратора к гипервизору и BMC выносится в отдельный сегмент, а регламенты обновлений и проверки восстановления становятся частью плановых работ. Это даёт предсказуемость аудита: понятно, где лежат логи, кто к чему ходил и когда.

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

Гибрид для SMB: разумный компромисс

Самый частый рабочий вариант для малого бизнеса — оставить рядом с пользователями то, что критично к задержкам, и вынести наружу то, что хорошо живёт «вне офиса». Файловый сервер и 1С остаются на своём железе: к ним тянется 10/25GbE, бэкапы идут в отдельный локальный объём и дублируются оффсайтом. Публичные сервисы — сайт, внешние интеграции, тестовые окружения — переезжают в облако, где их проще масштабировать и изолировать по проектам. Такой расклад снимает налог egress на ежедневных выгрузках и даёт предсказуемые миллисекунды для рутины, не лишая вас гибкости, когда появляется краткоживущая задача.

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

Мини-калькулятор: 12 ноутбуков, 2 ТБ файлов, 1С

Берём типовой офис: двенадцать сотрудников, активная 1С с пиковым одновременным доступом в 6–8 сессий, два терабайта рабочих файлов, прирост данных около 8–10% в месяц и требуемое восстановление не дольше четырёх часов. Для своего сервера счёт складывается из единовременной закупки корпуса со стойкой или настольного шасси, частотного процессора с запасом по каналам памяти, 64–128 ГБ ECC с возможностью нарастить, NVMe-зеркала под базу и журналы, отдельного массива под файлы, коммутатора с 10GbE, ИБП, а также электричества и регламентного обслуживания. На горизонте трёх лет значимыми остаются замены отдельных дисков и плановые работы, но стоимость операции одинакова из месяца в месяц, а задержки не зависят от внешнего канала. Пилот на копии базы показывает, что прирост скорости в 1С и стабильность файлового доступа приходят сразу после разведения «горячего» и «ёмкостного» слоёв.

В облаке стартовать проще: одна виртуальная машина под 1С и файлы, диски с гарантированным IOPS, отдельное хранилище под бэкапы и снапшоты, публичный IP, VPN-шлюз для удалёнки. Итоговый месячный платёж заметно зависит от двух вещей — класса диска и объёма трафика на выход. Пока файлы живут внутри облака, а пользователи работают из браузера или терминала, счёт предсказуем; как только офису нужны регулярные выгрузки копий и «толстые» каталоги, графа egress начинает расти быстрее, чем ожидалось. При тех же исходных 2 ТБ и росте в пределах десяти процентов разница в TCO за тридцать шесть месяцев обычно складывается не из «цены за терабайт», а из стоимости миллисекунд и возврата данных: локальный сервер удерживает постоянные нагрузки дешевле, облако выигрывает там, где проекты краткоживущие и их можно выключить без следа. Правильный выбор подтверждается коротким пилотом: замеряете время проведения типового документа и p95 задержек на файловой шаре до и после — цифры покажут, где экономика совпала с ощущениями.

Кейсы в трёх абзацах

Офис + склад, стабильная рутина. Файлы тяжёлые, 1С открыта весь день, удалёнки почти нет. На своём сервере латентность до шара и базы остаётся в миллисекундах, бэкапы не зависят от egress, а TCO за три года оказывается ниже: один CapEx, понятный OpEx и минимум сюрпризов. В облаке счёт растёт из-за дисков с IOPS и регулярного вывоза отчётов и резервных копий.

Проектная студия, сезонные пики. Девять месяцев — лайтовая нагрузка, три — интенсивная. Облако выигрывает: быстро наращиваем вири, берём производительные диски на время кампаний, затем «сдуваемся» до базового тарифа. Свой сервер окупится только если вне сезонов есть постоянная файловая рутина, иначе простоит полупустым.

Распределённая команда. Часть сотрудников постоянно вне офиса, сервисы смотрят наружу. Гибрид закрывает оба мира: локальный узел держит 1С и файловый контур для офиса, облако — внешние веб-сервисы, тестовые окружения и оффсайт-бэкап. Сеть настроена так, чтобы ежедневные операции не платили налог egress, а пиковые проекты оборачивались только облачными часами.

Матрица выбора в словах

Если ваши данные тяжёлые, операции повторяются ежедневно, а пользователи сидят рядом с серверной — выигрывает своё «железо»: задержки предсказуемы, egress отсутствует, а апгрейд — это добавить RAM/NVMe и 10/25GbE без пересборки процессов. Если задачи приходят «волнами», инфраструктура часто меняется, нужно быстро запускать пилоты и так же быстро их гасить — облако логичнее: платите по факту, не держите парк «на всякий случай». Когда есть и рутина, и всплески, гибрид снимает конфликт: локально живут 1С и файл-сервер с миллисекундными откликами, в облаке — внешние сервисы, тестовые окружения и оффсайт. Ключ к решению — профиль задержек и трафика: если ежедневная работа упирается в миллисекунды и возврат данных, локальный контур окупается, если же ценность в скорости изменений и «временных» средах — облако возвращает деньги гибкостью.

Ошибки, которые дорожают

Самая частая — считать только «цену за терабайт» и игнорировать задержки и egress. Ещё одна — держать бэкапы рядом с продом и не проверять восстановление: пока вы не подняли систему «на чистую», у вас нет защиты, только ощущение безопасности. Опасно смешивать рабочий и резервный трафик: ночные копии в одном VLAN с пользователями превращают утро в лотерею. В облаке легко забыть выключить «временные» ресурсы и копить снапшоты; на своём железе — сэкономить на памяти/каналах и получить вечные «подвисания» при нулевой загрузке CPU. И последнее: выбирать модель «по моде» без пилота. Час замеров на копии вашей базы снимает больше рисков, чем десяток презентаций.

Вывод

Выбор между облаком и своим сервером — это не про религию, а про математику задержек и денег. Если каждый день у вас много файлов и чувствительность к миллисекундам, предсказуемый он-прем с 10/25GbE и дисциплиной бэкапов даст меньший TCO и стабильную работу. Если ценность — в скорости изменений и кратких проектах, облако вернёт гибкостью. Чаще всего выигрывает гибрид: локальный контур держит рутину, облако — всё, что легко масштабировать и безопасно вынести наружу. Начните с короткого пилота и сведите цифры в трёхлетний TCO — решение станет очевидным, а инфраструктура перестанет быть источником сюрпризов.