Управление уровнем услуг и SLA (Service Level Management, Service Level Agreement)

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

Утром 28 февраля 2017 года инженер Amazon Web Services разбирался, почему медленно работает система выставления счетов хранилища S3 в регионе US-EAST-1 (Северная Вирджиния). По утверждённому сценарию он запустил команду, которая должна была вывести из работы несколько серверов, но ошибся в одном из параметров — и отключил гораздо больше машин, включая подсистему, где хранятся сведения о расположении всех объектов региона. Почти четыре часа не работали или работали со сбоями Trello, Quora, IFTTT и тысячи других сервисов. Компания по оценке киберрисков Cyence подсчитала, что компании из индекса S&P 500 потеряли около 150 млн долларов. А что получили клиенты, у которых было соглашение об уровне услуг? По условиям S3 при месячной доступности ниже 99,9% клиент получает сервисный кредит — скидку в процентах от счёта за само хранилище. Четыре часа простоя — это примерно 0,6% месяца, то есть доступность около 99,4%: по действующей шкале AWS это нижняя ступень компенсации, 10% месячного счёта за S3.

Этот случай лучше любой лекции показывает, что такое SLA и чем оно не является. Соглашение об уровне услуг — не страховка от убытков и не гарантия, что ничего не сломается. Это договорённость о том, какой уровень услуги считается нормой, как его измерять и что происходит при отклонении. Хорошее SLA помогает обеим сторонам заранее понять ожидания, вовремя увидеть проблему и спроектировать свою работу с учётом рисков. Плохое — превращается в «зелёный» отчёт, за которым скрываются недовольные пользователи. Ниже — откуда взялись SLA, как устроена практика управления уровнем услуг в ITIL 4, чем SLA отличается от OLA, SLO и XLA и как пройти путь от первого черновика до регулярного обзора услуги с клиентом.

Соглашение об уровне услуг (SLA): происхождение — от телекома и аутсорсинга к ITIL 4 и SRE

Телеком и аутсорсинг конца 1980-х

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

ITIL: управление уровнем услуг как процесс

Во второй половине 1980-х Центральное агентство по вычислительной технике и телекоммуникациям британского правительства (CCTA) начало собирать лучшие практики управления ИТ, потому что государственные ИТ-расходы росли, а качество не было прозрачным. В 1989 году свод получил название IT Infrastructure Library — ITIL. Первая версия состояла из десятков отдельных книг, и среди них было руководство по управлению уровнем услуг — наряду с работой службы поддержки, управлением изменениями, проблемами и конфигурациями. С этого момента SLA перестали быть только юридическим документом: ITIL описал вокруг них процесс — согласование требований, составление соглашения, мониторинг, отчётность и пересмотр.

В ITIL v3 управление уровнем услуг относилось к этапу проектирования услуг и разделяло соглашения на три вида: SLA на услугу (одно соглашение для всех клиентов услуги), SLA на клиента (все услуги для одного клиента в одном документе) и многоуровневые SLA (корпоративный уровень, уровень клиента и уровень отдельной услуги). Там же были закреплены опорные документы: внутреннее операционное соглашение (OLA) и договор с внешним поставщиком (UC). Требование управлять уровнем услуг есть и в международном стандарте управления ИТ-услугами ISO/IEC 20000-1.

В ITIL 4 (2019) процессы заменены 34 практиками, и управление уровнем услуг стало одной из них. Цель практики сформулирована так: установить понятные, основанные на потребностях бизнеса целевые уровни услуг и обеспечить, чтобы предоставление услуг правильно оценивалось, отслеживалось и управлялось относительно этих целей. Акцент сместился с измерения технических параметров на ценность и опыт пользователей; OLA и UC в описании практики отошли на второй план. Первой большой книгой о практике SLM стала работа Рика Стерма, Уэйна Морриса и Мэри Джандер «Foundations of Service Level Management» (2000).

Альтернативная линия: SLO, SLI и бюджет ошибок в SRE

Независимо от ITIL похожую систему понятий выработала инженерия надёжности Google. В книге «Site Reliability Engineering» (2016, редакторы Бетси Бейер, Крис Джонс, Дженнифер Петофф, Нил Ричард Мёрфи) различаются три термина. SLI (service level indicator) — точно определённая количественная мера какого-то аспекта уровня услуги, например доля успешных запросов. SLO (service level objective) — целевое значение или диапазон для SLI. SLA — явный или неявный договор с пользователями, где прописаны последствия выполнения или невыполнения входящих в него SLO. Отсюда вытекает понятие бюджета ошибок: если цель доступности 99,9%, то 0,1% времени или запросов команда «может себе позволить» потратить на сбои. Пока бюджет есть, выпускаются изменения; когда он исчерпан, приоритет переходит к надёжности.

