SLO и SLI на практике — что это такое, как внедрить и как контролировать на примере инструмента Instana

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

Если компания предоставляет SLA клиентам, обычно при прописывании SLO берутся в расчет установленные показатели SLA. Так как в случае не достижения SLO это напрямую отразиться на SLA, что приведет к определенным последствиям для бизнеса в лице нарушения договорных обязательств перед клиентами или даже штрафам.

В концепции SLI и SLO присутствует индикатор Error Budget или, как его иногда называют, «право на ошибку». Error Budget – это степень невыполнения наших SLO. Например, если наш SLO учитывает доступность, то error budget – это максимальное время, в течение которого наша система может быть недоступной без последствий для нас и нашей команды.

Использование данного показателя упрощает командам процесс контроля времени недоступности приложений/сервисов посредством ввода наглядного индикатора. Устанавливая Error Budget, мы ставим для себя цель – не выйти за рамки разрешенного нам самим downtime.

Например, если в качестве SLI для одного из наших приложений у нас указана метрика Availability, а в качестве SLO для этого SLI мы указали значение 99,95% в месяц, то наш Error Budget за месяц (30 дней) составит 21 минуту 54 секунды. Конкретную цифру Error Budget можно не рассчитывать самостоятельно, а воспользоваться готовым калькулятором.

Для анализа текущего положения дел с Error Budget с учетом установленного SLO/SLA и среднего показателя Availability на момент расчета, можно использовать вот такой калькулятор.

И так, мы разобрались, что из себя представляют SLI и SLO, теперь давайте перейдем к тому, как это внедрить. Для этих целей мы составили пошаговый план.

7 последовательных шагов по имплементации SLO

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

2. Для выбранных сервисов определяем набор метрик, которые войдут в наш SLI.
   
   Чаще всего в SLI включают метрики, непосредственно связанные с пользовательским опытом, доступностью и производительностью, такие как время исполнения транзакций, время отклика, процент ошибок, доступность.

3. Определяем текущее распределение значений выбранных метрик.
   
   Если вы используете промышленное APM решение, то скорей всего вам уже доступно определение baseline метрик. Например, мы видим, что у транзакции чекаута время исполнения по 90-му перцентилю равняется 110 мс за последние две недели.

4. Определяем SLO, учитывая нормальное поведение выбранных метрик или данных по baseline и устанавливаем Error Budget.

   Использовать «в лоб» текущие значения производительности как целевые - не совсем корректная практика, ведь SLO – это цель, к которой нужно стремиться, и она может и должна формироваться не только исходя из технических критериев и текущей ситуации. Но на практике проще оттолкнуться от измеренного значения и подкорректировать целевое, с учетом тех действий, которые позволят достичь этой цели.

   Например, можно установить порог 110 мс по 90-му перцентилю и SLO в 95%. Это будет означать, что мы допускаем 5% времени, в которое время исполнения транзакции по 90-му перцентилю будет выше 110 мс.

5. Прописываем процедуру действий на случай истощения Error Budget

   Важно заранее продумать, что мы будем делать в случае истощения Error Budget. В процедуру реагирования можно включить следующие действия:

   1. Оповещение при превышении Error Budget

   2. Повышение приоритета для команд разработки и DevOps у работ по восстановлению доступности сервиса перед работами по выкатке новых фич на определенный период времени.

   3. Lessons learned, post mortem и другие документы – фиксация причин превышения Error Budget в каждом конкретном случае в базу знаний и работа над ошибками.

6. Отслеживаем выполнение установленных нами SLO для соответствующих SLIs во времени.

7. Оцениваем результаты внедрения SLI SLO, как и с любым процессом, следующим логике Plan-Do-Check-Act. Лучше начать с небольшого количества SLO, определить достижимые цели, научиться отслеживать показатели и проводить улучшения постепенно.

 А теперь давайте посмотрим, как концепция SLI SLO реализована в инструменте Instana. 

Реализация концепции SLO и SLI в Instana

Инженеры Google рекомендуют начинать установку SLO с определения критичных путей пользователя по приложению, а именно конкретных действий пользователя, совершаемых в нашем приложении с целью достижения определенного бизнес результата. Например, путь пользователя по приложению с целью добавить товар в корзину. 

В Instana определить пути пользователя по приложению можно с помощью функции Application Perspective. Подробнее о том, как еще использовать Application Perspective, можно прочитать в нашем посте - Observability система для микросервисов на примере Instana, часть 1 

Для создания Application Perspective перейдем в интерфейсе Instana к разделу Application, кликнем на «New Application Perspective».

 В появившемся окне будут предложены варианты Application Perspective. Выбрав «a critical user journey», мы укажем, какие сервисы и эндпоинты входят в «путь пользователя». А если говорить проще – то мы определили какие сервисы и эндпоинты входят в одну из бизнес-транзакций, по которой необходимо определить SLO.

После того, как мы определили пути пользователя необходимо определить метрики, которые войдут в наш SLI и установить значение SLO.  Теперь мы можем перейти к созданию SLI. 

Конфигурация SLI

Создадим новый кастомный дашборд. 

На котором добавим SLO виджет и выберем созданное ранее Application Perspective. 

Кликнув на «Manage SLI» перейдем к списку всех доступных индикаторов для выбранного Application Perspective.  

Выбрав «Create SLI», мы перейдем к созданию SLI.

Для создания индикатора:

1. Укажем имя индикатора.

2. Определим тип индикатора: Time-Based или Event-Based.

