Сервер или облако: как сравнить затраты за три года?

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

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

Что именно сравнивается: сервер, VPS, IaaS или SaaS?

Собственный сервер можно разместить в офисе или ЦОД. Арендованный выделенный сервер — физический узел провайдера. VPS и облачная виртуальная машина предоставляют виртуальные ресурсы с определёнными условиями разделения и производительности. IaaS добавляет инфраструктурные возможности, а SaaS предоставляет готовое приложение. Эти услуги нельзя сопоставлять как одинаковую «аренду сервера».

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

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

Какие требования уравнять перед расчётом?

Зафиксируйте сервисы, число активных пользователей, часы работы и целевые задержки. Пара «16 ядер и 128 ГБ» сама по себе не определяет равенство: облачный vCPU не всегда равен физическому ядру, а производительность накопителей может ограничиваться тарифом. Требуется одинаковая способность выполнить прикладной сценарий.

• Ресурсы: измеренная CPU/RAM-нагрузка, место на дисках, IOPS, пропускная способность и рост.
• Доступность: допустимый простой, окна обслуживания, необходимость переживать отказ узла или площадки.
• Данные: RPO, срок хранения копий, скорость полного и частичного восстановления.
• Сеть: каналы, задержка до пользователей, исходящий трафик и связь с локальными системами.
• ПО: одинаковые лицензии либо ясно объяснённые функционально равные варианты.
• Эксплуатация: мониторинг, обновления, часы поддержки и ответственность за инцидент.

При недостатке исходных данных сначала нужен пилот. Для планирования ресурсов используйте расчёт мощности сервера для виртуальных машин. Прикладную нагрузку 1С рассматривает отдельная методика; здесь эти результаты становятся входными числами экономической модели.

Как сравнить производительность, если облачный vCPU не равен ядру сервера?

Начните с одинаковой прикладной работы. Например, один и тот же набор запросов к базе, пакет документов или цикл обработки файлов с одинаковыми данными. Зафиксируйте длительность, число одновременно работающих пользователей, средние и медленные операции. Для проекта важен результат сервиса, а не формальное равенство строки «16 CPU».

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

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

Почему нужно учитывать путь от пользователя до приложения?

Для интерактивных операций важна задержка до среды. В условном примере операция требует 100 последовательных сетевых обменов. При RTT 4 мс только этот компонент занимает около 0,4 секунды, при RTT 25 мс — около 2,5 секунды, без времени обработки. Реальное приложение может объединять запросы или работать иначе, поэтому эти числа объясняют риск, а не предсказывают вашу задержку.

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

Из чего состоит TCO собственного Supermicro?

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

Удобная формула: TCOсвой = оборудование + внедрение + расширения + Σ ежемесячных расходов + вывод из эксплуатации − подтверждённая остаточная стоимость. Вложения в резервный узел, сетевое оборудование и копии включают до сравнения, если они нужны по требованиям.

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

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

Какие расходы облака чаще пропускают?

Кроме CPU и RAM, могут оплачиваться диски, выделенные уровни IOPS, снимки, резервные копии, объектное хранение, трафик, публичные адреса, VPN и услуги поддержки. Условия конкретного договора определяют, какие строки есть и как они рассчитываются.

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

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

Как правильно учитывать людей и уже имеющуюся инфраструктуру?

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

Учебный пример: на собственную среду выделяется 8 часов работы в месяц, на облачную — 5 часов. При условной полной стоимости часа 2000 ₽ разница составляет 6000 ₽ в месяц, или 216 000 ₽ за 36 месяцев. Это не ставка рынка и не норматив времени. Такой расчёт полезен, когда часы подтверждены планом работ, а общие расходы не списаны целиком на один сервис.

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

Что происходит со счётом после выключения облачной ВМ?

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

Гибкость требует процесса: кто меняет размер ресурсов, когда удаляет ненужные стенды, как контролирует рост дисков и бюджетные уведомления. Если среда всегда остаётся в пиковом размере, расчёт «платим только за нужное» не реализован. Инженерные работы по автоматизации тоже входят в сравнение.

Пример расчёта сервера и облака на три года

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

В этом наборе предположений собственная система дешевле на 364 000 ₽, или примерно на 17,0% облачного бюджета. Это результат арифметики выбранных условий, а не доказательство, что сервер всегда выгоднее. Замена любой существенной строки может изменить выбор.

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

Как посчитать точку окупаемости?

Для постоянных ежемесячных расходов простое приближение: m = (Aсвой − Aоблако) / (Mоблако − Mсвой). A — стартовые вложения, M — полные месячные расходы. Формула имеет экономический смысл, когда облачные месячные расходы выше; при нулевой или отрицательной разнице такой точки в простой модели нет.

В примере стартовая разница — 730 000 − 50 000 = 680 000 ₽. Месячные расходы — 29 000 ₽ у своего сервера и 58 000 ₽ у облака. Расчётная точка равенства накопленных затрат — 680 000 / 29 000 ≈ 23,4 месяца. Это не срок «возврата денег», гарантированный любой покупкой.

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

Как выглядят накопленные расходы по годам?

Для исходного условного сценария полезно увидеть платежи во времени. При старте 730 000 ₽ и 29 000 ₽ в месяц собственный вариант требует больше денег сначала. Облачный вариант со стартом 50 000 ₽ и 58 000 ₽ в месяц накапливает расходы быстрее. Итоговая выгода на третьем году не отменяет первоначальную потребность в бюджете.

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

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

Как проверить, не зависит ли вывод от одной удачной цифры?

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

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

Когда собственный сервер чаще выглядит убедительнее?

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

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

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

Когда облако может быть выгоднее?

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

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

