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

Введение в тему

В состав решения Office 365 входит набор известных продуктов семейства Office в специальной облачной реализации, дополнительные продуктами OneDrive — облачный хостинг пользовательских файлов, Yammer — корпоративная социальная сеть. Для работы с облачными продуктами используются интернет-браузер или классические версии клиентского ПО Microsoft Outlook, Microsoft Lync, подключенные к серверам в облаке. Среди преимуществ облака Office 365 для отдельного пользователя — большой объем хранения (основной почтовый ящик — 100 Гб, плюс архив, до 1 Тб хранения файлов, документов в хостинге), совместная работа с документами, возможность доступа 24×7 везде, где есть Интернет, с различных устройств.

Заказчик через приобретение и активацию лицензий арендует у Microsoft ограниченную область — облачный тенант.

Укрупненно есть два сценария заказчика работы с облаком:

  • сценарий полного перевода пользователей в облако или подключения их напрямую в облачный тенант;
  • гибридный сценарий — часть пользователей остается на собственных серверах предприятия, часть пользователей работают в облачном тенанте. Гибридный сценарий также обеспечивает плавную по времени миграцию пользователей организации с развитой собственной инфраструктурой Microsoft Exchange (электронная почта), вплоть до полного перехода на облако.

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

Вопросы авторизации пользователей решаются либо непосредственным заведением паролей в облаке, либо через механизм связывания облачного Active Directory и Active Directory заказчика через службы ADFS (Active Directory Federation Services), что позволяет реализовать для пользователей заказчика Single Sing-On доступ к ресурсам облака.

С конца 2013 г. Microsoft, обновив версию облачного тенанта, декларировала поддержку сценария multi-forest для заказчиков с холдинговой структурой — группа компаний с разным ИТ-структурами, с пользователями, расположенными в несвязанных Active Directory с независимыми Exchange-организациями. Все независимые Exchange-организации могут присоединиться к одному общему тенанту в облаке, сохраняя возможность гибридного сценария для каждой компании. Выгода сценария multi-forest: в облаке работает единая адресная книга, доступны календари, статусы присутствия, группы рассылки, общие порталы, общие собрания, документы для пользователей из различных компаний.

Пивоваренная компания «Балтика» входит в состав группы «Карлсберг», включающей несколько десятков компаний, расположенных в разных странах, с разными ИТ-службами на несколько тысяч пользователей, что подтолкнуло нас к использованию сценария multi-forest. Далее на нашем примере рассмотрим, с какими проблемами сталкивается заказчик облачных решений с точки зрения ИТ, принимая решения о переходе на Office 365 и реализуя такой переход.

Общие проблемы для любой модели использования облака Office 365 заказчиками с собственной развитой инфраструктурой

Часть возможностей продуктов Office при переводе в облаке либо теряются, либо работают с ограничениями, по сравнению с использованием тех же продуктов в серверной инфраструктуре предприятия. Например, Microsoft Lync (система обмена мгновенными сообщениями, проведения собраний) имеет развитые возможности интеграции с телефонией заказчика: сотрудники, пользователи Lync могут звонить на городские телефоны, офисные телефоны других сотрудников и наоборот. Облачный Lync Online не поддерживает интеграцию с телефонией предприятия.

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

Группы безопасности Active Directory невозможно синхронизировать в облако, что означает, например, пересмотр и перестройку структуры доступа к порталам, мигрирующим в SharePoint Online, если в SharePoint (корпоративные порталы) на предприятии доступ базировался на AD-группах.

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

Особенности гибридных моделей облачного сервиса

В гибридной модели развернутые на предприятии решения Exchange, Lync, SharePoint, а также сервисы Active Directory, DNS, ADFS тесно работают с серверами, сервисами в облаке. Тесная работа с облаком ИТ-решений на стороне заказчика требует от него развертывания последних версий используемых продуктов. В дальнейшем заказчику обязательно придется своевременно обновлять связанные решения в корпоративной инфраструктуре. Использование необновлённых версий — это риски заказчика, невыполнение требования условий по поддержки решения, с непредсказуемым результатом функционирования облачных сервисов для пользователей. В некоторых случаях смена версий тенанта, связанная с этим смена версий серверных продуктов на стороне заказчика требуют обязательного обновления клиентской части, миграции с неподдерживаемых версий клиентов. Как следствие — это дополнительные усилия и затраты для заказчика на планирование, подготовку, тестирование, реализацию обновления, миграции. Нужно быть готовым к сбоям в процессе миграции, проявлению скрытых ошибок при миграции и в уже установленных новых версиях продуктов. К чести вендора, проблемы достаточно быстро решаются, но все же могут оказывать и оказывают влияние на непрерывность, стабильность работы пользовательских сервисов и на воспринимаемое пользователями качество, которым часто непонятна вся ИТ-суета со сменой версий продуктов.

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

