Возможен ли перевод крупной организации на опенсорсную корпоративную почту

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

Существует два типа почтовых решений — классические почтовые системы, то есть, разворачиваемые на собственной серверной инфраструктуре (on-premise), и облачные (cloud-born), которые были разработаны крупными почтовыми SaaS-провайдерами. Первые можно тиражировать и масштабировать на тысячи пользователей. Вторые же существуют в единственном экземпляре, полностью подконтрольны провайдеру и могут обслуживать десятки, даже сотни миллионов пользователей.

Cloud Native решения строятся как набор микросервисов, слабо связанных между собой и упакованных в контейнеры. Такие контейнеризированные приложения автоматически управляются облачными платформами, а сама микросервисная архитектура может масштабироваться до уровней, которые сложно достичь в монолитной. Кроме того, Cloud Native решения в сравнении с продуктами монолитной архитектуры более гибкие, но при этом стабильные и для их разработки необходимо меньше времени. Немаловажно, что показатели надежности продукта, построенного на принципе Cloud Native, позволяют обеспечить отсутствие времени видимого простоя – то есть, говоря на языке обычного пользователя, софт не будет «зависать». Можно считать, что решение соответствует принципу Cloud Native только в том случае, если оно способно к автоматическому мониторингу, самовосстановлению и масштабируемости.

В последние годы многие мировые производители программного обеспечения делают ставку на собственные публичные облака, куда помимо прочих продуктов также перемещаются и корпоративные продукты — почта, адресная книга и календарь. Так, по оценке The Radicati Group только за прошедшие 5 лет соотношение почтовых ящиков в облаках и на собственных серверах кардинально изменилось. И если в 2016 году облачных ящиков сервиса Microsoft Office 365 было всего 27% от общего количества, то в 2021-м их стало уже 67%, причем, рост доли произошел за счет сокращения доли on-premise ящиков. Если говорить про рынок в целом, то по оценкам аналитиков IDC среднегодовые темы роста рынка облачных услуг составляют 20%.

Ключевым требованием к корпоративным почтовым системам является гарантия отсутствия доступа третьих лиц к конфиденциальной информации. И публичные облака, очевидно, не могут ему соответствовать в полной мере — ведь физический доступ к данным в любом случае будет у самого владельца облака. Расположение же сервисов в ЦОД стран Европы и США также кратко увеличивает риски информационной безопасности. И с этим не готов мириться ни крупный бизнес, ни государства, проводящие проекты цифровой трансформации.

В 2021 году во всем мире наметился новый тренд на консолидацию. Участники отрасли стремятся к централизации ИТ-инфраструктур, чтобы максимально оптимизировать собственные бизнес-процессы и повысить управляемость информационных систем. Консолидация позволяет более гибко использовать IT-ресурсы, снизить стоимость владения средствами ИБ, а также избавляет от дублирования программного обеспечения на разрозненных серверах и облаках, создания копий интегрированных систем и обслуживания сразу нескольких хранилищ данных. Это особенно актуально для государственных корпораций России с филиалами по всей стране, поскольку их нынешняя традиционная архитектура требует большого числа дублируемых решений и ресурсов для их обслуживания и контроля.

Ноябрь 2021 года. Практически одновременно и не сговариваясь друг с другом, две российские ИТ-компании объявили о выпуске своих почтовых решений — МойОфис представил Mailion, а НПО «РусБИТех» — RuPost. Первое решение уже официально представлено, в настоящий момент стартовали пилотные проекты внедрения на нескольких крупных российских предприятиях. Второе пока еще только анонсировано, его появление на рынок запланировано на середину 2022 года.

Ключевым отличием двух разработок является технологический стек. В то время как инженеры МойОфис создают собственный продукт своими силами «с нуля» и доля СПО в нем, если считать в компонентах, не превышает 5%, наши коллеги по российскому рынку напротив решили сформировать свое решение из множества доступных на рынке опенсорсных технологий. Давайте разберемся, в чем разница между этими решениями.

МойОфис более 5 лет назад приступил к созданию собственного on-premise почтового решения для крупных компаний. Mailion – корпоративная почта нового поколения, которая построена на Cloud Native микросервисной архитектуре, поддерживает до миллиона пользователей и разворачивается на собственных серверах организации. В составе: почта, календарь, контакты, а также умный поиск. Mailion развивается при поддержке РФРИТ — фонд выделил 298,591 млн рублей на доработку и вывод продукта на рынок, и для фонда этот грант стал крупнейшим в истории российского ИТ-рынка. Общий же объем инвестиций в продукт в 2021 году превысил 429,543 млн рублей — с учетом нашего софинансирования в размере 130,952 млн рублей.

Любой продукт класса Enterprise требует длительного проектирования и большой команды. Применяя только СПО, это сделать гораздо сложнее. Нужно собрать команду, кто-то должен это финансировать, люди где-то должны работать: либо full-time на этом проекте, в режиме создания собственного СПО, либо рart-time при его создании. Сразу возникает вопрос – а насколько быстро такие команды придут к результату и насколько ответственно они будут подходить к своей работе?

Если потратить немного времени и разобраться в вопросе, то станет понятно, что в случае с on-premise опенсорсными почтовыми решениями их применимость сильно ограничена двумя-тремя десятками тысяч пользователей. И виной тому сразу несколько причин — технологические особенности, юридические ограничения и слабо прогнозируемые риски.

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

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

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

