Что такое SLA и что это означает для бизнеса?

1. Соглашение

Данное соглашение является приложением к Договору и определяет параметры Услуги «Виртуальные приложения» 1ОФИС (далее Услуга). В соглашении фиксируется стоимость, количественные и качественные характеристики оказываемой Услуги, такие как: конфигурация, доступность Услуги, время реакции на обращения Клиента, ограничения предоставляемого обслуживания, отчетность и т.п.

2. Определения

Согласованное время работоспособности (СВР) – указывает время, в которое услуга должна нормально функционировать. Например: 24×7 (круглосуточно, семь дней в неделю).

Согласованное время поддержки (СВП) – указывает время, в которое услуга поддерживается.

Если не указано иное, временная зона (MSK).

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

  • Запланированными окнами технического обслуживания.
  • Плановыми простоями в рамках проведения изменений, которые были предварительно согласованы с Клиентом.
  • Неработоспособность каналов связи и оборудования, находящихся вне зоны ответственности/контроля Компании 1ОФИС.
  • Приложениями или компонентами Клиента не подконтрольными и не управляемыми Компанией 1ОФИС, которые привели к невозможности оказать Услугу.
  • Негативной деятельностью Клиента, его работниками, партнерами, покупателями и т.п., что привело к негативному воздействию на компоненты Услуги (спам, спуфинг, нарушение правил использования Услуги и т.п.).
  • Другими неподконтрольными событиями, классифицируемыми как форс-мажорные обстоятельства.

Доступность (%) – минимально допустимый процент доступности услуги на единицу потребления за период. Определяется по формуле: ((СВР за период – Время простоя за период) / СВР) * 100%. Например, при суммарном простое 3 часа в месяц, при СВР = 24×7, процент доступности = (30 *24*60 – 3*60) / (30 *24*60) * 100% = 99.58%.

3. УРОВЕНЬ ОБСЛУЖИВАНИЯ

3.1. Целевые параметры уровня обслуживания

Согласованное время работоспособности Услуги (СВР) 24 x 7
Согласованное время поддержки Услуги (СВП) 24 x 7

3.2. Доступность Услуги

3.2.1. Окна технического обслуживания

Плановые 1-я и 3-я пятница каждого месяца, с 21:00-23:00МСК
Срочные По необходимости, с уведомлением не менее чем за 2 часа

3.2.2. Доступность

Виртуальные приложения (%) 99,9%

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

3.3. Нарушение показателей доступности и других параметров качества

(A) (% в мес.)* Размер компенсации (%)
99,45>А≥99,05 5
99,05>A≥98,5 10
98,5>A≥97,38 15
97,38>A 20

* — Измеренная доступность сервиса (А — availability) (% в месяц)Компенсация применяется в соответствии с договоромПРЕДУПРЕЖДЕНИЕ: Обращаю ваше внимание на дату поста. Прошло довольно много времени, поэтому к написанному предлагаю относиться критически. Сейчас, возможно, я бы делал по другому. Но пост сохраню для истории.      В прошлый раз я попытался раскрыть тему каталога сервисов. Логическим продолжением развития системы было составление Соглашения об уровне услуг (SLA). Договор должен был лечь в основу требований ко времени устранения инцидентов, заданному в системе.   Изначально стало очевидно, что простой перечень сервисов, полученный в результате составления каталога сервисов, лишь формализует обработку инцидентов, связав конкретные услуги с конкретными людьми. В дополнении к каталогу требовался документ, который бы описал качественные характеристики предоставления сервисов, а именно время устранения, в зависимости от важности инцидента, зоны влияния, заявителя и других его параметров.      Документ так же составлялся на основе результатов опроса ключевых пользователей и руководителей с учетом важности и влияния каждого сервиса. Данные были получены на основе совместного анализа предыдущего опыта работы службы и максимального возможного времени простоя конечного пользователя. Полученные показатели времени реакции были согласованы с руководством службы и представляли собой разумный баланс между необходимой срочностью устранения каждого инцидента и реальными возможностями обработки всех инцидентов службой.      Особенных трудностей при составлении документа встречено не было, так как фактически описывались существующие времена реакции на звонки пользователей.      Структура документов была выбрана на основе следующих источников:1. Как правильно составить SLA в ИТ?2. How to establish and maintain service level agreements2. Sample SLA templates3. Типовой состав SLA (от R-Style)4. Описание контракта SLA от IBSА также множества других примеров в основном заграничных каталогов, найденных на просторах интернета.И вот что получилось:

