site_logo

SLA

2 февраля 2024

обновлено: 24 августа 2026

Коротко о главном:
  • SLA (Service Level Agreement) — это соглашение об уровне сервиса. Документ, который переводит абстрактные обещания («сделаем быстро») в жесткие измеримые параметры («время реакции — 15 минут, аптайм — 99.9%»);
  • главная задача SLA — синхронизировать ожидания заказчика с реальными возможностями исполнителя и зафиксировать ответственность сторон (штрафы за просрочки);
  • SLA применяется как во внешних контрактах (с подрядчиками, облачными провайдерами), так и во внутренних процессах компании (между ИТ-отделом и бизнесом, бухгалтерией и продажами);
  • чтобы SLA работало, оно должно измеряться автоматически в Service Desk системах.

Что такое SLA

SLA (от англ. Service Level Agreement)

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

important1

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

SLA фиксирует договоренность между поставщиком услуги и ее получателем:

  • поставщик: ИТ-департамент, аутсорсинговая компания, провайдер облачных услуг, служба АХО;
  • получатель: бизнес-подразделение, корпоративный клиент, обычный пользователь.

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

Виды SLA

В практике сервисного обслуживания выделяют три основных вида SLA в IT:

  1. SLA, ориентированный на услугу (Service-based SLA). Универсальное соглашение для всех пользователей конкретной услуги. Например, SLA на работу корпоративной почты: правила едины как для менеджера, так и для генерального директора.
  2. SLA, ориентированный на клиента (Customer-based SLA). Соглашение, в котором прописаны все услуги, предоставляемые конкретному клиенту (или отделу). Например, VIP-клиент получает более жесткие сроки реакции на инциденты, чем пользователи базового тарифа.
  3. Многоуровневый SLA (Multi-level SLA). Сложный формат, разделенный на уровни. Например: корпоративный уровень (общие правила для всех сотрудников), уровень клиента (дополнительные гарантии для конкретного департамента) и уровень услуги (особые метрики для критичной ERP-системы).

Виды SLA

SLA, OLA и UC: в чем разница

В методологии ITIL (библиотека инфраструктуры ИТ) рядом с Service Level Agreement всегда идут еще два типа договоренностей. Они работают в связке, закрывая всю цепочку ответственности.

  • SLA (Service Level Agreement) — договор между ИТ и Бизнесом (или Провайдером и Клиентом). Клиента волнует только итоговый результат, прописанный в этом документе;
  • OLA (Operational Level Agreement) — соглашение операционного уровня между подразделениями внутри компании исполнителя. Например, первая линия поддержки обязана передать сложный инцидент на вторую линию за 15 минут, а вторая линия должна дать ответ за час. Клиент этот документ не видит, но без соблюдения OLA исполнитель не сможет выполнить SLA;
  • UC (Underpinning Contract) — контракт с внешним поставщиком или субподрядчиком. Например, SLA гарантирует клиенту работу сервера. Но сам сервер куплен у дата-центра по контракту UC. Условия UC должны быть не слабее, чем условия SLA.

image1

Зачем нужно SLA-соглашение

Внедрение соглашения об уровне сервиса решает сразу несколько критических бизнес-задач:

  1. Управление ожиданиями. SLA четко фиксирует, что именно является нормой, исключая завышенные требования.
  2. Объективная оценка качества. Когда есть SLA, спор «вы работаете медленно» переходит в конструктивное русло: «в этом месяце вы нарушили срок реакции по 15 заявкам из 100».
  3. Приоритизация задач. Операторы техподдержки понимают, за какую заявку хвататься в первую очередь. Упавший сервер (критичный приоритет по SLA) будет чиниться раньше, чем сломанный принтер (низкий приоритет).
  4. Снижение рисков. Штрафные санкции, прописанные в SLA, стимулируют исполнителя поддерживать инфраструктуру в рабочем состоянии.
«SLA — это не просто набор таймеров и штрафов. Это прежде всего инструмент управления ожиданиями. Когда бизнес четко понимает, за что он платит, а ИТ-команда видит, какие именно действия создают ценность для компании, отношения переходят из плоскости конфликта в плоскость партнерства. Автоматизация в этом процессе играет роль арбитра: она делает это партнерство прозрачным и предсказуемым для обеих сторон»

Андрей Вишняков
Андрей Вишняков

Директор по бизнес-продуктам компании SimpleOne, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ.

Кто заключает SLA

Исторически термин пришел из ИТ-отрасли (стандарты ITIL/ITSM), но сегодня соглашение об уровне обслуживания используется везде, где есть внутренний или внешний сервис:

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

Структура SLA: из чего состоит соглашение

