05.11.2020
ITBreeze LLC

Как составить оптимальный SLA-контракт для обслуживания ЦОДа

Любой сервисный процесс должен вестись по определенным правилам и с определенным уровнем качества. В случае если услуги, которые внешняя компания оказывает заказчику, не соответствуют данному уровню, – это приводит к существенному ухудшению надежности всей структуры эксплуатации. Как этот уровень определить и контролировать? Для этого существует SLA, или Соглашение об уровне сервиса (Service Level Agreement). 

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

В каждой отрасли список метрик и критерии оценки будут свои. Мы поговорим о том, как составить хороший SLA, применительно к обслуживанию инженерной инфраструктуры ЦОДа.

Зачем нужен SLA?

Начнем с того, что обозначим укрупненные типы ЦОДов по их функциональному назначению.

  • Коммерческие — построенные для того, чтобы продавать заказчикам услуги дата-центра: размещение стоек, предоставление в аренду серверов, виртуальных машин и т.д. Здесь ЦОД — это основной бизнес оператора, клиентами которого являются внешние компании.
  • Корпоративные — дата-центры банков, телеком-операторов и т.п. Такой ЦОД обслуживает нужды крупной компании, которой требуются большие вычислительные мощности. 
  • Смешанные — ЦОД построен под нужды компании, а избыточные мощности сдаются в аренду сторонним организациям или собственным клиентам. 

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

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

Что включает SLA: основные метрики для ЦОД

К инженерной инфраструктуре ЦОДа относится прежде всего оборудование, обеспечивающее электропитание — ИБП, щиты, дизельные установки; охлаждение — кондиционеры, чиллеры, гидромодули и прочее; системы безопасности и контроля доступа – СКУД, пожаротушение; системы мониторинга и диспетчеризации. 

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

Какие услуги предоставляют сервисные компании? Как правило, в “джентльменский набор” входит:

  • техподдержка в различных форматах: телефонная, с выездом специалиста, видеосвязь в режиме 7/24 или 5/8 и т.д.;
  • техобслуживание оборудования по регламентам, предписанным производителями;
  • аварийно-восстановительные работы в случае выхода оборудования из строя;
  • обеспечение складом, когда подрядчик обязуется при необходимости поставить компоненты для неисправного оборудования в определенные сроки.

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

  1. Время реакции на инцидент. 

Отсчет может вестись по-разному: от момента приема звонка, или получения электронного обращения и отправки сообщения о принятии заявки, или возникновения аварийного сигнала в системе мониторинга (если подрядчик имеет к ней доступ).

  1. Время прибытия на объект. 

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

  1. Более весомый параметр — время восстановления работоспособности. 

Важно учитывать, что здесь возможны варианты: 

  1. время восстановления работоспособности, под которым подразумеваются любые экстренные меры, “заплатки” и “костыли”, которые позволяют временно запустить систему до полноценного ремонта;
  2. время восстановления до исходного состояния. Очевидно, что на эту метрику должно быть отведено больше времени.

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

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

Как выбрать SLA

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

  • Баланс требований

Как строится работа над SLA? Необходимо сопоставить обязательства ЦОДа перед клиентами и его возможности. Если произойдет авария в той или иной системе — как это скажется на стабильности все системы, что может сделать служба эксплуатации, какова вероятность остановки ИТ нагрузки? 

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

Есть ситуации, когда вариативность для заказчика невелика. В частности, если ЦОД имеет международную сертификацию по Uptime Institute — это налагает на него определенные обязательства по подписанию SLA-контрактов с сервисными партнерами с полным пакетом поддержки.

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

Здесь действует простое правило: чем требования жестче, тем дороже контракт. 

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

С другой стороны, жесткие требования не всегда имеют смысл. Если в ЦОДе есть резервирование по инфраструктуре, ЗИП на собственном складе, дежурная смена квалифицированных сотрудников — это позволяет снизить целевые показатели, уменьшив и стоимость контракта.

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

  • Время реагирования

Время реакции на запрос — классическая метрика, которая используется практически во всех SLA. Но это не значит, что к ее определению можно подходить формально.

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

Нередко заказчики устанавливают чрезмерные требования по времени прибытия на объект. 2 часа — это много или мало? Это зависит от физического расположения объекта, удаленности от крупных городов и развитости транспортной инфраструктуры. С учетом, что аварийный вызов — всегда непредвиденная ситуация, а инженер с инструментом и комплектом ЗИП не всегда может оперативно прыгнуть в самолет, а может и банально застрять в пробке.

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

Как выбрать оптимальные параметры? Можно представить себя на месте исполнителя, оценить потенциальные задачи и разумное время их решения.

  • Учет географических различий

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

Очевидно, что ни одна сервисная компания не сравнится по охвату с федеральным банком или телеком-оператором. Это значит, что для большинства подрядчиков требование прибыть за 2 часа на удаленный объект в Сибири заведомо невыполнимо. 

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

Отсюда вопрос: насколько правильно устанавливать одинаковые требования для разных регионов? Критичность ситуаций практически всегда будет разной: одно дело, когда останавливается главный ЦОД банка, где расположено ИТ-ядро, и другое — сбой в серверной локального отделения. Задачи разного масштаба и значимости требуют разного подхода. 

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

  • Резервирование ЗИП

Зачастую перед заказчиком стоит дилемма — держать ЗИП на собственном складе или передать эту задачу подрядчику.

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

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

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

  • Санкции

Санкции — необходимый элемент SLA, однако не стоит переоценивать их значение.

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

Поэтому санкции нельзя рассматривать как реальную компенсацию убытков — это только средство мотивировать партнера на качественную работу. 

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

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

Еще 10-15 лет назад первые редакции SLA составлялись формально, “для галочки”. В них могла быть указана “круглосуточная поддержка” без какой-либо детализации, что в это понятие входит. Современные контракты отличаются куда большей зрелостью: они включают большое количество метрик с четкими требованиями, параметрами оценки и ответственности.

Драйвером качественных изменений SLA стало возникновение первых крупных коммерческих ЦОДов. Когда ЦОДы перестали быть подразделениями для внутренних нужд, а стали самостоятельным бизнесом с собственной ответственностью перед клиентами — тогда они научились прописывать требования и к своим партнерам.

Помимо грамотно прописанных условий SLA, важен и уровень компетенции сервисных партнеров. Предлагая контракт определенного уровня, ЦОД должен понимать, что подрядчик не просто подписывается под рисками, а готов и заинтересован в качественном выполнении своих обязанностей. Однако это — тема для отдельного разговора.


Другие статьи