Не меньшую угрозу несут и территориальные риски — так, например, сообщество Fedora Project изменило лицензионное соглашение и запретило поставки операционной системы в Крыму. Надо помнить, что за каждым сообществом стоят интересы спонсирующей организации. Так, за Fedora Project стоит Red Hat, и именно эта организация (ныне IBM) причастна к изменению лицензионной политики. Потому называть СПО «свободным» можно лишь отчасти.

Помимо этого, разработчики могут столкнуться с рисками прекращения выпуска самого продукта или изменения его функциональности. Наиболее ярким примером является история с проектом MySQL, который был поглощен Oracle в 2010 году. Из наиболее свежих примеров можно вспомнить недавний случай, когда разработчик часто используемых библиотек colors.js (3,3 млрд скачиваний) и faker.js (272 млн скачиваний) при очередном релизе подменил исходный код вредоносным. Это привело к проблемам более чем у 19 тысяч проектов, которые использовали такое СПО.

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

Суммируя, можно сказать, что для любого корпоративного продукта будут актуальны риски безопасности, работоспособности, потери доступа к обновлениям, потери ключевых компонентов и стремительно растущих экономических затрат при обслуживании. Создавая еnterprise-решения из десятков СПО-компонентов, любому разработчику нужно иметь квалифицированных мейнтейнеров и контрибьюторов во всех этих компонентах. Еще желательно, чтобы разработчик решения был представлен в таких СПО-проектах не одним человеком, а имел возможность делать существенную часть всего проекта и управлять им. Даже если за проектом с открытым кодом стоит крупная компания, особенно зарубежная, то это не является гарантией надежности или устойчивости проекта — например, упомянутая выше компания Red Hat предпочла закрыть проект CentOS в пользу собственной коммерческой разработки.

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

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

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

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

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

Когда речь заходит о создании по-настоящему масштабируемой почты, с возможностью самовосстановления и высокими показателями отказоустойчивости, то необходимо перестроить архитектуру и перейти от последовательной (монолитной) к микросервисной, или как еще говорят Cloud Native. Ключевое отличие такой архитектуры заключается в ином подходе к созданию и выполнению приложений с использованием преимуществ облачной модели.

Применение Cloud Native позволяет реализовать продукт, который стремится соответствовать концепции Zero-Downtime — то есть, показатели надежности которого позволяют говорить об отсутствии времени видимого простоя. Принципы соответствия Cloud Native можно охарактеризовать так: продукты дают больше гибкости и сфокусированы на стабильности, для их разработки требуется меньше времени, а их применение позволяет оптимизировать ИТ-процессы под потребности бизнеса. Чтобы соответствовать Cloud Native, необходимо обеспечить функции восстановления, масштабируемости, управления зависимостями и мониторинга, которые выполняются в автоматическом режиме.

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

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

Можно, и такие примеры существуют. Но они сложны в настройке и управлении. Легко выяснить, что именно нужно дедуплицировать, но при этом крайне тяжело определить достаточность и избыточности информации. Малейшая ошибка, и возникнет ситуация «дедуплицировал, дедуплицировал и в какой-то момент удалил собственный мастер-файл». Это называется додедуплицировался. Большинство опенсорсных объектных хранилищ, к сожалению, недостаточно качественно проработаны и сложны в эксплуатации, поэтому их пользователи сильно подвержены подобным сценариям. Можно вспомнить, например, аварию 2018 года в Росреестре, которую журналисты связывали с использованием СПО Ceph — тогда в 50 регионах РФ МФЦ лишились возможности проводить операции с недвижимостью.

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

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

Масштабирование бывает горизонтальным и вертикальным. Вертикальное масштабирование (оно же «Один Большой Сервер») ограничено в силу конечности аппаратных ресурсов и значительно дорожает в стоимости владения при достижении больших объемов данных. Более разумный с экономической точки зрения способ — горизонтальное масштабирование на типовом оборудовании. Именно такой подход лежит в основе концепции масштабирования Mailion и позволяет предлагать нашим клиентам гибкий подход к планированию мирграции и оптимизации затрат. Например, если требуется масштабировать почтовую систему до сотен тысяч пользователей, то в случае с Mailion этот процесс можно разделить на несколько этапов и масштабировать систему частями, добавляя по 30-50 тысяч пользователей за один раз.

Подводя итоги, отметим, что что количество рисков при использовании опенсорных почтовых решений непозволительно велико для крупных предприятий. ИТ-специалистам, которым предстоит внедрять такую почту, потребуется бороться с технологическими ограничениями и возникающими при эксплуатации сложностями, следить за лицензионной чистотой и юридическими рисками, к тому же, всегда иметь план «Б» на случай потери доступа к обновлениям и различным компонентам. На первый план также выходят и риски информационной безопасности — нет никакой гарантии, что найденные в СПО-компонентах ошибки/уязвимости будут своевременно устранены силами комьюнити.

И именно здесь появляется грань, переходя которую, мы теряем смысл использовать сторонние опенсорсные компоненты. Проще и актуальнее сразу создавать свои. Оценив все риски, мы приняли единственно верное решение — создать собственный уникальный продукт: тиражируемое on-premise решение для управления особо крупными почтовыми системами, которое будет иметь все нужные корпоративные функции и при останется отказоустойчивым, самовосстанавливаемым и масштабируемым, с возможностью хранения данных и поддержкой дедупликации. Мы отталкиваемся от современных принципов Cloud Native и построения информационных систем на основе микросервисной архитектуры. Применить новую архитектуру можно только разработав принципиально новое решение с нуля, которым и является Mailion. Суммарно мы уже потратили на наше решение больше 300 человеко-лет, и это только начало — в наших планах дальнейшее развитие продукта и появление еще большего количества корпоративных функций.