Соглашение об уровне предоставляемых услуг 1.Цель соглашения   Целью данного соглашения об уровне предоставляемых услуг являются:   — Достижение стабильного, четко определенного и измеряемого уровня поддержки для пользователей ИТ-сервисов;   — Увеличение удовлетворенности пользователей функционированием всей службы в целом и службой поддержки пользователей в частности, путем оперативного разрешения возникающих проблем;   — Оптимизация рабочего процесса службы путем определения необходимых уровней поддержки и формализации отношений между ними, что позволит сократить время решения проблемы и упростить работу сотрудников службы;   — Определение четких критериев, позволяющих определить уровень предоставляемого ИТ-сервиса.   Данный документ вместе с каталогом сервисов является основным для деятельности службы и определяет основные принципы его функционирования.2.Субъекты действия соглашения   Данное соглашение распространяется на все ИТ-сервисы, предоставляемые службой, в соответствии с Каталогом сервисов.3.Условия функционирования   Время работы. График работы службы поддержки пользователей:понедельник-пятница 9:00-18:00.   Дополнительные рабочие часы. Вне графика рабочих часов персонал службы устраняет инциденты только в периоды проведения специальных работ. Временные изменения графика дежурств согласовываются руководителем подразделения, которому необходима поддержка сервисов в дополнительное время, с руководителем службы.   Обработка неподдерживаемых заявок. В случае если в службу поддержки пользователей поступает заявка на устранение проблемы с сервисом, не входящим в список ИТ-сервисов, перечисленных в Сервисном каталоге, персонал службы постарается дать контакты лица, который мог бы помочь с решение проблемы.4.Установка приоритетов и классов заявок   Заявки имеют 5 уровней срочности (приоритетов), определяющих время реагирования на них сотрудников службы:   Уровень 5 (наивысший) – Проблема затрагивает большую часть сотрудников организации, либо ключевых сотрудников компании. Например, возникла проблема в серверной комнате, затрагивающая несколько основных серверов.   Уровень 4 (высокий) – Проблема, затрагивающая группу сотрудников. Например, нет связи с филиалом, нет связи с сервером.   Уровень 3 (средний) – Проблема, затрагивающая одного сотрудника. Например, неработоспособность компьютера, сетевого принтера.   Уровень 2 (низкий) – Проблема, возникающая у пользователей временно. Например, неработоспособность некритичного оборудования.   Уровень 1 (минимальный) – Проблема, возникшая единовременно и не связанная с основными производственными процессами компании.   Кроме того, время реагирования на заявку должно отличаться для различных групп ИТ-сервисов, поэтому на этапе регистрации заявки необходимо классифицировать поступившую заявку по типу ИТ-сервиса, который она затрагивает. Для этого все ИТ-сервисы, представленные в Сервис Каталоге, были разделены на следующие классы по степени важности:   Класс 0 – Сервисы, критические для работы большинства сотрудников компании. К ним относятся коммуникационная инфраструктура (непосредственно локальная сеть). Проблемы с сервисами этого класса приводят к невозможности взаимодействия одного или нескольких компьютеров в сети с другими компьютерами сети компании.   Класс 1 – Сервисы, критические для работы групп пользователей. К ним относятся все заказные сервисы и подписные, за исключением интернета и электронной почты. Проблемы с сервисами этого класса приводят к невозможности выполнения специальных задач пользователем.   Класс 2 – Сервисы, критические для работы одного пользователя. К ним относятся все базовые сервисы за исключением коммуникационной инфраструктуры, а так же интернет и электронная почта. Проблемы с сервисами этого класса влияют на работу одного пользователя.   Время реагирования для заявок с различными приоритетами и классами представлено в Приложении. При превышении заданного времени происходит уведомление менеджера инцидентов и руководителя службы, которые предпринимают все возможные действия для скорейшего устранения инцидента: привлечение дополнительных или более квалифицированных специалистов для устранения инцидента (иерархическая и функциональная эскалация), привлечение специалистов сторонних организаций, принятие решения о необходимости инициирования изменения или проблемы и другое.5. Целевые уровни качества сервиса   В разделе приведены определения и величины основных целевых уровней качества предоставляемых сервисов. При необходимости возможно введение дополнительных показателей.   a)доступность сервиса – число сбоев в период обслуживания;Для сервисов 0 класса – минимально. Не более 1 в год.Для сервисов 1 класса – не более 2 в год.Для сервисов 2 класса – не более 3 в год.   b)средняя длительность сбоя сервиса – длительность времени, в течение которого он недоступен потребителю;Для сервисов 0 класса – минимально. Не более 1 часа.Для сервисов 1 класса – не более 3 часов.Для сервисов 2 класса – не более 5 часов.   c)время отклика сервиса – время ожидания, прошедшее после вызова сервиса;Для сервисов 0 класса – минимально. Должно быть незаметно пользователем.Для сервисов 1 класса – Не более 1 секунды. Заметно, но не мешает работе.Для сервисов 2 класса – Не более 2 секунд. Заметно, но пользователь может продолжать работу.   d)текущая пропускная способность – пропускная способность канала, оцененная в данный момент. Используется для сравнения со средней пропускной способностью;   Отчеты по данным целевым показателям готовятся по требованию пользователя. При необходимости инициируется заявка на устранение инцидента, который снижает уровень предоставляемых услуг.   Кроме того, так же могут быть рассчитаны показатели качества работы службы поддержки. К ним относятся:a)Количество заявок, поступивших за контрольный интервал времени;b)Распределение полученных заявок по сервисам, которые они затронули, по классам заявок, подразделениям, уровням срочности;c)Процент успешно выполненных заявок;d)Соотношение инцидентов и запросов на изменения в заявках;e)Среднее время выполнения заявки, полученное для различных классов заявок и уровней их срочности;f)другие по необходимости.   Данное Соглашение призвано обеспечить разрешение возникающих инцидентов с заданным уровнем качества в установленные сроки сотрудниками службы. Отчеты по качеству и объемам работы Службы поддержки пользователей готовятся по необходимости и позволяют оптимизировать процесс устранения инцидентов.6.Процедура обновления соглашения   Регулярно необходимо проводить проверку соответствия данного Соглашения реальному положению дел в организации. Существенно может изменяться раздел 5, путем добавления новых обязательных отчетных целевых показателей.   В каждый момент времени данное Соглашение должно отражать существующее положение дел в организации.   Приложение. Выделенное время решения инцидентов   Разделение по классам предусмотрено, но не организовано. Время, выделенное на решение инцидентов с различными степенями срочности, представлено в таблице.
Наивысший уровень срочности Высокий уровень срочности Средний уровень срочности Низкий уровень срочности Минимальный уровень срочности
Время, выделенное на решение инцидента 4 часа 8 часов 1 рабочий день 5 рабочих дней 10 рабочих дней

      Несмотря на то, что многие рекомендации предлагают включить каталог услуг в состав SLA мы не стали так делать, т.к. к моменту написания SLA каталог существовал как отдельный документ, и требовалось лишь уточнить основные параметры и характеристики сервисов, описанных в каталоге. В иных случаях, возможно, правильно будет объединить эти два документа в один всеобъемлющий SLA, описывающий как сами сервисы, так и их параметры.      Естественно, приведенный здесь SLA имеет простейший вид, т.к. задача стояла только лишь в определении основных временных характеристик устранения инцидентов. В случае необходимости документ может быть расширен и дополнен разделами, предлагаемыми по вышеприведенным ссылкам.      На основе этого документа были сделаны настройки системы – заданы времена реакции в зависимости срочности инцидента. Наличие четко определенных параметров устранения инцидентов позволяет обращать внимание на узкие места системы и четко выделять их в отчетности.      Упрощенное содержание SLA стало приложением к регламенту использования системы.      Как и в случае с каталогом сервисов после написания SLA вышло довольно много интересных и полезных статей. Среди них можно отметить:1. Redefining SLAs in the Midmarket, Michael Singer в internetevolution.com2. The service level agreement is a living document, John Cusimano на ITSMPortal.comP.S. После нашествия ботов комментарии не от друзей скрываются до проверки. Но ни один вопрос не останется без внимания.tags: пример SLA, соглашение об уровне услуг, соглашение об уровне сервисов, Service Level Agreement

