Окупаемость перехода со Slack на свой сервер: считаем на команду 50 человек

MAATRIX

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

Сколько на самом деле стоит Slack для команды из 50 человек

Slack, как и большинство SaaS-мессенджеров, берёт деньги по модели «цена за пользователя в месяц», умноженная на число активных мест в воркспейсе. У Slack исторически несколько тарифных линеек — от бесплатной с урезанной историей сообщений до платных уровней с расширенным поиском, гостевыми каналами, SSO и повышенными лимитами на звонки и интеграции. Точные цифры тарифов меняются, поэтому здесь и дальше мы не приводим конкретных долларов или рублей за место — актуальную цену всегда нужно смотреть по официальным тарифам на сайте Slack на момент расчёта, тем более что цена может отличаться в зависимости от валюты биллинга, годовой или помесячной оплаты и региона.

Вместо конкретной цифры возьмём методику, которая не устареет вместе с прайс-листом:

Годовая стоимость Slack = P × N × 12

где:

• P — цена одного платного места в месяц (смотрите на сайте Slack, для нужного вам тарифа);
• N — число оплачиваемых мест (внимание: это не всегда равно числу сотрудников);
• 12 — месяцев в году, с поправкой на скидку при годовой предоплате, если она есть у вашего тарифа.

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

Второй нюанс — рост N во времени. SaaS-модель «за голову» устроена так, что каждый новый сотрудник — это не разовая настройка, а постоянный прирост счёта. Команда, которая сегодня платит за 50 мест, через два года интенсивного найма может платить за 80, и рост будет линейным без каких-либо скидок на масштаб (кроме, возможно, перехода на более дешёвый корпоративный тариф при большом объёме — это тоже стоит уточнять индивидуально у отдела продаж). Именно эта черта модели чаще всего и подталкивает команды считать альтернативы.

Что нужно вместо Slack: self-hosted мессенджер и его стоимость

На стороне open-source есть два зрелых кандидата на замену Slack для командного чата — Mattermost и Rocket.Chat. Оба поддерживают каналы, треды, поиск, интеграции через вебхуки и боты, десктопные и мобильные клиенты, а бесплатные редакции (Team Edition у Mattermost, community-редакция у Rocket.Chat) закрывают базовые потребности команды в 50 человек без месячной платы за место. Разница между ними и что выбрать под конкретный сценарий разобрана в статье Mattermost или Rocket.Chat: что выгоднее и когда — здесь не будем повторять этот выбор, возьмём для расчёта Mattermost как более распространённый вариант для корпоративного чата.

Стоимость этой части раскладывается на два принципиально разных элемента, и их нельзя путать:

1. Аренда сервера. Для команды в 50 человек с активной перепиской, несколькими десятками каналов и умеренным использованием файлового обмена достаточно скромной VPS-конфигурации — порядка 2 vCPU и 4 ГБ RAM для самого Mattermost плюс отдельная база данных PostgreSQL, которая на таком объёме комфортно живёт на том же сервере. Точную конфигурацию под вашу нагрузку и её ресурсоёмкость стоит свериться со статьёй сколько RAM нужно для Mattermost — там разбор по числу активных пользователей и объёму истории. Ориентировочно такая конфигурация на VPS с оплатой картой или криптой обойдётся в сумму на порядок меньше годового счёта за 50 платных мест в Slack — но здесь мы намеренно не называем точную цифру в рублях, потому что тарифы на серверы и курсы валют меняются быстрее, чем выходит эта статья; актуальную стоимость смотрите в тарифах на сайте хостинга на момент расчёта.

2. Время на развёртывание и поддержку. Это то, что SaaS-модель включает в цену подписки, а self-hosted — нет. Разворачивается Mattermost относительно быстро (пошаговая установка на Ubuntu 24.04 описана в статье как установить и настроить Mattermost на VPS), но дальше нужно кому-то в команде взять на себя обновления безопасности, мониторинг доступности, настройку TLS-сертификата, бэкапы базы данных и файлового хранилища. Это не разовая задача, а повторяющаяся, и её стоимость нужно считать не в деньгах за инфраструктуру, а в часах штатного сотрудника (или подрядчика), которые он тратит на это вместо другой работы.

Честная формула стоимости self-hosted решения выглядит так:

Годовая стоимость self-hosted = Аренда_сервера × 12
                                + Часы_поддержки_в_месяц × Часовая_ставка × 12
                                + Разовые_затраты_на_миграцию

Часы поддержки для стабильно работающей инсталляции Mattermost на 50 человек — это не полная ставка DevOps-инженера, а скорее несколько часов в месяц у человека, который и так администрирует прочую инфраструктуру компании: применить обновление, проверить бэкап, разобрать один-два тикета от пользователей. Но если в команде нет такого человека и его нужно нанимать или обучать с нуля именно под эту задачу, трудозатраты стоит считать не оптимистично, а с запасом на первые несколько месяцев, пока не отладятся процессы.

Разовые затраты на переход, которые часто забывают

Прежде чем сравнивать годовые суммы, нужно учесть разовую стоимость самого перехода — она съедает часть экономии в первый год и может свести её к нулю, если её не спланировать. Сюда входит:

• Перенос истории сообщений. У Mattermost есть встроенные инструменты миграции из Slack-экспорта (JSON-архив с сообщениями и вложениями), но перенос не идеален: часть форматирования, реакций и упоминаний может измениться, вложения нужно перезалить, а сам процесс на 50 пользователей с многолетней историей может занять от нескольких часов до пары дней в зависимости от объёма архива.
• Обучение команды. Даже похожий по логике интерфейс требует адаптации: горячие клавиши другие, поиск работает иначе, часть привычных интеграций (например, кастомные Slack-приложения из маркетплейса) нужно будет либо найти аналог, либо написать самостоятельно через вебхуки.
• Параллельный период. На практике команды редко переключаются одномоментно — обычно две-три недели оба инструмента работают параллельно, что означает временное дублирование затрат (Slack ещё не отключён, а новый сервер уже оплачивается).
• Настройка интеграций заново. Все боты, CI/CD-уведомления, интеграции с таск-трекером и календарём, которые были настроены в Slack годами, нужно поднять заново под Mattermost или Rocket.Chat — где-то это готовый плагин, где-то — самописный вебхук.

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

Что вы теряете при переходе на self-hosted мессенджер

Честный разбор обязан включать список потерь, а не только выгод — иначе это не расчёт, а реклама.

• Меньше готовых интеграций. У Slack многолетний маркетплейс приложений: от Google Calendar до узкоспециализированных корпоративных SaaS. У Mattermost и Rocket.Chat экосистема плагинов заметно меньше, и часть интеграций, которые в Slack ставились за пару кликов, на self-hosted решении придётся писать самим через API или вебхуки.
• Техподдержка — целиком на вас. В Slack за доступность сервиса, устранение инцидентов и security-патчи отвечает вендор. На своём сервере эта ответственность полностью переходит на вашу команду: если сервер упал ночью, чинить его будете вы, а не служба поддержки SaaS.
• Меньше отполированности мобильных клиентов. Официальные мобильные приложения Mattermost и Rocket.Chat рабочие, но по ощущениям UX и стабильности пуш-уведомлений уступают Slack — это стоит проверить на пилотной группе перед полным переездом, а не полагаться на общие впечатления из интернета.
• Нет встроенной инфраструктуры на случай отказа по умолчанию. У Slack за отказоустойчивость дата-центров отвечает сам сервис. На своём сервере резервирование, мониторинг и план восстановления после сбоя — это то, что нужно строить самим, и это дополнительная статья расходов сверх голой аренды VPS.
• Сложнее compliance «из коробки». Если компании нужны специфические сертификации (например, определённые стандарты обработки данных), у крупных SaaS они часто уже пройдены вендором. На self-hosted решении соответствие нужно обеспечивать самостоятельно.

Что вы приобретаете взамен

• Контроль над данными. Вся переписка, файлы и история хранятся на сервере, который принадлежит вам, а не в инфраструктуре стороннего вендора с его собственной политикой хранения и доступа третьих лиц по запросу.
• Предсказуемая стоимость инфраструктуры. Цена VPS не растёт линейно с числом сотрудников — сервер, рассчитанный на 50 человек, с запасом обслужит и 65-70 без апгрейда, а стоимость самой аренды не привязана к штатной численности.
• Нет риска блокировки аккаунта вендором. SaaS-сервис теоретически может ограничить доступ воркспейсу по своим внутренним причинам — это редкий, но реальный риск для бизнеса, зависящего от иностранного сервиса. Свой сервер такому риску не подвержен.
• Гибкость кастомизации. Открытый исходный код позволяет менять поведение системы под свои процессы там, где закрытый SaaS этого просто не позволит, каким бы длинным ни был список его настроек.
• Отсутствие growth-налога. Это главный финансовый аргумент: в Slack каждый новый сотрудник — это гарантированный прирост ежемесячного счёта. На self-hosted решении рост команды не увеличивает стоимость инфраструктуры напрямую, пока не упирается в реальный потолок производительности сервера.

Точка окупаемости: при каком условии переход выгоден

Сведём всё в одну формулу. Переход окупается, когда накопленная экономия превышает разовые затраты на миграцию за разумный горизонт (обычно 12-24 месяца, потому что более длинные горизонты слишком чувствительны к смене тарифов и роста команды):

Экономия_за_период = (Годовая_стоимость_Slack − Годовая_стоимость_self-hosted) × Число_лет
                      − Разовые_затраты_на_миграцию

Переход выгоден, если Экономия_за_период > 0

На практике для команды в 50 человек это условие выполняется тем увереннее, чем больше выполняется каждый из следующих пунктов:

Если у вас растущая команда, есть кому поддерживать инфраструктуру и горизонт использования от двух лет — расчёт почти всегда в пользу self-hosted, потому что growth-налог SaaS-модели со временем перекрывает даже разовые затраты на миграцию и обучение. Если команда стабильна по численности, интеграций со Slack много, а своего технического персонала нет и нанимать его невыгодно ради одного сервиса — экономия на бумаге может не отработать из-за скрытых трудозатрат на поддержку, и тогда честнее остаться на SaaS или хотя бы отложить переход до момента, когда появится профильный специалист.

Отдельно стоит проговорить: сама по себе аренда сервера — не главная статья расходов в этом уравнении. Разница между дешёвой и чуть более дорогой конфигурацией VPS для 50 человек измеряется copейками по сравнению с годовым счётом за Slack. Основной риск неудачного перехода — это недооценённые трудозатраты на поддержку и миграцию, а не выбор тарифа хостинга.

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