SLA, или Service Level Agreement, — это соглашение об уровне обслуживания, в котором заказчик и поставщик фиксируют измеримые параметры качества услуги. В документе могут быть указаны доступность сервиса, время реакции технической поддержки, сроки устранения инцидентов, порядок эскалации, ответственность сторон и правила расчета показателей.
SLA широко используется в облачных сервисах, дата-центрах, технической поддержке, аутсорсинге, телекоммуникациях, SaaS, хостинге и корпоративной ИТ-инфраструктуре. Его главная задача — превратить общие обещания вроде высокой надежности или быстрой поддержки в конкретные показатели, которые можно измерить.
Например, провайдер может обязаться обеспечивать доступность сервиса не ниже 99,9 процента в месяц и начинать обработку критичного инцидента не позднее чем через 15 минут после регистрации обращения.
Что такое SLA простыми словами
SLA можно представить как договоренность о том, насколько хорошо должна работать услуга и что произойдет, если установленный уровень не будет достигнут.
Фраза сервис работает стабильно слишком расплывчата. Непонятно, сколько простоев допустимо и как измерять стабильность. SLA заменяет такие формулировки конкретными параметрами.
SLA отвечает на вопрос не просто что предоставляет поставщик, а с каким измеримым уровнем качества он обязан это делать.
Например, для корпоративного облачного сервера можно определить доступность 99,95 процента, круглосуточную поддержку и время реакции на критичную аварию до 10 минут.
Для чего нужен SLA
SLA помогает синхронизировать ожидания заказчика и поставщика. Без формальных критериев обе стороны могут по-разному понимать выражения быстро, надежно или круглосуточно.
- фиксирует измеримые показатели качества;
- определяет зоны ответственности;
- устанавливает приоритеты обращений;
- задает время реакции и восстановления;
- описывает порядок эскалации;
- определяет правила измерения доступности;
- фиксирует исключения;
- описывает компенсации при нарушении условий;
- позволяет сравнивать поставщиков по одинаковым критериям.
Для бизнеса SLA также является инструментом управления рисками. Компания заранее понимает, какой уровень простоя считается допустимым и насколько быстро поставщик должен реагировать на проблему.
Какие показатели входят в SLA
Содержание SLA зависит от типа услуги. Для облачного сервера важны доступность и восстановление, для Service Desk — время реакции на заявку, для сети — доступность канала и задержка.
| Показатель | Что означает |
|---|---|
| Доступность | Доля времени, когда услуга доступна пользователю |
| Время реакции | Сколько времени проходит до начала обработки обращения |
| Время восстановления | Срок, за который должна быть восстановлена работа сервиса |
| Время решения | Срок полного устранения причины или выполнения заявки |
| Режим поддержки | Часы, в которые работает техническая поддержка |
| Приоритет инцидента | Категория проблемы, определяющая срочность обработки |
| Плановые работы | Правила проведения обслуживания и уведомления клиента |
| Компенсация | Последствия нарушения согласованных показателей |
Что такое доступность в SLA
Доступность показывает, какую долю времени сервис должен работать в течение расчетного периода. Обычно показатель выражается в процентах.
Например, доступность 99,9 процента означает, что за расчетный период допускается определенное ограниченное время недоступности. Однако сам процент недостаточен для оценки качества SLA.
Необходимо понимать, что именно считается недоступностью, какой период используется для расчета, исключаются ли плановые работы и как фиксируется начало инцидента.
| Доступность | Ориентировочно допустимый простой за 30 дней |
|---|---|
| 99 процентов | Около 7 часов 12 минут |
| 99,5 процента | Около 3 часов 36 минут |
| 99,9 процента | Около 43 минут |
| 99,95 процента | Около 22 минут |
| 99,99 процента | Около 4 минут |
Эти значения являются ориентировочными. Фактический расчет зависит от методики, закрепленной в конкретном SLA.
Как рассчитывается доступность
В простейшем случае доступность определяется как отношение времени нормальной работы услуги к общему времени расчетного периода.
Доступность = Время работы / Общее время периода × 100 процентов
Например, если за месяц услуга была недоступна 30 минут, это время вычитается из общего периода и используется при расчете показателя.
Однако реальные SLA часто содержат исключения. Из расчета могут исключаться согласованные плановые работы, аварии на стороне клиента или обстоятельства, которые находятся вне зоны ответственности поставщика.
Почему одинаковый процент SLA может означать разное
Два провайдера могут заявлять одинаковую доступность 99,9 процента, но фактические условия будут различаться.
У первого недоступность считается с момента автоматического мониторинга. У второго — только с момента регистрации клиентом обращения. Один включает в расчет все технические работы, другой исключает их.
Поэтому сравнивать SLA только по проценту доступности некорректно.
Что такое время реакции
Время реакции показывает, насколько быстро поставщик должен начать обработку обращения после его регистрации.
Реакция не означает, что проблема уже решена. Это подтверждение, что инцидент принят в работу и начата диагностика.
Например, SLA может устанавливать время реакции на критичный инцидент до 15 минут, а на обычный запрос пользователя — до четырех рабочих часов.
Что такое время восстановления
Время восстановления показывает, за какой срок поставщик должен вернуть сервис в рабочее состояние после инцидента.
Это может отличаться от времени полного решения проблемы. Например, поврежденный компонент временно обходят резервной схемой и сервис возвращается в работу за час. Поиск первопричины и окончательное исправление могут занять значительно больше времени.
Для бизнеса время восстановления часто важнее времени полного устранения причины, поскольку напрямую влияет на продолжительность простоя.
Приоритеты инцидентов
Не все обращения имеют одинаковую важность. Если у одного пользователя не открывается отдельный отчет, это не то же самое, что полная недоступность информационной системы для всей компании.
Поэтому SLA обычно разделяет инциденты по уровням критичности.
| Приоритет | Пример | Типичная логика |
|---|---|---|
| Критический | Полная остановка ключевого сервиса | Максимально быстрое реагирование |
| Высокий | Серьезное нарушение работы части пользователей | Ускоренная обработка |
| Средний | Есть проблема, но работа продолжается | Стандартная обработка |
| Низкий | Консультация или некритичное изменение | Обработка в обычном порядке |
Важно, чтобы критерии приоритетов были описаны объективно. Иначе клиент может считать любой инцидент критическим, а поставщик — стремиться снизить приоритет.
SLA и техническая поддержка
В службе поддержки SLA часто определяет, насколько быстро сотрудники должны отвечать на обращения и решать их.
Например, условия могут отличаться в зависимости от тарифа. Базовая поддержка работает только в рабочее время, а расширенная — круглосуточно.
Следует отдельно учитывать рабочие часы. Если SLA устанавливает реакцию в течение двух рабочих часов, обращение, зарегистрированное поздно вечером, может начать отсчитываться только утром следующего рабочего дня.
Что означает поддержка 24 на 7
Формулировка 24 на 7 означает круглосуточную доступность определенной функции поддержки. Однако она не всегда означает, что любые вопросы решаются ночью с той же скоростью.
Например, в круглосуточном режиме может работать только прием критических аварий, а консультации и изменения обрабатываются в рабочее время.
Поэтому SLA должен описывать не только наличие поддержки 24 на 7, но и перечень обращений, которые реально обслуживаются круглосуточно.
SLA и плановые технические работы
Серверам, сетям и программному обеспечению требуется обслуживание. Провайдер может устанавливать обновления, заменять оборудование или выполнять работы с инфраструктурой.
В SLA обычно определяются допустимые окна планового обслуживания и минимальный срок уведомления клиента.
Часто плановые работы не включаются в расчет доступности, если они были выполнены в предусмотренное время и клиент получил уведомление.
Для бизнеса важно оценивать не только процент доступности, но и возможную продолжительность таких окон.
Что такое Service Credit
Service Credit — один из распространенных механизмов компенсации при нарушении SLA. Если поставщик не достиг установленного уровня доступности, клиент получает скидку или кредит на будущие услуги.
Например, при снижении доступности ниже установленного значения часть ежемесячной платы может быть компенсирована.
Важно понимать, что такая компенсация обычно не равна реальным потерям бизнеса. Если интернет-магазин потерял значительную выручку из-за двухчасового простоя, скидка на услуги провайдера может покрыть только небольшую часть ущерба.
SLA не гарантирует отсутствие сбоев
Даже высокий уровень SLA не означает, что сервис никогда не остановится. Соглашение устанавливает целевой уровень качества и ответственность за его нарушение.
Например, доступность 99,9 процента прямо предполагает, что определенный объем недоступности возможен.
SLA — это измеримая договоренность о качестве сервиса, а не обещание абсолютной безотказности.
Если бизнес не может позволить себе даже короткий простой, необходимо дополнительно проектировать резервирование, отказоустойчивость и аварийное восстановление.
SLA и отказоустойчивость
SLA описывает результат, а отказоустойчивая архитектура является одним из способов достижения этого результата.
Например, провайдер может использовать два дата-центра, резервные каналы связи, несколько серверов и дублирование систем хранения для выполнения обязательств по доступности.
Однако заказчику важно оценивать не только обещанный процент, но и архитектуру критичных компонентов, особенно если от сервиса зависит ключевой бизнес-процесс.
SLA и резервное копирование
Доступность и сохранность данных — разные характеристики. Сервис может быть доступен 99,99 процента времени, но это не гарантирует наличие резервной копии случайно удаленного файла.
Если резервное копирование входит в услугу, в SLA или связанных документах следует определить периодичность копирования, срок хранения, время восстановления и ответственность сторон.
Для критичных систем дополнительно используют показатели RPO и RTO.
SLA, RPO и RTO
SLA определяет общий уровень обслуживания. RPO и RTO относятся к восстановлению после аварий и помогают конкретизировать требования к защите данных.
| Показатель | Что означает |
|---|---|
| SLA | Требуемый уровень качества услуги |
| RPO | Допустимый объем потери данных, выраженный через время |
| RTO | Допустимое время восстановления сервиса |
Например, RPO в один час означает, что при аварии организация допускает потерю данных максимум примерно за последний час. RTO в два часа означает, что сервис должен быть восстановлен в пределах двух часов.
SLA и KPI
SLA и KPI связаны, но не являются одним и тем же.
SLA фиксирует обязательства между поставщиком и потребителем услуги. KPI используются для оценки эффективности процессов, подразделений или сотрудников и могут быть внутренними.
Например, SLA устанавливает реакцию на критичную заявку не более 15 минут. Внутренним KPI службы поддержки может быть доля обращений, на которые сотрудники реагируют быстрее пяти минут.
SLA, OLA и договор с подрядчиком
Для выполнения клиентского SLA поставщику могут понадобиться внутренние соглашения между собственными командами.
Такие соглашения часто называют OLA, или Operational Level Agreement. Например, Service Desk обязуется передать критичный инцидент системным администраторам за пять минут, а администраторы — начать диагностику еще через десять минут.
Также поставщик может зависеть от внешних подрядчиков: оператора связи, дата-центра или облачной платформы. Их обязательства должны позволять поставщику выполнить собственный SLA перед конечным клиентом.
Внутренний SLA
SLA может использоваться не только между двумя компаниями. Крупные организации применяют внутренние SLA между ИТ-подразделением и бизнесом.
Например, внутренний Service Desk обязуется реагировать на критичные проблемы бухгалтерии в течение 10 минут, а стандартные заявки на создание учетной записи выполнять в течение одного рабочего дня.
Такой подход делает работу внутреннего ИТ-подразделения более прозрачной и помогает согласовать ожидания бизнеса.
SLA в облачных сервисах
В облачной инфраструктуре SLA обычно применяется к виртуальным серверам, хранилищам, сетям и другим сервисам.
Провайдер может гарантировать определенную доступность платформы, но условия необходимо читать внимательно. Некоторые показатели действуют только при использовании нескольких зон доступности или определенной конфигурации.
Также клиент может самостоятельно создать единую точку отказа внутри надежного облака. Например, если приложение работает только на одной виртуальной машине, ее сбой сделает сервис недоступным даже при исправной облачной инфраструктуре.
SLA в дата-центре
Для Colocation SLA может включать доступность электропитания, температурный режим, сетевые подключения и другие инженерные параметры.
При этом дата-центр обычно не отвечает за приложение клиента или отказ его физического сервера, если обслуживание оборудования не входит в услугу.
Поэтому важно четко разделять SLA инфраструктуры и SLA бизнес-сервиса.
SLA в SaaS
Для SaaS-сервисов SLA чаще всего относится к доступности самого приложения и работе технической поддержки.
Пользователь не управляет физической инфраструктурой и ожидает готовый сервис. Поэтому важны не характеристики отдельных серверов, а доступность функций приложения.
Для критичных SaaS-систем дополнительно оценивают резервное копирование, экспорт данных, сроки восстановления и порядок действий при длительной аварии.
Как правильно читать SLA
При выборе поставщика недостаточно найти в документе высокий процент доступности. Необходимо разобраться в методике его расчета.
- Определить, к какой именно услуге относится показатель.
- Проверить расчетный период.
- Посмотреть, что считается началом простоя.
- Изучить список исключений.
- Проверить правила плановых работ.
- Уточнить время реакции по каждому приоритету.
- Посмотреть режим работы поддержки.
- Проверить порядок эскалации.
- Изучить компенсации.
- Понять, какие действия должен выполнить клиент для получения компенсации.
На что обратить внимание при сравнении SLA
| Вопрос | Почему важен |
|---|---|
| Что считается недоступностью? | Разные методики могут давать разные результаты |
| Как фиксируется начало инцидента? | От этого зависит продолжительность простоя |
| Есть ли исключения? | Часть простоев может не учитываться |
| Как работает поддержка ночью? | 24 на 7 может распространяться не на все заявки |
| Есть ли финансовая ответственность? | Показывает последствия нарушения обязательств |
| Какой порядок эскалации? | Определяет действия при затянувшейся аварии |
Типичные ошибки при составлении SLA
- Использовать формулировки быстро или максимально оперативно без числовых показателей.
- Устанавливать доступность, но не описывать методику ее расчета.
- Не определять приоритеты инцидентов.
- Смешивать время реакции и время решения.
- Не указывать режим работы поддержки.
- Не определять правила проведения плановых работ.
- Не закреплять исключения из SLA.
- Устанавливать показатели, которые невозможно объективно измерить.
- Не определять источник данных для расчета метрик.
- Не пересматривать SLA после изменения бизнес-требований.
Ошибки заказчика при выборе SLA
Заказчик тоже может неправильно оценить условия обслуживания. Самая распространенная ошибка — выбирать сервис исключительно по максимальному проценту доступности.
Высокий SLA может увеличивать стоимость услуги, хотя конкретному бизнес-процессу такой уровень надежности не требуется.
Другой крайний вариант — выбрать минимальный тариф для критичной системы и только после аварии обнаружить, что техническая поддержка ночью не работает.
Поэтому требования к SLA должны исходить из реальной стоимости простоя для бизнеса.
Как выбрать нужный уровень SLA
Компания должна определить, насколько критична конкретная информационная система.
Для внутреннего тестового сервера несколько часов простоя могут быть допустимы. Для интернет-магазина, платежной системы или производственной платформы даже короткая остановка может привести к существенным потерям.
При оценке полезно ответить на несколько вопросов.
- Сколько стоит час простоя?
- Может ли бизнес продолжать работу без системы?
- Нужна ли поддержка ночью и в выходные?
- Как быстро требуется восстановить сервис?
- Какой объем потери данных допустим?
- Есть ли резервная система?
- Какие инциденты являются действительно критичными?
После этого можно выбирать соответствующий тариф и архитектуру.
Практический пример SLA
Компания размещает корпоративную систему в облаке. Ей требуется круглосуточный доступ для сотрудников нескольких филиалов.
В договоре провайдер указывает доступность инфраструктуры 99,95 процента в месяц. Критичным считается инцидент, при котором система полностью недоступна всем пользователям. Время реакции на такой инцидент составляет 15 минут.
Плановые технические работы проводятся в заранее определенные окна и не учитываются как нарушение доступности при своевременном уведомлении клиента.
При снижении доступности ниже установленного значения клиент может запросить компенсацию в виде части стоимости услуги.
Дополнительно компания организует резервное копирование и второй сервер приложения. Это важно, поскольку высокий SLA провайдера не защищает от ошибок внутри самой корпоративной системы.
Как контролировать выполнение SLA
Для объективной оценки желательно использовать автоматический мониторинг. Он позволяет фиксировать доступность сервиса и время возникновения инцидента без ручного учета.
Поставщик и заказчик должны заранее определить источник данных, которому доверяют обе стороны.
Также полезно регулярно формировать отчет по ключевым метрикам.
- фактическая доступность;
- количество инцидентов;
- среднее время реакции;
- среднее время восстановления;
- доля обращений с нарушенным SLA;
- количество критичных аварий;
- продолжительность плановых работ;
- причины наиболее значимых нарушений.
SLA и SLO
SLO, или Service Level Objective, — целевой показатель уровня сервиса. Например, доступность 99,9 процента может быть одним из SLO.
SLA является более широким соглашением и может включать несколько SLO, правила измерения, ответственность, исключения и компенсации.
Таким образом, SLO отвечает на вопрос какого уровня хотим достичь, а SLA закрепляет договоренность между сторонами.
SLA и SLI
SLI, или Service Level Indicator, — измеряемый показатель фактического состояния сервиса. Например, реальная доступность за месяц или фактическое время ответа.
Связь между терминами можно описать следующим образом: SLI показывает измеренное значение, SLO задает цель, а SLA закрепляет обязательства между сторонами.
| Термин | Суть |
|---|---|
| SLI | Фактически измеряемый показатель |
| SLO | Целевое значение показателя |
| SLA | Соглашение об уровне обслуживания и ответственности |
Преимущества SLA для бизнеса
- позволяет заранее определить ожидания от поставщика;
- делает качество услуги измеримым;
- упрощает контроль подрядчиков;
- помогает планировать риски простоя;
- создает понятный порядок обработки аварий;
- позволяет сравнивать предложения провайдеров;
- задает механизм ответственности за нарушения.
Ограничения SLA
SLA не заменяет техническую архитектуру и управление рисками. Даже хорошо составленное соглашение не восстановит данные, если компания не настроила резервное копирование.
Также компенсация от провайдера редко покрывает реальный бизнес-ущерб от длительного простоя.
Поэтому критичные системы необходимо защищать одновременно организационными, договорными и техническими мерами.
Связанные термины
| Термин | Связь с SLA |
|---|---|
| Доступность | Один из основных показателей качества сервиса |
| SLO | Целевое значение определенного сервисного показателя |
| SLI | Фактически измеряемое значение показателя сервиса |
| OLA | Внутреннее соглашение между командами, обеспечивающими услугу |
| RTO | Целевое время восстановления после сбоя |
| RPO | Допустимый объем потери данных, выраженный через время |
| Incident Management | Процесс управления инцидентами и восстановления сервиса |
| Service Desk | Точка приема и обработки пользовательских обращений |
| Отказоустойчивость | Техническая способность инфраструктуры продолжать работу при отказах |
| Мониторинг | Инструмент объективного контроля выполнения SLA |
Краткий итог
SLA — соглашение об уровне обслуживания, которое переводит ожидания от ИТ-сервиса в конкретные измеримые показатели. Оно может устанавливать доступность, время реакции, сроки восстановления, режим работы поддержки, правила эскалации и ответственность за нарушение условий.
Хороший SLA содержит не только красивый процент доступности, но и понятную методику расчета, определения инцидентов, исключения и порядок компенсации.
Для бизнеса SLA является инструментом контроля качества и управления рисками, но не заменяет резервное копирование, отказоустойчивую архитектуру и аварийное восстановление. Требуемый уровень обслуживания следует выбирать исходя из критичности системы и реальной стоимости ее простоя.
