Супрун Д.Е. - Облачные вычисления в бизнесе

Аннотация

Супрун Д.Е. Облачные вычисления в бизнесе. Произведен анализ облачных служб. Приведена модель облака с подробным описанием структуры. Рассмотрены особенности применения облачных вычислений в бизнесе и особенности поддержки уровней облака.

Современные бизнес-процессы нуждаются в совершенствование систем управления (СУ). Одним из таких направлений является реализация облачных вычислений при построении СУ.

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

Давно известная основа основ ITSM (IT Service Management) — переход от управления технологическими компонентами ИТ-инфраструктуры к управлению сервисами для бизнеса на базе этой инфраструктуры, однако, на практике это не реализуется в полной мере. Но именно этот фундаментальный сдвиг парадигмы управления ИТ является определяющим для успеха другого сдвига — перехода от локальных ИТ-инфраструктур к гибридной среде, объединяющей виртуализированные ресурсы ЦОД (Центр Обработки Данных) компаний с публичными облачными сервисами.

Так в компании Ovum прогнозируют к 2015 существенный рост использования частных и гибридных облаков в организациях. По данным Forrester к концу текущего десятилетия затраты ИТ-отделов по всему миру на облачные сервисы различных типов возрастут почти на порядок и составят около 45% от всех затрат на ИТ-сервисы. Оплата по факту использования, быстрый ввод в продуктивную эксплуатацию и гибкие возможности по изменению и улучшению ИТ-сервисов делают облачную модель все более привлекательной.

Для ИТ-служб ключевыми задачами становятся создание и поддержка сервисного каталога и портала самообслуживания, автоматизация процессов управления (оркестровки), подразумевающая интеграцию между собой разных процессов ITSM для поддержки сложных комбинированных сервисов. В Forrester отмечают, что в большинстве организаций, несмотря на рост зрелости реализованных базовых процессов, таких как управление инцидентами, проблемами и изменениями, они остаются слабо интегрированными, и в результате компании, избавившись от изолированности технологий (technology silos), оказываются в условиях изолированности процессов (process silos). В потреблении облачных сервисов основную роль начинают играть запросы бизнеса, а не ИТ-подразделения, и для реализации действительно бизнес-сервисов необходима максимально интегрированная картина всех параметров сервиса, что невозможно без интеграции процессов.

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

На первый план в облачной парадигме выходит процесс управления конфигурациями, тесно связанный с процессом управления активами. В конфигурационной базе данных (configuration management data base, CMDB) для каждого сервиса должна быть реализована сервисно-ресурсная модель, позволяющая понять, как операционная доступность отдельных инфраструктурных компонентов влияет на предоставление определенного сервиса. Интегрированная с CMDB финансово-ресурсная модель показывает вклад, который вносит в стоимость сервиса поддержка отдельных ИТ-активов, что обеспечивает точную оценку себестоимости каждого сервиса для выстраивания финансового управления.

Необходимые для облачных сервисов точные характеристики качества обслуживания в SLA (Service Level Agreement) недостижимы без использования решений класса BSM (Business Service Management), которые позволяют привязывать результаты мониторинга инфраструктуры к определенным сервисам. Одним из ключевых принципов облачных технологий является наличие портала самообслуживания, реализация которого требует создания автоматизированного каталога сервисов, включающего в себя четкий перечень сервисов вместе с заданными для них SLA. Предоставление эластичных сервисов по требованию делает обязательным и внедрение инструментов оркестровки, которые автоматизируют выполнение рутинных процедур управления ЦОД.

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

Облака характеризуются следующими основными свойствами:

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

Облака приобретают разные формы и построены из разных компонентов, поэтому необходима систематизация и классификация (таксономия) облаков.

Попытка облачной таксономии показана на рис. 1, где выделены пять признаков: физическая модель (Deployment Model), используемые стандарты (Standard), технологии (Technology), философия (Philosphy) и модель предоставления сервисов (Model). С учетом недостатков такой классификации, все-таки возникает общее представление о системе, хотя необходимо помнить, что само облако является сложной системой, а предоставляемые им сервисы служат для создания сложных систем.

Рисунок 1 – Таксономия облака

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

оплата по факту использования;
самообслуживаемость;
масштабируемость.

Сервисы VMware SlideRocket (SaaS), Socialcast (SaaS), ITBM (SaaS) или CloudFoundry (PaaS) удовлетворяют этим требованиям. Другие сервисы и решения дают возможность партнерам предложить решения, удовлетворяющие перечисленным требованиям. Если говорить про IaaS, то имеется комплексное решение vCloud Suite, позволяющее создать инфраструктуру частного, публичного или гибридного облака.

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

Для того чтобы помочь организациям эффективно решать задачи ITSM в случае облачных сред, VMware предлагает как различные программные решения, оптимизированные для облаков и автоматизирующие различные процессы ITSM, так и набор лучших практик по проектированию (vCAT) и эксплуатации (Cloud Ops) облачных сервисов.

Существование сервисов поддерживается системой стандартов и, что не менее важно, системой контактов — кроме формальных правил, по которым происходит взаимодействие, требуется еще и знание того, с кем и каким образом следует производить взаимодействие (адресная книга). Стандарты SOAP, WSDL, Atom и REST необходимы, но недостаточны — бизнес-сервисы, помимо стандартов, предполагают знание контактов. Под контактами понимают следующие свойства сервисов: временная доступность сервиса, его производительность, частота его использования, а также организация ответственности за возможные сбои, информацию изменения и модернизация и т. д. Использование контактов является важной частью управления; с использованием контактов строится слабосвязанная системная архитектура. Стандарты служат средством, обеспечивающим согласованность компонентов, а контакты определяют требуемую связанность. Сочетание стандартов и контактов позволяет автоматически вызывать для исполнения тот функционал, который нужен в данном местe и в данное время.

