Управление — непременное условие успешной реализации SharePoint. Без него неудачи неизбежны, и многие компании убедились в этом на собственном горьком опыте.
Значение управления огромно, и материалов по этой теме очень много. Среди источников информации первый — TechNet SharePoint Server 2010 Governance Resource Center (technet.microsoft.com/en-us/sharepoint/ff800826.aspx). Из многочисленных прочих ресурсов стоит отметить блоги SharePoint MVP и журнал SharePoint Pro.
В большинстве источников основное внимание уделяется созданию инфраструктуры управления: объединению людей, политик и процедур и подготовке плана управления. Но слишком часто из круга тем выпадает четвертый чрезвычайно важный компонент управления: технология.
Необходимо изучить технологию, которой предстоит управлять; нельзя возлагать на нее задачи, которые она не способна решить. В этой статье речь пойдет о технической стороне управления. Кроме того, мы ответим на несколько важных вопросов.
- Как, собственно, выглядит управляемая реализация SharePoint?
- Какова физическая и логическая архитектура такой реализации?
- Сколько ферм, серверов, веб-приложений, баз данных контента, семейств веб-сайтов и сайтов имеется в реализации?
К сожалению, немедленный ответ на все три вопроса: «Зависит от обстоятельств». Ответы зависят не от SharePoint, а от целей, для которых он применяется. Лучший способ найти ответ в конкретной ситуации — последовательно пройти по четырем этапам описываемого процесса проектирования управления. В результате вы не только ответите на приведенные выше вопросы, но и построите логическую, физическую и управляемую архитектуру, соответствующую особенностям вашего бизнеса.
Основное внимание в этой статье я хочу уделить самому процессу, который состоит из четырех основных шагов. В следующих статьях по этой теме я поясню, как применить процесс к конкретным обстоятельствам, чтобы получить алгоритм строительства оптимальной архитектуры. Кроме того, я покажу, как использовать технологию для автоматизации и применения политик управления.
Шаг 1. Определение требований
Шаг 1 связан с требованиями к управлению. Как консультант, я провожу примерно 80 % времени, помогая клиентам определить требования и навести порядок в информации для подготовки требований. Невозможно найти эффективное решение, не осознав требований к нему. SharePoint — не исключение.
Проблема в том, что реализации SharePoint связаны с многочисленными требованиями. Поэтому я пришел к выводу, что их полезно разбить на категории, а затем определить, какие категории наиболее важны для каждого шага процесса проектирования архитектуры управления. Итак, рекомендую разбить требования на следующие категории.
- Бизнес-требования — самые важные. Они определяют назначение решения, которое просит подготовить клиент. По возможности старайтесь не смешивать бизнес-требования с техническими требованиями. Чаще всего технические требования оказываются искусственными. Если клиент говорит: «Мне нужен дочерний сайт, который делает x» или «Мне нужна кнопка, которая делает y», то этот клиент занимает позицию технолога, разработчика решения. Посоветуйте ему отвлечься от деталей и сформулировать желаемый результат (x или y), не вдаваясь в тонкости технологии. Предоставьте проектировать техническое решение тем, кто в этом разбирается.
- Технические требования. Порой необходимо учитывать технические требования. Например, если разъездные продавцы будут использовать свои устройства iPad для доступа к решению, то обеспечение доступа через iPad — законное техническое требование. Такие технические требования чаще относятся к архитектуре — совместимости с другими решениями — или инфраструктуре, нежели к функциональности или особенностям применения.
- Требования к процессу проектирования. Они относятся к созданию решения, а не к его назначению. Основные примеры требований к проектированию — бюджет и сроки.
- Требования к информационной архитектуре. Согласно традиционному определению, информационная архитектура относится к методам описания, организации и обнаружения контента.
- Требования к управлению информацией. Они определяют, как управлять контентом в течение времени его существования: как он создается, поддерживается, архивируется или удаляется. Эти требования относятся к безопасности, управлению записями, аудиту и соответствию нормативным актам.
- Требования к управлению услугами. За решением, контентом и информацией стоит собственно услуга. Требования к управлению услугами описывают восстановление, доступность и производительность. Эти требования отражаются в целях уровня обслуживания (SLO) или соглашениях об условиях обслуживания (SLA).
Разделение требований на категории полезно по ряду причин. Прежде всего, можно обнаружить зависимости между требованиями. Это поможет выбрать более логичный подход к сбору требований.
Необходимо продумать и определить бизнес-требования и технические требования, прежде чем удастся верно изложить остальные требования. После того, как определено решение, можно определить типы информации, связанные с ним. Это вынуждает выяснить требования к информационной архитектуре и управлению информацией.
Деловые, технические и информационные требования определяют требования к управлению услугами. И на них влияют требования к процессу проектирования, в частности, бюджет и сроки. Возможно, требования к проектированию придется скорректировать с учетом требований других категорий.
Важное замечание: бесполезно обсуждать требования к управлению информацией или услугами, пока не определены деловые и технические требования.
Если процесс плохо организован или вводятся дополнительные технические или бизнес-требования, придется заново обратиться к требованиям информационной архитектуры, управления информацией и управления услугами.
Вторая причина, по которой полезно разделить требования на категории — возможность более эффективно перейти ко второму шагу нашего процесса, где основное внимание уделяется требованиям управления информацией и услугами.
Сохраняются двусторонние взаимозависимости с требованиями к процессу проектирования, но, по крайней мере, окончательно сформулированы требования бизнеса и информационной архитектуры, на основании которых определены требования управления информацией и услугами. К требованиям информационной архитектуры нам предстоит вернуться на последнем этапе процесса проектирования управления.
Определив требования, можно приступать к проектированию решения, соответствующего этим требованиям. На данном этапе нужно сделать выбор: строить решение самостоятельно или приобрести. Признак верного подхода на данном этапе: порой вы приходите к выводу, что SharePoint — не подходящее решение для конкретного требования.
Действительно, нельзя не согласиться, что SharePoint — не универсальное средство для удовлетворения нужд предприятия. Ваш процесс должен быть достаточно зрелым, чтобы преодолеть излишний энтузиазм по отношению к SharePoint в случаях, когда продукт просто не подходит для достижения конкретной цели.
Мы не будем тратить время на разбор технических вариантов. Пока исходим из того, что SharePoint — оптимальное решение в данной ситуации и переходим ко второму этапу.
Шаг 2. Согласование требований с параметрами управления и областями их действия.
На втором этапе мы определим, как спроектировать службу SharePoint в соответствии с конкретными требованиями организации, особенно в категориях управления информацией и услугами.
Прежде всего, необходимо уточнить, что мы будем называть параметрами управления в SharePoint. Параметр управления — настраиваемый параметр, который каким-то образом влияет на управляемость SharePoint. Рассмотрим простой пример.
Одно из требований к управлению услугами должно относиться к хранению контента (то есть сколько места в хранилище займет контент, связанный с решением). Требование обеспечить определенный объем хранилища реализуется, конечно, с помощью квот. Квоты представляют собой параметр управления, который можно настроить в соответствии с требованием.
Выявив параметр управления, обеспечивающий требование, необходимо определить область его действия. У ферм SharePoint есть физическая и логическая архитектура. Логическая архитектура представляет собой иерархию ферм, веб-приложений, баз данных контента, семейств сайтов, сайтов, списков и библиотек.
Веб-приложения имеют зоны и обычно потребляют одну или несколько служб, таких как поиск или метаданные. Логическая иерархия показана на рисунке. Физическая архитектура относится к серверам в ферме и распределению служб между серверами. Другими словами, на каких серверах размещены веб-сайты, на каких службы (например, поиск), и на каких — базы данных SharePoint?
.jpg) |
| Рисунок. Логическая иерархия ферм, веб-приложений, баз данных контента, семейств сайтов, сайтов, списков и библиотек |
Параметры управления обычно действуют в одном, и только в одном, контейнере логической или физической архитектуры SharePoint. Например, область применения квот — семейства веб-сайтов. Можно назначить квоту для семейства веб-сайтов, но не для дочернего сайта или всего веб-приложения. Нельзя также настроить лимит хранилища для отдельного пользователя в семействе веб-сайтов группы; первоначальная квота применяется ко всему контенту в семействе веб-сайтов, независимо от того, кто создает контент.
Область — абсолютно критичная концепция, так как она определяет, потребуется ли более одного экземпляра любого объекта в логической или физической архитектуре. Если отделу кадров и группе инженеров требуются особые квоты (например, инженерам требуется больше места для хранения документов САПР и изображений), то выбора нет: для обслуживания различных нужд необходимо две области — одна для кадровиков и одна для инженеров, — к которым применяются различные квоты. Таким образом, необходимы два семейства веб-сайтов.
Если каждое решение в компании имеет одинаковые требования к управлению информацией и услугами, то можно обойтись единственной фермой, одним веб-приложением и одной базой данных контента (размером 4 Тбайт) и одним семейством веб-сайтов. Но, вероятнее всего, требования к управлению информацией и услугами у разных решений различные, и областей потребуется много.
На практике области параметров управления так часто привязаны к семействам веб-сайтов, что я называю семейства веб-сайтов административным контейнером в архитектуре SharePoint. Многие параметры управления услугами и информацией, в том числе квоты, владение (членство в группе администраторов семейства веб-сайтов), область клиента, управление пользователями и группами, аудит, блокировки, песочницы и параметры поиска привязываются к областям на уровне семейства веб-сайтов.
Необходимо также учесть возможности параметра управления. Например, существует дикое требование управления услугами — выполнять резервное копирование данных в крупном решении каждую минуту. Если объем контента достаточно велик, то просто невозможно удовлетворить это требование с использованием API-интерфейсов SharePoint.
Другой пример — песочницы. Если требование управления услугами — изолировать пользовательский код, то можно настроить песочницу — параметр управления с областью, охватывающей семейство веб-сайтов. После того, как песочницы активированы, администратор семейства веб-сайтов может передать решения в песочницу и активировать их. Готовой функции для добавления рабочего процесса, посредством которого другой администратор более высокого уровня может одобрить решение перед его активацией, не существует.
В данном случае ключевое слово «готовой». Хотя параметры управления SharePoint могут иметь определенные ограниченные области и возможности, иногда можно создать или приобрести инструменты, расширяющие эти области и возможности.
Поэтому, если сложилась ситуация, в которой требования к управлению информацией или услугами ведут к неприемлемой архитектуре, можно обойти это ограничение, написать или приобрести программный код, который устраняет ограничения, либо вернуться к вопросу о том, является ли SharePoint удачным техническим решением для выполнения этого требования.
Второй этап — центральная часть процесса проектирования управления. Необходимо определить, каким образом SharePoint может обеспечить требования к управлению информацией или услугами через готовые или расширенные параметры управления, и как логическая и физическая архитектура необходима для назначения областей действия параметров.
Шаг 3. Согласование бизнес-требований с параметрами управления, функциональными возможностями и областями
Рассмотрение набора требований на втором этапе обычно дает архитектуру, которая определяет фермы, серверы, веб-приложения, базы данных контента и семейства веб-сайтов. Иногда архитектура распространяется глубже до сайтов, списков и библиотек. Полученная в результате архитектура обеспечит выполнение требований управления информацией и услугами.
Затем можно дополнительно углубить архитектуру для соответствия бизнес-требованиям, в частности, функциональным требованиям, реализованным как определение функции, шаблона, списка, библиотеки или сайта.
Например, предположим, что бизнес-требование можно выполнить, предоставив блог руководителю сайта группы. SharePoint реализует блоги как определение сайта (или шаблон), поэтому логическая архитектура должна содержать сайт для блога — обычно отличного от другого коллективного контента на сайте группы.
Шаг 3 похож на шаг 2, но на нем используется другой набор требований для достижения более низких уровней логической архитектуры. На шаге 3 бизнес-требования не учитывались, хотя они принимались во внимание при формировании рассматриваемых требований управления информацией и услугами.
Как правило, по завершении этого шага в логическую архитектуру, полученную на втором этапе, добавляются какие-либо дочерние сайты, списки и библиотеки. Как правило, на этапе 3 фермы, серверы, веб-приложения, базы контента или семейства веб-сайтов в архитектуре не изменяются.
Шаг 4. Совмещение информационной архитектуры и управляемости
Даже простая реализация SharePoint обычно содержит более одного семейства веб-сайтов, веб-приложения и фермы. А если контент распределен между двумя или несколькими семействами веб-сайтов, веб-приложениями или фермами, или базами данных и серверами, то работать с SharePoint становится трудно.
Прежде всего, усложняется навигация. Если создать контент внутри одного семейства веб-сайтов — например, дочерний сайт — то можно добавить ссылки на родительский контейнер для простых перемещений пользователей. Но если сформировать второе семейство веб-сайтов, такие навигационные ссылки не создаются. Необходимо управлять навигацией вручную, либо строить или покупать инструмент для управления и представления навигационной структурой.
Усложняется и администрирование. Если пользователю необходим доступ к контенту в каждом из двух семейств веб-сайтов, то его следует отдельно ввести в каждое из них; управление удостоверениями происходит в рамках семейства веб-сайтов. Если нужно получить отчет аудита контента, то необходимо получить отчеты из обоих семейств веб-сайтов; областью настройки и подготовки отчетов аудита является семейство веб-сайтов.
Поскольку семейства веб-сайтов, как отмечалось выше, представляют собой административный контейнер SharePoint, нагрузка на администратора возрастает немедленно после того как появляется второе семейство веб-сайтов.
Для администрирования и управления реализацией SharePoint с двумя или несколькими фермами, веб-приложениями, базами данных контента или семействами веб-сайтов лучше всего подходит Windows PowerShell. С помощью PowerShell можно организовать циклическую обработку элементов архитектуры, без труда выполняя повторяющиеся задачи. Несколько сторонних инструментов обеспечивают общее представление службы SharePoint, какой бы сложной ни была ее физическая и логическая архитектура.
При проектировании архитектуры управляемой реализации SharePoint конечное решение почти неизменно оказывается более сложным для повседневного управления, чем хотелось бы. Разрыв между управляемостью и простотой эксплуатации — досадное следствие применения платформы с ограниченной, но мощной функциональностью для обслуживания множества бизнес-требований.
Огромное значение приобретают обходные приемы, PowerShell и расширения для SharePoint. К счастью для всех нас, SharePoint располагает превосходным сообществом консультантов, разработчиков, менеджеров проектов, ИТ-специалистов, инженеров с сертификатом MVP и поставщиков информационных услуг.
В данной статье обозначены контуры процесса, в котором можно перейти от техзадания к управляемой архитектуре SharePoint. В следующей статье я приведу несколько типичных примеров из практики и опишу их влияние на физическую и логическую архитектуру.