SLAженная работа в облаках: эксперты об особенностях соглашений в облачных проектах

Каждый, кто хоть раз участвовал во внедрении ИТ или телекоммуникационных проектов, наверняка сталкивался с понятием SLA — Service Level Agreement. Это формальное соглашение между заказчиком и поставщиком, в котором содержится подробное описание предоставляемой услуги или проекта, права и обязанности каждой стороны и, как следует из самой аббревиатуры, уровня качества сервиса.

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

Между тем SLA — это прекрасный способ ещё «на берегу» определиться с большинством вопросов по внедрению инфраструктуры. Этот стандарт был создан в рамках ITIL (библиотека инфраструктуры информационных технологий), которая описывает лучшие практики в организации работы департаментов или компаний, занимающихся организацией и предоставлением услуг в отрасли информационных технологий. А сегодня SLA стало документом, который неизменно подписывают заказчики и аутсорсеры по всему миру. И в облачных технологиях такой документ имеет свои особенности.

«Даже SLA для различных облачных услуг (IaaS, SaaS, PaaS) сильно различаются, так как у каждой модели своя структура сервиса. Сравнивая же облачное SLA с аналогичным Соглашением для colocation, мы обнаружим следующее: для облаков первоочередное значение приобретает производительность системы (такие параметры, как IOPS и latency для дисковой подсистемы, задержки и процент потерь пакетов для каналов связи, MIPS для процессорного ресурса и пр.), в то время как для colocation на первом плане параметры доступности сервиса. В этой связи в SLA на облачные услуги особенно важно четко прописать инструменты контроля и мониторинга этих показателей (клиент сам не контролирует платформу виртуализации, получая услугу более высокого уровня), а также процедуры и скорость реакции на запросы клиентов» (директор по развитию бизнеса компании DataLine Григорий Атрепьев).

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

Что же должно содержать такое соглашение применительно к облачным технологиям? Какие этапы сотрудничества и какие требования к сервису должно предъявлять SLA? Для того чтобы понять, как выглядит облачное SLA, мы обратились к экспертам из компании DataLine, которая занимается ИТ-аутсорсингом и предоставляет облачные услуги на основе собственной сети ЦОДов. По мнению Григория Атрепьева, директора по развитию бизнеса компании DataLine, разработка SLA для ИТ-проектов в области облачных технологий состоит из следующих этапов.

1. Обсуждение задач и архитектуры информационной системы, которая будет развернута на облачных мощностях, оценка количества её пользователей.
2. Фиксация необходимых параметров доступности и производительности.
3. Подготовка провайдером технологического решения, которое удовлетворяет этим параметрам, и оценка его стоимости.
4. Фиксация средств мониторинга, с помощью которых будет контролироваться соблюдение параметров, указанных в SLA. Важно, чтобы доступ в систему мониторинга был как у провайдера услуг, так и у клиента.
5. Согласование заказчиком финансовой составляющей (штрафные санкции).
6. Корректировка параметров SLA при необходимости после запуска проекта. 

Таким образом, SLA оказывается своеобразным спасательным кругом, точкой отсчёта в этом нестабильном и чрезмерно динамичном мире. Причём Соглашение – это не просто документ, обеспечивающий выполнение поставщиком своих обязательств. Это двусторонний акт, который определяет действия и обязанности обоих участников договора, что и делает его столь необходимым для как для поставщика, так и для заказчика. А проблемы, как вы понимаете, могут возникнуть у кого угодно и где угодно. Как потребители или поставщики облачных решений мы участвуем в системе, которая опирается на десятки столпов, каждый из которых может как улучшить, так и ухудшить ситуацию. Проблемы могут прийти со стороны сетей, безопасности, вычислительной мощности, хранилища, баз данных. С любого другого фронта, включая законодательный. И в SLA все это должно быть описано, а особенно важно прописать действия обеих сторон в случае неполадок. Полагаясь на многолетний опыт работы с самыми разными заказчиками, Григорий Атрепьев из DataLine считает, что SLA должно содержать как минимум следующие пункты: 

• данные о времени доступности услуг;
• метрики производительности. Здесь указываются параметры IOPS, MIPS для vCPU, среднее время доступа к дискам на виртуальной машине, средний процент потерянных пакетов и сетевая задержка;
• порядок устранения инцидентов. В этом пункте устанавливается приоритет инцидентов, фиксируется время реакции провайдера на проблему и её решение, а также прописываются штрафные санкции за несвоевременное устранение сбоев. 
• проведение регламентных работ. В Соглашении важно закрепить периодичность и порядок проведения плановых технологических работ;
• типовые запросы. Этот пункт содержит перечень типовых запросов с их классификацией по приоритетности. 

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

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

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