Особенности облачного сервиса для крупных организаций

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

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

Проблемы, характерные для сценария multi-forest

Office 365 хорошо приспособлен для централизованной модели управления и плохо приспособлен для более сложных организационных моделей управления, поддержки совместных решений среди разных ИТ-групп, разных компаний.

В облачном тенанте используется «плоская» служба Active Directory, и нет возможности разбить объекты облачного тенанта, например, пользователей, по различным коллекциям и ограничить к ним доступ отдельным администраторам. Все пользователи доступны всем администраторам. Заказчик либо вынужден переходить на централизованную модель управления пользователями в облаке, либо искать и приобретать третьи продукты для управления, либо эмулировать распределенное управление на договоренности администраторов различных компаний не трогать «чужих» пользователей. У любых из обозначенных подходов есть свои минусы, усугубляющие проблему совместного управления. Например, в подходе «не трогать „чужие“ объекты» остается пресловутый человеческий фактор задеть вручную или скриптом автоматизации пользователей другой компании, лишить их возможности работы с облаком, и нет никакой возможности откатить проведенные изменения назад, отменить изменения. Чтобы исправить, надо будет сначала найти, что было сделано неправильно.

В облачном тенанте у вас единый пул лицензий на тенант, сразу на все компании, без возможности привязки к отдельным компаниям. Сам пул лицензий собирается из пакетов лицензий, активированных по контракту либо дополнительной закупкой, либо продлениями. И так по всем контрактам всех компаний — участниц тенанта. У каждого пакета свое количество и состав лицензий — планы (например: E1, E2, E3), сроки начала и окончания действия лицензий в пакете.

Отсюда проблема: нет возможности управлять пакетами лицензий, кроме как продлевать пакет на следующий срок. Управление происходит на уровне пула целиком, оперируя понятиями сколько всего есть лицензий различных планов, сколько занято (привязано к пользователю, объектам облака), сколько свободно. Вы можете привязать к пользователю лицензию из общего пула, взяв из числа свободных. При этом вам недоступна информации о сроке окончания лицензии конкретного пользователя. При наступлении срока окончания какого-либо пакета лицензий — сюрприз: случайный набор пользователей остается без лицензий, а значит, без доступа к сервису, даже если в пуле есть свободные лицензии. Администратору необходимо найти пользователей без лицензий и привязать к ним свободные лицензии из пула. По правилам использования ящик без лицензии хранится в облаке семь дней и потом удаляется. Никакого backup, никакой возможности восстановить.

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

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

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

Если у компании есть собственная инфраструктура Active Directory и для удобства авторизации пользователей в облаке требуется обеспечить им Single Sign-On, если есть собственная почтовая система Exchange и нужно сохранить всю наработанную пользователями корреспонденцию, архивы, группы рассылки, права доступа ассистентов к ящикам руководителей, совместные ящики, используемые адреса, то подключение к облаку — это только проект миграции в облако. Первое, с чем столкнется заказчик, — необходимость найти партнера с успешным опытом миграции в облако клиентов сопоставимых размеров и условий (и это уже будет нетривиальная задача), либо нанять профессионалов из Microsoft Consulting Services. Второе, миграция — это крупный проект, который начинается с обследования готовности серверной и клиентской инфраструктуры заказчика, сетей и требует приведения всех задействованных решений в состояние готовности к работе с облаком. Фактически это набор проектов по миграции на требуемые последние версии продуктов на серверах и клиентских устройствах, настройке сетевых решений. Необходимо будет развернуть дополнительные сервисы, такие как AADSync — для синхронизации объектов Active Directory заказчика в облако, ADFS — для авторизации облачных пользователей в Active Directory заказчика.

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

Проект также потребует организации тестовой среды с копией всех существующих Active Directory, Exchange организаций, Lync, SharePoint, настройки ADFS, инструментов синхронизации, сетевого дизайна, подключения к тестовому тенанту с обкаткой настроек и всех аспектов миграции и всех типовых задач подготовки к миграции и собственно миграции.

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

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

Выводы

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

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

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

Автор статьи — начальник отдела развития информационных систем и инфраструктуры пивоваренной компании «Балтика».