Перейти к основному содержимому

SLA — соглашение об уровне предоставления услуги

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Руководителю Аналитику Архитектору

SLA (Service Level Agreement — соглашение об уровне предоставления услуги) — официальная договорённость между заказчиком и поставщиком услуги, которая переводит абстрактные ожидания («нужно быстро и надёжно») в измеримые показатели и определяет ответственность сторон. В IT это часть модели ITSM; практические примеры метрик поддержки — в разделе техподдержки, расчёт «девяток» доступности — в уровнях SLA для архитекторов.

Услуга и предоставление услуги​

Услуга (service) — результат деятельности, который ценен для потребителя и обычно не сводится к передаче вещи: получатель не обязан владеть сервером, чтобы пользоваться корпоративной почтой или облачным API.

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

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

В IT одна и та же система часто описывается несколькими услугами разного уровня: «инфраструктура IaaS», «платформа», «прикладной сервис CRM» — у каждой могут быть свои SLA.

Договор, заказчик и поставщик​

Договор (договор) — юридическое соглашение сторон: предмет, срок, цена, ответственность. В проектах на разработку предметом часто является оказание услуг (проектирование, внедрение, сопровождение) или смешанная модель (лицензия + услуги).

РольКто этоВ IT-проекте
Заказчик (customer)Сторона, которая потребляет услугу и платит (или получает услугу по внутреннему SLA)Бизнес-подразделение, госорган, внешний клиент
Поставщик услугиСторона, которая организует предоставление услугиВнутренний ИТ, интегратор, облачный провайдер

SLA может быть приложением к договору или отдельным соглашением между внутренними подразделениями (Internal SLA / OLA — operational level agreement между командами внутри ИТ).

:::tip Различайте роли в команде Заказчик в договорном смысле — не всегда тот же человек, что Product Owner в Scrum: PO представляет продукт, а юридический заказчик подписывает акты и SLA. Путаница ролей — частая причина «устных обещаний», не попадающих в метрики. :::

Качество и стандарт качества​

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

Стандарт качества — зафиксированный набор критериев и порогов (числа, окна времени, исключения). В договоре стандарт качества для ИТ обычно выражают через:

  • перечень услуг и границ ответственности («SLA на ВМ, не на баги приложения»);
  • метрики и способ измерения (мониторинг, тикет-система, отчёты);
  • период отчётности (месяц, квартал);
  • санкции или компенсации при систематическом невыполнении.

Без стандарта споры неизбежны: «быстро» для заказчика — 10 минут, для исполнителя — два рабочих дня.

Что такое SLA и зачем он нужен​

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

Документ помогает:

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

Обзор SLA в контексте Service Desk: Atlassian — SLA в ITSM.

Что обязательно включает SLA​

Хороший SLA для ИТ-услуги обычно содержит следующие блоки.

1. Перечень услуг​

Что именно обязуется делать исполнитель: «поддержка портала 8×5», «хостинг БД 24×7», «реакция на инциденты P1–P4». Важно указать исключения (плановые работы, форс-мажор, зона ответственности клиента).

2. Метрики качества​

Точные числовые показатели. Типичные примеры:

МетрикаСмыслПример цели
Uptime (доступность)Доля времени, когда услуга доступна≥ 99,9% за календарный месяц
Время реакции (response)Первый ответ поддержки или начало работP1 — 15 мин, P2 — 1 ч
Время решения (resolution)Восстановление или обходной путьКритический инцидент — 2 ч
SLA ComplianceДоля обращений, закрытых в срок≥ 95% тикетов в месяц

Цифры в таблице условны — в контракте фиксируют свои, часто в рабочих часах поддержки и с уточнением праздников. См. также SLA в техподдержке.

Для архитектуры и облака те же идеи выражают через SLI (индикатор) и SLO (внутренняя цель команды); SLA — обещание наружу. Разбор: доступность в system design.

3. Санкции и компенсации​

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

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

Санкции привязывают к измеримому отчёту (простой по мониторингу, отчёт из ITSM), а не к субъективной оценке.

4. Процедуры измерения и споры​

  • источник данных (Zabbix, Prometheus, ServiceNow);
  • как учитываются плановые окна обслуживания;
  • как эскалировать спор по метрике.

SLA в жизненном цикле проекта​

ФазаРоль SLA
Тендер / договорЗакладывают NFR и SLA до оценки стоимости «девяток»
РазработкаАрхитектура и тесты должны позволять выполнить обещанную доступность
ПриёмкаПроверяют не только функции, но и согласованные пороги (нагрузка, мониторинг)
ЭксплуатацияИнциденты и изменения ведут в рамках ITSM

При внедрении ERP без SLA на сопровождение после go-live инциденты в production некому закрывать в срок — см. FAQ по ERP.

Типичные ошибки​

  1. SLA без перечня услуг — спор, входит ли «настройка отчёта» в поддержку или это новый проект.
  2. Только uptime, без времени реакции — сервис «формально доступен», но пользователи часами ждут ответа.
  3. Обещание 99,99% без архитектуры — невыполнимый договор или переплата; см. уровни и простой.
  4. Устные дедлайны вне тикета — ломают метрики и доверие; см. FAQ техподдержки.

Смежные материалы​

См. также

Другие статьи этого же раздела в боковом меню (как на странице "О разделе").

Содержание
Освоение главы0%