Sla что это в цод

Для чего нужен SLA и что кроется под заветными процентами

Что такое SLA

Service Level Agreement (SLA) часто встречается в описании преимуществ облачных провайдеров. Его можно назвать гарантией качества услуги. Термин появился благодаря руководству ITIL, самому распространённому документу по управлению ИТ-услугами. С его помощью компании во всём мире упорядочивают свои бизнес-процессы. Встречается SLA и в стандарте COBIT, регламентирующем большинство процессов облачных провайдеров, контроль их выполнения и взаимодействие с клиентами.

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

SLA определяет гарантированный уровень качества предоставляемой провайдером услуги. То есть ниже, чем зафиксировано в договоре, сервис быть не может. На разные сервисы могут прописываться разные Соглашения об уровне обслуживания. Условия тоже могут отличаться. Например, SLA на виртуальную инфраструктуру распространяется строго до ОС клиентской виртуальной машины. То, что внутри ВМ — касается только клиента и его ИТ-службы. Соответственно при каком-либо сбое начинать проверку надо с собственной системы. Потому что поломку инфраструктуры провайдер увидит раньше вас с помощью систем мониторинга.

Кому выгоден SLA и в чём его особенности

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

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

Соглашение об уровне обслуживания фиксирует следующие требования:

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

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

Время реакции на инциденты и другие цифры

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

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

Время инцидента = Время реакции на произошедшее + Время решения инцидента

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

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

Доступность — это те самые девятки, которые показываются как SLA. И в них кроется особая магия. Посмотрите:

Время простоя за месяц

Время простоя за год

7 час. 18 мин. 17,5 сек.

3 дня 15 час. 39 мин. 29.5 сек.

8 час. 45 мин. 57 сек.

4 часа 22 мин. 58,5 сек.

1 час 34 мин. 40,3 сек.

Вы заметили, как с ростом процентной точности снижается время простоя? 99% — это почти 4 дня простоя в год, а заявленные Cloud4Y 99,982% — всего полтора часа. Разница по времени колоссальная, хотя по цифрам — меньше 1 процента.

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

От чего зависят проценты? От организации инфраструктуры провайдера. Определённый уровень отказоустойчивости сервиса напрямую зависит от того, как построена виртуальная инфраструктура. Уровень доступности в 99,95% требует от провайдера наличия как минимум одного кластера active-passive. Показатель 99,982% дают распределённые системы с использованием нескольких ЦОДов Tier III. У Cloud4Y для обеспечения такого уровня доступности используется Hi-End оборудование корпоративного уровня, каждый элемент нашей инфраструктуры многократно дублируется, а информация передаётся по защищённым каналам и хранится в современных дата-центрах, расположенных в России и за рубежом.

Подчеркнём, что 99,99% и тем более 99,999% не должны быть самоцелью. Во-первых, такой уровень доступности будет стоить сильно дороже. Во-вторых, он не всегда нужен. Да, Cloud4Y может предложить некоторые сервисы с таким уровнем доступности. Но подавляющему большинству клиентов достаточно базового 99,982%.

Ещё один интересный нюанс — совокупная доступность. Она считается по наименьшему показателю. Если, к примеру, ваше приложение имеет доступность 99,95%, а дата-центр и облако, в котором оно развёрнуто — 99,982%, то общая доступность всё равно будет 99,95%. Всё определяется самым слабым звеном, не забывайте об этом. Нестабильное, часто сбоящее приложение не спасёт даже самое надёжное геораспределённое решение.

Чтобы снять все вопросы, приведём заявленный уровень доступности дата-центров разного уровня:

Уровень надежности ЦОД

Время простоя, часов в год

Что ещё может учитываться в SLA

Несомненно, доступность является самым важным параметром облачных ИТ-сервисов. Но виртуальные машины могут здорово потрепать нервы и при 100% доступности. Сетевые задержки, недостаточное количество IOPS, медленная СХД — эти и другие проблемы тоже нужно предусмотреть. Какие метрики нужно прописать в SLA?

Вместо заключения

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