SOA и CAP (Cloud Architecture Pattern, облачные архитектурные образы) разделяют ряд общих положений:

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

Говоря о любых облачных сервисах (*aaS), следует иметь в виду, что облака есть способ потребления технологий в привязке к бизнес-процессам, но не собственно технологии. Облака позволяют избавиться от забот об инфраструктуре и сосредоточиться на количестве и качестве потребляемых ресурсов. С пользовательской точки зрения *aaS описывает услуги, оказываемые тем или иным многократно используемым (reusable), тонко гранулированным (fine-grained) программным или аппаратным компонентом, размещенным в облаке. Из всего множества различных *aaS чаще всего встречаются SaaS, IaaS и PaaS, однако в облаках могут предоставляться в сервисной форме системы хранения (Storage as a Service, SaaS), безопасности (Security as a Service, SECaaS), СУБД (Database as a service, DaaS), средства мониторинга и управления (Monitoring/Management as a Service, MaaS), коммуникации, контент и вычисления (Communications, Content & Computing as a Service, CaaS), контроль идентификации (Identity as a Service, IDaaS), резервное копирование (Backup as a Service, BaaS) и десктопы (Desktop as a Service, DaaS). Каждый из перечисленных сервисов можно соотнести с шестиуровневой моделью облака (рис. 2).

Рисунок 2 – Шестиуровневая модель облака

На уровне IaaS и SaaS клиент получает в пользование нужный ему объем оборудования, поддерживаемого и обслуживаемого провайдером; PaaS обычно предоставляет в пользование ресурсы серверов приложений; SaaS позволяет использовать уже готовые приложения типа CRM, ERP и т. п. Мониторинг с применением MaaS позволяет упрощать процессы миграции приложений между частными и глобальными облаками.

Стандарты на формирование облачных процессов отсутствуют, в том числе и для облачных сервисов.

Можно выделить два направления в стандартизации для IaaS, которые распространяются на:

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

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

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

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

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

Основные компоненты сервиса (инфраструктуры поддержки моделей сервисов IaaS, PaaS и SaaS) отделены территориально, организационно и финансово (как активы) от потребителя (компании, которая использует и оплачивает сервисы) и конечного пользователя (работника компании). Это означает территориальный, организационный и финансовый разрыв в сопровождении, а в цепочке предоставления сервиса появляется еще один компонент — Интернет, от которого в огромной степени зависит надежность и качество предоставления сервисов. Иначе говоря, возникает и обретает главенствующую роль провайдер, от которого зависит благополучие потребителя и существование поставщика облачного сервиса. Очевидно, что должны усложниться юридические отношения между поставщиками и потребителями и возникнуть новые — между поставщиками отдельных компонентов сервиса, например между поставщиками инфраструктуры и приложений.

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

У потребителя возникает задача координации сопровождения отдельных сервисов, предоставляемых разными поставщиками. Если сервисы интегрированы, например, в случае SaaS (горизонтальная интеграция сервисов), то поддержка интегрированной системы становится сложной многовариантной задачей. Потому что в таком случае всегда будет возникать ситуация по поиску ответственных за решение целиком, а не за его отдельные части. Вполне возможен вариант вертикальной интеграции, когда поставщик SaaS предоставляет программный сервис потребителю, поставщик PaaS — платформу поставщику SaaS, а поставщик IaaS — инфраструктуру последнему. В этой цепочке могут участвовать также поставщик данных, поставщик рабочих мест и т. д.

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

Если раньше сопровождение и поддержку часто считали синонимами, то теперь это не так. Поддержка сервисов в облачную эру делится на две взаимосвязанные части:

поддержка пользователей;
эксплуатация сервиса.

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

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

Способы улучшения показателей использования уже принятого на сопровождение сервиса:

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

Остановимся на изменении роли соглашения об уровне обслуживания (Service Level Agreement, SLA) как основе, определяющей эксплуатацию сервисов в облачную эру (теперь это не одно соглашение между поставщиком сервиса и потребителем, а несколько).

В эпоху облаков ИТ-сервис оказывается в ведении разных поставщиков как горизонтально (на одном архитектурном уровне), так и вертикально (поставщики поставляют компонент ИТ-сервиса поставщикам более высокого архитектурного уровня), поэтому их взаимодействие должно быть регламентировано. Проще всего это сделать в модели SLA, которая должна будет существенно усложниться. На рис. 3 приведено распределение ответственности поставщиков для различных типов облаков, а в таблице даны типы ролей, которые участвуют в эксплуатации сервиса.

Рисунок 3 – Распределение ответственности по поддержке уровней облаков

Для вертикальной интеграции условия SLA между нижележащими уровнями должны быть строже, чем SLA между вышележащими. Например, если между поставщиком SaaS и потребителем восстановление после сбоя предусмотрено в течение двух часов, то в SLA на восстановление между поставщиком SaaS и поставщиком PaaS дол-жен быть указан параметр меньше этого срока, так как надо вычесть время, за которое удастся обработать и классифицировать сбой как инцидент PaaS. Аналогично — между поставщиком PaaS и IaaS.

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

Список литературы

1. И.П.Клементьев, В.А.Устинов. Введение в облачные вычисления. М., 2009. С. 135-148.
2. Питер Фингар. Облачные вычисления – бизнес-платформа XXI века. М. 2011. С. 45-64.
3. Журнал Открытые системы №10, 2012. С. 5-17.
4. К.А.Гребнев. Облачные сервисы: взгляд из России. М. 2011. С.15-56.