Бэкапы и патчи, латающие дыры в безопасности, вот уже много лет остаются одними из наиболее проблемных вопросов в IT-сфере. И если с резервным копированием дела обстоят получше (хотя анекдот про сисадминов, которые не делают или уже уже делают бэкапы ещё долго будет актуален), то вот с безопасностью всё печально. История с Garmin лишнее тому подтверждение.

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

В чём проблема

Ещё в феврале 2020 года Microsoft исправила уязвимость CVE-2020-0688, затрагивающую серверы Microsoft Exchange. Этот уязвимость безопасности присутствует в компоненте панели управления Exchange Control Panel (ECP) и позволяет злоумышленникам захватывать уязвимые серверы Microsoft Exchange, используя любые ранее украденные действительные учетные данные электронной почты. Чтобы подчеркнуть важность проблемы, компания добавила пометку уязвимости Exploitation More Likely Эксплуатация очень вероятна, намекая на то, что уязвимость является привлекательной целью для злоумышленников.

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

Непосредственно этап аутентификации, кстати, тоже не является проблемой. Злоумышленники могут пройти её с помощью инструментов сбора информации о сотрудниках компаний через LinkedIn. А затем использовать собранную информацию вкупе с credential stuffing, против Outlook Web Access (OWA) и ECP.

В феврале же специалисты по безопасности предупреждали активном сканировании сети в поисках уязвимых серверов Microsoft Exchange. Для осуществления атаки достаточно было обнаружить уязвимые серверы, найти адреса электронной почты, которые можно добыть через URL-адрес web-клиента OWA или собрать данные из предыдущих утечек. Если злоумышленнику удавалось перейти на сервер Exchange, он мог разглашать или подделывать корпоративные почтовые сообщения.

Два западных агентства по информационной безопасности NSA и CISA тоже выпустили предупреждения, призывавшие к скорейшей установке патча CVE-2020-0688, ссылаясь на случаи эксплуатации этой уязвимости группами хакеров.

Побурлили и забыли

Но, как это часто бывает, на шумиху обратили внимание не только лишь все (с). Большинство компаний проигнорировали угрозу. Специалисты ИБ-компании Rapid7 спустя пару месяцев использовали свой web-инструмент Project Sonar, чтобы обнаружить все общедоступные серверы Exchange в интернете. И результаты оказались весьма печальными.

Им удалось установить, что по меньшей мере 357 629 (82,5%) из 433 464 серверов Exchange по-прежнему открыты для атак, эксплуатирующих уязвимость CVE-2020-0688.

Некоторые из серверов, помеченные Rapid7 как защищённые от атак, могли по-прежнему быть уязвимыми, поскольку патч Microsoft обновлял не все сборки ОС. Но и это ещё не всё. Исследователи обнаружили почти 11 тысяч серверов под Microsoft Exchange 2007, использовавших ПО End of Support (EoS), чья поддержка прекратилась в 2017 году, и 166 тысяч серверов под управлением ОС Microsoft Exchange 2010, поддержка которой прекратится в октябре 2020 года. Вишенкой на торте стала информация о том, что к интернету подключено почти 31 тыс. серверов Microsoft Exchange 2010, не обновлявшихся аж с 2012 года, а на 800 из них ни разу не устанавливали обновления.

Кто виноват, решим позже. Что делать?

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

Скомпрометированные учетные записи пользователей, которые использовались для атаки на серверы Exchange, можно обнаружить, проверив журналы событий Windows и IIS на наличие частей закодированных полезных данных, включая текст Invalid viewstate или строку __VIEWSTATE и __VIEWSTATEGENERATOR в запросах запросов в пути в каталоге /ecp.

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

Ссылки на скачивание обновлений безопасности для уязвимых версий Microsoft Exchange Server, и соответствующие статьи из базы знаний доступны в таблице ниже:


Не забывайте про безопасность. Отсутствие защиты спустя несколько месяцев после выпуска патча это крайне печально.

Что ещё полезного можно почитать в блоге Cloud4Y

Искусственный интеллект поёт о революции
Какова геометрия Вселенной?
Нужны ли облака в космосе
Пасхалки на топографических картах Швейцарии
Победители конкурса стартапов The Europas Awards 2020

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу. Кстати, недавно мы провели вебинар на тему расчёта TCO для IT-проектов, где ответили на актуальные вопросы. Если вам интересно велком!

Может быть пора? Такой вопрос рано или поздно появляются у коллег, которые используют Lotus в качестве почтового клиента или системы документооборота. Запрос на миграцию (по нашему опыту) может возникнуть на совсем разных уровнях организации: от топ-менеджмента до пользователей (особенно, если таких много). Вот несколько причин, почему миграция с Lotus в Exchange не такая уж и простая задача:

• RTF формат IBM Notes не совместим с форматом RTF Exchange;
• IBM Notes использует SMTP-формат адресов только для внешних писем, Exchange для всех;
• Необходимость сохранения делегирований;
• Необходимость сохранения метаданных;
• Часть писем может быть зашифрована.

