SLA — соглашение об уровне услуг: расшифровка и примеры

Что это значит на практике

SLA — сокращение от английского service level agreement, по-русски чаще всего «соглашение об уровне услуг». Это документ — отдельный или часть договора, — в котором поставщик услуги и её заказчик записали, чего от услуги ждать: что она делает, в какие часы она доступна, за сколько её восстановят после сбоя. Записано числом — значит, можно проверить: спор о том, хорошо ли работает ИТ, превращается в сверку с тем, что записано. В разговоре словом «SLA» часто называют и счётчик в заявке пользователя — сколько осталось до срока ответа или восстановления. Это одно из условий соглашения, а не оно само.

Как расшифровывается SLA

Три слова, и все три важны.

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

ITIL 4 определяет SLA как документированную договорённость поставщика и заказчика, в которой названы нужные заказчику услуги и ожидаемый от них уровень. ГОСТ Р ИСО/МЭК 20000-1-2021, национальный стандарт по управлению ИТ-услугами, в пункте 3.2.20 говорит почти теми же словами: «документированное соглашение между организацией и потребителем, которое определяет сервисы и их согласованное функционирование» — сервисом ГОСТ называет услугу. Для самих обещаний у ГОСТ есть отдельный термин (пункт 3.2.21): целевой показатель уровня сервиса — измеримая характеристика услуги, которой организация обязуется соответствовать. FitSM, бесплатный стандарт управления ИТ-услугами, в словаре FitSM-0 складывает то же самое в одну фразу: SLA — документированное соглашение заказчика и поставщика, где названа услуга и целевые показатели, по которым её будут оказывать.

«Документированное» не значит «оформленное отдельным договором с подписями». Примечание к пункту 8.3.3 ГОСТ допускает, что соглашение может иметь форму протокола совещания или электронного письма, а примечание к пункту 3.2.20 — что SLA может входить в контракт как его часть. Первое примечание к тому же пункту добавляет, что соглашение бывает не только с заказчиком: его заключают и с внешним поставщиком, и с подразделением внутри организации.

Единого русского названия у термина нет. ГОСТ пишет «соглашение об уровне сервисов», русский глоссарий MOF 4.0 — свода Microsoft об эксплуатации ИТ — «соглашение об уровне обслуживания», мы — «соглашение об уровне услуг». А сокращение не переводят: даже в тексте ГОСТ стоит латинское SLA.

Из чего состоит соглашение

ГОСТ Р ИСО/МЭК 20000-1-2021 в пункте 8.3.3 задаёт обязательный минимум из трёх частей: цели уровня сервисов, предельная рабочая нагрузка и исключения. Цели — сами обещания в проверяемом виде: «кассовая система доступна в рабочие часы магазина», «после критичного сбоя услугу восстанавливают за час». Предельная нагрузка — при каком числе пользователей или операций эти цели действуют; без неё поставщик формально обязан держать те же обещания и при десятикратном росте, о котором никто не договаривался. Исключения — случаи, на которые обещание не распространяется: плановые работы, сбой у внешнего провайдера связи.

Как это выглядит на бумаге, показывает бесплатный шаблон SLA из FitSM-4 — части стандарта FitSM с шаблонами и образцами документов. Разделы в нём такие:

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

Список длинный, и шаблон сам оговаривает: заполнять надо только то, что относится к делу. Ами Нахари в книге «Secrets of Service Level Management» (издательство TSO, 2013) смотрит на состав иначе — у хорошего SLA четыре главные части, и каждая отвечает на свой вопрос. Описание услуги — что поставщик предоставляет. Цели — какого уровня. Способ расчёта — как это измеряют. Последствия — что будет за нарушение и что за перевыполнение. Нахари советует строить документ из двух частей: общая — часы работы, правила расчёта, таблица исключений, одинаковые для всех услуг, — и отдельные части по каждой услуге с её целями. Тогда при добавлении услуги общую половину не переписывают.

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

По каким сторонам качества ставят цели

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

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

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

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

Четыре требования к соглашению, которое работает

Книга ITIL 4 Foundation называет четыре требования к соглашению, которое будет работать, а не лежать в папке. Оно привязано к услуге из каталога — иначе это, словами ITIL, набор показателей без цели. Оно описывает результат для заказчика, а не только технические показатели работы ИТ. Оно и правда согласовано: условия обсудили с заказчиком, пользователями и партнёрами, а не спустили сверху. И написано просто, чтобы каждая сторона понимала его без переводчика.

