Соглашение об уровне предоставления услуги (англ. ServiceLevelAgreement(SLA)) — термин методологии ITIL, обозначающий формальный договор между заказчиком (в рекомендациях ITIL заказчик и потребитель — разные понятия) услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.
Определение
SLA используется внутри организации для регулирования взаимоотношений между подразделениями, а также является основным инструментом непрерывной оценки и управления качеством предоставления услуг аутсорсинга специализированной организацией — аутсорсером.
Как правило термин SLA используется применительно к ИТ и телекоммуникационным услугам. В таком соглашении может содержаться детальное описание предоставляемого сервиса, в том числе перечень параметров качества, методов и средств их контроля, времени отклика поставщика на запрос от потребителя, а также штрафные санкции за нарушение этого соглашения. Для того, чтобы соблюсти SLA, поставщик услуг в свою очередь заключает операционное соглашение об уровне услуг (OLA, operational-level agreement) с другими внутренними подразделениями, от которых зависит качество предоставления услуг.
В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное обеспечение для максимизации способности удовлетворять SLA.
Контрольные параметры соглашения
Параметры качества услуги, указанные в SLA, должны быть измеримыми, то есть представимыми в виде числовых метрик. Например, для услуги доступа в Интернет это может быть максимальное время недоступности, максимальное суммарное время недоступности за период (например, за месяц). Скорость доступа при этом является плохим параметром, поскольку зависит не только от оператора, но и от других операторов, от загруженности сервера сайта и т. п., на что, как правило, поставщик повлиять не может.
Часто в SLA определяется период, за который поставщик услуги предоставляет заказчику отчёт об измеренных параметрах качества.
Типовая структура SLA
Различные примеры соглашений SLA приведены в описаниях стандартов ITIL и COBIT, где также даны развернутые рекомендации по оценке ключевых показателей эффективности (KPI) при анализе работы с SLA.
Типовая модель SLA должна включать следующие разделы:
1. Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.
2. Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизации.
3. Число и размещение пользователей и/или оборудования, использующих данный сервис.
4. Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень. Должно быть включено время подготовки отчета.
5. Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.
6. Спецификации целевых уровней качества сервиса, включая:
- Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса
- Минимальная доступность для каждого пользователя
- Среднее время отклика сервиса
- Максимальное время отклика для каждого пользователя
- Средняя пропускная способность
- Описания расчёта приведённых выше метрик и частоты отчётов
7. Описание платежей, связанных с сервисом. Возможно как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.
8. Ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой изменения).
9. Процедура разрешения рассогласований, связанных с предоставлением сервиса.
10. Процесс улучшения SLA. [1]
Какой уровень сервиса нужен клиенту?
В теории все выглядит привлекательно, но на практике и заказчики, и поставщики услуг сталкиваются с незримым барьером недопонимания — сказывается дисбаланс между потребностями в уровне сервиса и предложением сервисных подрядчиков. Первые ищут идеальный сервис: недорогой, со 100 %-ными гарантиями и полным возмещением убытков, вторые же пытаются минимизировать ответственность при невыполнении обязательств. Попытаемся понять, почему трудно найти компромисс, и предложить выход из создавшегося положения.
Каждый заказчик хочет получить идеальную услугу, обязательно обладающую следующими возможностями:
- обеспечение работоспособности систем ЦОДа в круглосуточном, круглогодичном режиме с минимальным временем простоя;
- минимальная стоимость (желательно бесплатно);
- привлечение максимально квалифицированных кадров;
- минимальное время реакции исполнителя при аварийных ситуациях и мгновенное устранение их последствий, а лучше — круглосуточное нахождение специалистов сервисной компании по всем обслуживаемым системам на объекте;
- полная компенсация ущерба от простоя ЦОДа, включая репутационный и моральный ущерб — по возможности, на основании договора, без обращения в суд;
- 100 %-ная гарантия наличия на складе исполнителя любого возможного ЗИПа, который может потребоваться в ходе эксплуатации ЦОДа, а также включенная в цену контракта замена и ремонт любого оборудования.
Вероятно, такой перечень выглядит смешно, тем не менее подобный список требований формирует подавляющее большинство заказчиков на начальных этапах заключения сервисного договора.
Для того чтобы сделать этот список более реалистичным и сбалансированным с точки зрения обоснованности тех или иных включенных в него параметров, разберемся, каковы способы организации аутсорсинга эксплуатации ЦОДа.
Прежде всего: нужно ли выносить на аутсорсинг все инженерные системы, либо стоит ограничиться лишь их частью?
Никто не будет спорить, что обслуживать тем или иным способом необходимо весь комплекс инженерных систем ЦОДа. Передача на аутсорсинг — скорее вопрос экономической целесообразности. Например, в большом ЦОДе, где сервисный инженер задействован не менее чем на 80 % рабочего времени, передача обслуживания на аутсорсинг может оказаться бессмысленной. В небольшом же — почти все обслуживание выгоднее отдать под ответственность внешней сервисной организации.
Разумное снижение издержек — первостепенная задача любого бизнеса и, на наш взгляд, некоторые «второстепенные» инженерные системы ЦОДа (такие, как система видеонаблюдения или система охранной сигнализации) не требуют заключения полноценного дорогостоящего аутсорсингового контракта с высокой скоростью реакции на инциденты. Достаточно лишь периодического технического обслуживания. В то же время жизненно важные для функционирования ЦОДа системы, например кондиционирования и энергоснабжения, должны обслуживаться ежедневно, еженедельно и ежемесячно.
Как и автомобиль, инженерные системы ЦОДа необходимо обслуживать в несколько этапов (по аналогии с ТО-1, ТО-2 и т. д.). Ежедневные проверки уровня масла и давления шин автомобиля подобны ежедневным осмотрам и контролю параметров оборудования ЦОДа. И дата-центру, и автомобилю необходимы и более редкие, но периодичные, процедуры технического обслуживания систем и модернизация, и это существенно более сложные процедуры, требующие специализированных навыков. Также в полный цикл эксплуатации должно входить и устранение аварийных ситуаций; а если ЦОД обслуживается аутсорсинговой компанией, то и ликвидация аварий должна быть непременно включена в сервисный договор.
Таким образом, можно выделить четыре вида услуг эксплуатации:
1. Текущая эксплуатация (выполнение ежедневных процедур по контролю параметров оборудования систем дата-центра).
2. Техническое обслуживание (мероприятия профилактического характера, проводимые систематически, принудительно через установленные периоды, включающие определенный комплекс работ для поддержания необходимого уровня технического состояния оборудования).
3. Плановый ремонт (все виды) и модернизация систем для адаптации к новым условиям и требованиям целевой нагрузки.
4. Реакция на аварийные ситуации, ремонтно-восстановительные работы после аварий.
Попытаемся определить применимость основных (на наш взгляд) параметров сервисного обслуживания к выделенным нами видам услуг эксплуатации (табл. 1).
Таблица 1
Обязательные параметры SLAи их применимость к различным видам услуг эксплуатации
Какой уровень сервиса предлагает рынок?
В настоящее время услуги аутсорсинга эксплуатации ЦОДов на российском рынке предоставляют несколько типов компаний.
Компании — производители инженерного оборудования, имеющие собственные сервисные подразделения. Их преимущество в том, что зачастую они имеют возможность содержать обширный склад ЗИПа. Кроме того, специалисты по обслуживанию конкретной марки оборудования проходят регулярное обучение в специализированных лабораториях при заводах-производителях, что дает им преимущество перед специалистами, такого обучения не проходящими. Они имеют узкую специализацию и сталкиваются с множеством проблем в рамках конкретной марки у разных заказчиков, что позволяет им накопить внушительный опыт эксплуатации и ремонта данного оборудования. Из минусов можно отметить то, что не каждый производитель имеет в своем портфеле всю линейку инженерного оборудования ЦОДа (кондиционирование, ДГУ, ИБП и т. д.). Дата-центры не всегда строятся на основе решений одного бренда, и поэтому такие компании не смогут собственными силами эксплуатировать все системы не монобрендового дата-центра. Помимо этого, часто компании-производители не акцентируют внимание на ЦОДе как на комплексе инженерных систем и готовы нести ответственность за работоспособность конкретных подсистем, но не за дата-центр в целом.
Компании-интеграторы, имеющие инженерные и сервисные подразделения, инжиниринговые компании. Плюсами подобных исполнителей являются комплексный системный подход к эксплуатации инженерных систем дата-центра, богатый опыт строительства ЦОДов разной архитектуры с применением оборудования множества вендоров. Важным подспорьем при построении модели эксплуатационных процессов может послужить опыт внедрения и интеграции ИТ-решений; инженеры компаний-интеграторов могут знать многие марки и модели оборудования. Минусами интеграторов зачастую являются не столь глубокие, нежели у компаний-производителей, знания конкретных моделей оборудования.
Операторы дата-центров (иногда они же — компании-интеграторы), которые имеют собственный обслуживающий персонал. Такие компании эксплуатируют собственные дата-центры, но в силу неполной загрузки персонала имеют возможность предоставлять аутсорсинговые услуги сторонним организациям. Сотрудники таких сервисных компаний могут обладать наиболее полезными практическими знаниями в области обслуживания дата-центров, но в случае небольшого числа объектов на эксплуатации уступают специалистам компаний двух первых типов в опыте использования разнообразных технических решений.
Все три типа сервисных компаний имеют свои преимущества и недостатки, поэтому представляется правильным построение таких моделей внешнего сервисного обслуживания, которые бы объединяли преимущества всех трех типов; это позволит получить интересный синергический эффект при эксплуатации дата-центров.
Два способа составления SLA
Традиционно на российском рынке существуют два способа составления соглашения об уровне обслуживания.
В первом случае заказчик, имеющий опыт в составлении подобных документов, транслирует его поставщикам «сверху» в виде технического задания либо требования конкурсной документации, либо RFP (Request For Proposal — запрос предложения). При таком сценарии чаще всего в SLA содержатся максимально жесткие требования к срокам, качеству услуг и ответственности поставщика — сервисной компании. Во втором случае, если заказчик не слишком искушен и соглашение разрабатывает (предлагает) поставщик услуг, ситуация обратная: требования к штрафным санкциям и ответственности могут быть вовсе «позабыты», а сроки реакции — максимально комфортны, в зависимости от имеющихся у поставщика человеческих ресурсов. К сожалению стандартов SLA, даже неофициальных, в России еще не существует, поэтому и вариантов предложений может быть великое множество.
После получения второй стороной SLA вырабатывается компромисс между ценой контракта и уровнем оказываемой услуги. По всем пунктам поставщик может удовлетворить потребности заказчика, скорректировав цену контракта, но вероятнее всего, в силу отсутствия института страхования подобных рисков, он никогда не пойдет на покрытие всех убытков заказчика в рамках штрафных санкций.
Дополнительно к стандартным параметрам (сроки, деньги, штрафы, качество услуги) по желанию заказчика могут быть добавлены такие опции, как систематическое обучение персонала, периодический аудит инфраструктуры с выработкой мер по оптимизации, выделенная дежурная смена и пр. (табл. 2). Все они, увеличивая стоимость контракта, повышают и уровень надежности функционирования ЦОДа.
Таблица 2
Необязательные параметры SLAи их применимость к различным видам услуг эксплуатации
Разрыв между идеалом и реальностью
Итак, существует три подхода к формированию соглашения об уровне услуг: первый (табл. 1, 2) представляется нам наиболее взвешенным, второй формируется продвинутым заказчиком, отстаивающим свои метрики и состав соглашений, и третий — тот, который сервисные компании в состоянии предоставить на российском рынке.
Между тремя этими подходами существует разрыв, но не пропасть. Мы попробовали проанализировать основные причины несоответствия запросов заказчиков и предложений исполнителей (табл. 3).
Таблица 3
Отдельные параметры SLAи причины расхождения запросов и предложений по ним
Поиск золотой середины: несколько простых советов
Запросы идеального уровня услуг никогда не получат адекватного ответа рынка. Необходимо искать золотую середину между ценой сервисного контракта и уровнем SLA. При этом необходимо понимать, что наибольшее влияние на цену оказывает время реакции и уровень штрафных санкций. Причем такая связь может быть подчинена далеко не только линейной зависимости.
Например, чтобы иметь возможность снизить скорость прибытия аварийной бригады на объект с восьми до четырех часов (в два раза!) поставщику может потребоваться набрать в свой штат еще несколько дополнительных специалистов для организации посменной работы. А поскольку подобные сервисы в России еще не широко востребованы, не многие поставщики позволяют себе иметь готовые круглосуточные аварийные бригады в достаточном количестве. Подобные изменения могут существенно повлиять на стоимость контракта, так как потребуют кастомизированных усилий со стороны поставщика.
Схожая ситуация может сложиться и с непреодолимым желанием ряда заказчиков иметь гарантированный ЗИП на складе поставщика: на стоимости контракта негативно скажется и это.
При выборе того или иного уровня SLA заказчику необходимо точно подсчитать и проанализировать убытки от каждого часа простоя ЦОДа и стоимость контракта при каждом уровне SLA, соответствующем максимальным усилиям поставщика услуг по предотвращению такого простоя. Если остановка работы дата-центра, например, в течение восьми часов ночью и в выходные никак не отразится на работе вашего бизнеса, то, скорее всего, отказавшись от обслуживания по схеме «24Ч7», вы сможете существенно снизить стоимость внешних сервисных услуг. Но если каждый час простоя приносит вам, например, $100 тыс. убытка, то дополнительные расходы в объеме, скажем, $50 тыс. в год, позволяющие снизить время реакции с четырех до двух часов, вероятно, будут оправданы. [2]
Литература:
1. https://ru.wikipedia.org/wiki/ %D0 %A1 %D0 %BE %D0 %B3 %D0 %BB %D0 %B0 %D1 %88 %D0 %B5 %D0 %BD %D0 %B8 %D0 %B5_ %D0 %BE %D0 %B1_ %D1 %83 %D1 %80 %D0 %BE %D0 %B2 %D0 %BD %D0 %B5_ %D1 %83 %D1 %81 %D0 %BB %D1 %83 %D0 %B3
2. http://www.iksmedia.ru/articles/5144206-SLA-kamen-pretknoveniya-pri-autsors.html
