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 присутствует индикатор ErrorBudget или, как его иногда называют, право на ошибку. ErrorBudgetэто степень невыполнения наших SLO. Например, если наш SLO учитывает доступность, то error budget это максимальное время, в течение которого наша система может быть недоступной без последствий для нас и нашей команды.

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

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

Для анализа текущего положения дел с ErrorBudget с учетом установленного 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определитьпутипользователяпоприложениюможно с помощьюфункцииApplicationPerspective.Подробнее отом,какещеиспользоватьApplicationPerspective, можно прочитать в нашем посте-Observabilityсистема для микросервисов на примереInstana, часть 1

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

Впоявившемся окне будутпредложены вариантыApplicationPerspective. Выбрав acriticaluserjourney, мыукажем, какие сервисы иэндпоинтывходятв путь пользователя.А если говоритьпроще то мы определили какие сервисы иэндпоинтывходятв одну из бизнес-транзакций, по которойнеобходимоопределитьSLO.

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

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

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

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

КликнувнаManageSLIперейдемк списку всех доступных индикаторов для выбранногоApplicationPerspective.

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

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

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

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

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

   1. Inboundcalls:ВсевходящиевызовыврамкахсервисоввходящихвApplicationPerspective.

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

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

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

Time Based SLI

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

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

• CallCount количество вызовов;

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

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

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

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

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

• Выбираемметрику,которая войдет вSLI. Этоможетбыть-Latency, CallCount, ErrorRate, ErroneousCalls.

• Определяем, как будем агрегировать значение метрики: по перцентилям (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 отчет

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

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

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

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

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

В этом разделе мы расскажем, как создатьSLOWidgetдля любогоApplicationPerspective.

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

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

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

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

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

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

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

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

      

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

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

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

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

Итоги

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

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

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