Второе требование ITIL поясняет примером. Доступность 99,6 % выглядит отлично, но допустимый простой может выпасть на тот час, когда работают кассы или идёт операция в клинике. Тогда заказчик недоволен при выполненном соглашении. ITIL называет это эффектом арбуза: как у арбуза, снаружи — в отчёте — всё зелёное, а внутри красное.

Лекарство от арбуза руководство ITIL 4 по управлению уровнем услуг называет прямо: записанный уровень всегда покрывает только часть качества, поэтому рядом с показателями собирают отзывы пользователей и заказчика. Соглашение, в котором есть проценты и нет ни слова о том, как узнать мнение людей, наполовину слепое.

Как формулируют условия

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

Доступность записывают процентом, и процент стоит перевести в часы, чтобы понять, о чём договорились. В образце корпоративного SLA из комплекта FitSM-4 цель 99,5 % в год для круглосуточной услуги, 8 760 часов работы, означает не больше 43 часов недоступности за год. Там же оговорено: плановые и объявленные заранее перерывы недоступностью не считаются, потому что не входят в часы обслуживания, от которых доступность считают. Примечание к пункту 3.2.16 ГОСТ Р ИСО/МЭК 20000-1 считает доступность так же — как долю согласованного, а не календарного времени. Отсюда первый вопрос к любому проценту: от какого времени он посчитан.

Сроки по сбоям зависят от того, насколько услуга важна. В том же образце FitSM услуги разделены на три класса критичности. Для самых важных поддержка круглосуточная, а восстановление быстрее четырёх часов. Для средних поддержка в рабочие часы, восстановление — в течение рабочего дня. Для остальных восстановление зависит от приоритета инцидента и занимает до трёх рабочих дней. Отдельно записан срок реакции: на обычное обращение — до двух часов в часы поддержки, на критичный инцидент, о котором сообщили по особому аварийному каналу, — до двадцати минут. Это образец, а не норма: числа в вашем соглашении будут свои. Важно в нём другое — для инцидента записаны два срока, реакции и восстановления, и записаны отдельно.

И последнее про слова. Книга ITIL 4 Foundation настаивает, чтобы соглашение было написано просто; Нахари добавляет, что юридический язык здесь не нужен, а вот словарь терминов в конце — нужен, чтобы «инцидент», «рабочие часы» и «восстановление» обе стороны понимали одинаково. В шаблоне FitSM словарь стоит отдельным разделом.

Три соглашения: SLA, OLA и UC

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

SLA заключают поставщик и заказчик: какой уровень услуги получает заказчик.

OLA — соглашение операционного уровня (operational level agreement). Его заключают поставщик и его внутренние группы: кто и в какой срок делает свою часть работы, чтобы обещание заказчику было выполнено. FitSM-0 определяет OLA как документированное соглашение поставщика с внутренним поставщиком — группой той же организации — о поддерживающих услугах или частях услуги и их рабочих целях. Русский глоссарий MOF 4.0 говорит короче: внутреннее соглашение между группами ИТ-специалистов, которые обеспечивают выполнение требований, записанных в SLA.

UC — договор с внешним поставщиком (underpinning contract). Его заключают поставщик и подрядчик: без обязательств подрядчика поставщик не выполнит обещание заказчику. FitSM называет этот документ underpinning agreement, «обеспечивающее соглашение», разрешает сокращать его как UC и поясняет: это SLA с внешним поставщиком, в котором поставщик основной услуги сам выступает заказчиком. MOF добавляет то, чего нет у двух первых документов: договор с внешним поставщиком имеет юридическую силу.

ГОСТ Р ИСО/МЭК 20000-1 в пункте 7.5.4 относит все три документа к обязательной документации системы управления услугами — стандарт называет её системой менеджмента сервисов. В перечне это соглашения об уровне сервисов, договоры с внешними поставщиками и соглашения с внутренними поставщиками. В пункте 8.3.4 стандарт требует, чтобы договор с внешним поставщиком включал цели уровня сервисов, и обязывает организацию проверять, сходятся ли целевые показатели подрядчика с тем, что обещано заказчику. FitSM-1 в требованиях PR2.4 и PR2.5 просит того же: для поддерживающих услуг заключать OLA и UC по мере необходимости, пересматривать их в плановые сроки и сверять показатели подрядчиков с записанными целями.

