Цели уровня обслуживания — Примеры

Пример 1 — Цель, которую прячет среднее

Команда написала первую цель как среднее время ответа. Два из трёх последних инцидентов были медленными для меньшинства пользователей, и цель не сдвинулась. Ниже набросок того, что написано. Переформулируйте показатель так, чтобы хвост шёл в счёт.

иллюстративные числа
сервис     checkout
показатель среднее время ответа запросов checkout
цель       меньше 200 мс, измеряется непрерывно
область    все запросы

на прошлой неделе    118 мс среднее
во время инцидента    97 мс среднее, при этом 4 процента запросов дольше 2 секунд

Решение

сервис     checkout, без внутренних проверок здоровья
показатель доля запросов, обслуженных успешно за 300 мс
цель       99,9 процента за скользящие 30 дней
область    запросы checkout из витрины
измеряется по данным запросов и длительностей, которые уже собираются

Среднее — это утверждение о системе, поэтому инцидент, задевающий меньшинство, оставляет его на месте; доля в пределах порога учитывает самые медленные запросы и самых невезучих пользователей — то, что цель и должна обещать. Формулировка показателя так, как его переживает пользователь, ещё и заставляет команду сказать, какие запросы входят в область. Обычная ошибка — поставить порог на сегодняшнюю наблюдаемую задержку, что превращает цель в описание настоящего, а не в договорённость.

Пример 2 — Ориентир для сервиса без трафика

У нового внутреннего сервиса нет статистики трафика, и команда предложила почти идеальную доступность, потому что так звучит безопаснее. Сейчас доступность не измеряется вообще никак. Напишите цель, к которой сервис можно будет обязывать, и скажите, откуда взялось её число.

сервис        reporting-api
пользователи  три внутренние команды, все ещё мигрируют
данные сейчас счётчик запросов по маршруту, счётчик ошибок по маршруту
предложение   «почти идеальная доступность»

Решение

начать с заимствованной цели 99,9 процента за 30 дней, собственная цель платформы
затем измерять               реальное поведение сервиса месяц
показатель                   доля запросов, обслуженных успешно, из уже собранных счётчиков
владелец                     команда reporting-api, названная в цели
пересмотреть                 когда мигрирующие команды начнут зависеть в продакшене

Ориентир, выбранный для сервиса без пользователей, — гадание, поэтому взять ориентир соседа, а затем установить свой по месяцу реального поведения и есть практичный путь; так цель остаётся живой договорённостью. Показатель должен вычисляться из данных, которые уже собираются, иначе цель — желание, за которым никто не следит; счётчиков запросов и ошибок выше для этого достаточно. Обычная ошибка — сначала выбрать амбициозное число, затем обнаружить, что его ничто не вычисляет, и тихо перестать упоминать цель.