Формирование SLA

Основным стратегическим направлением совершенствования организационной поддержки бизнес-процессов со стороны информационных технологий является создание и внедрение системы соглашений по уровню обслуживания (Service Level Agreement – SLA). Каждое соглашение определяет спецификация на ИТ-услугу (группу услуг) в конкретной бизнес-области.

Рис. 6.6. Субъекты SLA

Общие положения:

• предприятие осуществляет покупку сервисных ИТ-услуг. Каждая сервисная услуга оказывается по группе однородных ИТ-объектов (устройств, систем). Объект описывается в специальном паспорте;

• при покупке услуг должен выполняться учет инцидентов (любое событие, нарушающее предоставление услуги) и заявок на выполнение работ в разрезе услуг и объектов;

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

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

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

Качество уровня услуг определяется, с одной стороны, по объективным данным обращений в службу поддержки и результатам независимого аппаратного мониторинга, с другой – на основе выяснения мнения пользователей относительно степени удовлетворенности услугами ИТ-инфраструктуры.

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

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

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

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

Формирование SLA позволяет менеджерам:

• определить ключевые бизнес-процессы на предприятии;

• измерить критичные виды деятельности для предприятия;

• проверить полученные результаты на предмет принципиальных ошибок и проблем;

• внести необходимые поправки для устранения ошибок и проблем;

