«Контракт со средой»

«Контракт со средой»

В ходе предшествовавшего обсуждения мы упоминали соглашения об уровне сервиса, а также тот факт, что ресурсные ИТ-службы и их пользователи ограничивают себя соблюдением общих правил, формирующих среду их функционирования. Для традиционных ресурсных служб эти правила иногда представляют собой юридические ограничения (например, услуги телефонной компании должны быть доступны всем домохозяйствам в ее зоне обслуживания), иногда правила, введенные самой ресурсной службой (так, абонентам сети кабельного телевидения не разрешается подключать усилители к входному кабелю), иногда неформальные договоренности (например, пользователи услуг Интернет-провайдеров не должны распространять спам). Такого рода правила поведения принимаются по умолчанию и обычно не указываются в SLA.
Концепция ресурсных ИТ-служб быстро развивается, а многие общедоступные и общепринятые правила поведения, необходимые для их беспрепятственного функционирования, еще не сложились. Для преодоления этой проблемы в модели RM-ODP определено соглашение, сходное с SLA по сути, но значительно более широкое по охвату — т.н. контракт со средой.
Контракт со средой можно представить себе как конкретизацию того, что ресурсная ИТ-служба может ожидать от среды своего функционирования, а среда — от ресурсной службы. При первоначальном проектировании ресурсной ИТ-службы контракт со средой определяет требуемые сервисы. Когда ресурсная служба вступит в строй, контракт со средой становится стандартом предоставления сервисов.
Контракт со средой определяет как коммуникации, так и семантику. С коммуникационной точки зрения он конкретизирует:.
протоколы, применяемые для передачи данных (например, TCP/IP, iSCSI, Fibre Channel, ленты формата tar);.
представление данных (например, форматы баз данных и файлов при обмене);.
коммуникации между ресурсной службой и окружающей ее средой (например, системы управления рабочими процессами). Спецификации семантики включают правила, политики, зоны безопасности, ограничения, налагаемые окружающей средой. Например, внешние взаимодействия может быть необходимо осуществлять через брандмауэр, в то время как внутренние должны будут происходить за брандмауэром.
На Рис. A-5 приведен перечень параметров полного контракта со средой. Спецификации качества сервиса, типичные для современных SLA, показаны здесь в более широком контексте контракта со средой. Зрелая ресурсная ИТ-служба должна иметь контракты со средой для каждого из бизнес-приложений, которым она предоставляет свои сервисы, и для каждого предоставляемого сервиса.
Контракты со средой ресурсной ИТ-службы должны отражать себестоимость предоставления сервисов. Обычной практикой является назначение более высокой платы за сервис более высокого качества (например, зеркалированные устройства хранения или ежечасное резервное копирование). Однако, как видно на Рис. A-5, с затратами могут быть сопряжены и другие, менее очевидные аспекты ресурсных сервисов. Например, предоставление дополнительных ресурсов оперативного хранения данных через несколько минут или часов после запроса пользователя очевидным образом обходится ресурсной ИТ-службе дороже, чем предоставление тех же ресурсов с предварительным уведомлением за неделю, — и это тоже должно быть отражено в цене сервиса.
Рис. A-5: Компоненты контракта со средой
Соотнося цену сервиса с его качеством, ресурсная ИТ-служба получает возможность сделать предоставление услуг более гибким. Операторы могут корректировать эксплуатационные политики на основании данных о потреблении ресурсов, чтобы обеспечить максимальную эффективность. Какие-то ИТ-подразделения могут реально выставлять.
пользователям счета за потребление ресурсов, в то время как другие могут лишь принимать эти знания к сведению при выработке бизнес решений.
В зрелой ресурсной ИТ-службе должны существовать шаблоны контрактов со средой, выраженные в понятной для пользователей форме. Пользователи ресурсных услуг не обязаны, например, быть специалистами в технологиях, применяемых для реализации сервисов. Тщательное согласование контрактов со средой с сообществами пользователей дает ресурсной ИТ-службе возможность мягко реагировать на меняющиеся режимы пользования и потребности бизнеса и закладывает основу для автоматизации по мере появления необходимого инструментария.
Пример точки зрения на ресурсную ИТ-службу.
В качестве примера того, как с помощью модели RM-ODP можно представить один из аспектов ресурсной ИТ-службы, на Рис. A-6 показана инженерная точка зрения на ресурсную ИТ-службу, предоставляющую бизнес-приложениям различные сервисы.
На Рис. A-6 конечные пользователи (роль A) взаимодействуют с бизнес-приложением (роль B), состоящим из функций представления, бизнес-логики и управления базой данных. Каждая функция использует сервисы ресурсной службы, представленные ролями D — I. Роль C отвечает за управление ресурсами и предоставление сервисов приложениям по запросу. Она включает в себя роли управления рабочими процессами, менеджера сервисов, координатора ресурсов и менеджера ресурсов. Эти менеджеры формируют сервисы (например, зеркалированное хранение данных E или сетевой доступ F) из ресурсов (например, дисков, портов коммутаторов) и предоставляют их функциям приложения. Пути, по которым ресурсная служба предоставляет сервисы, на рисунке названы каналами. Канал символизирует способность ресурсной ИТ-службы измерять потребление ресурсов, как для выставления счетов, так и для оценки уровня реально предоставленного сервиса по сравнению с SLA-компонентом контракта со средой.
Поскольку Рис. A-6 отражает инженерную точку зрения, на нем представлены роли и функции, а не исполняющие их конкретные типы компьютеров или связывающие их соединения и протоколы (которые были бы представлены в технологической точке зрения). Идентификация ролей и составляющих их функций в такой абстрагированной форме позволяет легче анализировать влияние потенциальных изменений на ресурсную ИТ-службу в целом. Например, для замены человека в роли менеджера сервисов хранения автоматизированной программой нужно, чтобы функции бизнес-приложений, потребляющие сервисы хранения, умели взаимодействовать с программой, а программа могла управлять устройствами хранения, которые применяются в данной ресурсной ИТ-службе.
Рис. A-6: Ресурсная ИТ-служба с инженерной точки зрения
В прошлом недостаточная автоматизация была одним из препятствий для создания реальных ресурсных ИТ-служб. Сервисы можно стандартизовать, однако без автоматизации управление ресурсной службой очень трудоемко и потому дорого и ненадежно. Автоматическое обнаружение, конфигурирование, развертывание и возврат ресурсов — важнейшее направление исследований и разработок в области управления компьютерными системами.
Некоторым пользователям может не нравиться, что их данные, приложения и сервисы могут использовать общие ресурсы с данными, приложениями и сервисами других организаций. Даже если технология допускает совместное использование ресурсов, надо принимать во внимание соображения безопасности и эксплуатации, а пользователей необходимо убедить, что преимущества перевешивают риски.
Выводы.
Утвержденный Международной организацией по стандартизации (ISO) стандарт Reference Model for Open Distributed Processing (RMODP) (Эталонная модель открытой распределенной обработки) определяет эталонную рамочную модель для архитектуры ресурсной ИТслужбы.
Модель RM-ODP включает пять точек зрения на распределенную компьютерную систему — точку зрения предприятия, информационную, вычислительную, инженерную и технологическую точки зрения. Каждая из этих точек зрения представляет интересы различных заинтересованных сторон (например, для руководства предприятия обычно представляет интерес точка зрения предприятия). Архитектура на базе RM-ODP описывает взаимоотношения между объектами разных точек зрения, позволяя анализировать отдаленные последствия предполагаемых изменений в ресурсной ИТ-службе.
Поскольку модель RM-ODP основана на абстрактных объектах, в ее рамках можно моделировать функционирование как бизнеса (например, отопительной системы, потребляющей электроэнергию, поставляемую ресурсной компанией), так и самой ресурсной ИТ-службы. Модель RM-ODP включает концепцию ролей, конкретизирующих те или иные функциональные ответственности. Абстрагирование ролей и функций дает два преимущества. Оно проясняет, на какие аспекты влияет изменение в технологии или процессе, и закладывает основу для автоматизации рутинных функций ресурсной службы, таких как обнаружение и развертывание ресурсов.
Чтобы ресурсная служба была успешной, соглашения об уровне сервиса (SLA), широко применяемые сегодня в сфере информационных технологий, необходимо расширить до контрактов со средой, аналогичных по сути, но более всеобъемлющих, чем SLA.
Мы привели пример архитектуры ресурсной ИТ-службы на базе модели RM-ODP, который иллюстрирует важность ролей и точек зрения. При планировании ресурсной ИТ-службы на предприятии необходимо изучить модель RM-ODP и серьезно рассмотреть вопрос о ее использовании для разработки архитектуры ресурсной ИТ-службы, прежде чем принимать какие-либо решения о финансовых вложениях.