Третья линия: XLA и «эффект арбуза»

С середины 2010-х набирает силу критика SLA изнутри отрасли. Нидерландская исследовательская компания Giarte в 2015 году предложила формат Experience Level Agreement — соглашение об уровне опыта. Его сторонники описывают проблему метафорой арбуза: SLA-отчёт зелёный снаружи, а внутри всё красное — сроки соблюдены, услуга доступна, а пользователи раздражены. XLA фиксирует цели с точки зрения пользователя: время, за которое человек снова может работать, удовлетворённость решением обращения, ощущаемую производительность. Giarte формулирует разницу так: SLA — это контракт, XLA — это обязательство.

Соглашение об уровне услуг: ключевые идеи и принципы

Принцип: SLA начинается с потребностей бизнеса, а не с возможностей поставщика

Соглашение об уровне услуг начинается не с шаблона договора, а требования к уровню услуги (service level requirements). Что для клиента значит «услуга работает»? Какие операции критичны, в какие часы, сколько стоит час простоя? Если цели задаёт поставщик исходя из того, что ему удобно измерять, получается соглашение о том, что легко считать, а не о том, что важно. ITIL 4 прямо требует, чтобы целевые уровни были основаны на потребностях бизнеса и понятны ему.

Принцип: структура соглашения

Типичное соглашение об уровне услуг содержит: описание услуги и её границ (что входит и что не входит); область действия (какие клиенты, подразделения, системы); часы поддержки и каналы обращений; классификацию приоритетов; целевые показатели с методикой измерения; обязанности обеих сторон, включая обязанности клиента; исключения — плановые работы, форс-мажор, проблемы на стороне клиента; порядок отчётности и обзоров; последствия нарушений и порядок пересмотра соглашения. Без методики измерения цель ничего не значит: «доступность 99,9%» надо определить — по каким проверкам, из какой точки, за какой период, с учётом ли плановых окон.

Принцип: приоритеты и цели реакции и решения

Обращения различаются по влиянию на бизнес и срочности, поэтому цели задаются по приоритетам. Распространённая схема — четыре уровня: P1 (критичный — остановлена работа многих пользователей или ключевой процесс), P2 (высокий), P3 (средний), P4 (низкий, плановые вопросы). Для каждого приоритета задаются два срока: время реакции (когда исполнитель взял обращение в работу и связался с заявителем) и время решения (когда услуга восстановлена). Приоритет обычно определяется по матрице «влияние × срочность», а не по ощущению заявителя — иначе всё становится «критичным». Как организован сам процесс обработки, описывает управление инцидентами ITIL, а действия при серьёзной аварии — матрица экстренной эскалации.

Принцип: доступность в «девятках» и бюджет ошибок

Цель доступности удобно переводить в допустимый простой. За 30-дневный месяц 99% — это около 7,2 часа простоя, 99,5% — около 3,6 часа, 99,9% — около 43 минут, 99,99% — около 4,3 минуты. Каждая следующая «девятка» стоит дорого: нужны резервирование, дежурства, автоматизация. Поэтому цель выбирают не «как можно выше», а по цене простоя для бизнеса. Бюджет ошибок делает цель управляемой: команда видит, сколько допустимого простоя уже израсходовано, и решает, можно ли сейчас рисковать изменениями.

SLA с целью 100% — это не амбиция, а ошибка: такую цель невозможно выполнить, и она лишает команду права на любое изменение.

Принцип: SLA, OLA и UC — цепочка обязательств

Соглашение об уровне услуг перед клиентом держится на обязательствах внутри компании и снаружи. OLA (operational level agreement) — соглашение между внутренними командами: если клиенту обещана реакция за 30 минут, первая линия должна передать обращение второй, скажем, за 10 минут, а вторая — начать работу за следующие 15. UC (underpinning contract) — договор с внешним поставщиком: облачным провайдером, дата-центром, производителем оборудования. Если поставщик гарантирует восстановление за 8 часов, а клиенту обещаны 4, SLA заранее невыполнимо. Управление поставщиками в этой цепочке — тема управления взаимоотношениями с поставщиками.

Принцип: измерять то, что чувствует пользователь

Агрегаты обманывают. Среднее время решения 3 часа может скрывать, что 10% обращений ждут сутки. Инженеры Google советуют смотреть на распределения и процентили, а не на средние. Технические показатели стоит дополнять пользовательскими: удовлетворённостью после закрытия обращения, повторными обращениями, жалобами. Так видно, когда SLA превращается в «арбуз». Удовлетворённость удобно измерять методикой CSAT, а общую картину по нескольким атрибутам — индексом удовлетворенности клиентов (CSI).

