Практикум по эксплуатации

SRE для дежурной смены: цели, сигналы и оповещения

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

База → эксплуатационная проверка140 минут8 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Разделять числовую цель и договорные последствия.
  2. Считать скорость расхода бюджета ошибок и проверять логику окон оповещения.
  3. Оценивать число временных рядов и выбирать метки с ограниченным набором значений.
  4. Связывать симптом, полезное действие дежурного и передачу смены.
Модуль 1 из 8

SLA и внутренняя цель

Сначала разделите измеряемый результат, внутреннюю цель и соглашение с последствиями.

  • SLI задаёт точную количественную меру, SLO — её целевое значение. Укажите одинаковые область и окно до сравнения процентов.

    Проверить тезис: SLI 01 · SLO 01 02

  • SLA отличает наличие согласованных последствий нарушения. Вид и размер последствий читают в самом соглашении.

    Проверить тезис: SLA 01

  • Внутренняя цель может быть строже договорной; её изменение не переписывает условия клиента.

    Проверить тезис: SLA 02

  • 99,8% ниже внутренней цели 99,9%, но выше договорного числового порога 99,5%. Это проверка двух чисел, а не всех условий договора.

    Проверить тезис: SLA 03

  • Проценты сравнимы только при одинаковом измерении. Суточная доля успешных запросов не подтверждает месячную доступность по времени.

    Проверить тезис: SLA 04

  • Последствия читают в самом соглашении после проверки его применимости и показателя. Нарушение внутреннего SLO само по себе не назначает компенсацию.

    Проверить тезис: SLA 05

Модуль 2 из 8

Четыре сигнала для одной услуги

Соберите пользовательский результат и признаки ограничения ресурсов в одну картину.

  • Задержка, трафик, ошибки и насыщение — четыре золотых сигнала. Единицы и ресурс ограничения выбирают по услуге.

    Проверить тезис: Четыре золотых сигнала 01

  • Быстрая ошибка не равна быстрой полезной работе: задержку успехов и ошибок смотрят отдельно.

    Проверить тезис: Четыре золотых сигнала 02

  • Запросы в секунду и биты в секунду измеряют разную работу. Для трафика назовите единицу и уровень.

    Проверить тезис: Четыре золотых сигнала 03

  • Насыщение проверяют по пределу ресурса, очередям и ожиданию; низкое среднее по серверу не исключает локального ограничения.

    Проверить тезис: Четыре золотых сигнала 04

  • В двух выборках по 100 запросов замена половины успехов по 200 мс ошибками по 10 мс снижает общее среднее до 105 мс. Вместе с ним обязательно смотрят выросшую до 50% долю ошибок.

    Проверить тезис: Четыре золотых сигнала 05

Модуль 3 из 8

Скорость сгорания бюджета

Безразмерный множитель связывает наблюдаемые ошибки с допустимой долей по SLO.

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

    Проверить тезис: Скорость расходования бюджета SLO 01 02

  • При SLO 99,9% доля ошибок 1% даёт скорость 10: 1% делят на 0,1%. Это не ошибки в секунду.

    Проверить тезис: Скорость расходования бюджета SLO 03

  • 30 суток / 10 = 3 суток только в заданной модели постоянной нагрузки и полного начального бюджета; это не точный прогноз при меняющемся трафике.

    Проверить тезис: Скорость расходования бюджета SLO 04

  • Быстрое и медленное ухудшение требуют разных окон обнаружения и сроков действий. Один высокий порог способен пропустить длительный умеренный расход.

    Проверить тезис: Скорость расходования бюджета SLO 05

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

    Проверить тезис: Бюджет ошибок 05

Модуль 4 из 8

Быстрые и медленные ветви тревоги

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

  • В рекомендованной схеме Google SRE Workbook длинное и короткое окна одного порога соединены через И. Не переносите это свойство на все правила, которые используют несколько окон.

    Проверить тезис: Многооконное оповещение по скорости расхода 01 02

  • В учебном правиле пара 1 час / 5 минут с порогом выше 14,4 соединена через ИЛИ с парой 6 часов / 30 минут с порогом выше 6.

    Проверить тезис: Многооконное оповещение по скорости расхода 03

  • 20 за час и 2 за пять минут не проходят одну пару со строгим выше 14,4: короткое окно не подтверждает продолжающийся высокий расход.

    Проверить тезис: Многооконное оповещение по скорости расхода 04

  • Одна ошибка из десяти запросов при цели 99,9% даёт скорость 100; это результат малой выборки, требующий осмысленной политики реакции.

    Проверить тезис: Многооконное оповещение по скорости расхода 05

Модуль 5 из 8

Сколько рядов создают метки