Пример, на котором это видно. Заказчику обещали восстановить услугу за час после регистрации обращения. Без запасной части сервер не вернуть в работу, а внешний поставщик по договору везёт её два дня. Обещание не обеспечено, и первый же серьёзный сбой покажет, что срок восстановления не выдержать. «Свободный ITIL» — бесплатный русский пересказ ITIL, который написал Елхимов, — поэтому советует пересматривать операционные соглашения до подписания нового SLA или пересмотра действующего. А в справочнике метрик Питера Брукса «Метрики для управления ИТ-услугами» число ещё не согласованных OLA и UC стоит отдельным показателем практики.

Соглашение под заказчика и «из коробки»

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

Услуга под заказчика. Цели обсуждают до начала работы, и на каждом шаге круг будущих обязательств сужается. Заказчик описывает ожидания — а это лишь часть потребностей его организации. Стороны договариваются о требованиях — круг сужается. Поставщик описывает уровень, за который готов отвечать, — круг сужается ещё раз. То, что осталось, и попадает в SLA.

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

FitSM-2 предлагает практичный порядок для тех, кто начинает: сначала оформить одно базовое SLA для всех услуг, по которым нет отдельных договорённостей, потом подготовить отдельные соглашения для самых важных услуг. Образец такого базового документа в FitSM-4 называется корпоративным SLA: общие условия по всем услугам из каталога, которые позже можно заменить более точными.

Как делить условия между соглашениями, когда услуг и заказчиков много, разбирает «Свободный ITIL». Можно взять одну услугу и описать её для всех, кто ею пользуется: просто, но разным группам порой нужны разные условия. Можно пойти от заказчика и собрать все услуги его подразделения в один документ: ему удобно, поставщику тяжелее. Третий способ — три этажа: общие условия для организации, условия для подразделения, условия для конкретной услуги. Такой порядок избавляет от переписывания одних и тех же условий в каждом документе. ГОСТ Р ИСО/МЭК 20000-1 способ не предписывает: пункт 8.3.3 говорит об одном или нескольких SLA по каждой услуге.

Что бывает за нарушение SLA

Своды знаний о штрафах молчат, и это не пробел. ГОСТ Р ИСО/МЭК 20000-1 в пункте 8.3.3 требует одного: если цели не достигнуты, найти возможности для улучшения. FitSM-2 добавляет обязанность уведомить заказчика о нарушении, а шаблон SLA из FitSM-4 отводит под правила такого оповещения отдельный раздел. Руководство ITIL 4 по управлению уровнем услуг замечает, что формальную ответственность поставщика обычно ограничивают согласованным уровнем, а не ожиданиями заказчика. И тут же предупреждает: отношения на этом не держатся, держатся они на том, довольны ли люди.

Внутри одной организации штрафы работают плохо. Книга itSMF «Введение в ИТ Сервис-менеджмент» в русском издании 2003 года разбирает этот спор прямо. Когда ИТ-подразделение и пользователи работают на одни и те же цели компании, санкции и тем более денежные штрафы вряд ли отвечают интересам компании. Разумнее договориться о совместных мерах против сбоев. Санкции возможны в договоре с внешним поставщиком — и тогда, пишет книга, нужен юридически обязывающий договор, а не соглашение об уровне сервиса. MOF 4.0 разводит документы так же: соглашение операционного уровня — внутренняя договорённость, договор с внешним поставщиком — документ с юридической силой.

С внешним подрядчиком штраф — распространённое условие. Учебник «Аутсорсинг в стратегии современного бизнеса» (Питер, 2019) описывает договор аутсорсинга так: общие положения в основном тексте, а по каждой услуге — приложение с параметрами, стоимостью и ответственностью поставщика в виде штрафов или пеней. Раздел договора с параметрами услуги там и называют SLA. Учебник советует на переходный период, пока подрядчик осваивается, записывать более мягкие условия без штрафов и включать полные требования позже.

Учебное пособие Молотковой и Сахарова «Качество услуг ИТ-аутсорсинга» (ТГТУ, 2008) приводит самый наглядный пример SLA — обещание доставки за тридцать минут, иначе заказ отдают бесплатно: здесь есть услуга, показатель и последствие нарушения. И там же трезвая оговорка: штраф — слабое утешение, если бизнес простоял день, а взыскать такой штраф без суда бывает трудно. Соглашение стоит строить так, чтобы поставщику было выгодно работать хорошо, а не так, чтобы заказчику было чем его наказать.

