Как мы сэкономили 3 млн рублей в год, заменив Slack на Rocket.Chat

Google Talk, Jabber, Slack, WhatsApp, Telegram, Zulip, Rocket.Chat, Selectel Chat, — мы не собрали рейтинг мессенджеров, но описали свой путь к идеальному для нас корпоративному инструменту.

Опыт может быть полезен и вам: мы несколько раз меняли ориентиры и успешно перестраивались на новые технологичные волны.

В начале был Jabber

Первыми корпоративными мессенджерами в Selectel были Google Talk и Jabber. C момента основания компании мы использовали экосистему Googlе для работы с электронной почтой и документами, а GTalk был тесно интегрирован с почтовым сервисом и позволял обмениваться сообщениями прямо из интерфейса Gmail. Однако, большими недостатками GTalk было отсутствие групповых чатов и каких-либо интеграций.

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

Welcome to Slack

Спустя несколько лет нам пришлось задуматься о смене корпоративного мессенджера. Хотя с технической точки зрения Jabber в целом устраивал, мобильные клиенты были достаточно архаичными. Это вызывало проблемы с настройкой и подключением у тех сотрудников, которые не имеют непосредственного отношения к IT. Самостоятельная настройка Jabber для сотрудников той же бухгалтерии была нетривиальной задачей.

Параллельно появился сначала WhatsApp, а потом и Telegram, которые были на порядок удобнее своих предшественников, поэтому очень скоро мы обнаружили что по факту вся переписка сотрудников идет в Telegram, а официальный корпоративный Jabber пришел в полное запустение. Этого ли мы хотели? 🤔

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

Что изменилось благодаря Slack:

• Теперь при приеме на работу все сотрудники автоматически получали аккаунт, где уже есть все коллеги, что сильно облегчало онбординг и помогало при необходимости делать массовые объявления и получать обратную связь.
• Любое событие от мониторинга или непосредственно от устройств прилетало прямо в мессенджер ответственному сотруднику или отделу. Обо всех инцидентах инфраструктуры мгновенно оповещались все сотрудники, чтобы действовать соответствующим образом.
• При совместной работе с документами в Google Docs, Slack оповещал о сделанных изменениях и тем самым сразу обращал на них внимание получателя.
• Впоследствии в Slack прокрались и разнообразные боты, например, наш собственный HR-бот, позволявший бронировать переговорные комнаты, узнавать даты выплаты заработной платы и даже просто поболтать с «искусственным интеллектом», если все люди надоели.

Кажется, нам нужен новый мессенджер!

1. Корпоративный мессенджер — важный инструмент, который должен быть очень надежным для обеспечения непрерывной работы. В доступности Slack из России несколько раз возникали сбои: как из-за отказов работы самого сервиса, так и из-за проделок Роскомнадзора.
2. Мы ожидаем от мессенджера приватность и безопасность. Но в случае Slack, как и в любом SaaS сервисе, неизвестно, насколько безопасно можно использовать его для обмена приватными данными и конфиденциальных коммуникаций, поэтому для наиболее критичных для бизнеса вопросов приходилось искать другие инструменты коммуникации.
3. Постепенно число сотрудников компании растет, и уже приближается к 500 человек. Цена Slack тоже незаметно, но неуклонно увеличивалась, и за прошлый год составила для нас около 3 млн рублей.
4. В России есть федеральный закон № 152-ФЗ «О персональных данных». Slack не соответствует требованиям этого закона и хранит все данные на серверах за границей. В принципе все западные сервисы так делают, и пришли пока только за Linkedin, но все же — это дополнительный риск.

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

Прежде всего наше внимание привлекла к себе платформа Zulip, которая является средством корпоративной коммуникации в Dropbox. Платформа стала доступна под свободной лицензией Apache 2.0 после того как Dropbox выкупил Zulip в 2014 году и опубликовал исходный код приложения на Github. Написанный на Python и использующий PostgreSQL в качестве базы данных, Zulip легко интегрируется практически со всеми популярными системами и поддерживает множество разных сервисов, а клиенты Zulip есть под все популярные мобильные и десктопные платформы. Но в процессе тестирования мы отметили низкую скорость работы решения, а также непривычную и сложную структуру интерфейса: потоки делятся на темы, темы содержат в себе чаты. А нам хотелось сделать переход со Slack максимально простым и бесшовным.

Вторым рассматриваемым вариантом стал Rocket.Chat, выпущенный по лицензии MIT. Что нам больше всего понравилось — по функциональным возможностям и интерфейсу Rocket.Chat максимально схож со Slack: также позволяет создавать публичные каналы, закрытые группы и обсуждения, обмениваться файлами, аудио- и видеосообщениями. Работа над улучшением Rocket.Chat ведется постоянно, о чем свидетельствует множество коммитов на Github.

Оценив плюсы и минусы разных платформ, мы приняли решение: переходим на Rocket.Chat, а в случае выявления серьезных проблем в его работе запасным вариантом оставляем Zulip.

Как осуществлялся переезд

Серверное приложение Rocket.Chat написано на JavaScript и использует MongoDB в качестве хранилища сообщений. Поэтому в первую очередь нам следовало обеспечить отказоустойчивость базы данных. MongoDB «из коробки» поддерживает аварийное переключение (Failover) при помощи механизма репликации, поэтому мы развернули 3 небольшие виртуальные машины в разных регионах и настроили механизм Replica Set. Приложение архитектурно построено таким образом, что мы передаем ему данные обо всех репликах в наборе и оно само распределяет нагрузку между ними (с какой реплики читать и в какую писать).

Для развертывания сервера мы используем официальный Docker-образ Rocket.Chat, размещенный в DockerHub. Приложение запущено в 3-х экземплярах на разных физических хостах и управляется с помощью Kubernetes. Нагрузка на «поды» (совокупность запущенных контейнеров) балансируется также средствами Kubernetes, обеспечивая тем самым не только равномерность утилизации ресурсов, но и возможность производить обновления без остановки сервиса. В этом случае один из подов останавливается, корректно обрабатывая все активные подключения, и вместо него запускается новый под с обновленной версией образа приложения. Помимо легкости обновления, такой подход позволяет буквально в 1 клик масштабироваться горизонтально при возрастающей нагрузке.

Следует отметить, что Rocket.Chat имеет важную особенность. Все пересылаемые в чатах файлы приложение по умолчанию хранит локально, а не в БД. Поэтому, когда требуется работа нескольких экземпляров приложения, нужно общее хранилище. В нашем случае мы воспользовались собственным S3-совместимым Облачным хранилищем, доступ к которому организовали для всех экземпляров приложения. Это позволило всем экземплярам приложения хранить файлы в едином месте, но это не стало потенциальной точкой отказа, так как все данные, размещенные в облачном хранилище, реплицируются N+2.

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