А если Exchange уже есть, но Lotus ещё используется, возникают проблемы сосуществования:

• Необходимость использования скриптов или сторонних систем для синхронизации адресных книг между Domino и Exchange;
• Domino использует plain text для отправки писем в другие почтовые системы;
• Domino использует формат iCalendar для отправки приглашений в другие почтовые системы;
• Невозможность Free-Busy запросов и совместного бронирования ресурсов (без использования сторонних решений).

В этой статье мы разберем специализированные программные продукты Quest для миграции и сосуществования: Migrator for Notes to Exchange и Coexistence Manager for Notes соответственно. В конце статьи вы найдете ссылку на страницу, где можно оставить заявку на бесплатную тестовую миграцию нескольких почтовых ящиков для демонстрации простоты процесса. А под катом пошаговый алгоритм миграции и другие подробности по процессу миграции.

Если различать подходы к миграции, можно предположить, что есть три основных вида:

• Переход без миграции. Пользователи получают пустые почтовые ящики, исходный почтовый сервис продолжает работать в режиме read-only.
• Миграция с сосуществованием. Настраивается интеграция между исходной и целевой системами, после чего данные почтовых ящиков поэтапно переносятся в новую систему.
• Миграция в режиме offline. Исходная система отключается, данные всех пользователей переносятся в новую систему.

Ниже поговорим о миграции в режиме offline и миграции с сосуществованием. За эти процессы, как мы писали выше, отвечают два продукта Quest: Coexistence Manager for Notes и Migrator for Notes to Exchange соответственно.

Coexistence Manager for Notes (CMN)

Это решение выполняет двустороннюю синхронизацию LDAP-каталогов, создает контакты для почтовых объектов (ящики, списки, рассылки, ресурсы) из исходной системы. Есть возможность произвольной настройки сопоставления атрибутов и использования трансформации данных на лету. В результате вы получите идентичные адресные книги в Lotus и Exchange.

CMN также обеспечивает SMTP-связь между инфраструктурами:

• Правит письма на лету;
• Преобразует в правильный формат RTF;
• Обрабатывает DocLinks;
• Упаковывает Notes-данные в NSF;
• Обрабатывает приглашения и запросы на ресурсы.

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

Еще одна важдая функция CMN эмуляция Free-Busy. С ней коллегам необязательно знать кто чем пользуется: Lotus или Exchange. Эмуляция позволяет почтовому клиенту получить данные о доступности пользователя из другой почтовой системы. Вместо синхронизации данных, запросы между системами пересылаются в режиме реального времени.В результате можно пользоваться Free-Busy даже после миграции части пользователей.

Migrator for Notes to Exchange (MNE)

Этот инструмент выполняет непосредственную миграцию. Сам процесс миграции можно условно разделить на несколько этапов: пре-миграция, миграция и пост-миграция.

Пре-миграция

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

Миграция

При миграции выполняется копирование данных почтовых ящиков в несколько потоков с сохранением ACL и метаданных. Также мигрируют группы. При необходимости, можно выполнить дельта-миграцию, если по каким-то причинам не удалось это сделать за один раз. MNE также юерет на себя управление перенаправлением почты. Вся миграция происходит со скоростью сетевого соединения, поэтому нахождение окружения Lotus и Exchange в одном ЦОД дает большое преимущество по скорости.

Пост-миграция

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

Еще один опциональный этап миграции это миграция приложений. Для этого у Quest есть специализированный продукт Migrator for Notes to Sharepoint. В отдельной статье мы расскажем о работе с ним.

Пошаговый пример процедуры миграции при помощи решений MNE и CMN

Шаг 1. Выполнение обновления AD с помощью Coexistence Manager. Извлечение данных из каталога Domino и создание учетных записей пользователей (контактов) с включенной поддержкой почты в Active Directory. При этом почтовые ящики пользователей в Exchange еще не созданы. Записи пользователей в AD содержат текущие адреса пользователей Notes.



Шаг 2. Exchange может перенаправлять сообщения в почтовые ящики пользователей Notes сразу после изменения MX-записи. Это временное решение, чтобы перенаправить входящую почту Exchange до тех пор, пока не будут перенесены первые пользователи.



Шаг 3. Мастер переноса данных Migrator for Notes to Exchange включает учетные записи AD мигрирующих пользователей и устанавливает правила пересылки почты в Notes, чтобы почта, адресованная адресам Notes уже перенесенных пользователей, была перенаправлена в их активные почтовые ящики Exchange.



Шаг 4. Процесс повторяется при переходе каждой группы пользователей на новый сервер.



Шаг 5. Сервер Domino может быть выключен (на самом деле нет, если остались приложения).



Миграция завершена, можно расходиться по домам и открывать там клиент Exchange. Если вы уже задумываетесь о миграции из Lotus в Exchange, рекомендуем прочитать в нашем блоге статью о 7 шагах к успешной миграции. А если хотите посмотреть на тестовую миграцию в действии и убедиться в простоте использования продуктов Quest, оставьте заявку в форме обратной связи и мы проведем для вас бесплатную тестовую миграцию в Exchange.

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

