SLA, SLO и SLI: что такое и в чем разница

В статье рассмотрим, как настроить метрики для управления сервисами и как это связано с мониторингом ИТ-инфраструктуры.

Что такое SLA, SLO и SLI

Мониторинг инфраструктуры и сервисное обслуживание взаимосвязаны: от ИТ зависит доступность и качество услуг. Для поддержки этих процессов можно настроить различные метрики, которые помогут соблюдать условия предоставления услуг, назначать приоритеты инцидентам и вовремя выявлять отклонения в работе ИТ-сервисов.

Service Level Agreement, или SLA — это документ, в котором зафиксированы договоренности организации предоставлять пользователям услуги на определенном уровне. Например, в соглашении может быть указано, что поставщик ПО обязуется отвечать на обращения в течение 10 минут после регистрации запроса и обеспечивать доступность корпоративного приложения 98% времени в месяц.

Service Level Objectives, или SLO — это целевые значения метрик, которые используются для внутреннего контроля работоспособности сервисов и услуг. Так, если в соответствии с условиями соглашения корпоративное приложение должно быть доступно 98% времени, то целевой показатель для внутреннего контроля должен быть выше — например, 98,5%.

Service Level Indicator, или SLI — это набор ключевых метрик для оценки качества сервиса. Обычно в набор включаются показатели, от которых зависит уровень удовлетворенности пользователей — время ожидания реакции на запрос, скорость решения запроса, количество обращений, решенных с первого раза. SLI показывает реальное значение метрик. Например, в определенном месяце корпоративное приложение было доступно для пользователей 99% времени. Это хороший показатель, так как SLI оказался выше целевого значения (98,5%), также были соблюдены условия SLA.

В чем разница между этими показателями

Метрики рассматриваются в разных плоскостях, благодаря чему появляется возможность настроить эффективный процесс управления качеством услуг и мониторинг ИТ-инфраструктуры.

Как помогают управлять качеством услуг

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

Представим, в соглашении указано, что поставщик услуг обязуется решить инцидент за 48 часов. Сотрудник компании-клиента обратился в поддержку, так как в приложении перестали загружаться файлы. Оператор поддержки задал уточняющие вопросы клиенту и попросил сделать скриншоты. Подготовка ответа заняла больше суток. В итоге компания исправила ошибку за 52 часа с момента регистрации запроса, то есть не выполнила свои обязательства. Чтобы не возникало таких спорных ситуаций, стоит заранее зафиксировать в SLA, что при учете времени решения инцидентов считаются только те периоды, когда запрос находится на стороне поставщика услуг.

Значения SLA и SLO всегда должны быть разными. Если в соответствии с соглашением значение какого-то показателя не должно превышать 99%, то SLO должен быть еще выше, например, 99,5%. Если значение показателя приблизится к пороговому, то возникнет вероятность нарушения условий обслуживания. При этом у команды останется время исправить ситуацию и не допустить нарушения обязательств перед клиентами.

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

Для критичных услуг устанавливается минимальный error budget, чтобы клиентский опыт не ухудшился. Для менее востребованных услуг допустимое количество отклонений может быть выше.

Примеры использования SLA, SLO и SLI в работе

Метрики позволяют компании контролировать не только уровень сервиса. Также с их помощью можно определить, как должны работать компоненты ИТ, которые участвуют в предоставлении услуг.

Как это сделать? Допустим, поставщик предоставляет корпоративному клиенту высокий уровень обслуживания. Чтобы минимизировать риски нарушения соглашения, можно установить критичные приоритеты для инцидентов, которые затрагивают работу этого клиента. А также определить такие пороговые значения метрик для серверов клиента, чтобы фиксировались даже незначительные отклонения в работе оборудования.

Показатели позволяют:

• определять правила обработки событий и управлять качеством предоставления услуг;
• настраивать и оптимизировать бизнес-процессы;
• устанавливать приоритеты и сроки решения запросов и инцидентов;
• назначать ключевые показатели эффективности сотрудников;
• настраивать мониторинг метрик компонентов ИТ-инфраструктуры.

Рассмотрим на примерах, как это работает.

Пример 1. Поставщик ИТ-системы для управления выездным обслуживанием оценивает работу мобильного приложения с помощью SLI. В набор метрик входит несколько ключевых показателей — время отклика, доступность, частота ошибок и другие. При превышении целевых значений показателя доступности возникает риск снижения удовлетворенности пользователей. Чтобы избежать этого, компания разбирается с причинами.

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

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

Пример 2. Разработчик систем класса Service Desk может планировать изменения ПО, отслеживая SLI. Допустим, в этом месяце ИТ-команда собирается выпустить обновление корпоративного ПО для управления заявками на сервисное обслуживание, из-за чего могут возникнуть сбои в его работе. Однако общий период недоступности приложения за 21 день составил 30 минут. При этом error budget не должен превышать 35 минут в месяц. Чтобы не превысить показатель, команда перенесла выпуск обновления на следующий месяц.

Таким образом, с помощью метрик можно контролировать нужный уровень клиентского сервиса и поддержки собственной ИТ-инфраструктуры.

Что еще интересного