Сколько стоит почта на своём сервере и в облаке для офиса до 50 человек

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

Миф о дешевизне собственного сервера: где прячется TCO

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

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

Кейс сети «Горизонт»: как они посчитали и ошиблись

В задании задана сеть «Горизонт» как условный пример. Я не выдаю её за реального клиента и не приписываю ей аварии, потери писем или финансовый результат, которых нельзя подтвердить. Представим офис на 45 человек, где почта работает на локальном Exchange 2013. Это версия с завершённой поддержкой: Поддержка Exchange Server 2013 завершилась в апреле 2023 года. Следовательно, при выборе следующего шага надо учитывать отсутствие обычной поддержки и обновлений безопасности; сама эта дата не доказывает, что конкретная установка уже скомпрометирована. Варианты — спланированный переход на поддерживаемую платформу, размещение почты у поставщика или сопровождение собственной системы при наличии компетенций. Купить железо за условные 150 тысяч рублей и объявить задачу решённой нельзя: к цене покупки добавятся все регулярные работы и ответственность за восстановление.

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

Облако vs Своё железо: сравнение рисков и стоимости

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

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

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

Как правильно перенести почту: этапы миграции

Перенос начинаю с карты исходной системы: ящики, псевдонимы, общие адреса, группы, календари, архивы, правила и устройства, которые отправляют почту. Затем фиксирую целевую платформу, проверяю домен и доступы, измеряю объём данных, готовлю план переключения и отката. Для Exchange способ зависит от версии, состояния организации и целевой системы. Microsoft описывает cutover-миграцию как перенос всей организации одним этапом и указывает поддержку до 2 000 ящиков, но рекомендует мигрировать не более 150. Это не обещание, что перенос закончится за конкретное число часов: скорость зависит от объёма, канала, ограничений сторон и состояния почтовой базы. Для меньшего офиса метод всё равно выбирают по совместимости и рискам, а не только по числу ящиков.

Гибридный сценарий может переносить ящики партиями и временно поддерживать совместную работу локальной и облачной среды Exchange. В документации Microsoft для минимальной гибридной миграции описан перенос содержимого ящиков в течение нескольких недель или меньше; это ориентир конкретного сценария, не гарантия для любого источника и назначения. Я планирую пилот на нескольких разных ящиках: обычном, с большим архивом и с нестандартными правилами. Проверяю отправку и приём, папки, вложения, календари, мобильные устройства и общие адреса. До массового переноса согласовываю окно переключения и способ вернуть маршрутизацию, если контроль не пройден. Перенос последних шести месяцев не объявляю обязательным правилом: срок хранения выбирает владелец данных, а объём истории влияет на план и длительность синхронизации. Старую систему не отключаю, пока не сверены результаты и не закрыт согласованный период контроля.

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

Безопасность и защита данных: кто отвечает за пароль?

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

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

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

Итоги: что выбрать для офиса до 50 человек

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

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

Частые вопросы