Exchange обладает достаточно разветвлённой системой логирования. Самые востребованные логи логи трэкинга, которые отслеживают пошаговое прохождение конкретного письма внутри почтовой организации; логи веб-сервера, которые отслеживают каждую новую сессию пользователя в системе, и логи конкретных веб-приложений с разной степенью детализации сессии. Также Exchange умеет хранить сырые логи протоколов smtp, imap и pop3.

Какие инструменты мы можем использовать для работы с логами:

• Штатный командлет Get-MessageTrackingLog: удобно обрабатывать логи трэкинга;
• Утилита logparser: для логирования использует псевдо-SQL язык для поиска и работает достаточно быстро;
• Внешний SQL-сервер: для особо специфических случаев (например, анализ данных за большие промежутки времени).

Всё это работает неплохо, когда у нас пара серверов и объем обрабатываемых логов измеряется десятками-сотнями гигабайт. А что, если счёт серверов идёт на десятки, а размер логов перевалил за терабайт? Эта схема, вероятнее всего, начинает сыпаться.

И вот что происходит: Get-MessageTrackingLog начинает отваливаться по тайм-ауту, logparser упирается в потолок 32-битной архитектуры, а выгрузка в SQL-сервер ломается в самый неподходящий момент, не переварив многострочный exception от сервиса.

Тут на сцену выходит новый игрок стэк ELK, который специально заточен под жонглирование огромными объемами логов в разумные сроки и с терпимым потреблением ресурсов.

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

Установка

Итак, файл-архив агента filebeat можно скачать с этого сайта.

Мы выполним установку простой распаковкой содержимого zip-файла. Например, в c:\Program Files\filebeat. Затем необходимо запустить PowerShell-скрипт install-service-filebeat.ps1, который идёт в комплекте, для установки сервиса filebeat.

Теперь мы готовы начать настраивать файл конфигурации.

Отказоустойчивость

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

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

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

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

Подробнее об этом можно почитать в документации в параграфах: How does Filebeat keep the state of files и How does Filebeat ensure at-least-once delivery?

Настройка

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

Блок обработки логов

Блок обработки логов начинается с поля:

filebeat.inputs:

Мы будем использовать общий инструмент сбора логов:

- type: log

Далее указываем статус (включен) и пути до папки с логами. Например, в случае с логами IIS настройки могут быть следующими:

    enabled: true    paths:- C:\inetpub\logs\LogFiles\W3SVC1\*.log- C:\inetpub\logs\LogFiles\W3SVC2\*.log

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

multiline:pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'negate: truematch: after

Имеет смысл добавить тэги в отправляемую запись, например:

  tags: ['IIS', 'ex-srv1']

И не забыть исключить из обработки строки, начинающиеся с хэш-символа:

  exclude_lines: ['^#']

Итак, блок чтения логов будет выглядеть следующим образом:

filebeat.inputs:- type: log  enabled: true  paths:- C:\inetpub\logs\LogFiles\W3SVC1\*.log- C:\inetpub\logs\LogFiles\W3SVC2\*.log  multiline:pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'negate: truematch: after  tags: ['IIS', 'ex-srv1']  exclude_lines: ['^#']

Блок отправки логов

Отдельные записи в лог файле filebeat отправляет в виде объекта json, в котором конкретная запись из лога содержится в единственном поле message. Если мы хотим как-то работать с этой информацией, нам необходимо это поле предварительно распарсить на отдельные поля. Сделать это можно, например, в logstash. Он и будет являться получателем записей из filebeat. Вот как это может выглядеть в файле конфигурации filebeat:

output.logstash:  hosts: ["logstash1.domain.com:5044"]

Если серверов несколько, то для них можно включить балансировку: тогда filebeat будет отправлять логи не на первый доступный сервер из списка, а распределять отправляемые логи между несколькими серверами:

hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true 

Filebeat при обработке логов в отправляемый json помимо записи лога, которая содержится в поле message, добавляет некоторое количество метаданных, которое сказывается на размере документа, попадающего в elastic. Эти метаданные можно выборочно из отправки убрать. Делается это в блоке processor с помощью процессора drop_fields. Исключить можно, например, следующие поля:

processors:- drop_fields:fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

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

Итак, блок отправки логов будет выглядеть следующим образом:

output.logstash:  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true processors:- drop_fields:fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"]

Настройки логирования filebeat

Имеет смысл выставить следующие настройки логирования:

• Уровень логирования info;
• Записываем логи в файлы, расположенные по дефолту (директория logs, в директории установки filebeat);
• Имя файла лога filebeat;
• Хранить последние 10 файлов логов;
• Запускать ротацию при достижении размера 1Мб.

Финально блок настройки логирования будет выглядеть так:

logging.level: infologging.to_files: truelogging.files:  name: filebeat  keepfiles: 10  rotateeverybytes: 1048576

Итоговая конфигурация

Мы собрали конфигурацию, и теперь она выглядит следующим образом:

filebeat.inputs:- type: log  enabled: true  paths:    - C:\inetpub\logs\LogFiles\W3SVC1\*.log    - C:\inetpub\logs\LogFiles\W3SVC2\*.log  multiline:    pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'    negate: true    match: after  tags: ['IIS', 'ex-srv1']  exclude_lines: ['^#'] output.logstash:  hosts: ["logstash1.domain.com:5044", "logstash2.domain.com:5044"]  loadbalance: true processors:- drop_fields:    fields: ["agent.ephemeral_id", "agent.hostname", "agent.id", "agent.type", "agent.version", "agent", "ecs.version", "ecs", "input.type", "input", "log.offset", "version"] logging.level: infologging.to_files: truelogging.files:  name: filebeat  keepfiles: 10  rotateeverybytes: 1048576

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

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

.\filebeat.exe test config

Ещё filebeat умеет проверять сетевую доступность приёмника логов. Запускается проверка так:

.\filebeat.exe test output

В следующих частях я расскажу про подключение и дружбу Exchange с компонентами Logstash и Kibana.

Полезные ссылки

• How Filebeat works
• Log input
• Manage multiline messages
• Configure the Logstash output
• Drop fields from events
• Configure logging

Переход с IBM Notes на Microsoft Exchange или Office 365 дает весомое количество преимуществ для организации, но сам проект миграции выглядит пугающе и не совсем понятно с чего нужно начинать миграцию. Сам Exchange не включает собственные инструменты для полной миграции или установления сосуществования Notes и Exchange. Фактически, выполнение некоторых задач миграции и сосуществования невозможно без сторонних продуктов. В этой статье мы опишем семь ключевых шагов, которые необходимо выполнить в соответствии с лучшими практиками и нашим опытом проведения успешных миграций.

Успешная миграция включает следующие шаги:

1. Предварительная оценки миграции.
2. Установление сосуществования Notes и Exchange.
3. Планирование оптимальной точности миграции.
4. Обеспечение максимальной эффективности миграции.
5. Запуск пробной миграции.
6. Планирование времени миграции, для минимизации влияния на организацию.
7. Запуск миграции и отслеживание ее прогресса.

В этой статье мы разберем как подготовиться к миграции и выполнить ее при помощи двух решений от Quest Coexistence Manager for Notes и Migrator for Notes to Exchange. Под катом некоторые подробности.

Шаг 1: Предварительная оценка миграции

Проведение инвентаризации текущей среды

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

• Сколько существуют доменов Notes и серверов Domino?
• Сколько у вас почтовых ящиков? Сколько из них не используются?
• Сколько места на дисках занимают файлы основной почты? Сколько в архивах? Сколько в локальных репликах?
• Где находятся архивы?
• Сколько пользователей используют шифрование? Зашифрованный контент нужно перенести?
• Сколько личных папок существует в окружении?
• Какие пользователи используют ссылки на документы? Сколько пользователей получили ссылки от других пользователей и приложений?
• Сколько данных вы собираетесь переносить? Например, вы хотите перенести данные только за последние полгода.
• Будут ли перенесены нативные архивы в персональные архивы Exchange или в файлы *.pst Outlook?
• Каковы ограничения полосы пропускания? Сколько данных можно перенести в
  определенный промежуток времени?
• Какой объем хранилища потребуется после миграции?

Как миграция повлияет бизнес и операционную деятельность

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

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

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

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

Прежде чем начать миграцию, нужно определить критерии для измерения успеха. В частности, нужно понимать, что неразумно ожидать 100% переноса данных. Не у каждого типа элемента Notes есть эквивалент в Exchange (Active Mail самый вопиющий пример). Следовательно, реальность такова что не все элементы в Notes будут существовать в Exchange после миграции. Достижимая и измеримая цель 95% элементов перенесено для 95 процентов почтовых ящиков. Измерение и документирование результатов имеют решающее значение для обеспечения успеха миграции, а настоящие результаты возможны только если были определены критерии успешности в самом начале проекта миграции электронной почты.

Шаг 2: установление сосуществования Notes и Exchange

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

Разработка стратегии сосуществования

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

Переход с Notes на Exchange и Office 365 требует планирования миграции почтовых ящиков и приложений одновременно. Должна поддерживаться текущая функциональность приложений Notes для всех пользователей независимо от их текущей почтовой платформы. Как пользователи, перешедшие на Exchange и Office 365, они должны иметь доступ и использовать приложения Notes в рамках существующих рабочих процессов. Эта возможность должна сохраняться до тех пор, пока приложения Notes перенесутся на SharePoint или другую платформу.

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

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

Шаг 3: Планирование оптимальной точности миграции

Планирование перехода с Notes на Exchange или Office 365 требует понимания ряда конкретных различий между платформами.

Адреса электронной почты

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

Структура папки

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

Локальные реплики и архивы