• непрерывно управлять процессом для получения желаемого результата.

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

По результатам анализа потребностей бизнеса процесс планирования услуг (service planning) составляет и контролирует «портфель» стандартных услуг, необходимых большинству корпоративных заказчиков. При желании стандартные услуги могут быть модифицированы для решения специфических задач бизнес-подразделения.

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

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

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

•  задание категории. Ключевая бизнес-функция, процесс или процедура, которая подвергается измерению, описанию и непрерывному совершенствованию;

•  временные рамки (доступность). Временной период, в течение которого данный уровень сервиса может быть измерен (как правило, указывается факт включения/исключения выходных и праздничных дней);

•  допущения/ответственность. Отражение специфических требований со стороны как поставщика, так и получателя услуг, выполнение которых является необходимым условием согласованности и непротиворечивости SLA;

•  сервисные метрики. Измерение выполняемых поставщиком услуг, обычно выражаемое в процентах;

•  формула для расчета. Описание математической формулы, используемой для измерения услуги;

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

•  источники данных. Описание типов и источников собираемых данных, мест и способов их хранения, а также информация о лицах, ответственных за предоставление и сбор данных;

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

•  исключения, штрафы, премии. Описание включенных в договорные обязательства каких-либо исключений, штрафных санкций и систем мотивации;

•  формула для расчета премий/штрафов . Описание математической формулы, используемой для расчета премий/штрафов;

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

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

В качестве примера можно привести описание ИТ-услуги по предоставлению серверных и сетевых сервисов:

•  задание категории. Время отклика End-to-end response time;

•  временные рамки (доступность). Серверные и сетевые сервисы доступны круглосуточно в течение 24 часов, с воскресенья по субботу, за исключением определяемых клиентом праздников и выходных дней;

•  качество. Ошибки – менее чем в 1 % соединений;

•  реактивность (время реакции) – менее 1 секунды;

•  взаимодействие. Регистрация проблемы – при наличии проблемы в течение первых 30 минут она регистрируется/решается менеджером программы (или другим уполномоченным лицом); если в течение 4 часов проблема остается, то ее регистрация/решение передается региональному менеджеру. Управление проблемами – ведется менеджером программы, если неисправность не устранена в течение первого отчетного месяца; ведется региональным менеджером, если неисправность не устранена в течение двух отчетных месяцев;