Источник

Чистота – залог энергоздоровья ЦОДа, или как уход за ДГУ влияет на SLA

Без надежного резервного электроснабжения нет гарантий бесперебойной работы дата-центра. Поэтому мы решили посвятить этой теме сразу несколько постов. Ранее мы уже рассказывали про систему топливного мониторинга ЦОДа Linxdatacenter в Санкт-Петербурге. Сегодня расскажем, как правильно ухаживать за важнейшим элементом резервного энергопитания — дизель-генераторной установкой (ДГУ).

TPM для ДГУ

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

В этом заключается основной объем работ, обязательный для всех элементов системы электроснабжения. Но такое важное, технологически сложное оборудование, как ДГУ, требует дополнительного комплекса работ для повышения надежности, который описывается концепцией TPM (Total Productive Maintenance).

TPM – это концепция менеджмента управления производством, первоначально внедренная японскими компаниями. Основная идея заключается в непрерывном улучшении процессов ТО и планового ремонта, работе по принципу «ноль дефектов» и систематическом устранении всех источников потерь. Чтобы не отпугнуть читателей, мы пропустим описание всех столпов и философии этой концепции и перейдем сразу к практическому смыслу и внедрению.

Регламент работ по обслуживанию ДГУ с применением TPM состоит из:

Больше, чем чистка

Как это выглядит на практике в дата-центре?

TPM занимаются четверо инженеров-электриков, и за каждым из них закреплен свой ДГУ с площадкой и коммуникациями.

Для проведения работ по ТРМ требуется соблюдение требований безопасности. Для этого мы применяем подходы, описанные нами в рамках проекта системы Lock Out Tag Out. Каждый раз перед началом работ проводятся мероприятия по отключению оборудования и блокировки пуска ДГУ. Тем самым мы придерживаемся принципа Safety First – безопасность превыше всего.

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

Физическая чистота в буквальном смысле слова является краеугольным камнем TPM. Мы устраняем подтеки масла или антифриза, ослабление болтов, проверяем плотность закрутки фильтров и крепление шлангов для превентивного обнаружения «слабых звеньев» и мелких дефектов в ДГУ и их устранения в кратчайшие сроки.

Все процедуры проводятся по чек-листу, где зафиксирован подробный порядок действий сотрудника.

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

В концепции TPM мы сами выполняем эти действия со своим «автомобилем» (то есть с ДГУ), с заботой о нем.

Логическим завершением работ становится тестовый запуск ДГУ для проверки работоспособности системы.

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

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

Что мы обнаруживаем в процессе очистки

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

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

Вот, к примеру, трещина:

Так выглядит протечка масла из-за незатянутого масляного фильтра:

Только после устранения таких «мелочей» и успешного контрольного запуска система считается готовой для ввода в эксплуатацию и может гарантировать полную энергетическую безопасность ЦОДа, и, как следствие, возможность выполнения SLA в разрезе требований Uptime. Профилактика всех ключевых систем дата-центра и бережное отношение к оборудованию позволяет значительно снизить риски аварийных ситуаций. Ведь очень часто критические аварии в ЦОДе – это инциденты в результате халатности, которые могут повлечь за собой даже отказ ДГУ.

Эффекты и результаты

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

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

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

Комплекс ДГУ должен работать как часы, именно поэтому все эти процедуры по регламенту TPM играют такую важную роль в системе энергобезопасности ЦОДа в целом.

Общий регламент работ по уходу за ДГУ у нас выглядит так:

Источник

SLA на облако: как читать и на что обратить внимание

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

Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.

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

SLA – что это такое и для чего

SLA – это своего рода гарантийный талон на услугу. Но это не просто пункт с девятками в основном договоре. Это развернутое приложение, в котором фиксируются все параметры оказываемой услуги. Правильно составленное приложение страхует и клиента, и сервис-провайдера.

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

В хорошем SLA на виртуальную инфраструктуру должны быть:

Доступность

Доступность – это те самые девятки, которые чаще всего выдаются за SLA. Проценты доступности переводятся в минуты и часы недоступности сервиса в месяц или год.

