Решили переезжать, потому что Slack перестал работать в России

Выбрали Time из-за кластерной архитектуры и понятного интерфейса

Перенесли в Time все интеграции и настройки за три недели

Развели сотрудников по выделенным пространствам внутри Time

Закрыли все цели и сэкономили ресурсы

У нас более 500 сотрудников, и до переезда в Time мы использовали три разных мессенджера. ИТ-команда жила в Slack, бэк-офис и операционная сеть — в Telegram, а служба поддержки пользователей — в Discord.

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

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

Нам было важно оперативно перенести данные и создать обособленные пространства для команд. Также хотелось, чтобы мессенджер имел функции, похожие на функции Slack, Telegram и Discord, и мы могли сохранить интеграции и легко адаптировать сотрудников.

Time закрывал наши требования и привлекал архитектурой, построенной на подходах Site Reliability Engineering (SRE). Это значит, что мессенджер устойчив к сбоям за счет следующих факторов:

• Кластерная архитектура. Time поддерживает запуск приложений в нескольких копиях и распределенное хранение на нескольких серверах одновременно. Это обеспечивает равномерную нагрузку даже при высоком числе одновременных пользователей.
• Автоматизированные процессы. Ручные операции сведены к минимуму, что снижает вероятность ошибок и обеспечивает стабильность системы. Time автоматически распределяет нагрузку между серверами, позволяет инженерам не отвлекаться на устранение мелких технических проблем.
• Высокая отказоустойчивость. Система продолжит работу при деградации кластера и даже при отказе отдельных компонентов. Например, если один сервер приложения выйдет из строя, другой автоматически возьмет на себя его функции, чтобы пользователи не заметили сбоя. В случае отказа одной из реплик базы данных приложение обнаружит это и распределит нагрузку на другие реплики.
• Мониторинг и алертинг. Time отслеживает ключевые метрики, такие как время отклика и типы ошибок. В случае отклонений от нормы система отправляет алерты ответственным инженерам.

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

Мы получили документацию и доступы к Time, и наш ИТ-отдел начал все настраивать. Трех технических специалистов оказалось достаточно, чтобы провести все интеграции.

Большую часть данных из Slack удалось перенести простой заменой URL-адресов. Интеграции, основанные на вебхуках, такие как Opsgenie, Prometheus AlertManager, Elasticsearch и Jira, также перенесли с помощью замены URL-адресов. Сами интеграции переписывать не пришлось.

За три недели все наши сотрудники и рабочие процессы переехали в Time. Причем полный объем информации, настройки и автоматизация процессов полностью перешли в новый мессенджер. Например, сразу заработали уведомления из Jira и алерты из Prometheus.

Интерфейс Time напоминает интерфейс Slack, поэтому он оказался интуитивно понятным для команды. Сотрудники сразу включились в работу и начали использовать мессенджер в полном объеме, в том числе работать в выделенных пространствах для ИТ, бэк-офиса и службы поддержки пользователей. Такое разделение помогло минимизировать хаос, избежать флуда в чатах и сделать работу каждого отдела более структурированной в одном мессенджере.

Переход в Time прошел быстро и без потери данных. Каждая команда получила свое пространство для работы, а мы смогли наладить коммуникацию между коллегами и отделами. Time закрыл все цели, которые мы ставили перед новым мессенджером, а мы в качестве бонуса получили экономию денежных и ИТ-ресурсов.

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