Пункты переговоров с облачным провайдером

До подписания SaaS-контракта компаниям надо продумать план возврата данных, соглашения об уровне сервиса и стратегию расторжения договора.

При обсуждении условий контракта на использование ПО в форме сервиса (SaaS) стоит заранее подумать о его возможном расторжении. И вот почему. К 2013 г. 20% пользователей SaaS перейдут на собственное ПО, развертываемое внутри организации. А к 2014 г. половина пользователей SaaS убедится в том, что их затраты превышают ожидания.

Интересно отметить, что с взрослением SaaS этот вид сервиса все более усложняется. Вот несколько предконтрактных советов.

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

В ходе переговоров следует уделить ключевое внимание ценовой защите, которая бы ограничивала рост тарифов при продлении договора и давала компании право на уменьшение выплат при падении цен. В соглашениях о качестве сервиса важно оговорить весомые штрафы и возможность прекращения действия контракта при аварийных простоях или систематических неполадках. Желательно, чтобы компания также могла регулировать свой уровень использования ресурсов при спаде деловой активности.Как с помощью EvaProject и EvaWiki построить прозрачную бесшовную среду для успешной работы крупного холдинга 2.4 т

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

В части отказов сервиса SaaS-провайдеры обычно считают форс-мажорными обстоятельствами простои по вине поставщиков и перебои в работе Bнтернета. Заказчикам надо внимательно вчитываться в юридические формулировки контракта, чтобы простои по вине SaaS-провайдеров не сходили им с рук легко.

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

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

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

Основные практические сложности при миграции в Облако

• Трудно разобраться в SLA и учесть риски при переносе сервиса
• Разобраться с функциональностью сервисов и порталом
• Оценка затрат на сервисы и ресурсы в облаке
• Новые угрозы безопасности, знакомство с IAM
• Частые изменения в облачных сервисах и адаптация к этим изменениям
• Управление данными, дополнительные усилия по изменению их архитектуры из-за регуляторов
• Организация гибридной модели на практике, разный технологический стек, сложная сетевая топология затрудняют бесшовную интеграцию.

Убедитесь, что условия соглашения являются предметом переговоров

Хотя согласование условий соглашения в ходе переговоров может показаться само собой разумеющимся, многие облачные провайдеры, включая Google, Microsoft и Amazon, обычно не позволяют вносить изменения в свой вариант соглашения, аргументируя это тем, что особые условия для различных клиентов подрывают модель предоставления коллективного доступа и позиционирование провайдеров на рынке. Это не означает, будто предприятиям не следует пользоваться сервисами на стандартных условиях. Но необходимо сознавать связанные с этим риски.

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

Убедитесь, что структура цен не лишает облако его преимуществ

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

Разработайте соглашение об уровне обслуживания с учетом имеющегося опыта

Соглашения об уровне обслуживания (SLA), как и в случае с любым ИТ-сервисом, должны отражать полный спектр услуг. Например, поскольку облачный провайдер будет отвечать за подключение к Интернету и инфраструктуру, доступность сервисов не должна определяться посредством мониторинга сервера в ЦОДе. В соглашении могут оговариваться определенный пользовательский интерфейс и производительность запросов, своевременность выполнения важнейших пакетов задач и время реагирования/устранения в случае сбоя.

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

Учитывайте влияние коллективной платформы на работу компании

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

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

Обратите внимание на переход в облако и выход из него

Развертывание в облаке и истечение срока либо прекращение аренды также требуют внимательного отношения. Что касается перехода в облако, то вам следует убедиться, что действия провайдера четко определены, и договориться о SLA при установке и конфигурировании приложения, а также при загрузке данных. Если предоставляются дополнительные профессиональные услуги по развертыванию, следует добиться, чтобы по умолчанию они были привязаны к ключевым облачным сервисам. При отказе от использования облака провайдер должен помочь в организации миграции, включая экспорт данных и их схемы в согласованном формате. Следует подумать также о требовании периодического архивирования данных, чтобы смягчить текущие или связанные с особенностями контракта трудности на пути их упорядоченного переноса. Каким бы хорошим ни было соглашение с провайдером, ожидать от него чего-то большего вашему предприятию не приходится. Лучшей защитой является проверенная возможность легкого перехода к другому провайдеру и на другое решение. Руководителям ИТ-подразделений следует помнить, что отсутствие уверенности в благополучном переходе к другому провайдеру сильно ослабляет позиции предприятия на переговорах и сужает спектр имеющихся у него вариантов.

Важнейшая статья соглашения - об условиях его прекращения. Тем не менее она часто не получает должного внимания. Нет ничего вечного под Луной, поэтому важно проработать до мелочей все вопросы расставания. По умолчанию вам, скорее всего, предложат 30-дневный срок для выхода из договора. При этом за такой срок найти альтернативу и произвести миграцию данных бывает невозможно. Мы видели, что хорошие провайдеры предлагают 60 или даже 90 дней. Необходимо понимать, что при гарантированном снижении доходов из-за прекращения коммерческих отношений с вами провайдер будет не очень мотивирован вам помогать. Были случаи, когда клиенты сталкивались с трудностями при получении своих данных обратно. Иногда провайдеры отказываются обеспечивать безопасность и резервирование данных спустя 30 дней после прекращения соглашения. Поэтому важность проработки этой статьи соглашения нельзя переоценить. Постарайтесь добиться для себя шестимесячного срока уведомления провайдера о прекращении соглашения со своей стороны и документированного процесса удаления данных со стороны провайдера.

Пункт о географическом размещении данных/приложений и регламентации доступа

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

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

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