Стоимость начинается с состава рядов и частоты отсчётов; точные байты требуют измерения.

  • Ряд задаётся полным сочетанием меток. Кардинальность одного поля не равна общему числу рядов.

    Проверить тезис: Кардинальность метрик 01 · Кардинальность метки 02 01

  • Независимые измерения перемножаются: 20 маршрутов × 3 метода × 5 классов ответа дают 300 рядов при публикации всех сочетаний.

    Проверить тезис: Кардинальность метрик 02 03

  • 300 рядов с интервалом 15 секунд дают 20 отсчётов в секунду и 1 728 000 за сутки без пропусков. Это ещё не объём в байтах.

    Проверить тезис: Кардинальность метрик 04

  • Классическая гистограмма с десятью конечными границами даёт 11 бакетов, _sum и _count: 13 рядов на сочетание, 3900 для 300 сочетаний.

    Проверить тезис: Кардинальность метрик 05

Модуль 6 из 8

Почему request_id дорог в метриках

Метрики агрегируют ограниченные группы; уникальная идентичность запроса разрушает такое повторное использование рядов.

  • Prometheus не рекомендует неограниченные значения меток. Высокая кардинальность увеличивает число рядов даже при прежней частоте сбора.

    Проверить тезис: Высокая кардинальность 01 02

  • Новый request_id в метках создаёт новое сочетание для каждого запроса. Фиксированный интервал сбора не ограничивает этот поток новых рядов.

    Проверить тезис: Высокая кардинальность 03

  • Ограниченный шаблон /orders/{id} группирует маршрут; полный уникальный путь дробит его по заказам. Подробности запроса связывают с журналом или трассировкой.

    Проверить тезис: Высокая кардинальность 04

  • Короткое хранение уменьшает историю, но не ограничивает создание новых сочетаний сейчас. Сначала ограничьте измерения и затем измерьте ресурсный бюджет.

    Проверить тезис: Высокая кардинальность 05

Модуль 7 из 8

Симптом, действие и дежурный

Оповещение должно помочь человеку изменить ситуацию за полезное время.

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

    Проверить тезис: Оповещение по симптомам 01 02

  • Быстрое сгорание требует срочной реакции, если есть полезное действие и ответственный. Медленное ухудшение можно направить в задачу с ответственным и сроком; один высокий множитель не делает вызов полезным.

    Проверить тезис: Оповещение, требующее действия 01 02

  • Определите получателя, срок реакции и первый шаг. Активное состояние правила не подтверждает, что сообщение доставлено и принято.

    Проверить тезис: Оповещение, требующее действия 03

  • В вызов включите последствие, а ресурсные графики и журнал используйте для диагностики; несколько признаков одного последствия не обязательно требуют нескольких вызовов.

    Проверить тезис: Оповещение, требующее действия 04

  • Несрочной задаче тоже нужны ответственный и срок, согласованный с оставшимся временем до ущерба.

    Проверить тезис: Оповещение, требующее действия 05

Модуль 8 из 8

Шум, восстановление и передача смены