•  допущения/ответственность. Сервер является собственностью получателя услуг, у него же на рабочем месте он и располагается. Доступ к серверным системам предоставляется получателем услуг в соответствии с требованиями поставщика. В то же время поставщик услуг выполняет все требования организации-клиента по безопасности и защите информации. Intranet – поддерживается время отклика менее 1 секунды. Internet – поддерживается время отклика менее 3 секунд;

•  формула для расчета. Время отклика = < 1 секунды (под временем отклика понимается интервал, необходимый для появления всех символов на экране конечного пользователя после начального запроса);

•  интервал измерения и отчетный период. Интервал измерения – ежедневно. Отчетный период – еженедельно (обобщенный);

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

•  регистрация проблемы. См. взаимодействие;

•  управление проблемами. См. взаимодействие;

•  исключения, штрафы, премии (из договора). Уровень услуг считается неприемлемым, если организация-получатель услуг за 90 дней не предоставляет прогноз по всем необходимым стандартным продуктам, или производители этих продуктов не смогут предоставить их поставщику услуг. Штрафные санкции применяются, начиная со следующего за отчетным месяца, если в отчетном месяце не было достижения или превышения оговоренного уровня услуг. Штраф устанавливается в размере 10 % от стоимости услуг. Премиальные выплаты не предусмотрены;

•  формула для расчета штрафов. Штраф = 10 % стоимости;

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

Обычно разработка SLA состоит из следующих этапов:

• проведение оценки существующих в организации предложений поставщиков услуг (Statement of Work – SOW) и соглашений об уровне услуг (SLA) по сравнению с лучшей мировой практикой. Разработка шаблонов контрактов организации с поставщиками услуг. Цель – подготовка соглашения по услугам, в котором устанавливались бы расценки за соответствующие услуги и штрафные санкции в случае невыполнения поставщиком своих обязательств;

• настройка шаблонов SLA и критических показателей;

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

• обеспечение поощрения и стимулирования (Incentives and Credits methodology), гарантирующих выполнение SLA и представляющих собой средство управления, с помощью которого организация может успешно и на долгосрочной основе взаимодействовать с поставщиком услуг. Внедрение этой методики даст возможность контролировать такие значимые параметры, как работоспособность систем, разрешение инцидентов, удовлетворенность заказчика и др.;

• контроль удовлетворенности уровнем ИТ-услуг.

Проведение исследований удовлетворенности ИТ-пользователей позволяет обеспечить:

• инструмент для мониторинга и развития ИТ-услуг и управления ими в целях улучшения бизнеса и производительности труда персонала;

• поддержку принятия решений по информационным технологиям в части составления ИТ-бюджета, распределения ресурсов, стратегического планирования;

• оценку ценности информационных технологий, потребностей и уровней удовлетворенности для различных групп ИТ-пользователей;

• оценку качества услуг.

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

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

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

Мониторинг изменений мнения пользователей проводится с помощью кратких периодических исследований.

Области исследования:

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

• уровень ИТ-услуг и уровень работы ИТ-департамента;

• взаимодействие ИТ-департамента и провайдеров услуг;

• способность сотрудников использовать возможности информационных систем;

• функционирование информационных систем.

После сбора информации проводится ее сопоставительный анализ с типовыми компаниями на предмет:

• расхождения в ожиданиях пользователей и их удовлетворенности;

• расхождения во мнениях пользователей и ИТ-департамента при оценке важности отдельных факторов и услуг;

• расхождения в удовлетворенности пользователей и мнении ИТ-департамента при оценке степени удовлетворенности по отдельным факторам и услугам;

• расхождения в оценке важности и степени удовлетворенности ИТ-услугами;

• подготовки отчета для руководства с выводами и рекомендациями. План работ по проведению опросов состоит из следующих этапов:

• подготовка анкет для опроса;

• планирование выборки пользователей и прогнозируемых ответов;

• управление сбором данных через специальное Web-приложение (портал);

• статистическая интерпретация ответов;

• оценка и подготовка отчетности по результатам.

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

Данный текст является ознакомительным фрагментом.