В целях контроля затрат на хранение и лучшего управления ростом объема данных, многие организации устанавливают квоты на почтовые ящики. Непреднамеренным следствием этой политики часто бывает увеличение количества и размера архивов. Эти дополнительные данные источники должны быть оценены и вопрос их миграции стоит рассмотреть во время планирования миграции. Можно предоставить пользователям компонент самообслуживания, который даст им перенести только важные данные. Для оптимизация хранилища Exchange мы рекомендуем использовать другой продукт Quest Archive Manager for Exchange, в нем есть, в частности, полезный функционал по дедупликации вложенных файлов, аналог DAOS в Notes.

ACL и делегирование

Разрешенные списки для контроля доступа (ACL) и делегирование ключевые элементы для операционной в среде Notes, они также имеют решающее значение для защиты целостности. В результате важно точно преобразовать связанные права и права доступа к эквивалентным правам в Exchange Server и Office 365. В идеале сделать это автоматически, что ускорит процесс и исключит человеческую ошибку. Чтобы поддержать эффективность защиты информационных активов организации, ACL и преобразование делегирования должно быть выполнено одновременно с почтовыми данными. Некоторые организации пытаются назначить эквивалентные права вручную или с помощью скриптов, после завершения переноса данных. Однако, такой подход может негативно повлиять на производительность и добавить пробелы в безопасность данных организации.

Собственное содержание Notes

Тот самый Active Mail. Еще одна распространенная проблема, когда миграция с IBM Notes встречается с большим количеством форматированного текста. Exchange и Office 365 не поддерживают интегрированные таблицы с вкладками, кнопки, сохраненные формы и другой проприетарный контент в Notes. В результате вам потребуется либо подготовиться к потере этой функциональности или инвестировать в решение для миграции, способное преобразовать эти элементы в формат, который может быть перенесен. Скажем сразу, что решения от Quest такое никак не конвертируют и могут разве что перенести такие письма в виде вложений, чтобы пользователь мог их потом открыть через клиент Notes.

Группы и личные адресные книги

Многие организации широко используют публичные списки рассылки для внутренней и
внешней связи. К тому же, пользователи Notes часто считают важным вести деловые контакты в личных адресных книгах. Эти источники данных важны для бизнес-операций и должны быть эффективно преобразованы во время перехода на платформу Microsoft. В результате важно автоматически подготовить группы к миграции в Active Directory и эффективно конвертировать все личные адреса, даже те, которые хранятся на рабочих местах пользователей.

Взаимодействие с приложениями Notes

Точки интеграции между приложениями и почтовой службой, такие как процессы согласования, имеют большое значение при планировании и составления графика миграции. IBM Notes имеет более тесную интеграцию между электронной почтой и приложениями, чем другие платформы. Эти интеграции могут включать все: от простых doclinks до бизнес-процессов.

Ресурсы и почтовые базы данных

Многие организации используют базы данных резервирования ресурсов, почтовые базы данных и другие общие базы данных в Notes. В результате, эти базы данных играют важную роль в работе организации. Для обеспечения непрерывности бизнеса и продуктивности сотрудников, очень важно учитывать подход и сроки реализации для:

• Создания ресурсных почтовых ящиков в целевой среде;
• Переноса данных из базы данных резервирования в Exchange;
• Обеспечения того, чтобы пользователи обеих систем могли сотрудничать и использовать ресурсы в Notes и Exchange.

Шаг 4: обеспечение максимальной эффективности миграции

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

Архитектура миграционного решения

Один из важнейших факторов влияния на эффективность архитектура миграционного решения. Очень важно выбрать решение с многопоточной архитектурой, которая позволяет одному серверу миграции переносить несколько пользователей одновременно. Многопоточная архитектура снижает требования к оборудованию для миграции и увеличивает скорость миграции, резко снижая общую стоимость проекта. Не обманывайтесь решениями для миграции которые утверждают, что они многопоточны, но фактически выполняют миграцию только одного пользователя за раз и требуют добавления рабочих станции, чтобы переносить больше пользователей одновременно. В зависимости от конфигурации и окружения, настоящие многопоточные решения от 30 до 5000 процентов эффективнее при переносе данных на Exchange и Office 365.

Процесс миграции

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

Гибкость и самообслуживание

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

Шаг 5: запуск пробной миграции

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

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

Определение объема пилотной миграции

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

Выбор данных и систем

В процессе пилотной миграции важно использовать боевые данные и боевые системы. Это очень важно по некоторым причинам:

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

Установление ожиданий

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

Шаг 6: планирование времени миграции для минимизации влияния на организацию

Группировка пользователей

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

Сроки миграции

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

Шаг 7: запуск миграции и отслеживание ее прогресса

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

Заключение

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

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

Статья на Хабр: Миграция IBM Lotus Notes/Domino в Microsoft Exchange

Quest Migrator for Notes to Exchange на сайте Gals

Quest Coexistence Manager for Notes на сайте Gals

Quest Migrator for Notes to Exchange на сайте Quest

Quest Coexistence Manager for Notes на сайте Quest

Я продолжаю свой рассказ о том, как подружить Exchange и ELK (начало тут). Напомню, что эта комбинация способна без колебаний обрабатывать очень большое количество логов. На это раз мы поговорим о том, как наладить работу Exchange с компонентами Logstash и Kibana.