Ами Нахари в «Secrets of Service Level Management» называет три способа связать деньги с уровнем услуги: штраф за недостигнутую цель, возврат штрафа, если поставщик исправился, и премия за перевыполнение. Про премию он же предупреждает: одна служба экстренной помощи обнаружила, что подрядчик сам создавал фиктивные обращения — «призрачные звонки», — чтобы получать премию за их обработку. Про штрафы — что слишком жёсткие санкции превращают ежемесячный обзор услуги — встречу сторон по итогам отчёта — в спор юристов, и качеством услуги в этой комнате уже никто не занят. Штраф, по Нахари, должен влиять на поведение исполнителя, а не запускать судебную тяжбу.

Обычная форма компенсации — вычет из платы. В статье альманаха itSMF России за 2015 год разобраны два облачных соглашения того времени. У российского провайдера — вычет пяти процентов стоимости услуг за каждые полные полчаса недоступности, но не больше ста процентов за период. У Microsoft Azure компенсация ни при каких обстоятельствах не превышает месячной платы. Автор статьи делает из этого вывод, который годится для любого SLA: компенсация возвращает часть платы за услугу, а не убытки бизнеса от простоя. Переложить риски простоя на поставщика одним штрафом нельзя — заказчику надо оценивать и снижать их самому.

Отсюда правило. Штраф — не признак хорошего соглашения и не его обязательная часть. Признак хорошего соглашения — нарушение видно в отчёте, о нём узнаёт заказчик, и нарушение разбирают на обзоре. Число нарушений SLA и число случаев, когда SLA был под угрозой нарушения, Брукс держит первыми метриками практики.

Что ещё называют словом SLA

В системе поддержки у каждого обращения тикает срок: «до нарушения SLA осталось полчаса». Это одно из условий соглашения — срок по обращению такого типа и приоритета, а не соглашение целиком. У Брукса нарушением SLA считается всё, что вышло за согласованные рамки: не только просроченный инцидент, но и любой другой показатель из соглашения.

Пункт 8.3.3 ГОСТ Р ИСО/МЭК 20000-1 допускает для одной услуги одно или несколько SLA — например, отдельные для разных групп пользователей. Так что «наш SLA» в единственном числе часто означает одно условие из соглашения, а не документ целиком.

Ещё две путаницы — с SLO, целью уровня обслуживания, и с требованием сервиса — разбираем ниже, в разделе «Чем отличается».

→ Сроки и эскалация в управлении инцидентами. Какие два срока стоят в договорённости по инциденту — реакции и восстановления — и почему отчёт любит первый.

Где соглашения ломаются

Шесть мест, и у каждого есть своё требование в сводах.

Подписали и забыли. Цели не пересматривали с момента внедрения, а услуга за это время изменилась дважды. FitSM-1 требует пересматривать SLA в заранее назначенные сроки, ГОСТ Р ИСО/МЭК 20000-1 требует в запланированные сроки отслеживать показатели и отчитываться по ним, у ITIL обзор с заказчиком — отдельный шаг, по расписанию или после события. Молоткова и Сахаров называют «заключить и забыть» главной причиной неудач с SLA у предприятий.

В соглашении только проценты доступности. О том, что услуга должна уметь, нет ни строки: из семи сторон качества, перечисленных выше по руководству ITIL 4, учтена одна.

Обещали больше, чем обеспечивают внутренние договорённости. Соглашение с заказчиком есть, а операционных соглашений и договоров с подрядчиками для его выполнения нет; FitSM-1 требует их заключать, ГОСТ — сверять целевые показатели подрядчика с SLA.

Отчёт вместо разговора. Цифры рассылаются, обзоры не проводятся. Руководство ITIL 4 связывает качество обзора с качеством услуги и удовлетворённостью напрямую.

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

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

И одно место, самое обидное, которое в сводах не описано. Требование «решать 95 % обращений в срок» часто выполняют не ускорением работы, а переклассификацией: инциденты начинают регистрировать как запросы на обслуживание, где срок длиннее. Цифра в отчёте растёт, услуга не меняется. Заметить подмену помогает второй показатель рядом с процентом — удовлетворённость пользователей: если сроки соблюдены, а люди недовольны, это повод проверить, не подменили ли что-то.

