Вопросы на собеседовании: SRE-инженер

SLI измеряет поведение сервиса, SLO задаёт внутреннюю цель, а SLA фиксирует внешнее обязательство.

• Для SLI нужны точное определение события, источник данных и окно измерения.
• SLO устанавливает допустимый результат, например 99,9% успешных запросов за 28 дней.
• SLA обычно содержит более мягкую цель и описывает последствия нарушения обязательства.

Я выбираю SLI, который показывает, выполнил ли пользователь ценное действие успешно и достаточно быстро.

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

SLI доступности на основе запросов равен доле корректных успешных запросов среди всех корректных запросов за окно.

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

Перцентили задержки показывают медленные пользовательские запросы, которые среднее значение может скрыть.

• Среднее может оставаться стабильным, хотя небольшая, но важная доля запросов становится очень медленной.
• Цель задаёт и порог, и охваченную долю, например 99% запросов быстрее 400 миллисекунд.
• Перцентили нельзя складывать, поэтому сквозную задержку измеряют напрямую или собирают из гистограмм.

Оповещения по burn rate с несколькими окнами выявляют слишком быстрый расход error budget на коротком и длинном интервале.

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

Error budget задаёт общий количественный предел для выбора между скоростью поставки и надёжностью.

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

Эффективная политика задаёт объективные триггеры, соразмерные действия, ответственных и условия возврата к обычной поставке.

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

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

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

Я использую скользящее окно для постоянно актуальной оценки без сброса на границе месяца.

• Оно подходит для расчёта скорости расходования и не позволяет плохому периоду исчезнуть в первый день месяца.
• Календарные окна удобнее для договоров и фиксированных бизнес-обзоров.
• Выбранное окно должно отражать обычные колебания трафика и оставаться полезным для решений.

При низком трафике я сочетаю длинные окна с пользовательскими синтетическими проверками, а не полагаюсь на редкие запросы.

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

RED описывает сервис через частоту запросов, долю ошибок и длительность запросов.

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

USE рассматривает каждый ресурс через утилизацию, насыщение и ошибки, дополняя ориентированный на запросы RED.

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

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

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

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

• HTTP- и RPC-клиенты добавляют стандартные заголовки, а получатели извлекают их до создания дочерних спанов.
• Производители сообщений кладут контекст в метаданные, а потребители создают связанные спаны.
• Для долгой фоновой работы связь спанов может быть точнее прямого отношения родитель-потомок.

Я выбираю семплирование по объёму трафика, задачам анализа и стоимости, сохраняя редкие, но ценные трассы.

• Head sampling стоит дёшево, но не знает заранее, окажется ли трасса медленной или неуспешной.
• Tail sampling отбирает трассы по результату или задержке ценой буферизации и сложности коллекторов.
• Наследование решения от родителя сохраняет целостность трассы между сервисами.

Высокая кардинальность создаёт слишком много временных рядов, увеличивая память, хранение, стоимость запросов и записи.

• Неограниченные идентификаторы пользователей, запросов и исходные URL нельзя использовать как метки.
• Предпочтительны ограниченные измерения: сервис, регион, класс статуса и нормализованный маршрут.
• Подробные идентификаторы хранят в логах или трассировках, рассчитанных на отдельные события.

Бакеты гистограммы определяют точность и стоимость серверной агрегации задержки.

• Границы размещают около значимых целей и известных диапазонов, а не берут произвольные значения.
• Широкие бакеты скрывают изменения у порога SLO, а лишние бакеты умножают временные ряды.
• Для корректной агрегации экземплярам нужны совместимые границы.

Полезная метка метрики представляет ограниченное измерение для известной агрегации или решения.

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

Полезное SLO-оповещение сообщает о существенном риске для бюджета, указывает владельца и ведёт к решению.

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

Синтетический мониторинг обеспечивает контролируемые проверки, а мониторинг реальных пользователей измеряет фактический опыт.

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