За последние несколько лет on-premise решения стали одним из основных направлений развития корпоративных коммуникаций. Причины понятны: требования информационной безопасности, контроль над данными и независимость от внешних сервисов.

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

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

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

Все начинается не с установки

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

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

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

Команда оценивает организационную структуру заказчика, предполагаемое количество пользователей, особенности администрирования и существующие бизнес-процессы. Одновременно определяется состав будущего решения: потребуется ли запуск локальных сервисов искусственного интеллекта, нужен ли внутренний корпоративный видеопортал, какие средства защиты уже используются в инфраструктуре и потребуется ли дополнительно развернуть WAF (Web Application Firewall), а также с какими внутренними системами предстоит интегрироваться.

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

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

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

Когда мессенджер становится частью инфраструктуры

После проверки инфраструктуры начинается подготовка среды для будущего кластера.

Настраивается сеть, маршрутизация, DNS, сертификаты, параметры операционной системы, различные подсистемы и политики доступа. Со стороны может показаться, что все это не имеет отношения к мессенджеру, однако именно здесь определяется надежность будущей системы.

Современный корпоративный мессенджер давно перестал быть одним приложением. За чатами, звонками и каналами обычно скрываются десятки взаимосвязанных сервисов, которые должны работать как единая платформа.

Платформу коммуникаций Frisbee мы разворачиваем на платформе контейнеризации dBrain.cloud — это также наш продукт, облачная платформа, которая выступает инфраструктурной основой для любых микросервисных приложений (подробнее о платформе читайте в блоге).

По сути, dBrain.cloud берет на себя задачи подготовки и управления Kubernetes-кластером, развертывания инфраструктурных сервисов, мониторинга, логирования и дальнейшей эксплуатации платформы. Благодаря этому внедрение не сводится к ручной настройке десятков компонентов и позволяет воспроизводить одинаковую архитектуру в различных инфраструктурах заказчиков. Для заказчика это означает, что вместе с мессенджером он бесплатно получает не просто набор сервисов для обмена сообщениями, а полноценную отказоустойчивую инфраструктуру для эксплуатации корпоративных коммуникаций с системой мониторинга, бэкапирования, резервирования и понятным горизонтальным масштабированием.

Как выглядит деплой на практике

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

Следующим шагом становится подготовка конфигурации будущего развертывания. По сути, именно этот конфигурационный файл описывает, как будет выглядеть инфраструктура после завершения установки. В нем задаются все необходимые сервисы и параметры платформы. Например, будет ли использоваться локальный registry для хранения контейнерных образов, потребуется ли MAAS-сервер для управления физическими узлами, какие ресурсы необходимо выделить под мониторинг и систему логирования, нужен ли внутренний S3-совместимый слой хранения данных.

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

Сам деплой выполняется совместно с командой DevOps, однако большая часть процесса автоматизирована. Для установки используются собственные скрипты развертывания, разработанные командой dBrain.cloud.

Процесс установки разделен на несколько последовательных этапов. Сначала выполняется подготовка операционной системы и обновление необходимых пакетов до поддерживаемых версий. После этого устанавливается специализированное Linux-ядро, которое используется платформой dBrain.cloud и предварительно тестируется командой разработки.

Следующим этапом разворачивается Kubernetes-кластер. Именно он становится базовой средой выполнения для всех сервисов платформы. После установки Kubernetes при необходимости разворачивается кластер Ceph, который обеспечивает S3-совместимое хранение файлов, вложений и других данных платформы.

Завершающим этапом становятся сервисы мониторинга. Внутрь кластера устанавливаются система мониторинга на базе Grafana и система централизованного логирования на базе Elasticsearch и Kibana.

Фактически еще до подключения первых пользователей команда эксплуатации получает полную картину состояния платформы и всех инфраструктурных компонентов.