Ключевое различие между LA и OLA заключается в том, что LA — это договор между поставщиком услуг (поставщиком) и конечным пользователем (заказчиком), в котором указывается уровень обслуживания, ожидае

Содержание:

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

СОДЕРЖАНИЕ 1. Обзор и основные отличия 2. Что такое SLA 3. Что такое OLA 4. Параллельное сравнение — SLA и OLA 5. Резюме

Что такое SLA?

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

  • Описание услуг
  • Надежность, оперативность и согласованный уровень производительности
  • Порядок сообщения о проблемах
  • Мониторинг и отчетность уровня обслуживания
  • Последствия невыполнения служебных обязательств, включая подлежащие уплате штрафы
  • Предложения или ограничения escape

Ниже приведены различные типы соглашений об уровне обслуживания.

SLA на основе клиента

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

Многоуровневый SLA

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

SLA на основе сервисов

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

Технические определения, такие как «среднее время наработки на отказ» (MTBF), «среднее время до ответа» (MTTR) или «среднее время восстановления» (MTTR), используются в SLA вместе со сторонами, ответственными за уплату сборов и сообщение о неисправностях.

Что такое OLA?

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

В чем разница между SLA и OLA?

SLA против OLA

SLA — это договор между поставщиком услуг (поставщиком) и конечным пользователем (заказчиком), в котором указывается уровень обслуживания, ожидаемого от поставщика услуг. OLA определяет взаимозависимые отношения в поддержку Соглашения об уровне обслуживания.
Фокус
SLA фокусируется на сервисной части соглашения. OLA — это соглашение в отношении технического обслуживания и других услуг.
Природа
SLA — это соглашение между поставщиком услуг и конечным пользователем. OLA — это внутреннее соглашение.
Техничность
SLA — это менее технический контракт. OLA — это высокотехнологичный контракт.

Резюме — SLA против OLA

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

Рассматривая облачные сервисы для Big Data проектов, мы уже говорили про SLA (Service Level Agreement, соглашение об уровне предоставления услуг) и упоминали показатели измерения эксплуатационной надежности в материале про эволюцию Agile-подходов. Читайте в нашей сегодняшней статье, как эти SRE-метрики помогают DevOps-инженерам и администраторам обосновать экономическую необходимость затрат на средства дополнительной защиты Big Data систем от сбоев и когда такие инвестиции выгодны бизнесу.

Зачем SLAмерит доступность BigDataсистемы и как это связано с SRE, DevOpsи клиентами

Как правило, для Big Data характерна высокая или постоянная доступность, а также непрерывный режим работы – это значит, что система защищена, а также легко, быстро с использованием автоматизированных средств восстанавливается от небольших простоев [1]. Именно доступность считается главным показателем качества. Поэтому большинство облачных провайдеров для Big Data систем стремятся гарантировать значение этой метрики на уровне более 99% за счет защищенных протоколов, резервирования каналов передачи информации, шифрования SSH, изоляции данных, аутентификации и гибких настроек политики безопасности на основе ролей [2].

Вычисление и поддержание необходимого уровня доступности является одной из задач SRE (Site/System Reliability Engineering) – инженерной Agile-дисциплины обеспечения эксплуатационной надежности, которая возникла как продолжение DevOps. В частности, SRE уточняет, какие именно показатели эксплуатационной надежности приложений должны непрерывно измеряться и оцениваться. Обычно эти параметры и диапазоны их значений указаны в SLA– договоре между поставщиком и получателем услуги. Этот документ, возникший из практической методологии эффективной организации работ ИТ-подразделений ITIL, необходим провайдеру и клиенту сервиса по следующим причинам [3]:

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

Сама библиотека ITIL в разделе описания процесса управления доступностью приводит следующие метрики оценки качества ИТ-сервиса[4]:

  • доступность (availability);
  • производительность (performance);
  • надежность (reliability);
  • сопровождаемость (maintainability);
  • обслуживаемость (serviceability);
  • безопасность (security).

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