Как SLA живёт после подписания

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

Следующий шаг — обзор: встреча или другая форма разговора, где стороны смотрят на отчёт и решают, что менять: цели, условия или саму услугу. ITIL даёт редкую для себя конкретику по частоте: обзоры реже раза в три месяца работают плохо, а чаще раза в месяц обычно не проводятся. Внеплановый обзор собирают после крупного сбоя, при заметном изменении услуги или когда изменились потребности заказчика. ГОСТ Р ИСО/МЭК 20000-1 в пункте 8.3.3 требует в запланированные сроки отслеживать и показатели, и фактическую нагрузку в сравнении с предельной нагрузкой из SLA.

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

У соглашения есть и конец: когда услуга больше не нужна, по руководству ITIL 4 SLA отзывают, а FitSM-2 среди действий практики отдельно называет прекращение соглашения. Это тоже работа: предупредить пользователей и отменить или изменить внутренние соглашения, заключённые ради этой услуги.

Как это выглядит в жизни

Как правильно и как не надо

Как написать своё первое SLA

Порядок основан на требованиях, разобранных выше; числа в примере условные.

Сначала услуга. Возьмите её из каталога услуг и назовите так, как её называют пользователи: «кассовая система», а не «сервер БД № 4». Без этого шага, напоминает ITIL 4 Foundation, получится набор показателей без цели.

Потом требования. Спросите тех, кто услугой пользуется, чем хороший день отличается от плохого и в какие часы сбой обходится дороже всего — книга ITIL 4 Foundation советует начинать именно с таких вопросов. Из ответов складываются требования к уровню услуги; из них выбирают то, что поставщик готов гарантировать.

Дальше три обязательные части по ГОСТ Р ИСО/МЭК 20000-1: цели с числами, предельная нагрузка, исключения. К каждому числу — правило расчёта: от какого времени считается доступность, с какого момента идёт срок восстановления и кто фиксирует его конец.

Скелет документа можно не придумывать: шаблон SLA из FitSM-4 бесплатный, его разделы перечислены выше. Если услуг много, а различий между заказчиками мало, FitSM советует начать с одного корпоративного SLA на все услуги и заменять его отдельными по мере надобности.

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

Напишите соглашение простым языком и приложите словарь терминов. Затем назначьте пилотный период и дату пересмотра — и то и другое прямо в тексте.

Как надо. «Кассовая система магазинов сети. Часы обслуживания: с 8:00 до 23:00 ежедневно. Критичный сбой — остановка продаж хотя бы в одном магазине: реакция службы поддержки в течение 15 минут, восстановление в течение часа; оба срока считаются от регистрации обращения: реакция — до ответа службы поддержки, восстановление — до подтверждения магазином, что продажи идут. Плановые работы — по воскресеньям с 2:00 до 5:00, в расчёт недоступности не входят. Условия действуют при нагрузке до 120 одновременно работающих касс. Пилотный период — три месяца, пересмотр — раз в полгода.»

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

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

Чем отличается от цели уровня обслуживания (SLO)

SLA — договорённость с заказчиком, записанная и им принятая: что даёт услуга и какой уровень услуги получает заказчик. SLO (service level objective), цель уровня обслуживания, — целевое значение одного показателя, которое команда ставит себе сама, например по доле успешных запросов за месяц; заказчик под ним не подписывается, это ориентир для самой команды. Слово пришло из инженерии надёжности (SRE, site reliability engineering), где от SLO считают допустимую долю отказов за период. Из SLO может вырасти условие SLA — когда о нём договорились с заказчиком и записали.

Разбор соседнего термина — цель уровня обслуживания.

Чем отличается от требования сервиса (SLR)

Требование — то, чего заказчик хочет от услуги; его собирают до соглашения, по-английски service level requirement, SLR. SLA — то, о чём договорились и за что поставщик готов отвечать. Руководство ITIL 4 показывает, как предмет сужается на каждом шаге: ожидания шире требований, требования шире записанного уровня. Брукс измеряет расстояние между ними временем: сколько дней проходит от первых записанных требований до подписанного SLA.

Разбор соседнего термина — требование сервиса.

Где встречается

Практики справочника, рядом с которыми живёт этот термин:

Своды знаний, в которых этот термин определён:

Что с этим делать здесь

Откуда термин

ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами». Формулировка на этой странице своя.

Термины рядом