Sre – Существует Ли Стандартный Или Общий Подход К Определению Индикаторов Уровня Обслуживания?

Я подошел к моменту, когда начинаю перенимать принципы из Проектирование надежности объекта использовать современные приложения Cloud Native.

Из моего чтения на сегодняшний день я установил, что одной из основных практик является мониторинг. Способ, которым SRE подходит к мониторингу, заключается в определении Индикаторы уровня обслуживания (SLI) которые измеряют аспект взаимодействия с конечным пользователем, а затем определяют пороговое значение SLI, которое называется Целевой уровень обслуживания (SLO).

Существует ли стандартный или общий подход к определению показателей уровня обслуживания?

#sre #operations #операционная модель

Хотя это и не является строго стандартным подходом, Google опубликовал меню SLI и процесс разработки SLI для пользовательского маршрута:

1. Для каждого пути пользователя/потока данных определите в меню SLI подходящие типы SLI:

   

2. Примите решение о том, как измерить хороший и действительный события,

3. Решите, где измерять SLI, из следующих источников: конечный пользователь, инструментарий на стороне клиента, синтетические клиенты, внешние метрики, метрики приложения или ведение журнала на стороне сервера.

Затем в документе описывается, как вы сопоставляете все свои SLI для всех ваших пользовательских циклов, а затем проходите путь в поисках пробелов в покрытии. Затем, наконец, установите SLO на основе SLI либо на основе деловая необходимость или прошлые результаты.

Вы должны определить, что наиболее важно для клиентов (или пользователей) в кросс-функциональном виде, например, разработчики, менеджер проектов, поддержка, руководители, SRE.

Например, само по себе использование памяти обычно НЕ имеет прямого значения для клиентов и большинства вышеперечисленных должностей. Однако это имеет значение для планирования мощности — поэтому, хотя это и не SLI/SLO приложений, это может быть важно для разработчиков/SRE и, в конечном итоге, для руководителей (финансирование). Для поддержания высокой эффективности может использоваться внутренний SLI/SLO.

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

Учитывая все это, существует потребность в кросс-функциональных показателях (SLI) и границах (SLO), которые будут отражать боль/недовольство клиентов. Отсутствие таких общих показателей, как правило, приводит к следующему эффекту: «низкий уровень использования памяти» (разработчики/SRE), «функции были отправлены» (PM), «мне не позвонили» (руководители), «пользователи». недовольны» (Поддержка).

Google также опубликовал свой семинар (в рамках CC-BY 4.0) о том, как определять SLI и SLO: https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice

Также есть сообщение в блоге о том, как со временем настраивать SLI (и SLO): https://cloud.google.com/blog/products/management-tools/tune-up-your-sli-metrics-cre-life-lessons

Отказ от ответственности: я работаю в Google.