Принцип: не перевыполнять обещанное

Неожиданный, но важный урок SRE. Внутренний сервис блокировок Google Chubby работал настолько стабильно, что команды-потребители начали считать его доступность абсолютной и перестали закладывать защиту от его сбоев. Когда Chubby всё же падал, последствия оказывались непропорционально тяжёлыми. Команда стала намеренно устраивать плановые отключения, чтобы фактическая доступность соответствовала заявленной цели. Вывод: если фактический уровень сильно выше обещанного, потребители начинают зависеть от фактического, и SLA перестаёт описывать реальные риски.

Принцип: регулярный обзор услуги

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

Принцип: последствия нарушений

Последствия бывают финансовыми (сервисные кредиты, скидки, штрафы) и управленческими (обязательный разбор причин, план исправления, право клиента расторгнуть договор при систематических нарушениях). Сервисные кредиты почти всегда ограничены долей стоимости услуги и не покрывают убытков клиента — это видно по случаю AWS. Поэтому для клиента SLA — прежде всего информация для собственного управления рисками: если поставщик обещает 99,9%, архитектура и процессы клиента должны выдерживать 43 минуты простоя в месяц.

Ограничения, слепые зоны и критика: где соглашение об уровне услуг не работает

«Эффект арбуза»

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

Соглашение подменяет отношения

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

Метрики провоцируют игру

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

Средние скрывают хвосты

Цель «среднее время решения не больше 4 часов» выполняется, даже если десятая часть пользователей ждёт сутки. Для таких пользователей услуга плохая, хотя SLA соблюдено. Цели по процентилям («95% обращений P2 решаются за 4 часа») честнее средних.

Цель без возможности её обеспечить

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

Чем SLA не является

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

Типовые ошибки при внедрении SLA

Ошибка 1: цели задаёт поставщик по тому, что легко измерить.

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

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

Ошибка 2: нет методики измерения.

В соглашении написано «доступность 99,9%», но не определено, как она считается: по каким проверкам, из какой точки, за какой период, входят ли плановые работы. При первом же споре стороны получают разные цифры.

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

Ошибка 3: SLA не подкреплено OLA и договорами с поставщиками.

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

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

Ошибка 4: все обращения «критичные».

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

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

Ошибка 5: только средние значения.

Цели заданы как средние, и отчёт выглядит хорошо, хотя часть пользователей ждёт решения сутками.

Как избежать: формулируйте цели как долю обращений в срок («95% P2 решаются за 4 часа») и смотрите на распределение, а не только на среднее.

Ошибка 6: SLA без пользовательских метрик.

Все сроки соблюдаются, отчёт зелёный, а недовольство растёт: обращения закрывают формально, проблемы возвращаются.

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

Ошибка 7: соглашение подписали и забыли.

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

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

Главное, что нужно знать: соглашение об уровне услуг в пяти тезисах

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

2. Цели задаются по потребностям бизнеса и по приоритетам: для каждого — время реакции и время решения, для услуги в целом — доступность, переведённая в допустимый простой.

3. SLA держится на цепочке обязательств: внутренние соглашения команд (OLA) и договоры с поставщиками (UC) должны обеспечивать обещанное клиенту с запасом.

4. Технические показатели нужно дополнять пользовательскими, иначе возникает «эффект арбуза»; честнее задавать цели как долю обращений в срок, а не как среднее.

5. SLA живёт только при регулярном обзоре с клиентом и пересмотре целей; бюджет ошибок помогает решать, когда рисковать изменениями, а когда заниматься надёжностью.

Хорошее соглашение об уровне услуг отвечает не на вопрос «кто виноват», а на вопрос «что мы оба считаем нормой и что делаем, когда норма нарушена».

План внедрения SLA

Управление уровнем услуг — корпоративная практика, поэтому план расписан по месяцам.

Соглашение об уровне услуг, которое никто не обсуждает с клиентом, через год описывает уже не услугу, а прошлое.

Месяц 1: требования и каталог услуг

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

• Проведите интервью с клиентами: какие процессы зависят от услуги, какие часы критичны, сколько стоит час простоя, что пользователи считают «услуга не работает».

• Соберите данные за последние 3–6 месяцев: число обращений по категориям, фактические сроки реакции и решения, простои.

Месяц 2: проект соглашения

• Определите приоритеты P1–P4 по матрице «влияние × срочность» с примерами для каждого уровня.

