Почта для офиса на 20 человек: сервер или облачный сервис

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

Какие требования предъявить почте на 20 сотрудников

Начинаю не с выбора сервера, а со списка рабочих требований: сколько сотрудников и общих адресов, какой объём архива нужен, используются ли календари и мобильные устройства, как сотрудники работают с 1С и кто отвечает на обращения. Если ящикам нужен архив за несколько лет, это надо записать отдельно от объёма облачного Диска: почтовая квота и файловое хранилище — разные вещи. В тарифах Яндекс 360 сейчас заявлен бесконечный почтовый ящик, а объём Диска на сотрудника указан отдельно. Поэтому требование «минимум 20 ГБ почты» нельзя выдавать за универсальную норму или за лимит сервиса. Проверяю актуальные условия перед договором, потому что тарифы меняются. Для проектирования корпоративной почты фиксирую также требования к общим адресам, делегированию и хранению писем.

Затем выясняю, что значит «интеграция с 1С». Иногда программе нужно лишь отправлять уведомления через SMTP; иногда сотрудникам нужна полноценная работа с календарями и адресной книгой. Это разные задачи с разными способами подключения. Я не обещаю интеграцию одним словом, пока не знаю версию 1С, сценарий отправки и действующие ограничения почтовой платформы. То же правило относится к журналам аудита, архиву и срокам хранения: наличие почты в тарифе не означает, что в нём есть любая нужная функция. Составляю короткий список обязательного, желательного и необязательного. Так сравниваются решения, а не рекламные описания.

Есть и практичная мелочь, которую легко пропустить в расчёте: общие адреса вроде info@ или sales@ — это не обязательно отдельные пользовательские лицензии, но способ совместного доступа зависит от тарифа. В документации Яндекс 360 указано: к одному общему ящику могут получить доступ до 10 пользователей на тарифах «Минимальный» и «Основной» и до 40 — на «Продвинутом» и корпоративных тарифах. Это конкретное ограничение имеет значение для очереди поддержки или отдела продаж. Я записываю, кто читает входящие, кто имеет право отправлять от имени адреса и что увидит получатель. Если сотрудник уходит, доступ нужно отозвать и проверить; само наличие общего адреса не решает управление правами.

С общими ящиками важен не только лимит. Документация Яндекс различает отправку «от имени» и отправку «как»: в первом случае адресат видит фактического отправителя, во втором письмо выглядит отправленным от имени общего адреса. В веб-интерфейсе доступен режим «как», а почтовый клиент должен поддерживать нужное действие и иметь соответствующие права. Это влияет на разбор претензий и на то, как сотрудники ведут переписку от имени отдела. Я заранее проверяю сценарий на тестовом ящике: удобная функция с неверно назначенными правами быстро превращается в путаницу с авторством писем.

• Число пользовательских и общих ящиков
• Нужный срок хранения писем
• Календарь, мобильные клиенты и делегирование
• Сценарий связи с 1С
• Кто отвечает за поддержку и восстановление

Из чего складывается TCO своего почтового сервера

В собственной схеме Postfix может принимать и отправлять почту, а Dovecot — предоставлять доступ к почтовым ящикам. Но названия двух программ ещё не образуют готовую почтовую систему. Нужны домен и DNS, хранилище, учётные записи, защита от нежелательной почты, контроль очереди, обновления, мониторинг и план восстановления. Развернуть это можно на VPS или на своём оборудовании; у вариантов разные статьи затрат. Для VPS считаю аренду и резервное хранилище, для собственной площадки — оборудование, замену компонентов, питание и доступность площадки. В обоих вариантах отдельно закладываю часы специалиста на поддержку и аварийные работы. Связку Postfix и Dovecot экспертная база фиксирует как распространённый набор компонентов, но она не подтверждает универсальную стоимость владения: её нужно считать по конкретной архитектуре.

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

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

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

• VPS или оборудование и площадка
• Часы администратора и подмена специалиста
• Мониторинг, обновления и антиспам
• Резервное хранение и тест восстановления
• Простой и работы по возврату сервиса

Что именно сравнивать в облачном тарифе

Яндекс 360 для бизнеса объединяет корпоративную почту на домене с другими сервисами; состав функций и объём Диска зависят от тарифа. На официальной странице сейчас указаны разные варианты оплаты и объёмы облачного хранилища. В описании тарифов почтовый ящик назван бесконечным, поэтому прежнее утверждение о фиксированных 20 ГБ на ящик неверно. Цена считается по действующим условиям и числу сотрудников, а не по выдуманному «фиксированному годовому бюджету». Перед расчётом проверяю, что именно включено для организации, какие функции требуют более высокого плана и как оплачиваются дополнительные пользователи. Текущую цену следует брать из официальной таблицы тарифов непосредственно перед покупкой.

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

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

• Тариф и стоимость на сотрудника
• Объём Диска отдельно от почтового ящика
• Нужные функции архива и аудита
• Условия поддержки и восстановления
• Правила оплаты дополнительных пользователей

Риски: доставка, резервные копии и ответственность

У собственного сервера есть операционные задачи, которые часто забывают включить в проект. Для исходящей почты настраивают аутентификацию домена, включая SPF и DKIM; DMARC помогает применять политику домена к сообщениям, не прошедшим проверки. Но эти записи не гарантируют попадание во входящие: репутация отправителя, содержимое писем и правила принимающих систем тоже влияют на результат. Проверяю DNS после изменения и слежу за отчётами, а не объявляю доставляемость решённой одной записью. Во время переноса особенно важно понять, кто сейчас принимает входящие письма и в какой момент менять MX. Инструкция Яндекса объясняет назначение MX и указывает, что распространение DNS-изменений может занять до 72 часов; это верхний ориентир для обновления данных, а не обещание длительности каждой миграции.

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

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

• SPF и DKIM для отправки от домена
• DMARC и анализ результатов проверок
• Копии отдельно от основного хранилища
• Регулярное тестовое восстановление
• Зафиксированные границы ответственности

Как принять решение и спланировать переход

Для условной компании «Шторм-Трейд» я бы сначала собрал инвентаризацию: список 20 сотрудников, общие адреса, размер ящиков, используемые клиенты и сценарии 1С. Затем уточнил бы требования по сроку хранения и восстановлению. Лишь после этого можно сравнить текущий сервер с тарифами облака и оценить стоимость перехода. В статье нет подтверждённых счетов, измерений простоя или договора этой компании, поэтому я не приписываю ей миграцию за два дня, экономию в сотни тысяч рублей или получение SLA. Это не результаты расчёта, а придуманные числа. На практике срок зависит от объёма писем, числа ящиков, состояния исходной системы, доступа к ней и окна переключения. Экспертная база также отмечает зависимость срока переноса от объёма переписки и числа ящиков. Поэтому срок называю после инвентаризации и пробного переноса, а не по числу сотрудников.

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

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

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

• Инвентаризация ящиков и сценариев
• Расчёт TCO за одинаковый период
• Пробный перенос и сверка данных
• План переключения DNS и поддержки
• Ответственный за дальнейшую эксплуатацию

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