Как сравнивать доступность и резервное копирование?

Разделите отказ оборудования, ошибку ПО, удаление данных и недоступность площадки. Один физический сервер с RAID и двумя БП не переживает все эти события. Облачная ВМ также не обязательно защищена от каждого из них одним базовым тарифом.

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

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

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

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

Для понимания масштаба: 99,9% доступности оставляют 0,1% времени, то есть 43,2 минуты за условные 30 дней. Это математическая интерпретация процента, а не обещание конкретного провайдера и не прогноз распределения сбоев. Один длинный инцидент и несколько коротких могут давать похожую долю времени, но различаться для бизнеса.

RTO отвечает за длительность возврата сервиса после конкретного события, RPO — за допустимую потерю последних изменений. Эти параметры не выводятся непосредственно из процента SLA. В обоих вариантах проверьте удаление данных, потерю узла, недоступность канала и сбой приложения. Если один вариант закрывает событие, а другой нет, бюджеты пока несопоставимы.

Как оценить цену простоя?

Используйте конкретные последствия: остановленные операции, дополнительные работы, перенос сроков и расходы на восстановление. Например, если организация сама оценила один час остановки в 50 000 ₽, сценарий четырёх часов даёт 200 000 ₽ последствий. Это сценарная оценка, а не гарантированный годовой убыток. Чтобы вычислять ожидаемую стоимость, нужна обоснованная вероятность, которую нельзя придумать.

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

Почему высокая доступность требует отдельного бюджета?

Для собственного варианта могут понадобиться дополнительные узлы, сеть, хранение и лицензии. Для облачного — разнесение ресурсов, резервные экземпляры, репликация, дополнительные услуги и настройка приложения. Ни второй сервер, ни вторая ВМ сами по себе не дают законченной схемы HA. Сравнивайте две проверенные архитектуры с одинаковыми требованиями к отказам.

Подходит ли гибридный вариант?

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

Проверьте зависимость приложений от расположения данных. Частые обращения через медленный или нестабильный канал способны изменить задержки и расходы. Локальная база с облачным приложением требует пилота на реальных операциях, а не только успешного ping.

Сколько стоит выйти из облака или перенести собственный сервер?

Стоимость выхода учитывают до покупки. Перенести ВМ, выгрузить данные управляемого сервиса и заменить SaaS — разные проекты. Уточните форматы экспорта, доступ к резервным копиям, права на ПО, порядок передачи ключей и срок доступности данных после завершения договора. Наличие кнопки «скачать» не подтверждает возможность быстро восстановить весь сервис.

В бюджет входят работа инженеров, передача данных, временное хранение и параллельная эксплуатация. Условный пример: дополнительные работы стоят 60 000 ₽, временное хранение — 15 000 ₽, один месяц параллельной среды — 45 000 ₽. Событие миграции добавляет 120 000 ₽, а не только цену скачивания файлов. Если оно запланировано за пределами 36 месяцев, покажите его отдельно от основного горизонта.

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

Как составить проверяемый план миграции?

1. Зафиксировать данные, приложения, зависимости, учётные записи и ключи.
2. Проверить экспорт и восстановление представительного сервиса на новой площадке.
3. Измерить доступную скорость переноса и время заключительной синхронизации.
4. Определить окно переключения и проверку пользователей после него.
5. Установить условия возврата к прежней среде и срок её сохранения.
6. Удалять старые ресурсы и завершать договор только после согласованной проверки результата.

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

Как принять решение, если суммы близки?

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

Составьте короткую записку решения: что сравнивали, какие требования одинаковы, какие расходы подтверждены предложениями и какие являются сценарными. Укажите условия пересмотра — рост выше определённого объёма, изменение тарифа, новые требования к восстановлению. Тогда выбор можно обновить по фактам, не начиная спор «сервер против облака» заново.

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

Что проверить перед окончательным выбором?

1. Одинаково описать сервисы, рост, RPO/RTO и условия обслуживания.
2. Подтвердить производительность представительным пилотом.
3. Получить комплектное предложение на сервер и полную спецификацию облачного тарифа.
4. Посчитать стартовые вложения, регулярные расходы, расширение и миграцию выхода.
5. Проверить базовый и неблагоприятный сценарии, границы ответственности и восстановление.
6. Зафиксировать результат вместе с исходными предположениями и датой предложений.

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

Как проверить рост бюджета и скрытые обязательства на 36 месяцев?

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

Пример роста регулярных расходов

Пусть условный пакет стоит 50 000 ₽ в месяц первый год, 60 000 ₽ второй и 72 000 ₽ третий. За три года получится 12 × (50 000 + 60 000 + 72 000) = 2 184 000 ₽. Постоянные 50 000 ₽ дали бы 1 800 000 ₽. Разница — 384 000 ₽, поэтому прогноз только по первому месяцу существенно меняет итог.

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

Как учесть скидку за обязательство?

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

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

Как сравнить лицензии, не ограничиваясь строкой «ОС включена»?

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

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

Как оценить связь и действия при её недоступности?

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

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

Какие документы должны завершать сравнение?

• Согласованная спецификация полезного сервиса и уровней восстановления.
• Актуальные предложения с полным составом услуг, сроком действия и способом учёта сумм.
• Таблица платежей по месяцам либо периодам с расширениями и выходом.
• Результат прикладного пилота и восстановления.
• Границы поддержки и ответственный за инцидент.
• Условия, при которых выбор пересматривается.

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

Частые вопросы: свой сервер или облако?

Правда ли, что любой сервер окупается за три года?

Нет. Срок зависит от стартовой разницы, месячных расходов, роста и состава услуг. Три года — выбранный горизонт модели, а не установленный срок замены оборудования.

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

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

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

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