SRE измеряет доступность по следующим показателям и целям уровня обслуживания, которые индивидуальны для каждого приложения и класса данных [5]:

  • SLI (Service Level Indicator) — метрики времени (задержка запроса, пропускная способность, число запросов в секунду или число сбоев на запрос). Они, как правило, агрегируются во времени, а затем преобразуются в среднее или процент по отношению к пороговому значению;
  • SLO (Service Level Objective) — целевые показатели совокупного успеха SLI в течение определенного периода времени (месяц, квартал и т.д.), согласованные заинтересованными сторонами.

Как оценить доступность сервиса во времени и деньгах

Фактическая доступность сервиса (A) за конкретный период зависит от планового значения этого показателя (B) и суммарного времени простоев (C) [1]:

A= (B C) / B × 100 %

Например, если Big Data система не отвечала в январе в течение 45 минут, то ее уровень доступности составляет 99,9 % [1].

Однако, простой BigDataсистемы для бизнеса означает потерю денег. Поэтому очень важно определить максимально возможное время простоя и его цену, прежде всего в потерянных данных. Для этого используются следующие показатели [6]:

  • RPO (Recovery Point Objective, целевая точка восстановления) – максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, если для системы определен RPO в 15 минут, это значит, что, в случае аварии систему удастся восстановить, но в ней будут потеряны данные не более, чем за последнюю четверть часа. В идеале этот показатель должен стремиться к нулю, однако на практике это почти нереализуемо. Для Big Data систем на Apache Hadoop автоматическое реплицирование данных в файловой системе HDFS помогает снизить RPO. Однако этого недостаточно для обеспечения высокой доступности всего сервиса. Вычисление RPO и поддержание ее на должном уровне относятся к задачам DevOps- и SRE-инженеров.
  • RTO (RecoveryTimeObjective, целевое время восстановления) – промежуток времени, в течение которого система может оставаться недоступной в случае аварии, т.е. время, необходимое для восстановления полного функционирования сервиса после наступления аварийного события. Например, RTO равен 2 часа, если в датацентре произошла авария (пожар, наводнение и пр.), и сервис должен быть снова доступен через 120 минут или раньше. SRE-инженеры организуют систему так, чтобы за это время восстановить работоспособность системы на резервном оборудовании или площадке с помощью различных технологий отказоустойчивости или восстановления из резервных копий на другой сервер. RTO, как и RPO, должен быть как можно меньше.
Смысл понятий RPO и RTO

Построив график зависимости финансовых потерь от простоев системы, можно определить экономически выгодное для бизнеса значение метрик RPO и RTO [7]:

Экономически выгодное вычисление RPO и RTO

Чем меньше значение RPO и RTO, тем дороже будет стоить система восстановления. Снижение времени восстановления на 10—20% в разы увеличивает стоимость системы резервного копирования [7]. Однако, для крупных data driven компаний убытки от сбоев Big Data систем критичны не только в финансовом выражении: страдает репутация предприятия и парализуются операционные бизнес-процессы. Поэтому SREоценивает риски через бюджеты ошибок, которые определяют баланс между доступностью и особенностями разработки и эксплуатации. Разработчики, желающие предоставить много новых функций, должны выбрать менее строгие SLO, чтобы продолжать поставку в случае ошибки. Владельцы сервисов, ориентированные на надежность, выбирают более высокий SLO, но его нарушение задержит новые выпуски. Согласно SRE-подходу, когда бюджеты ошибок исчерпаны, фокус смещается с разработки функций на повышение надежности [5].

Важно отметить, что решение о допустимых значениях RPO и RTO принимают не только DevOps– и SRE-инженеры. Поскольку эти SLO-метрики непосредственно влияют на финансовые показатели, определять их должен бизнес: руководители подразделений, ИТ-директор и аналитики. Сбалансированные SLOи SLAвозможно разработать только при участии всех заинтересованных сторон.

Еще больше пользы от SRE-, DevOps и других Agile-приемов в нашем курсе обучения «Аналитика больших данных для менеджеров» в учебном центре для руководителей, аналитиков, архитекторов, инженеров и исследователей Big Data в Москве.

Смотреть расписание Записаться на курс

Источники

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
А как считаете Вы?
Напишите в комментариях, что вы думаете – согласны
ли со статьей или есть что добавить?
Добавить комментарий