TL;DR — Краткое содержание
"Непрерывность работы электронной почты" для разных людей означает разное. Исторически сложилось так, что большинство организаций не беспокоились об этом. Если бы вы несколько лет назад спросили администратора Exchange или Microsoft 365, он ответил бы, что сбои в работе электронной почты устраняются сами собой, и он был бы прав. Инфраструктура Microsoft действительно хороша, SMTP ставит письма в очередь, и большинство сбоев носят кратковременный характер.
Это уже не полная картина. Даже если перебои в работе не длительные, вопрос уже не сводится только к тому, чтобы:
“Придет ли в конце концов электронная почта?”
Вместо этого получилось:
“Может ли организация продолжать работу, если нет электронной почты?”
Любой сбой в работе Microsoft 365 приводит к снижению производительности, задержкам в обмене информацией и упущенным деловым возможностям, и эти последствия особенно заметны в крупных организациях.
Кроме того, системы обеспечения соответствия, такие как NIS2, ДОРАи SOC 2 способствуют укреплению этой тенденции к обеспечению непрерывности бизнеса. Такие рамки являются частью более широкой тенденции в области регулирования, которая побуждает организации выходить за рамки простого резервного копирования и восстановления данных и стремиться к поддержанию операционной готовности во время сбоев, киберинцидентов и перебоев в предоставлении услуг.
Хотите сразу перейти к тому, как Google Workspace, работающий параллельно с Microsoft 365, может обеспечить непрерывность бизнеса?
Explore Google Workspace for Business Continuity благодаря Connecting Software — технологическому уровню, обеспечивающему работу продукта Google Business Continuity Plus.
Резервное копирование защищает данные. Обеспечение непрерывности работы электронной почты способствует операционной отказоустойчивости.
Когда речь заходит о решении для резервного копирования Microsoft 365, обычно на первый план выходит вопрос восстановления данных после инцидент.
Решения по обеспечению непрерывности работы электронной почты, с другой стороны, призваны поддерживать работоспособность систем связи, календарей и средств совместной работы в течение этот инцидент.
Это различие имеет значение в следующих случаях:
- Сбои в работе Microsoft 365,
- блокировка доступа арендаторов,
- случаи использования программ-вымогателей,
- сбои в идентификации,
- или кибератаки.
На самом деле вопрос заключается в следующем:
Как пользователи могут продолжить работу, если основная среда недоступна?
Именно здесь пригодятся два показателя, к которым в конечном итоге сводится любая дискуссия о BCP/DR: RTO и RPO.
В традиционном обсуждении вопросов резервного копирования показатель RTO обычно измеряется как время, необходимое для восстановления пострадавшей системы или данных, тогда как показатель RPO отражает возраст точки восстановления (иными словами, объем данных за последнее время, которые могут быть утрачены).
В ходе обсуждения вопросов обеспечения непрерывности работы по электронной почте на уровне бизнес-функций часто используются те же показатели: показатель RTO определяет, сколько времени организация может выдержать, прежде чем пользователи смогут возобновить обмен данными, а показатель RPO — насколько актуальной должна быть резервная среда связи.
Это различие имеет значение для NIS2, DORA, SOC 2 и аналогичных обсуждений, касающихся отказоустойчивости и соблюдения нормативных требований, поскольку речь идет о том, сможет ли бизнес-функция продолжать работу во время сбоев.
Сравнение подходов к обеспечению непрерывности работы электронной почты в Microsoft 365
Как только требование изменится на “обеспечить поддержание связи между людьми во время сбоев”,” архитектурные вопросы в сфере ИТ становятся гораздо интереснее.
Достаточно ли будет использовать упрощенный сервис аварийной почтовой рассылки? Нужно ли учитывать особенности разных регионов? Стоит ли использовать собственную локальную инфраструктуру?
Существует множество подходов и компромиссных решений, которые необходимо учитывать для достижения того уровня непрерывности деятельности, который действительно необходим бизнесу. В приведенной ниже таблице сравниваются основные подходы, которые мы рассмотрим более подробно далее.
| Подход | Основная мысль | Примеры инструментов и поставщиков | Сильные стороны | Типичные вопросы |
|---|---|---|---|---|
| Облачные услуги по обеспечению непрерывности бизнеса | Платформа обеспечения непрерывности работы в чрезвычайных ситуациях, размещенная у стороннего поставщика | Mimecast, Retarus, Trend Micro | Быстрое развёртывание Снижение операционных затрат |
Ограниченная непрерывность работы после перехода на аварийный веб-почту |
| Второй арендатор Microsoft 365 | Отдельная среда Microsoft 365, подготовленная для переключения на резервный сервер | Microsoft 365 | Привычная экосистема Microsoft Облачная архитектура |
Зависимость от экосистемы одного поставщика, риск концентрации |
| Сервер Exchange для локальной установки | Независимая среда Exchange, синхронизированная с Microsoft 365 | Microsoft, CB Exchange Server Sync | Операционная независимость и контроль Привычная для конечных пользователей экосистема Microsoft |
Дополнительная инфраструктура и техническое обслуживание |
| Google Workspace в режиме «горячего резервирования» | Автономная среда Google Workspace, синхронизированная с Microsoft 365 | Обеспечение непрерывности бизнеса в Google Workspace, CB Exchange Server Sync для Google Workspace | Независимость от конкретного облака Можно расширить до SharePoint/Google Drive |
Различные аспекты пользовательского опыта, идентичности и отображения |
Выбор подходящей модели зависит от профиля операционных рисков организации, требований по соблюдению нормативных требований и допустимого уровня простоев. Рассмотрим каждый из вариантов более подробно.
Вариант 1: Облачные сервисы обеспечения непрерывности работы электронной почты
Это один из традиционных подходов. Такие поставщики, как Mimecast, Retarus и Trend Micro, предоставляют облачные платформы обеспечения непрерывности работы, которые обеспечивают доступ к почтовым ящикам в чрезвычайных ситуациях, маршрутизацию почты и услуги временной связи.
К преимуществам относятся быстрое развертывание и снижение эксплуатационных затрат.
Однако корпоративные команды часто задаются вопросом, насколько эти платформы действительно обеспечивают непрерывность работы, помимо временного доступа к веб-почте. Смогут ли пользователи по-прежнему синхронизировать календари, работать с общими почтовыми ящиками и беспроблемно вернуться к работе в Microsoft 365 после инцидента?
Вариант 2: Вторичный арендатор Microsoft 365
Некоторые организации используют дополнительный арендатор Microsoft 365 для обеспечения отказоустойчивости, иногда расположенный в другом регионе, чтобы снизить риск возникновения сбоев в работе сервисов, связанных с региональными проблемами.
Это может повысить отказоустойчивость, особенно если вторичный тент спроектирован с использованием отдельных систем администрирования, маршрутизации, политик доступа и процедур восстановления. Однако межрегиональная конфигурация не устраняет более общую зависимость от облачной экосистемы Microsoft.
Есть ещё один, более тонкий момент: если вторичный клиент проходит аутентификацию через того же поставщика идентификации, что и производственная среда (как правило, это тот же клиент Entra ID), то инцидент или сбой, связанный с идентификацией, может одновременно затронуть обе среды.
Вариант 3: Локальный сервер Exchange, синхронизированный с Microsoft 365
Третий подход заключается в поддержании независимой серверной среды Exchange, синхронизированной с Microsoft 365.
Одним из примеров является использование локального сервера Exchange, синхронизированного с Microsoft 365.
В данной модели:
- Microsoft 365 по-прежнему остается основной операционной платформой,
- Сервер Exchange представляет собой автономную среду обеспечения непрерывности работы,
- Переход от CB Exchange Server Sync к Connecting Software для BCP обеспечивает синхронизацию между ними.
Синхронизация может включать:
- почтовые ящики,
- календари,
- контакты,
- общие папки,
- группы рассылки,
- и синхронизация GAL.
Поскольку эта среда работает локально с собственным Active Directory, ей не нужно совместно использовать плоскость идентификации с арендатором Microsoft 365. Это существенное отличие от варианта 2: атака на основе идентификационных данных, направленная против облачного арендатора, не распространяется автоматически на локальную среду Exchange, что имеет непосредственное значение для перечисленных выше сценариев "сбоев идентификации" и "блокировки доступа арендатора".
Развертывание на локальных серверах также означает, что это оптимальный вариант, если вашей организации требуется решение такого типа для сети с воздушным разрывом. Для реализации такого сценария локальную версию можно использовать в сочетании с диодами данных.
Почему некоторые организации отдают предпочтение именно этой архитектуре
Для организаций, к которым предъявляются более строгие требования к операционной устойчивости, данный подход может обеспечить:
- операционная независимость от Microsoft 365,
- знакомый Outlook и непрерывность календаря,
- более эффективный контроль над инфраструктурой и обеспечение отказоустойчивости,
- поддержка регулируемых или изолированных сред,
- независимость идентичности от производственного арендатора,
- и снижение риска скопления облаков.
Организации, которые также используют SharePoint и совместную работу с документами, могут дополнительно внедрить стратегии синхронизации документов с помощью Secure Sync for SharePoint от Connecting Software для обеспечения безопасной синхронизации SharePoint между независимыми или изолированными средами.
Вариант 4: Google Workspace в режиме «горячего резервирования»
Четвёртый подход основан на той же логике, что и вариант 3, но предусматривает смену резервной платформы: вместо локального сервера Exchange в качестве независимой среды используется Google Workspace, которая постоянно синхронизируется с Microsoft 365 посредством .
Это предоставляет организациям возможность межоблачного переключения на резервный сервер, полностью независимую от экосистемы Microsoft. Это может иметь значение с точки зрения риска концентрации, а также пользуется популярностью среди организаций, которые уже частично используют Google Workspace в своей деятельности. Даже в тех случаях, когда это не так, пользователи зачастую знакомы с Google Workspace по личному опыту, что оказывается полезным при переключении на резервный сервер.
В следующей статье мы подробно рассмотрим эту архитектуру, её модель идентификации и связанные с ней конкретные компромиссы.
Узнайте, как настроить «горячий» резерв с помощью Google Workspace для обеспечения непрерывности бизнеса от Connecting Software
Обеспечение работоспособности при сбоях: устранение «окна восстановления»
Традиционный подход, основанный на резервном копировании и восстановлении, предполагал, что в случае сбоя кому-то всё равно приходилось запускать процедуру восстановления, прежде чем сотрудники могли возобновить работу.
Здесь возникают две проблемы: необходимость ручного вмешательства и время, требуемое для восстановления, которое пропорционально объему данных, подлежащих восстановлению. Для крупных арендаторов нередко показатель RTO измеряется в днях.
Облачные сервисы обеспечения непрерывности работы электронной почты позволяют обойти эту проблему, но их возможности ограничены.
Синхронизированная резервная среда позволяет обойтись без этого этапа. Поскольку у вас имеется постоянно обновляемая копия почтовых ящиков, календарей и, в конечном итоге, документов, пользователям достаточно просто перенаправить их в эту среду, и они смогут продолжить работу. Это переключение на резервный сервер без «окна восстановления» — среда находится в рабочем состоянии и содержит актуальные данные, что позволяет исключить «окно восстановления» из расчета RTO.
Вам придётся сопоставить эти затраты со стоимостью отсутствия у ваших пользователей доступа к электронной почте, календарю и другим данным почтового ящика с точки зрения потери производительности, незавершённых сделок и затрат на обеспечение соответствия нормативным требованиям, если это применимо.
Восстановление после сбоя: как избежать ручной сверки
Переключение на резервную систему — это лишь половина дела. В какой-то момент основная среда возобновляет работу, и пользователям необходимо вернуться в неё. Это этап возврата к основной среде, и здесь возникает важный вопрос: что происходит с отправленной и полученной почтой, изменениями в календаре и правками документов, внесёнными в резервной среде, чтобы не потерять данные и не создать дубликаты.
Придётся ли вручную синхронизировать новые электронные письма, изменения в календаре и отредактированные документы с рабочей средой? Эта работа никому не нравится, ведь именно такие ручные операции приводят к ошибкам, путанице с версиями и задержкам.
Благодаря двунаправленной синхронизации эта сверка происходит автоматически: изменения, внесенные во время сбоя, передаются обратно в Microsoft 365 без вмешательства ИТ-специалистов сразу после восстановления основной среды. Под угрозой находятся только те данные, которые изменились в течение последнего интервала опроса синхронизации — промежутка времени между одним циклом синхронизации и следующим. Если интервал составляет пять минут, то фактический RPO равен примерно пяти минутам изменений, а не полной продолжительности сбоя. Вы можете синхронизировать время восстановления после сбоя с интервалом опроса, чтобы снизить RPO до нуля.
Стоит отметить, что выбор интервала опроса сопряжён с компромиссом: его сокращение снижает RPO, но ; его увеличение уменьшает накладные расходы, но расширяет окно возможной потери данных.
Не существует единственной “правильной” архитектуры электронной почты.
Правильный выбор зависит от следующих факторов:
- операционная зависимость от Microsoft 365,
- допустимое время простоя,
- нормативные требования,
- внутренние ИТ-ресурсы,
- и цели в области операционной устойчивости.
Организации с умеренными требованиями вполне могут остаться довольны облачными сервисами обеспечения непрерывности работы.
Организациям, работающим в соответствии с требованиями NIS2, DORA или имеющим строгие требования к отказоустойчивости, может потребоваться более высокая операционная независимость и расширенные возможности переключения на резервные системы.
Заключительные размышления
Microsoft 365 обеспечивает превосходную доступность.
Однако сама по себе доступность не гарантирует отказоустойчивость системы.
Организации всё чаще признают, что обеспечение непрерывной работы электронной почты, доступа к календарю и совместной работы имеет решающее значение для поддержания деятельности в условиях сбоев.
Ведь во время реального сбоя в работе самый важный вопрос заключается не в том, чтобы:
“Можем ли мы это наверстать позже?”
Это:
"Можем ли мы продолжить работу?"
Узнайте, как настроить «горячий» резерв с помощью Google Workspace для обеспечения непрерывности бизнеса от Connecting Software
Подробнее об обеспечении непрерывности бизнеса и восстановлении после сбоев
Резервное копирование — это не обеспечение непрерывности работы: «горячее» и «холодное» восстановление для Exchange, SharePoint и Microsoft 365
Ловушка простоты: почему облачная электронная почта должна присутствовать в каждом разговоре о BCP
Восход суверенных облаков: Вопрос о контроле над данными в эпоху облаков
Об авторе
По адресу Ана Нето, технический консультант в Connecting Software.
Я работаю инженером-программистом с 1997 года, а в последнее время полюбил писать и выступать публично". У вас есть вопросы или комментарии по поводу этой статьи? Я буду рад получить ваш отзыв, оставьте комментарий ниже!"