Все варианты можно посмотреть здесь.
Казалось бы, всё понятно, в чем же подвох?

Месяц или год. Не зря я наверху выбрал две колонки – месяц и год. Когда видите заветные девятки в SLA, обратите внимание, к какому периоду они относятся. Чаще всего провайдеры говорят о месяце. То есть при доступности 99% мы получаем 7 с лишним часов даунтайма в месяц, а не в год. Уточняйте этот момент, чтобы потом не было разочарований.

Девятки и инфраструктура. Если вам необходим определенный уровень отказоустойчивости сервиса, то и виртуальная инфраструктура должна быть построена таким образом, чтобы эту доступность обеспечивать. Так, для достижения уровня доступности 99,95% вам, как минимум, понадобится кластер active-passive. Если вы хотите перешагнуть за 99,982% (уровень доступности в дата-центрах Tier III), вам нужно строить систему, распределенную по нескольким ЦОД.

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

Если вы выбираете облачные ресурсы, определитесь, какую задачу вы решаете сейчас: строите тестовую среду или холодный резерв или размещаете критические сервисы – интернет-магазин, платежную систему или CRM.

Совокупная доступность. Если ваше приложение имеет доступность 99,5%, облако имеет доступность 99,95%, а дата-центр, где оно развернуто, – 99,982%, то на выходе вы будете иметь доступность не выше 99,5%. Так как доступность всего сервиса не может быть выше доступности самого слабого его звена. Помните об этом при выборе сервиса и не пытайтесь лечить перелом подорожником. Защищенный геораспределенный кластер не спасет падающее через день приложение.

Не доступностью единой

Доступность для ИТ-сервисов – главный параметр. Но и при стопроцентном аптайме виртуальная машина может жестко тупить из-за сетевых задержек, недостаточного количества IOPS, высокой latency СХД и прочих проблем. Поэтому в правильном SLA должны быть все качественные метрики по инфраструктуре. На что смотреть и к чему стремиться?

секунды. Поэтому норма для этого параметра – в пределах от 0 до 1%. Как и в случае с сетевой задержкой, уточните у провайдера, где заканчивается его ответственность.

В SLA также следует прописать способы измерения и мониторинга по каждому параметру. Например, так:

Запросы, инциденты и технические работы

Сначала разведем понятия запрос и инцидент. Запрос – это заявки на штатные работы. Инцидент – когда что-то сломалось и не работает, например: машина сильно тупит или не пингуется. Если что-то сломалось у провайдера, то уведомление об инциденте приходит из системы мониторинга. Все запросы и инциденты разделяются по приоритетам. Это позволяет быстро реагировать на вопросы жизни и смерти и чинить все вовремя. Важно определить статус заявки на этапе ее регистрации. Как это устроено у нас, мы рассказывали в статье о службе поддержки.

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

Если используете разные типы дисков, не забудьте прописать инциденты по каждому из них:

Пример инцидентов первого приоритета.

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

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

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

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

Мы делим запросы на три типа, которые отличаются по характеру работ и времени исполнения:

Проведение регламентных работ и уведомление. Инфраструктура – это живой организм. Ее нужно обслуживать: апгрейдить, накатывать критические обновления, проводить плановые работы (например, обновлять прошивку на серверах). Не все работы можно сделать без остановки сервиса. Поэтому в SLA фиксируется порядок уведомления о таких работах, время проведения работ и возможное время перерыва в сервисе. Проверяйте, чтобы срок уведомления о плановых работах был достаточным и было зафиксировано максимальное время остановки сервиса.

У нас это выглядит так:

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

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

Если есть вопросы, традиционно жду в комментариях. Здорового вам облака!

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качественный 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, важен и уровень компетенции сервисных партнеров. Предлагая контракт определенного уровня, ЦОД должен понимать, что подрядчик не просто подписывается под рисками, а готов и заинтересован в качественном выполнении своих обязанностей. Однако это — тема для отдельного разговора.

Источник