Впервой части статьи «Перенос Exchange в «облако»» я рассказывал о меняющихся технологиях Microsoft Exchange Server и о работе инженеров — проектировщиков Exchange Server 2010, стремившихся создать такую версию программного продукта, которую можно было бы разместить в «облаке» в составе поставляемого Microsoft решения Business Productivity Online Standard Suite (BPOS). Во второй части речь пойдет о ряде проблем, с которыми компании сталкиваются, рассматривая вопрос о том, удовлетворяют ли «облачные» службы предъявляемым требованиям.

Компаниям, рассматривающим целесообразность переноса в «облако» своих почтовых служб на базе Exchange, приходится принимать во внимание множество факторов. Некоторые из этих компаний хорошо подготовились к переходу, поскольку для связи между корпоративными сетями и поставщиком услуг хостинга они используют не дорогостоящие выделенные линии, а каналы Интернета. Исследуя собственный вариант «облака», они могут лучше разобраться с проблемами, которые встанут перед ними, если эти организации действительно перейдут на «облачное» обслуживание. Другие компании, возможно, так и не откажутся от использования собственных серверов по причине консервативного подхода к ИТ, из-за опасений относительно целостности данных, в связи с требованиями, предъявляемыми законом к ИТ-подразделениям предприятий отдельных отраслей (такими, как требование Управления по продовольствию и лекарствам США проверять системы, используемые фармацевтическими компаниями для испытаний лекарственных препаратов), из-за отсутствия высококачественных или обладающих достаточной пропускной способностью каналов связи либо потому, что эти компании функционируют в странах, законодательство которых предписывает организациям хранить данные в пределах национальных границ. Некоторые компании, возможно, стремятся поскорее приступить к использованию служб Microsoft Online Services, поскольку они эксплуатируют более старые версии Exchange Server и видят в «облачных вычислениях» эффективный путь обновления своей инфраструктуры.

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

Хостинг электронной почты

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

Представители Microsoft уверяют, что для центров обработки данных, где сейчас используются системы Exchange Server 2007 и планируется их обновление до уровня Exchange Server 2010, период работоспособного состояния серверов составит 99,9%. Отметим, что в рамках программы Exchange Labs корпорация Microsoft уже предлагает Exchange 2010 в качестве дистанционно размещаемой службы клиентам в образовательном секторе; этот подход позволил группе проектировщиков Microsoft протестировать код и испытать его на предмет готовности к широкомасштабному дистанционному развертыванию.

Стандартный вариант удаленного размещения Exchange предусматривает использование нескольких дополнительных модулей за отдельную плату; к этим факультативным возможностям относится увеличение вместимости почтового ящика от базового уровня в 1 Гбайт, поддержка смартфонов BlackBerry, архивирование и миграция с другой системы обработки электронной почты. В стандартном варианте обеспечивается поддержка устройств Windows Mobile 6.0 и более новых версий, Outlook 2007, Outlook 2003, Outlook Web Access (OWA) и Entourage; в дальнейшем будет поддерживаться и Outlook 2010.

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

Цены на услуги зависят от страны. В ноябре 2009 года Microsoft объявила, что за использование BPOS будет взиматься ежемесячная плата 10 долл. в расчете на пользователя (включая Exchange, SharePoint и Office Communications Server, OCS). Цены были снижены из соображений прямой конкуренции с решением Google Apps Premier Edition, минимальный ежегодный взнос за использование которого составляет 50 долл. в расчете на пользователя плюс дополнительные компоненты. Однако для многих партнеров по услугам хостинга эта новая цена стала серьезным ударом, поскольку она оборачивается заметным сокращением маржи в бизнесе. Ценовая война между Microsoft и Google будет продолжаться, что, возможно, приведет к дальнейшему снижению затрат на почтовые ящики.

Инженеры Microsoft проектировали Exchange 2007 для традиционного развертывания, поэтому неудивительно, что некоторые из новаторских функций, такие как транспортные правила, управление правами и система объединенных коммуникаций (Unified Messaging, UM), не функционируют в средах, управляемых внешними подрядчиками. В Microsoft предполагают, что поддержка упомянутых возможностей будет реализована в версии Exchange 2010, поскольку данная версия разрабатывалась для многопользовательских распределенных систем. Кроме того, в Exchange 2010 реализуется усовершенствованная распределенная модель управления, в которой используются дистанционные возможности PowerShell 2.0, позволяющие администраторам управлять своими данными, обрабатываемыми серверами в центрах обработки данных Microsoft.

Пользователи

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

Еще один заслуживающий внимания вопрос: как взаимодействуют ваши пользователи? Могут ли они, например, в смешанной среде, включающей как внутренние, так и «облачные» серверы, по-прежнему делегировать права доступа к календарям и другим папкам почтовых ящиков? Есть ли у вас пользователи, которым необходима возможность совместного использования данных на той же платформе? Ограничено ли число календарей, с которыми может работать пользователь? Есть ли у вас общедоступные почтовые ящики, почтовые ящики ресурсов или почтовые ящики, используемые приложениями? Пока эти вопросы остаются без удовлетворительных ответов, поскольку еще не накоплен достаточный опыт управления крупными организациями Exchange, в которых используется BPOS. Однако эти вопросы необходимо задавать, чтобы лучше разобраться в требованиях пользователей — от базовых прав доступа к почтовым ящикам до тщательно проработанных методов использования новаторских функций Outlook и Exchange Server.

