Skip to main content

Chapter 4. Service Level Objectives

Service Level Terminology​

Для того чтобы понимать работу сервису нужно его измерить и оценить, тут на помощь приходят:

  • SLIs (service level indicators) - показатели уровня качества обслуживания
  • SLOs (service level objectives) - целевые показатели уровня обслуживания
  • SLAs (service level agreements) - соглашения

SLI - это показатели, например - метрики, латенси или qps (запросы в секунду)

SLO - строиться на основе SLI, например я хочу чтобы количество успешно обработанных запросов (все кроме 5xx) было больше 99%

SLA - это контракт, что случиться если требования SLO не соблюдаются? (штрафы / скидки). Это показатель бизнеса и он может быть не всегда определен (я создал опенсорс проект, сделал для него SLO, но контракт со всем миром я подписывать не хочу)

Indicators in Practice​

Определяем метрики для сервиса (в данном случае шекспира).

нужно помнить что мы можем замерять только время ответа сервера (клиент может получать ответ на свой запрос значительно дольше)

  • FE сервисы:
    • availability (доступность) - Можем ли мы ответить пользователю на запрос?
    • latency (время отклика) - Сколько времени требует ответ на запрос?
    • throughput (пропускная способность) - Сколько запросов мы способны обработать?
  • Storage сервисы:
    • latency (время отклика) - Сколько времени потребуется чтобы считать или записать данные?
    • availability (доступность) - Можем ли мы получить доступ к данным когда потребовалось?
    • durability (долговечность) - Сможем ли мы получить доступ к данным через N лет?
  • Big Data системы:
    • throughput (пропускная способность) - Сколько данных обрабатывается прямо сейчас?
    • end-to-end latency (общая задержка) - Как долго данные находятся внутри системы?
  • correctness:
    • Был ли корректный ответ на запрос?
    • Получены данные?

Мониторинг, + нужно собирать метрики на стороне клиента (Sentry).

Агреггирование - данные интересная штука, нужно помимо средних значений смотреть на персентили - на интересует 99ый персентиль (худший сценарий). В идеале он должен удовлетворять нашему SLO

Objectives in Practice​

SLO должен быть определен инженерами + бизнесом. Помогает определить приоритетные задачи для SRE и продуктовых разработчиков.

  • 99% (averaged over 1 minute) of Get RPC calls will complete in less than 100 ms (measured across all the backend servers).
  • 99% of Get RPC calls will complete in less than 100 ms.

Можно выставлять SLO для юзеров и внутри команды (внутри более жесткие SLO)

Agreements in Practice​

SLA - вопросы бизнеса, юристов и etc. Задача SRE - определить SLIs и SLOs

Key Insights​

Symlinks
  • Borgmon - (26)
note

Empty