28 июля 2011 г.

Хотите использовать облако? 7 вещей, о которых нельзя забывать

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

CRN обратился к руководителям VAR-компании Progress Software, чтобы получить знание «из первых рук». Мэтт Чиччари, менеджер по маркетингу OpenEdge/SaaS-платформ и внедрению облака, и Майк Ормерод, архитектор облачных и SaaS-решений, поделились своим опытом: какие главные элементы должны присутствовать в «брачном» договоре с вендором облака, чтобы потенциальный клиент мог смело сказать «да».

Сначала уясните суть облака
Руководители Progress Software предупреждают, что решение о внедрении облака может завязнуть в терминах, акронимах и обозначениях. Важно, чтобы потенциальный заказчик выполнил «домашнюю работу» и освоился с терминами, которыми оперируют вендоры, прежде чем вступать на путь переговоров.
«Не следует сразу кидаться в новое дело, если вы не понимаете какие-то термины и технологии», - говорит Чиччари.
«Прежде всего, нужно понимать, во что вы вступаете», - вторит ему Ормерод.

Знайте все детали SLA
Недавняя череда облачных отказов чему-то нас научила. Необходимо четкое соглашение об уровне обслуживания (SLA), которое поможет этому союзу был долгим и счастливым.
Руководители Progress Software рекомендуют покупателям облачных сервисов внимательно изучить все условия SLA, чтобы знать, кто за что отвечает в разных обстоятельствах. Важно убедиться, что критически важные приложения не будут потом меняться; подписанное SLA защищает не только вашу репутацию, но и имя вендора.
«Текст и формулировки SLA - это всё», - говорит Ормерод.
«Как во всяком договоре, вы должны иметь абсолютную ясность, кто что делает, когда и как», - добавляет Чиччари.

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

Имейте план аварийного восстановления
Союз двоих - это постоянный труд, и что-то может пойти не так. Важно планировать свои действия на случай неожиданных проблем. Progress Software готова к этому. Прежде чем окунуться в облако, нужно иметь готовый план восстановления после отказов и воссоздания рабочей среды. Высокий уровень готовности - это работа вендора облака, но преодоление отказов - нет, предупреждает Чиччари.
«Есть такое заблуждение: я отправляю все свои приложения в облако - и никаких забот», - вторит ему Ормерод.

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

Многоплатформная облачность
Это может выглядеть как «неверность», но любой «облачный» договор вендора должен содержать пункт о поддержке различных типов облака с возможностью использовать другие платформы. Следует спрашивать вендоров, обеспечивают ли они поддержку общедоступного, частного облака и гибридной модели, говорит Чиччари. Чтобы отношения были долгими, заказчик должен иметь возможность использовать нескольких вендоров облака одновременно для одного и того же приложения, системы или среды.
«Зачем ограничивать себя лишь одним облаком? - говорит он. - А если что-то случится у Amazon, GoGrid или Rackspace?»
Заказчики должны задаться вопросом: «Насколько легко мне будет перенести свои приложения от одного вендора к другому?» - добавляет Ормерод.

Нужна стратегия выхода
И, наконец, что делать, если отношения не сложились, и обе стороны вынуждены расстаться? Когда медовый месяц прошел, пользователи должны знать, что делать, говорит Чиччари. Что делать, если возникла проблема, как восстановить данные и вновь запустить облачное приложение? А если заказчик просто передумал и больше не хочет использовать облако? Если изменился профиль бизнеса или рынок, и нужно менять стратегию? Договор облачного обслуживания должен предусматривать стратегию выхода, чтобы и вендор, и заказчик могли полюбовно расстаться, избежав неприятных разборок.

Источник: По матералам crn.com