• Для каждого приоритета задайте цели времени реакции и решения, для услуги — цель доступности и допустимый простой; цели проверьте на прошлых данных.

• Опишите методику измерения, исключения и окна обслуживания, обязанности клиента, отчётность и последствия нарушений.

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

Месяц 3: запуск измерений

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

• Добавьте короткий опрос удовлетворённости после закрытия обращения.

• Подпишите соглашение с клиентом на пробный период и договоритесь о дате первого обзора.

Месяцы 4–6: обзоры и корректировка

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

• По каждому серьёзному нарушению проводите разбор причин без поиска виноватых — по методике Blameless Postmortem.

• Скорректируйте цели, которые оказались недостижимыми или слишком лёгкими, и OLA, на которых срываются сроки.

Далее: поддержание и обновление

• Пересматривайте соглашение раз в год и при изменениях в бизнесе клиента или в архитектуре услуги.

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

• Расширяйте набор пользовательских метрик и при зрелости процесса переходите от технических целей к целям опыта (XLA).

Как реализовать этот план с помощью фрейма «Управление уровнем услуг (SLA)» в OrgDevTools

На странице методики работает бесплатный фрейм-тренажёр «Управление уровнем услуг (SLA)». Он не ведёт обращения сам, а помогает проверить уже собранные за период данные: выполняется ли обещанное и почему нет. Фрейм состоит из шести вкладок.

Вкладка «1. Приоритеты» — месяцы 2 и 4–6

Таблица с автоматическим расчётом. Пока вы ничего не внесли, в ней показаны четыре строки P1–P4; названия можно изменить, строки — удалить или добавить кнопкой «+ добавить приоритет». Для каждого приоритета вносятся цель реакции в минутах, цель решения в часах, число обращений за период и число нарушений срока. Колонка «В срок» считается сама: доля обращений без нарушений; число нарушений, превышающее число обращений, приравнивается к нему. Ниже — общий процент обращений в срок по всем приоритетам и рабочий порог фрейма 95%.

Вкладка «2. Доступность» — месяцы 2–3 и далее

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

Вкладка «3. Опыт клиента» — месяцы 3–6

Поле «Довольны обслуживанием, %» — доля положительных оценок после закрытия обращений. Рядом — процент обращений в срок и доля довольных; если в срок 95% и больше, а довольных меньше 80%, появляется предупреждение об «эффекте арбуза». Здесь же список «Что обсуждаем на обзоре услуги».

Вкладка «4. Опоры и исключения» — месяц 2

Два редактируемых списка: «На чём держится SLA» — внутренние соглашения (OLA) и договоры с поставщиками (UC) — и «Исключения и окна обслуживания».

Вкладка «Визуализация»

Горизонтальные полосы выполнения по каждому приоритету с пунктиром на уровне 95% и полоса израсходованного бюджета ошибок: зелёная до 75%, жёлтая от 75%, красная после 100%.

Вкладка «Итоги» — вердикт

Вердикт вычисляется из данных и называет первую найденную проблему в таком порядке: ничего не внесено; у какого-то приоритета нет целей реакции или решения (называется первый); бюджет ошибок исчерпан; у самого слабого приоритета в срок меньше 95% обращений; «эффект арбуза»; израсходовано 75% бюджета ошибок и больше; не внесена доля довольных пользователей; пуст список «На чём держится SLA». Если ничего из этого нет — зелёный вердикт. Ниже — сводка и кнопка создания задачи (после первого сохранения фрейма): разобрать нарушения по слабейшему приоритету или провести обзор услуги.

Чего фрейм не делает

Фрейм не подключается к системе обращений и не считает сроки сам — числа обращений и нарушений вносятся вручную за период. Он не проверяет, что время реакции меньше времени решения, не учитывает рабочие часы и календарь, не считает процентили и не ведёт историю периодов: для сравнения заполните отдельный экземпляр на каждый период. Пороги 95%, 75% и 80% — рабочие настройки фрейма, а не нормы ITIL.

Реальная работа — в инструменте «Сервис деск»

Фрейм — тренажёр для анализа. Настоящие SLA по обращениям ведёт инструмент «Сервис деск» OrgDevTools: откройте «Сервис деск» в левом меню, выберите категорию обращений и перейдите на вкладку «Настройка формы». В блоке «Расширение ITIL — SLA» задаются часы на первый ответ и на полное решение для обращений этой категории; обращения, вышедшие за срок, получают в списке метку SLA, а в карточке — отметку «Просрочен SLA». Блок доступен на тарифе с расширением ITIL.