Logstash в стеке ELK используется для интеллектуальной обработки логов и их подготовки к размещению в Elastic в виде документов, на основе которых удобно строить различные визуализации в Kibana.

Установка

Состоит из двух этапов:
Установка и настройка пакета OpenJDK.
Установка и настройка пакета Logstash.

Установка и настройка пакета OpenJDK
Пакет OpenJDK необходимо скачать и распаковать в определённую директорию. Затем путь до этой директории необходимо внести в переменные $env:Path и $env:JAVA_HOME операционной системы Windows:



Проверим версию Java:

PS C:\> java -versionopenjdk version "13.0.1" 2019-10-15OpenJDK Runtime Environment (build 13.0.1+9)OpenJDK 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Установка и настройка пакета Logstash

Файл-архив с дистрибутивом Logstash скачайте отсюда. Архив нужно распаковать в корень диска. Распаковывать в папку C:\Program Files не стоит, Logstash откажется нормально запускаться. Затем необходимо внести в файл jvm.options правки, отвечающие за выделение оперативной памяти для процесса Java. Рекомендую указать половину оперативной памяти сервера. Если у него на борту 16 Гб оперативки, то ключи по умолчанию:

-Xms1g-Xmx1g

необходимо заменить на:

-Xms8g-Xmx8g

Кроме этого, целесообразно закомментировать строку -XX:+UseConcMarkSweepGC. Подробнее об этом тут. Следующий шаг создание конфигурации по умолчанию в файле logstash.conf:

input { stdin{}} filter {} output { stdout { codec => "rubydebug" }}

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

PS C:\...\bin> .\logstash.bat -f .\logstash.conf...[2019-12-19T11:15:27,769][INFO ][logstash.javapipeline    ][main] Pipeline started {"pipeline.id"=>"main"}The stdin plugin is now waiting for input:[2019-12-19T11:15:27,847][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}[2019-12-19T11:15:28,113][INFO ][logstash.agent           ] Successfully started Logstash API endpoint {:port=>9600}

Logstash успешно запустился на порту 9600.

Финальный шаг установки: запуск Logstash в виде сервиса Windows. Это можно сделать, например, с помощью пакета NSSM:

PS C:\...\bin> .\nssm.exe install logstashService "logstash" installed successfully!

Отказоустойчивость

Сохранность логов при передаче с исходного сервера обеспечивается механизмом Persistent Queues.

Как работает

Схема расположения очередей в процессе обработки логов: input queue filter + output.

Плагин input получает данные от источника логов, записывает их в очередь и отправляет источнику подтверждение получения данных.

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

Настройка

Регулируется ключами в файле C:\Logstash\config\logstash.yml:

queue.type: (возможные значения persisted и memory (default)).
path.queue: (путь до папки с файлами очередей, которые по умолчанию хранятся в C:\Logstash\queue).
queue.page_capacity: (максимальный размер страницы очереди, значение по умолчанию 64mb).
queue.drain: (true/false включает/выключает остановку обработки очереди перед выключением Logstash. Не рекомендую включать, потому что это прямо скажется на скорости выключения сервера).
queue.max_events: (максимально число событий в очереди, по умолчанию 0 (не ограничено)).
queue.max_bytes: (максимальный размер очереди в байтах, по умолчанию 1024mb (1gb)).

Если настроены queue.max_events и queue.max_bytes, то сообщения перестают приниматься в очередь при достижении значения любой из этих настроек. Подробнее про Persistent Queues рассказано тут.

Пример части logstash.yml, отвечающей за настройку очереди:

queue.type: persistedqueue.max_bytes: 10gb

Настройка

Конфигурация Logstash обычно состоит из трёх частей, отвечающих за разные фазы обработки входящий логов: приём (секция input), парсинг (секция filter) и отправка в Elastic (секция output). Ниже мы подробнее рассмотрим каждую из них.

Input

Входящий поток с сырыми логами принимаем от агентов filebeat. Именно этот плагин мы и указываем в секции input:

input {  beats {    port => 5044  }}

После такой настройки Logstash начинает прослушивать порт 5044, и при получении логов обрабатывает их согласно настройкам секции filter. При необходимости можно канал получения логов от filebit завернуть в SSL. Подробнее о настройках плагина beats написано тут.

Filter

Все интересные для обработки текстовые логи, которые генерирует Exchange, имеют csv-формат с описанными в самом файле логов полями. Для парсинга csv-записей Logstash предлагает нам три плагина: dissect, csv и grok. Первый самый быстрый, но справляется с парсингом только самых простых логов.
Например, следующую запись он разобьёт на две (из-за наличия внутри поля запятой), из-за чего лог будет разобран неправильно:

,"MDB:GUID1, Mailbox:GUID2, Event:526545791, MessageClass:IPM.Note, CreationTime:2020-05-15T12:01:56.457Z, ClientType:MOMT, SubmissionAssistant:MailboxTransportSubmissionEmailAssistant",

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

filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }    }  }} 

Конфигурация Logstash позволяет использовать условные операторы, поэтому мы в плагин dissect можем направить только логи, которые были помечены filebeat тэгом IIS. Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message, которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

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

filter {  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }}

Внутри плагина мы сопоставляем значения полей с их названиями, удаляем исходное поле message (а также поля tenant-id и schema-version), которое содержало запись из лога, и можем добавить произвольное поле, которое будет, например, содержать имя приложения из которого мы собираем логи.

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

Числовые поля будут распознаны как текст, что не позволяет выполнять операции с ними. А именно, поля time-taken лога IIS, а также поля recipient-count и total-bites лога Tracking.
Стандартный временной штамп документа будет содержать время обработки лога, а не время записи его на стороне сервера.
Поле recipient-address будет выглядеть одной стройкой, что не позволяет проводить анализ с подсчётом получателей писем.

Настало время добавить немного магии в процесс обработки логов.

Конвертация числовых полей

Плагин dissect имеет опцию convert_datatype, которую можно использовать для конвертации текстового поля в цифровой формат. Например, так:

dissect {    convert_datatype => { "time-taken" => "int" }  }

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

Для логов трэкинга аналогичный метод convert лучше не использовать, так как поля recipient-count и total-bites могут быть пустыми. Для конвертации этих полей лучше использовать плагин mutate:

mutate {  convert => [ "total-bytes", "integer" ]  convert => [ "recipient-count", "integer" ]}

Разбиение recipient_address на отдельных получателей

Эту задачу можно также решить с помощью плагина mutate:

mutate {  split => ["recipient_address", ";"]}

Изменяем timestamp

В случае с логами трэкинга задача очень просто решается плагином date, который поможет прописать в поле timestamp дату и время в нужном формате из поля date-time:

date {  match => [ "date-time", "ISO8601" ]  timezone => "Europe/Moscow"  remove_field => [ "date-time" ]}

В случае с логами IIS нам будет необходимо объединить данные полей date и time с помощью плагина mutate, прописать нужную нам временную зону и поместить этот временной штамп в timestamp с помощью плагина date:

mutate {   add_field => { "data-time" => "%{date} %{time}" }  remove_field => [ "date", "time" ]}date {   match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]  timezone => "UTC"  remove_field => [ "data-time" ]}

Output

Секция output используется для отправки обработанных логов в приёмник логов. В случае отправки напрямую в Elastic используется плагин elasticsearch, в котором указывается адрес сервера и шаблон имени индекса для отправки сформированного документа:

output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Итоговая конфигурация

Итоговая конфигурация будет выглядеть следующим образом:

input {  beats {    port => 5044  }} filter {  if "IIS" in [tags] {    dissect {      mapping => {        "message" => "%{date} %{time} %{s-ip} %{cs-method} %{cs-uri-stem} %{cs-uri-query} %{s-port} %{cs-username} %{c-ip} %{cs(User-Agent)} %{cs(Referer)} %{sc-status} %{sc-substatus} %{sc-win32-status} %{time-taken}"      }      remove_field => ["message"]      add_field => { "application" => "exchange" }      convert_datatype => { "time-taken" => "int" }    }    mutate {       add_field => { "data-time" => "%{date} %{time}" }      remove_field => [ "date", "time" ]    }    date {       match => [ "data-time", "YYYY-MM-dd HH:mm:ss" ]      timezone => "UTC"      remove_field => [ "data-time" ]    }  }  if "Tracking" in [tags] {    csv {      columns => ["date-time","client-ip","client-hostname","server-ip","server-hostname","source-context","connector-id","source","event-id","internal-message-id","message-id","network-message-id","recipient-address","recipient-status","total-bytes","recipient-count","related-recipient-address","reference","message-subject","sender-address","return-path","message-info","directionality","tenant-id","original-client-ip","original-server-ip","custom-data","transport-traffic-type","log-id","schema-version"]      remove_field => ["message", "tenant-id", "schema-version"]      add_field => { "application" => "exchange" }    }    mutate {      convert => [ "total-bytes", "integer" ]      convert => [ "recipient-count", "integer" ]      split => ["recipient_address", ";"]    }    date {      match => [ "date-time", "ISO8601" ]      timezone => "Europe/Moscow"      remove_field => [ "date-time" ]    }  }} output {  elasticsearch {    hosts => ["127.0.0.1:9200", "127.0.0.2:9200"]    manage_template => false    index => "Exchange-%{+YYYY.MM.dd}"  }}

Полезные ссылки:

How to install OpenJDK 11 on Windows?
Download Logstash
Elastic uses depricated option UseConcMarkSweepGC #36828
NSSM
Persistent Queues
Beats input plugin
Logstash Dude, where's my chainsaw? I need to dissect my logs
Dissect filter plugin
Conditionals
Mutate filter plugin
Date filter plugin
Elasticsearch output plugin

