Наблюдаемость
SLO и error budget: тест на воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть модельный — усилие припоминания и закрепляет арифметику SLO, когда выводишь её вживую на постмортеме.
Восстанови костяк юнита — что делает SLI хорошим, арифметику бюджета и burn rate, почему MWMBR использует AND, composite-потолок и организационную политику — не подглядывая в уроки.
- 01Определи SLI, SLO и error budget и назови формулы бюджета и burn rate с одним посчитанным числом.
- 02Выведи пороги burn rate 14.4x / 6x / 1x из первых принципов.
- 03Почему MWMBR-алертинг использует AND между длинным и коротким окном и что ломается при single-window или OR?
- 04Объясни composite-потолок SLO и два архитектурных рычага, которые его поднимают.
- 05Что должна содержать error budget policy, почему важны подписи и чем она отличается от SLA?
- 06Почему низкотрафиковые сервисы ломают наивную арифметику SLO и какие четыре стандартных средства?
Если ты смог восстановить каждый ответ по памяти, ты держишь костяк юнита: SLI — это пользовательское отношение good/total, бюджет = (1 − SLO) × events, а burn rate нормализует трату, каждый порог MWMBR выводится из (budget_fraction × period) / window с AND, связывающим длинное и короткое окно, пути перемножаются в потолок 0.999^N, который поднимают ретраи и hedging, error budget policy нужны подписи и исключения, чтобы быть зубастой, SLO обязан быть строже SLA, а низкотрафиковым поверхностям нужны пробы, агрегация, длинные окна или count-based алерты плюс защита от NaN.