3. Определим границы для вызовов: Inbound Calls или All Calls. 

   1. Inbound calls: Все входящие вызовы в рамках сервисов входящих в Application Perspective.

   2. All calls: Все входящие вызовы в рамках Application Perspective и исходящие вызовы из Application Perspective.

4. Укажем необходимую конфигурацию в зависимости от выбранного типа индикатора. 

5. Сохраним SLI кликнув на “Create”.

Time Based SLI

Time-Based индикатор – основывается на значениях выбранной метрики (временного ряда). Среди доступных метрик: 

• Latency – время исполнения вызовов;

• Call Count – количество вызовов;

• Error Rate – процент ошибок;

• Erroneous Calls – количество вызовов, содержащих ошибку.

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

В процессе установки SLI мы:

• Определяем область действия этого индикатора - можем выбрать как конкретный сервис, так и использоваться все сервисы входящие в Application Perspective. Для более детального определения можем указать конкретный эндпоинт сервиса. 

• Выбираем метрику, которая войдет в  SLI.  Это может быть - Latency, Call Count, Error Rate, Erroneous Calls.

• Определяем, как будем агрегировать значение метрики: по перцентилям (90, 50, 99 и т.д.), по среднему значению, по минимальному или максимальному значению.

• Определяем пороговое значение метрики.

 
После того, как мы указали метрику и ее пороговое значение, SLI рассчитается по формуле: 

SLI = (1 - #minutes_where_threshold_is_violated / #minutes_in_time_window) * 100% 

Посмотрим на пример настройки Time-Based индикатора. 

 Все вызовы сервиса proto.group должны исполняться в среднем не более чем за 25мс.  

Event-Based SLI

Event-Based индикатор основывается на «хороших» и «плохих» событиях.

«Хорошие» события - это набор вызовов, которые указывают на положительное качество работы сервиса, например, 2хх HTTP статус коды.

«Плохие» события – это набор вызовов, которые указывают на отрицательное качество работы сервиса, например, 5хх HTTP статус коды. 

В ходе настройки Event-Based SLI мы: 

• С помощью фильтров определим, какие вызовы указывают на положительное качество работы сервиса;

• С помощью фильтров, определим, какие вызовы указывают на отрицательное качество работы сервиса.

SLI в таком случае рассчитывается по формуле: 

SLI = #good_events / (#good_events + #bad_events) * 100%  

Рассмотрим пример настройки Event-Based индикатора. 

 Мы определили, что «хорошие» события – это все вызовы с 2хх HTTP статус кодом, а «плохие» - все вызовы с 5хх HTTP статус кодом. 

SLO отчет

В Instana SLO отчет предоставляется в виде «виджетов», которые можно добавить на свои кастомные дашборды. Виджеты позволяют проанализировать качество работы предоставляемого нами приложения/сервиса за определенный период времени.  

На представленном примере виджета – Robot Shop SLO. Мы используем метрику времени исполнения транзакции добавлении товара в корзину, как ключевой индикатор SLI, значение метрики должно не превышать 20мс. 

SLO рассматриваем за выбранный промежуток времени – 24 часа, и нам доступно 72 минуты на простой нашего сервиса (Error Budget). На дашборде выше мы видим, что SLO нарушался 116 минут за выбранный промежуток времени, наш Error Budget превышен на 44 минуты.  

Еще пример SLO отчета для Event-Based SLI:

Конфигурация SLO виджета 

 В этом разделе мы расскажем, как создать SLO Widget для любого Application Perspective. 

 Перейдем на свой кастомный дашборд и добавим SLO виджет, просто кликнув на “Add Widget”:

 В открывшемся окне перейдем на вкладку SLO и для настройки сделаем следующее:

1. Укажем имя виджета.

2. Выберем Application Perspective/критически важный пользовательский путь, по которому нужно задать SLO 

3. Выберем заранее созданный целевой индикатор SLI для выбранного Application Perspective.  

4. Определим цель SLO которую нужно достичь 

5. Выберем временной период, за который будет рассчитываться SLO: 

   1. Dynamic time window – SLO будет рассчитываться за период, который указан в тайм пикере. Тайм пикер доступен в правом верхнем углу интерфейса Instana, в нем мы выбираем период времени, за который будут отображаться данные.  
      

      

       

   2. Rolling Time Window – SLO будет рассчитываться за выбранный период времени, где конечная дата периода указана в тайм пикере. Например, мы всегда можем посмотреть данные за предыдущую неделю, без необходимости изменять период времени в тайм пикере. 

   3. Fixed time interval – SLO будет рассчитываться за фиксированный период времени с определенной датой начала и длительностью. Например, ежемесячно начиная с 2020-01-01. 

6. Убедимся, что мы заполнили все необходимые поля конфигурации. Нажав на «Highlight missing configuration» нам подсветятся все не заполненные поля. 

7. Сохраним виджет, нажав на «Create» 

Итоги

Мы настроили SLI и SLO для сервисов, начали с выбора критичного пути пользователя по сайту, определили какие метрики использовать для SLI, указали error budget и настроили виджет, визуализирующий текущий статус SLO. Метрики приложений мы собрали автоматически, путем установки агента, реализующего инструментацию приложений - метрики не потребовалось описывать вручную.

Подробнее про основные возможности observability системы Instana можно почитать в нашем обзоре продукта.

Также приглашаем на наш вебинар, посвященный использованию Instana для мониторинга Kubernetes и снижения MTTR.