Почти четыре года назад мы начали проектировать принципиально новую распределенную почтовую систему Mailion, которая предназначена для корпоративных коммуникаций. Наше решение построено на Cloud Native микросервисной архитектуре, способно работать с более чем 1 000 000 пользователей одновременно и будет готово покрыть 100% потребностей крупных корпораций.

За время работы над Mailion команда выросла в несколько раз, и сейчас в продукт вовлечено почти 70 разработчиков. Мы прошли большой путь от идеи и первых прототипов до этапа пилотирования коммерческой версии. Настало время рассказать Хабру о том, что за продукт мы создаем, как устроена и работает наша почтовая система, какой стек технологий мы используем и почему за нашим решением будущее корпоративных коммуникаций. Погнали!

Хабр, привет! Меня зовут Антон Герасимов, я руковожу департаментом разработки в московском центре разработки компании МойОфис. Сегодня мы хотим представить Mailion принципиально новую российскую почтовую систему корпоративного класса, которая станет достойной альтернативой популярным иностранным решениям. Mailion обладает высокой нагрузочной способностью, беспрецедентными возможностями масштабирования и отказоустойчивости, а также требует минимального внимания со стороны системных администраторов.

Сейчас наша разработка находится в стадии бета-версии, но совсем скоро, по нашему плану до конца 2020 года, перейдет в статус пилотного внедрения коммерческого продукта.

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

• Что такое корпоративная почтовая система?
  
  • Кому и зачем нужна еще одна почта?
  • Что скрывается под капотом
  • Какие вызовы стоят перед разработчиками
    
    • Надежность
    • Отказоустойчивость
    • Самостоятельность
    • Простота эксплуатации
    • Экономическая эффективность
    • Децентрализованность
    • Системные требования
• Технологический стек
• Из чего состоит продукт
  
  • Совместимость с почтовыми системами
  • Легкость администрирования
  • Современный дизайн
    
    • Адаптивность
    • Системность
    • Настройка фирменного стиля
  • Мобильные приложения
  • Интеллектуальная медиа панель
  • Локализация
• Yes, we are hiring!

---

## Что такое корпоративная почтовая система?
Простой и очевидный ответ на этот вопрос средство для работы с электронной почтой и календарем. Но дьявол, как известно, кроется в деталях.

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

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

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

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

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

### Что скрывается под капотом
[](http://personeltest.ru/aways/habrastorage.org/webt/ms/uk/xl/msukxlv16wc4nms_4af5hj50f2s.jpeg)

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

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



### Какие вызовы стоят перед разработчиками
Далее по тексту я буду говорить только про новую корпоративную почтовую систему Mailion.

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

Большая доля кода Mailion собственная разработка, код, права на который полностью принадлежат нам и который мы можем изменять и дорабатывать при необходимости. Большая часть кода нашей почтовой системы написана самостоятельно на Go (Golang). Кроме Go, мы используем C++, а также Java Script ES6 для веб-части.

Оставшиеся 5% так называемые тяжелые компоненты, такие как базы данных. К их числу относятся RethinkDB, ArangoDB и Redis. Из ключевых технологий также отмечу еще gRPC систему удаленного вызова процедур, которая используется как единый механизм для взаимодействия по API, это важная часть.

## Из чего состоит продукт
Корпоративная почтовая система это не сервер в вакууме. В состав нашего продукта входит порядка 70 компонентов и 45 сервисов, которые занимаются обслуживанием почтовой системы. Все эти элементы написаны с нуля и являются собственной разработкой МойОфис.

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

### Совместимость с почтовыми системами
Mailion работает по стандартным протоколам. Для того чтобы начать пользоваться нашим решением, нужно лишь настроить клиентские приложения и дальше работать с ними в привычном окружении. Например, можно использовать входящее в продукт МойОфис Почта клиентское приложение.

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

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

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

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

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

[](http://personeltest.ru/aways/habrastorage.org/webt/e_/_b/74/e__b74fo4yx844m2zg2vtdx-34c.jpeg)

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

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

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

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

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

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

Устройству нашей цветовой библиотеки и особенностям работы со шрифтами мы посвятим отдельные статьи.

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

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

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

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

### Локализация
Потребность в корпоративной почтовой системе есть не только у российских пользователей. МойОфис проводит последовательную политику по выходу на иностранные рынки, поэтому вопросам локализации продуктов уделяется довольно большое внимание.

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

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

## Yes, we are hiring!
На создание нашего продукта ушло несколько сотен человеко-лет. И при всем желании я бы не смог рассказать сразу обо всем в рамках одной статьи. Тем не менее я надеюсь, что эта публикация послужит отправной точкой для знакомства с нашим продуктом как я уже сказал выше, я планирую в дальнейшем рассказывать более подробно как о самом решении и его особенностях, так и о наших подходах к разработке.

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

Прямо сейчас у нас открыто почти [полсотни](http://personeltest.ru/aways/hh.ru/employer/213397?customDomain=1) вакансий в разработке. Приходите к нам на работу, если вы хотите вместе с нами создавать продукт, который способен перевернуть представление корпоративного мира об электронной почте.