Строили и построили, или Как избежать ошибок при проектировании облака

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

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

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

Тезис № 2: облако – это виртуализация и еще чуть-чуть

Если облако является только ИТ-проектом, ИТ-команда решает поставленную задачу классическим способом, а именно при помощи внедрения новых технологий. Как правило, команда понимает необходимость виртуализованной ИТ-инфраструктуры и наличия средств автоматизации как основы для облачного решения. На текущий момент в России уровень зрелости ИТ-инфраструктур таков, что лишь у немногих заказчиков можно встретить единый виртуализованный уровень систем хранения данных или сети. В связи с этим в рамках облачного проекта большее внимание уделяется именно построению программно-определяемых СХД (Software-Defined Storage, SDS) и сети (Software-Defined Network, SDN). Как показывает практика, большая часть усилий ИТ-команды уходит на модернизацию именно этих составляющих ИТ-ландшафта. После ее успешного завершения добавляются средства автоматизации и, возможно, мониторинга, проект по построению облака заканчивается, и результаты демонстрируется бизнесу.

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

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

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

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

Тезис № 3: облако – лекарство от всех бед для бизнеса

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

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

Тезис № 4: облако – это просто набор новых технологий

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

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

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

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