Как управлять облаками

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

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

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

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

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

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

Особенности облаков как средства эксплуатации

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

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

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

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

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

Новые принципы сопровождения и поддержки

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

Поддержка пользователей

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

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

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

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

Эксплуатация сервиса

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

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

Рис. 1. Распределение ответственности за поддержку архитектурных уровней облаков

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

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

Роль аутсорсинга

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

Рис. 2. Роль аутсорсинга в облаках

***

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

Марина Аншина (anshina@mail.ru) — председатель Комитета по стандартам, Российский союз ИТ-директоров (Москва).