Качество дежурства оценивают по действиям и последствиям, а не по числу пересланных сообщений.

  • Частые незначимые вызовы скрывают настоящий инцидент; оценивайте нагрузку за смену и устойчивость канала.

    Проверить тезис: Alert fatigue 01 02

  • Повторные вызовы без полезного действия дают материал для пересмотра правила. Снижение числа сообщений само по себе не означает улучшения услуги.

    Проверить тезис: Alert fatigue 03

  • После подавления правила тишина доказывает только изменение оповещения. Для восстановления проверяйте показатели услуги и исправность сбора.

    Проверить тезис: Alert fatigue 04

  • Учебная передача смены включает открытое последствие, выполненные действия, подавления и следующий шаг с ответственным.

    Проверить тезис: Alert fatigue 05

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01В одном окне с одинаковыми исключениями результат 99,8%, внутренний SLO 99,9%, договорный числовой порог 99,5%. Что следует из этих чисел?
02Команда задала цель 99,9%, но не определила соглашение с клиентом и последствия нарушения. Что именно задано?
03Служба стала быстро отдавать ошибки. Среднее время всех ответов снизилось. Как оценивать задержку?
04Средняя загрузка сервера невысока, но часть запросов ждёт один ресурс. Какая проверка нужна?
05SLO равен 99,9%, наблюдаемая доля ошибок — 1%. Какова скорость сгорания?
06Для бюджета по запросам на 30 суток получили скорость 10. Трафик будущих дней неизвестен. Можно ли обещать ровно три суток до исчерпания?
07Одна ветвь требует скорости выше 14,4 за час И за пять минут. Сейчас значения 20 и 2 соответственно. Сработала ли эта ветвь?
08В учебном правиле быстрая пара (1 час и 5 минут выше 14,4) ложна. Медленная пара (6 часов и 30 минут выше 6) истинна. Пары соединены через ИЛИ. Каков результат?
09Одна метрика публикует все сочетания 20 маршрутов, трёх методов и пяти классов ответа. Других переменных меток нет. Сколько рядов?
10У классической гистограммы десять конечных границ, бакет +Inf, _sum и _count. Для неё публикуют 300 сочетаний других меток. Дополнительных рядов нет. Сколько рядов?
11Метрика получает уникальный request_id каждого запроса. Частота сбора не изменилась, поток запросов вырос. Что ограничит создание новых рядов по идентификаторам?
12Нужно измерять поток заказов и находить отдельный запрос при расследовании. Какой вариант ограничивает метки метрики?
13Правило перешло в активное состояние. Данных о получателе и подтверждении доставки нет. Что известно?
14Медленный расход бюджета направили в задачу вместо срочного вызова. Что требуется для реакции?
15После подавления шумного правила сообщений стало меньше. Как проверить результат для пользователей?
16Смена заканчивается, инцидент остаётся открытым и часть правил временно подавлена. Что передать следующему дежурному?
17Панель показывает 99,9% успешных запросов за сутки. SLA определяет доступность по времени за месяц. Какой вывод допустим?
18Внутренний SLO не выполнен. Известен только его процент, текста SLA в задаче нет. Можно ли определить компенсацию клиенту?
19Было 100 успехов по 200 мс. Стало 50 успехов по 200 мс и 50 ошибок по 10 мс. Каково новое среднее всех 100 запросов?
20В той же закрытой выборке общее среднее упало с 200 до 105 мс, а доля ошибок выросла с 0% до 50%. Что передать дежурному?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Официальная документация

    Service Level Objectives

    Google Site Reliability Engineering · Site Reliability Engineering, Chapter 4

    Определяет SLI, SLO и SLA и объясняет user-centric latency, error rate, throughput и percentiles.

    Открыть первоисточник
  • Официальная документация

    Implementing SLOs

    Google Site Reliability Engineering · The Site Reliability Workbook, Chapter 2

    Описывает построение SLI/SLO от пользовательской цели, measurement window и error-budget policy.

    Открыть первоисточник
  • Официальная документация

    Monitoring Distributed Systems

    Google Site Reliability Engineering · Site Reliability Engineering, Chapter 6

    Формулирует symptom-based paging, actionable pages и риск alert fatigue от частых незначимых notifications.

    Открыть первоисточник
  • Первичная спецификация

    RFC 5136: Defining Network Capacity

    IETF · RFC 5136, February 2008

    Разделяет nominal link capacity, available capacity и измерение результата на выбранном protocol layer.

    Открыть первоисточник
  • Официальная документация

    Pressure Stall Information

    Linux Kernel · Linux kernel documentation, проверено 29 августа 2026 года

    Определяет CPU/memory/I/O pressure через долю времени stalled tasks и связывает contention с latency/throughput loss.

    Открыть первоисточник
  • Официальная документация

    Alerting on SLOs

    Google Site Reliability Engineering · The Site Reliability Workbook, Chapter 5

    Определяет error-budget burn rate и multiwindow multi-burn-rate approach, включая разные page/ticket windows.

    Открыть первоисточник
  • Официальная документация

    Example Error Budget Policy

    Google Site Reliability Engineering · Published policy, 19 февраля 2018 года

    Определяет error budget как 1 minus SLO и связывает exhaustion с заранее согласованными actions.

    Открыть первоисточник
  • Официальная документация

    Alerting Rules

    Prometheus Authors · Prometheus latest documentation, checked 29 August 2026

    Документирует alert expressions, pending/firing states, for/keep_firing_for и передачу notifications в Alertmanager.

    Открыть первоисточник
  • Официальная документация

    Metric and Label Naming

    Prometheus Authors · Prometheus best practices, checked 29 August 2026

    Определяет каждую unique комбинацию label pairs как отдельную time series и запрещает unbounded high-cardinality labels.

    Открыть первоисточник
  • Официальная документация

    Prometheus Storage

    Prometheus Authors · Prometheus latest documentation, checked 29 August 2026

    Документирует time/size retention, oldest-first deletion, capacity formula и временный disk overhead compaction.

    Открыть первоисточник
  • Официальная документация

    Histograms and Summaries

    Prometheus · Prometheus documentation, проверено 29 августа 2026 года

    Определяет quantiles/percentiles, histogram buckets и ограничения aggregation precomputed quantiles.

    Открыть первоисточник
  • Первичная спецификация

    OpenTelemetry Specification Overview

    OpenTelemetry · OpenTelemetry Specification 1.60.0

    Описывает signals, raw measurements, aggregation, resources и context propagation.

    Открыть первоисточник
  • Официальная документация

    Alerting Best Practices

    Prometheus Authors · Prometheus best practices, checked 29 August 2026

    Рекомендует простые alerts по user-visible symptoms, slack для коротких blips и диагностические links вместо paging на каждую cause.

    Открыть первоисточник
Подтвердите действие