Грамотно составленный документ не должен оставлять места для двояких трактовок. Стандартная структура SLA включает:

  1. Определение услуги. Что конкретно предоставляется? Подробное описание сервиса (например, «Поддержка рабочих мест»).
  2. Время предоставления услуги. Когда услуга доступна? (например, 24/7 или 5/2 с 9:00 до 18:00).
  3. Матрица инцидентов и приоритетов. Как классифицируются обращения (от «Критического» до «Низкого»).
  4. Целевые метрики. Конкретные цифры: время реакции, время решения, процент доступности.
  5. Ответственность сторон. Что должен делать заказчик (например, своевременно предоставлять доступы) и исполнитель.
  6. Санкции и бонусы. Штрафы за нарушение метрик (обычно в виде процента от стоимости услуг) и, реже, премии за их превышение.
  7. Порядок отчетности и пересмотра. Как часто формируются отчеты по SLA и при каких условиях документ может быть изменен.

Основные метрики и показатели уровня сервиса

Для контроля качества используют метрики SLA. Чаще всего это:

  • время реакции (Response Time): время с момента подачи заявки до момента, когда оператор взял её в работу (или ответил клиенту);
  • время решения (Resolution Time): время от создания заявки до полного устранения проблемы;
  • MTTR (Mean Time to Recovery/Resolve): среднее время восстановления работоспособности после сбоя;
  • уровень доступности (Uptime/Availability): процент времени, когда сервис полностью работоспособен (знаменитые «девятки», например, 99.99%);
  • FCR (First Contact Resolution): доля заявок, которые оператор решил при первом же обращении, без передачи на другие линии.

Как составить SLA-соглашение: пошаговая инструкция

Написать SLA, который будет работать, а не лежать «в столе», можно за пять шагов.

Шаг 1. Определите каталог услуг. Составьте исчерпывающий список того, что вы делаете. Не пишите «Обеспечение работы ИТ», пишите «Поддержка корпоративной почты», «Ремонт ПК».

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

Шаг 3. Задайте реалистичные метрики. Не ставьте время реакции в 5 минут, если в смене один инженер. Опирайтесь на исторические данные. Метрики должны быть измеримыми и достижимыми.

Шаг 4. Согласуйте ответственность. Обсудите с бизнесом или клиентом штрафные санкции. Они должны быть адекватны стоимости услуги.

Шаг 5. Заведите правила в Service Desk. SLA бесполезен, если за ним следит человек с секундомером. Все метрики должны автоматически отслеживаться в вашей ИТ-системе.

Как контролировать соблюдение SLA

Следить за выполнением SLA вручную (в Excel или почте) — путь к ошибкам и конфликтам с заказчиком. Для автоматизации этого процесса используются Service Desk системы, где практика Service Level Management (SLM) встроена в архитектуру.

В системах управления услугами (например, в SimpleOne ITSM) контроль показателей происходит автоматически:

  • гибкие Индикаторы. Система не просто запускает таймер. В ней настраиваются четкие условия: когда счетчик времени должен запуститься, когда встать на паузу (например, при ожидании ответа от пользователя) и когда остановиться;
Визуализация жизненного цикла заявки: автоматический контроль времени реакции, учет пауз и фиксация итогового времени решения
Визуализация жизненного цикла заявки: автоматический контроль времени реакции, учет пауз и фиксация итогового времени решения
  • визуализация через виджеты. Оператору не нужно держать в голове сроки. Специальный виджет прямо в карточке заявки в реальном времени показывает обратный отсчет до истечения срока по целевым метрикам (SLO — Service Level Objectives);
  • автоматические действия и эскалации. Если время реакции или решения подходит к критической отметке (угроза SLA Breach), система может автоматически поменять приоритет заявки, поднять ее вверх списка или отправить уведомление руководителю смены для оперативного вмешательства;
  • единая база контрактов. Все утвержденные требования и договоренности (SLA, OLA, внешние контракты UC) хранятся в системе и жестко связаны с конкретными услугами из Сервисного портфеля. Это исключает споры: в конце месяца платформа генерирует прозрачные отчеты по каждому клиенту, опираясь на железобетонные системные логи;
  • светофорные сбалансированные карты показателей — это инструмент платформы SimpleOne для визуального управления KPI и метриками. Позволяет формировать сводные дашборды с цветовой индикацией достигнутых значений и быстро выявлять отклонения.
Светофорные карты в SimpleOne
Светофорные карты в SimpleOne

Ошибки при внедрении SLA

  1. SLA ради SLA. Соглашение написано сложным юридическим языком, спрятано в дальний ящик, а техподдержка работает «как получится».
  2. Нереалистичные показатели (Watermelon SLA). Исполнитель пообещал аптайм 99.99% и решение инцидентов за 10 минут, не имея нужного штата и архитектуры. В отчетах всё «зеленое» (арбуз снаружи), а клиенты в бешенстве (арбуз красный внутри).
  3. Метрики, оторванные от бизнеса. В SLA прописана «доступность сервера», но не прописана «доступность биллинга». Сервер работает, а клиенты платить не могут. Бизнесу не важен сервер, ему нужна услуга.
  4. Забыты OLA и UC. Вы пообещали решить проблему клиента за 2 часа (SLA), но ваш внешний вендор по договору меняет сломанный жесткий диск только через 24 часа (UC). Вы неизбежно сорвете сроки.

Резюме

Что такое SLA? Это гарант предсказуемости в отношениях между заказчиком и исполнителем.

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

FAQ