Поддержка

Согласование условий предоставления «облачных» услуг предполагает заключение соглашения об уровне обслуживания (service level agreement, SLA), в котором определяется уровень доступности услуги (например, 99,99‑процентный период работоспособного состояния сервера), разъясняется, какие меры поставщик услуг будет принимать в случае отказов электросети, и указывается объем компенсаций в случае, если провайдер не обеспечивает указанное в контракте время безотказной работы. Простое заключение соглашения SLA — это еще полдела, гораздо труднее обеспечить сквозной мониторинг прохождения электронной почты и разобраться с ролями, которые играют локальная и «облачная» поддержка.

Если ваша компания обеспечивает собственную локальную поддержку, обычно сюда входит сетевая инфраструктура, скажем, средства подключения к Интернету, клиентское программное обеспечение, интеграция с другими приложениями, зависящими от электронной почты. Поставщик услуги обеспечивает поддержку предоставляемой услуги. Почти все мероприятия по поддержке осуществляются на локальном уровне; контакт с поставщиком услуг требуется лишь в тех случаях, когда услуга недоступна в течение продолжительного времени (как это было при выходе из строя почтовой службы Gmail компании Google в августе 2008 года). Ваша сеть связана с «облаком» через Интернет, поэтому временные сбои в сети, из-за которых клиенты время от времени теряют возможность взаимодействия, совершенно естественны — в конце концов, за Интернет никто не отвечает и ни один поставщик услуг Сети не может гарантировать безукоризненную связь. Именно по этой причине, кстати, режим кэширования Exchange является столь ценной функцией Outlook.

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

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

Приложения

Exchange часто интегрируется с другими приложениями, включая приложения Microsoft, такие как SharePoint и OCS, с приложениями других крупных поставщиков программного обеспечения, например SAP и Oracle, а также с приложениями собственной разработки, спроектированными «поверх» Outlook или Exchange с помощью целого ряда API — от WebDAV до Exchange Web Services. При переходе на систему на базе «облака» вам нужно определиться, как быть со всеми приложениями, связанными с электронной почтой.

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

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

Рассматривая вопрос о взаимодействии Exchange с приложениями, не забудьте об общедоступных папках. Хотя после 2003 года представители Microsoft неоднократно заявляли о своем намерении покончить с общедоступными папками в системе Exchange, настойчивые просьбы со стороны клиентов вынудили компанию сохранить поддержку таких папок по меньшей мере до 2016 года. В некоторых компаниях имеются тысячи общедоступных папок с гигабайтами данных. В этих папках хранятся архивы сообщений дискуссионных форумов или приложений документооборота. Определить, как применяемые в вашей организации общедоступные папки поведут себя в «облаке», может быть весьма непросто. Взять хотя бы такой вопрос: сможет ли почтовый ящик в «облаке» обращаться к содержимому общедоступной папки, размещенной на внутреннем сервере? Или другой случай: если эта общедоступная папка использует приложение на базе форм, сможет ли упомянутый почтовый ящик обратиться к этой форме и заполнить ее корректными данными, так чтобы пользователи могли успешно взаимодействовать с приложением? Невозможно себе представить, что Microsoft позволит компаниям переносить общедоступные папки в Exchange Online, поскольку идея поддержки настраиваемых приложений противоречит подходу, когда услуги предоставляются с помощью многопользовательской инфраструктуры по принципу коммунального предприятия, то есть ограниченного набора функций, предоставляемого за умеренную плату, ведь это можно реализовать в больших масштабах только потому, что все получают одну и ту же услугу.

Та же проблема дает о себе знать, когда мы начинаем рассматривать различные аспекты других приложений Microsoft, таких, как настройки OWA (например, изменение страницы регистрации для размещения на ней логотипа корпорации) или веб-частей SharePoint, необходимых для функционирования приложений. Коммунальные услуги являются не более чем коммунальными услугами. Ведь не станете же вы требовать от водопроводной или электроэнергетической компании оказания особых услуг; не следует ждать и от Microsoft того, что эта корпорация будет предоставлять вам специализированную форму Exchange или SharePoint в рамках своей коммунальной услуги. Возможно, в будущем Microsoft позволит компаниям оптимизировать определенные аспекты онлайн-услуг, но я не думаю, что это случится в ближайшее время.

Издержки

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

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

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

План действий в чрезвычайных обстоятельствах

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

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

Будущее «облака»

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

Тони Редмонд (exchguru@windowsitpro.com) — редактор журнала Windows IT Pro, старший технический редактор Exchange & Outlook Administrator, вице-президент и главный технолог HP Services