Практикум по эксплуатации
SRE для дежурной смены: цели, сигналы и оповещения
Курс для дежурной смены: чем внутренняя цель SLO отличается от договорного SLA, какие четыре сигнала снимают с услуги и когда оповещение стоит того, чтобы разбудить человека. Разбираются скорость расхода бюджета ошибок, цена меток и передача смены.
Что вы сможете сделать
- Разделять числовую цель и договорные последствия.
- Считать скорость расхода бюджета ошибок и проверять логику окон оповещения.
- Оценивать число временных рядов и выбирать метки с ограниченным набором значений.
- Связывать симптом, полезное действие дежурного и передачу смены.
SLA и внутренняя цель
Сначала разделите измеряемый результат, внутреннюю цель и соглашение с последствиями.
SLI задаёт точную количественную меру, SLO — её целевое значение. Укажите одинаковые область и окно до сравнения процентов.
SLA отличает наличие согласованных последствий нарушения. Вид и размер последствий читают в самом соглашении.
Проверить тезис: SLA 01
Внутренняя цель может быть строже договорной; её изменение не переписывает условия клиента.
Проверить тезис: SLA 02
99,8% ниже внутренней цели 99,9%, но выше договорного числового порога 99,5%. Это проверка двух чисел, а не всех условий договора.
Проверить тезис: SLA 03
Проценты сравнимы только при одинаковом измерении. Суточная доля успешных запросов не подтверждает месячную доступность по времени.
Проверить тезис: SLA 04
Последствия читают в самом соглашении после проверки его применимости и показателя. Нарушение внутреннего SLO само по себе не назначает компенсацию.
Проверить тезис: SLA 05
Четыре сигнала для одной услуги
Соберите пользовательский результат и признаки ограничения ресурсов в одну картину.
Задержка, трафик, ошибки и насыщение — четыре золотых сигнала. Единицы и ресурс ограничения выбирают по услуге.
Проверить тезис: Четыре золотых сигнала 01
Быстрая ошибка не равна быстрой полезной работе: задержку успехов и ошибок смотрят отдельно.
Проверить тезис: Четыре золотых сигнала 02
Запросы в секунду и биты в секунду измеряют разную работу. Для трафика назовите единицу и уровень.
Проверить тезис: Четыре золотых сигнала 03
Насыщение проверяют по пределу ресурса, очередям и ожиданию; низкое среднее по серверу не исключает локального ограничения.
Проверить тезис: Четыре золотых сигнала 04
В двух выборках по 100 запросов замена половины успехов по 200 мс ошибками по 10 мс снижает общее среднее до 105 мс. Вместе с ним обязательно смотрят выросшую до 50% долю ошибок.
Проверить тезис: Четыре золотых сигнала 05
Скорость сгорания бюджета
Безразмерный множитель связывает наблюдаемые ошибки с допустимой долей по SLO.
Скорость 1 расходует полный начальный бюджет за окно только при постоянном расходе и, для доли запросов, постоянной интенсивности. При уже потраченном бюджете срок до исчерпания будет другим.
При SLO 99,9% доля ошибок 1% даёт скорость 10: 1% делят на 0,1%. Это не ошибки в секунду.
Проверить тезис: Скорость расходования бюджета SLO 03
30 суток / 10 = 3 суток только в заданной модели постоянной нагрузки и полного начального бюджета; это не точный прогноз при меняющемся трафике.
Проверить тезис: Скорость расходования бюджета SLO 04
Быстрое и медленное ухудшение требуют разных окон обнаружения и сроков действий. Один высокий порог способен пропустить длительный умеренный расход.
Проверить тезис: Скорость расходования бюджета SLO 05
Порог 1000 или больше и остановка некритичных изменений в примере — явно заданная учебная политика организации. Источники обосновывают согласованные действия, а не эти обязательные числа.
Проверить тезис: Бюджет ошибок 05
Быстрые и медленные ветви тревоги
Проверьте логику окна до выбора чисел: одна пара должна подтвердить значимость и продолжение расхода.
В рекомендованной схеме Google SRE Workbook длинное и короткое окна одного порога соединены через И. Не переносите это свойство на все правила, которые используют несколько окон.
Проверить тезис: Многооконное оповещение по скорости расхода 01 02
В учебном правиле пара 1 час / 5 минут с порогом выше 14,4 соединена через ИЛИ с парой 6 часов / 30 минут с порогом выше 6.
Проверить тезис: Многооконное оповещение по скорости расхода 03
20 за час и 2 за пять минут не проходят одну пару со строгим выше 14,4: короткое окно не подтверждает продолжающийся высокий расход.
Проверить тезис: Многооконное оповещение по скорости расхода 04
Одна ошибка из десяти запросов при цели 99,9% даёт скорость 100; это результат малой выборки, требующий осмысленной политики реакции.
Проверить тезис: Многооконное оповещение по скорости расхода 05
Сколько рядов создают метки
Стоимость начинается с состава рядов и частоты отсчётов; точные байты требуют измерения.
Ряд задаётся полным сочетанием меток. Кардинальность одного поля не равна общему числу рядов.
Проверить тезис: Кардинальность метрик 01 · Кардинальность метки 02 01
Независимые измерения перемножаются: 20 маршрутов × 3 метода × 5 классов ответа дают 300 рядов при публикации всех сочетаний.
300 рядов с интервалом 15 секунд дают 20 отсчётов в секунду и 1 728 000 за сутки без пропусков. Это ещё не объём в байтах.
Проверить тезис: Кардинальность метрик 04
Классическая гистограмма с десятью конечными границами даёт 11 бакетов, _sum и _count: 13 рядов на сочетание, 3900 для 300 сочетаний.
Проверить тезис: Кардинальность метрик 05
Почему request_id дорог в метриках
Метрики агрегируют ограниченные группы; уникальная идентичность запроса разрушает такое повторное использование рядов.
Prometheus не рекомендует неограниченные значения меток. Высокая кардинальность увеличивает число рядов даже при прежней частоте сбора.
Новый request_id в метках создаёт новое сочетание для каждого запроса. Фиксированный интервал сбора не ограничивает этот поток новых рядов.
Проверить тезис: Высокая кардинальность 03
Ограниченный шаблон /orders/{id} группирует маршрут; полный уникальный путь дробит его по заказам. Подробности запроса связывают с журналом или трассировкой.
Проверить тезис: Высокая кардинальность 04
Короткое хранение уменьшает историю, но не ограничивает создание новых сочетаний сейчас. Сначала ограничьте измерения и затем измерьте ресурсный бюджет.
Проверить тезис: Высокая кардинальность 05
Симптом, действие и дежурный
Оповещение должно помочь человеку изменить ситуацию за полезное время.
Симптом показывает, что сломано для пользователя, причины помогают понять почему. Высокоуровневые задержки и ошибки служат основой срочного оповещения.
Быстрое сгорание требует срочной реакции, если есть полезное действие и ответственный. Медленное ухудшение можно направить в задачу с ответственным и сроком; один высокий множитель не делает вызов полезным.
Определите получателя, срок реакции и первый шаг. Активное состояние правила не подтверждает, что сообщение доставлено и принято.
Проверить тезис: Оповещение, требующее действия 03
В вызов включите последствие, а ресурсные графики и журнал используйте для диагностики; несколько признаков одного последствия не обязательно требуют нескольких вызовов.
Проверить тезис: Оповещение, требующее действия 04
Несрочной задаче тоже нужны ответственный и срок, согласованный с оставшимся временем до ущерба.
Проверить тезис: Оповещение, требующее действия 05
Шум, восстановление и передача смены
Качество дежурства оценивают по действиям и последствиям, а не по числу пересланных сообщений.
Частые незначимые вызовы скрывают настоящий инцидент; оценивайте нагрузку за смену и устойчивость канала.
Повторные вызовы без полезного действия дают материал для пересмотра правила. Снижение числа сообщений само по себе не означает улучшения услуги.
Проверить тезис: Alert fatigue 03
После подавления правила тишина доказывает только изменение оповещения. Для восстановления проверяйте показатели услуги и исправность сбора.
Проверить тезис: Alert fatigue 04
Учебная передача смены включает открытое последствие, выполненные действия, подавления и следующий шаг с ответственным.
Проверить тезис: Alert fatigue 05
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Источники курса
Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.
- Официальная документация
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.
Открыть первоисточник