Улучшение наблюдаемости с помощью метрик уровня обслуживания

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

ИТ-отдел отвечает за совместное использование ограниченных ресурсов (таких как ЦП, память и диск) между бизнес-функциями, поэтому они измеряют потребление. Затем ИТ-отдел использует эти показатели, чтобы определить, когда ресурс близок к исчерпанию, чтобы избежать проблем и снизить затраты. С другой стороны, бизнесу нужны оперативные и безошибочные услуги, поэтому успех измеряется скоростью и качеством. Несоответствие — это две команды с совершенно разными представлениями об успехе, что приводит к большому напряжению между ИТ и бизнесом.

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

Индикаторы уровня обслуживания

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

• Задержка/время отклика

• Частота ошибок/качество

• Доступность

• Время безотказной работы
  

Да, существует различие между временем безотказной работы (надежность) и доступностью (потеря времени). И вот некоторые потенциальные варианты SLI, которые вам не следует использовать, поскольку они не имеют прямого отношения к влиянию на бизнес:

• Процессор, диск, потребление памяти

• Скорость попадания в кэш

• Время сбора мусора

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

Ключевым моментом здесь является выбор метрики для вашего SLI, которая четко и недвусмысленно связана с предоставлением услуг и проста и удобна для общения с нетехническими людьми. Это устранит разъединение, облегчив задачу всем участникам.

Цели уровня обслуживания

SLO — это просто цель, которую вы устанавливаете для своих SLI. Во-первых, вы определяете свои SLI. Затем, устанавливая пороговые значения для каждого SLI, вы создаете свои SLO.

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

Установка SLO

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

1. Определите службу, для которой вы хотите установить SLO.

1. Определите ключевые транзакции сервиса. Многие сервисы имеют транзакции, такие как проверки работоспособности, которые не должны влиять на SLO производительности.

1. Определите SLI для обслуживания и транзакций.

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

1. Настройте оповещения о нарушении SLO.

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

Вывод

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

Также опубликовано здесь