Gartner рекомендует включать в соглашение пункт об ограничении доступа к некоторым классам данных только ISO-сертифицированным персоналом облачного провайдера, исключив третьих лиц. К таким классам обычно относятся: персональные данные, включая финансовую и налоговую информацию, таблицы, структуры таблиц, файлы, а также любые данные, которые классифицированы или отмечены как служебная или коммерческая информация.

Безопасность данных

Контракты облачных провайдеров содержат либо довольно туманные описания условий обеспечения безопасности данных, например, «в соответствии с отраслевыми стандартами», либо явный отказ от своей ответственности, что переносит всю полноту ответственности за обеспечение безопасности, резервное копирование и восстановление данных на клиента. Важно не только тщательно проработать уровень обслуживания по данной статье соглашения, но и потребовать обязательной ежегодной сертификации, например, со стороны ISO/International Electrotechnical Commission (IEC) 27001 certifications, Payment Card Industry (PCI) DSS certifications, SSAE16, SOC или уже нарождающихся облачных стандартов безопасности: Cloud Security Alliance (CSA), Shared Assessments Program, FedRAMP.

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

Персональные данные

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

О чем облачный провайдер может умолчать

Вот основные моменты, на которые клиенту стоит обратить внимание при выборе провайдера облачных услуг и которые непременно нужно выяснить перед началом работы.

Информация об оборудовании

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

О чем облачный провайдер может не рассказать своему Клиенту:

Во-первых, о модели оборудования. Чем старше модель оборудования, тем более вероятно снижение производительности и надежности облака. Обязательно заострите внимание на том, какую модель оборудования использует провайдер. Использование современных моделей оборудования снижает ваши риски.

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

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

В-четвертых, о бесперебойной работе оборудования. Сбои случаются с любым, даже самым надежным оборудованием. Главное здесь - своевременное осуществление дублирования и резервирования данных, а также отсутствие единой точки отказа. Убедитесь, что сервера провайдера имеют задублированные блоки питания и охлаждения, и обладают достаточным запасом мощности, для того чтобы справиться с неожиданными скачками потребления вычислительных ресурсов. Не менее важным аспектом является организация системы хранения данных: задублирована она или располагает двумя независимыми контроллерами. Все сетевое оборудование должно быть задублировано, а сбой в работе какого-либо элемента системы не должен отражаться на работе оборудования в целом.

Производительность дисковой подсистемы

Параметры облачных ресурсов включают в себя вычислительные мощности процессора (GHz), оперативную память (Gb) и дисковое пространство (Gb). Для клиента крайне важны эти параметры, к их выбору необходимо подходить особенно тщательно. Всегда нужно помнить, что на работу приложения влияют не только объём выделенного дискового пространства, но и сама производительно дисковой системы.

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

Таким образом, единственный правильный критерий оценки производительности дискового пространства – это количество операций чтения-записи в секунду (IOPs) и уровень задержек при обращении к дискам (Latency, мс).

Обязательно уточните, предоставляет ли облачный провайдер возможность управлять IOPs‑ами и может ли он предоставить информацию о дисковых массивах его инфраструктуры. Когда облачный провайдер обещает гарантированные показатели производительности, проблема выбора клиентом типа дисков неактуальна.

Площадка и ее безопасность

Надежность и безопасность площадки, где размещается облачная платформа – это один из самых важных факторов при выборе облачного провайдера. Даже если провайдер согласился продемонстрировать будущему клиенту свою площадку, это не гарантирует ее надежность, а заявления о том, что оборудование соответствует стандарту по категории надежности Tier III, на деле могут оказаться только словами. Нередко провайдеры вводят клиентов в заблуждение, надеясь на то, что тот откажется от проведения фактической демонстрации из-за нежелания терять время или из-за недостатка соответствующих инженерных знаний.

Чтобы избежать подобных недоразумений, для клиента будет проще и надежнее запросить у провайдера сертификаты международной организации Uptime Institute:

• Tier III Certification of Constructed Facility;
• Tier III Certification of Design Documents.

Если облачный провайдер располагает сертифицированной инфраструктурой, клиент может быть уверен в качестве и надежности предлагаемой ему площадки.

Поддержка и обслуживание

Решив развернуть собственную инфраструктуру в облаке, клиент должен быть уверен, что поддержка и обслуживание этой инфраструктуры будет проводиться на самом высоком уровне. Главное при этом – выяснить, как именно у облачного провайдера организованы процессы сопровождения и поддержки облака.

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

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

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

• Доступность по всем каналам в режиме 24/7.
• Обращение к провайдеру через несколько каналов: электронная почта, сайт, чат, телефон, скайп.
• Четко фиксированное время реакции на обращение, время решения типовых запросов, время решения инцидента.
• Информирование о проведении регламентных работ, об инцидентах и их решении;
• Активная помощь врешении проблем, выходящих за рамки договора и формального описания услуги.

Вид деятельности компании провайдера

Компании, предлагающие облачные услуги на российском рынке, как правило, занимаются следующими видами деятельности: Облачные провайдеры. Компании, которые занимаются исключительно предоставлением облачных сервисов. Обычно такие компании располагают собственным оборудованием, которое размещается в арендованных дата-центрах.

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

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

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

Как правило, если клиенту необходим минимальный перечень услуг в облаках, операторы связи самостоятельно могут закрыть эту потребность. Если же речь идет о сложном комплексе проработанных услуг, то лучшим выбором станет компания, у которой облачный сервис является основным профилем. Облачные провайдеры в данном случае более техничны и лучше организованы. К тому же они легко могут варьировать с корректировкой цены услуг для каждого клиента.

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

SLA

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

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

• По материалам PCWEEK и Club.CNews.ru