После развертывания платформы контейнеризации, настройки WAF и сетевой связанности с CI/CD начинается выкатка самого мессенджера. Если между контуром заказчика и CI/CD проложен защищенный сетевой мост, команда запускает пайплайн, который загружает контейнерные образы Frisbee в подготовленный кластер. Затем выполняется прикладная настройка инсталляции и переносятся необходимые данные. Отдельно настраивается подключение для видеоконференций. После этого инфраструктурная платформа превращается в готовый к работе корпоративный мессенджер с настроенными сервисами, интерфейсом и функциями.

СЗИ — не галочка, а архитектура

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

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

Именно поэтому вопросы безопасности прорабатываются еще на этапе проектирования.

У некоторых крупных заказчиков уже существует собственный стек средств защиты информации, и наша задача — корректно встроить платформу в существующую архитектуру. Но бывают проекты, где отдельные компоненты отсутствуют. Например, если в инфраструктуре заказчика нет собственного Web Application Firewall, мы можем использовать Frisbee WAF — наша собственная разработка.

WAF в корпоративном мессенджере — это не про «закрыть дыры в вебе». Он контролирует весь поток запросов на опубликованные в сети Интернет приложения: авторизацию, загрузку файлов, отправку сообщений, поиск, работу API и другие сервисные операции. По сути, это первый рубеж защиты, который анализирует входящий трафик, выявляет аномальное поведение и блокирует потенциальные атаки еще до того, как они достигнут сервисов платформы.

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

Эксплуатация начинается сразу после запуска

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

Поэтому сразу после развертывания настраивается система мониторинга. Все оповещения условно делятся на две категории.

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

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

Такой подход позволяет выявлять большинство инфраструктурных проблем еще до того, как их заметят пользователи.

А как обновлять систему в закрытом контуре?

Если политика безопасности заказчика позволяет предоставить контролируемый доступ к инфраструктуре, для платформы может быть настроен полноценный CI/CD-процесс. В этом случае новые версии автоматически проходят весь путь от публикации до установки в Kubernetes-кластере. Но в полностью закрытых контурах такой сценарий возможен не всегда.

Тогда обновления выполняются вручную совместно с командами эксплуатации, DevOps-инженерами и разработчиками.

Для многих государственных организаций, промышленных предприятий и объектов критической инфраструктуры именно такой подход остается стандартной практикой.

Закрытый контур и push-уведомления

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

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

Для большинства сотрудников такой сценарий неудобен. Поэтому даже в закрытых инфраструктурах обычно создаются строго контролируемые каналы взаимодействия с сервисами доставки push-уведомлений.

После этого возникает следующий закономерный вопрос: получают ли внешние сервисы доступ к содержимому корпоративной переписки? Нет.

Во Frisbee содержимое push-уведомлений передается только в зашифрованном виде. Когда пользователь отправляет сообщение, сервер формирует push-уведомление и помещает в него зашифрованный payload. При этом ключ шифрования никогда не передается вместе с уведомлением. Внешний сервис доставки получает лишь набор зашифрованных данных, который невозможно расшифровать без клиентского ключа. Сам ключ существует только на устройстве получателя.

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

Для компаний с повышенными требованиями к безопасности это позволяет сохранить привычный пользовательский опыт без компромиссов в вопросах защиты данных.

Одинаковых внедрений почти не бывает

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

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

Хороший пример из нашей практики — интеграция с корпоративной SIP-телефонией. Во многих крупных компаниях телефонная инфраструктура существует десятилетиями и остается одним из ключевых инструментов коммуникации. При внедрении одной из таких систем в корпорации с аудиторией несколько десятков тысяч сотрудников нашей задачей было не заменить существующую телефонию, а сделать ее частью новой платформы коммуникаций.

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

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

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

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

Корпоративный мессенджер сегодня — это уже полноценная часть инфраструктуры компании. И чем крупнее организация, тем заметнее становится эта трансформация.

А как у вас обстоят дела с on-premise-решениями? С какими неожиданными задачами вы сталкивались при внедрении корпоративных коммуникационных платформ? Делитесь опытом в комментариях — интересно сравнить подходы и обсудить реальные кейсы.