Надёжность и SRE
SLI/SLO/SLA и бюджеты ошибок, расчёт доступности, burn-rate алерты, золотые сигналы, toil, реагирование на инциденты и безвинные постмортемы, chaos engineering и DR.
14 вопросов
JuniorТеорияОчень частоЧто такое бюджет ошибок и как он вычисляется из SLO?
Что такое бюджет ошибок и как он вычисляется из SLO?
Бюджет ошибок — это ненадёжность, разрешённая SLO: бюджет = 100% − SLO. Месячный SLO 99.9% допускает 0.1% сбоев — около 43 минут простоя. Это общая валюта: пока бюджет есть, быстро выкатываете фичи; когда потрачен — замораживаете рискованные релизы. Поэтому 100% — неверная цель: закладываете сбои.
Типичные ошибки
- ✗Путать бюджет с процентом SLO вместо 100% минус SLO
- ✗Считать 100% надёжности целью, а не планкой, ниже которой закладывают бюджет
- ✗Не связывать потраченный бюджет с заморозкой рискованных релизов
Уточняющие вопросы
- →Сколько простоя допускает бюджет месячного SLO 99.95%?
- →Что команде делать в момент исчерпания бюджета ошибок?
JuniorТеорияОчень частоЧто такое SLI, SLO и SLA и как эти три понятия связаны между собой?
Что такое SLI, SLO и SLA и как эти три понятия связаны между собой?
SLI — это измеряемый сигнал здоровья сервиса: доля хороших событий среди валидных, например доля запросов быстрее 300ms. SLO — внутренняя цель по этому SLI за окно, скажем 99.9% в месяц. SLA — внешний контракт, обещающий клиенту уровень, с последствиями (компенсации), если его нарушить; SLO держат строже SLA.
Типичные ошибки
- ✗Считать SLI, SLO и SLA синонимами, а не сигналом, целью и контрактом
- ✗Ставить SLO равным или мягче SLA, а не строже
- ✗Думать, что у SLA нет пункта о штрафах — его последствия и есть суть
Уточняющие вопросы
- →Почему 100% почти никогда не является верной целью SLO для сервиса?
- →Почему SLA обычно мягче внутреннего SLO?
JuniorТеорияЧастоКакие есть четыре золотых сигнала мониторинга?
Какие есть четыре золотых сигнала мониторинга?
Четыре золотых сигнала Google SRE — это latency (сколько длятся запросы, отдельно для успехов и ошибок), traffic (нагрузка на систему, например запросов в секунду), errors (доля неуспешных запросов) и saturation (насколько заполнен самый узкий ресурс). RED и USE — близкие аналоги.
Типичные ошибки
- ✗Перечислять сырые ресурсы хоста (CPU/RAM) вместо сигналов уровня запроса
- ✗Терять saturation или не разделять latency на успехи и ошибки
- ✗Путать золотые сигналы с трёхметричным методом RED
Уточняющие вопросы
- →Чем метод USE отличается от золотых сигналов?
- →Почему latency стоит измерять отдельно для успешных и неуспешных запросов?
MiddleТеорияЧасто99.9% доступности — сколько простоя это допускает в год и в месяц?
99.9% доступности — сколько простоя это допускает в год и в месяц?
Доступность — это аптайм к общему времени, поэтому 99.9% допускает 0.1% простоя: около 8.76 часов в год, 43 минут за 30-дневный месяц или 10 минут в неделю. Каждая девятка урезает бюджет примерно вдесятеро — 99.99% даёт около 52 минут в год. Этот бюджет простоя и есть бюджет ошибок SLO.
Типичные ошибки
- ✗Путать цифру простоя в 60 раз (минуты против часов)
- ✗Думать, что добавленная девятка расширяет, а не сужает бюджет
- ✗Не видеть, что бюджет простоя — это бюджет ошибок SLO
Уточняющие вопросы
- →Сколько месячного простоя допускает SLO 99.95%?
- →Почему каждая следующая девятка обходится экспоненциально дороже?
MiddleТеорияЧастоЧто такое burn-rate алерт и чем он лучше статического порога ошибок?
Что такое burn-rate алерт и чем он лучше статического порога ошибок?
Burn rate — это скорость траты бюджета ошибок относительно окна SLO: rate 1 тратит весь бюджет за окно, 14x — в 14 раз быстрее. Burn-rate алерт срабатывает на эту скорость, обычно по длинному окну плюс короткому для подтверждения. В отличие от статического порога он отражает влияние на SLO: пейджит на быстром прожигании.
Типичные ошибки
- ✗Читать burn rate как метрику хоста, а не скорость траты бюджета
- ✗Думать, что одного окна хватает вместо пары длинное-плюс-короткое
- ✗Считать, что статический порог отражает влияние на SLO не хуже burn rate
Уточняющие вопросы
- →Почему короткое вторичное окно снижает ложные пейджи burn-rate алерта?
- →Какой burn rate потратит месячный бюджет за один час?
MiddleТеорияЧастоЧто измеряют MTTR и MTBF и как сюда вписывается серьёзность инцидента?
Что измеряют MTTR и MTBF и как сюда вписывается серьёзность инцидента?
MTTR (среднее время восстановления) — среднее время от инцидента до восстановления; MTBF (среднее время между отказами) — средний аптайм между инцидентами. Доступность растёт с MTBF, падает с MTTR. MTTR = обнаружение + подтверждение + диагностика + фикс; быстрое обнаружение через золотые сигналы даёт больше всего. Severity задаёт срочность.
Типичные ошибки
- ✗Менять местами смысл MTTR и MTBF
- ✗Считать MTTR только временем фикса, игнорируя обнаружение и диагностику
- ✗Назначать severity, не давая ему задавать срочность реакции
Уточняющие вопросы
- →Какая часть MTTR обычно даёт наибольшее сокращение и почему?
- →Как бы вы провели границу между SEV1 и SEV2?
SeniorДизайнЧастоКлючевая зависимость вашего сервиса — бэкенд рекомендаций — периодически становится медленной или недоступной, и сегодня это кладёт весь продукт вместе с ней. Спроектируйте graceful degradation, чтобы продукт оставался полезным при отказе зависимости. Опишите, как выглядит урезанный-но-полезный опыт (fallback, кэш или дефолтные ответы, отключение некритичных фич), как load shedding защищает ядро при перегрузке, и роли timeout, circuit breaker и bulkhead в остановке распространения сбоя. Объясните, как решаете, что урезать или деградировать первым.
Ключевая зависимость вашего сервиса — бэкенд рекомендаций — периодически становится медленной или недоступной, и сегодня это кладёт весь продукт вместе с ней. Спроектируйте graceful degradation, чтобы продукт оставался полезным при отказе зависимости. Опишите, как выглядит урезанный-но-полезный опыт (fallback, кэш или дефолтные ответы, отключение некритичных фич), как load shedding защищает ядро при перегрузке, и роли timeout, circuit breaker и bulkhead в остановке распространения сбоя. Объясните, как решаете, что урезать или деградировать первым.
Деградируйте вместо отказа: отдавайте урезанный, но полезный опыт — кэш или дефолтные ответы, либо скройте некритичную фичу — когда зависимость лежит. Ставьте timeout на каждый вызов, чтобы медленная зависимость не занимала потоки, circuit breaker для быстрого отказа (проба в half-open) и bulkhead для изоляции пула. При перегрузке рано сбрасывайте низкоприоритетный трафик по ценности.
Типичные ошибки
- ✗Ронять весь продукт вместо отдачи урезанного опыта
- ✗Вызывать зависимость без timeout, из-за чего медленные вызовы занимают все потоки
- ✗Сбрасывать сперва критичный трафик, а не низкоприоритетный
Уточняющие вопросы
- →Как состояние half-open у circuit breaker безопасно проверяет восстановление?
- →Что делает хорошим fallback для упавшей фичи персонализации?
SeniorДизайнЧастоВы отвечаете за платёжный API. Продукт хочет еженедельные релизы фич, но инциденты прошлого квартала ударили по клиентам и доверию. Спроектируйте SLO и политику бюджета ошибок, которая держит скорость релизов высокой, защищая надёжность. Опишите, как выбираете SLI, цель и окно SLO, как бюджет считается и отслеживается, и конкретно что происходит с релизами фич по мере траты бюджета и после его исчерпания — включая, кто решает и как снимается заморозка. Объясните, почему цель намеренно ниже 100%.
Вы отвечаете за платёжный API. Продукт хочет еженедельные релизы фич, но инциденты прошлого квартала ударили по клиентам и доверию. Спроектируйте SLO и политику бюджета ошибок, которая держит скорость релизов высокой, защищая надёжность. Опишите, как выбираете SLI, цель и окно SLO, как бюджет считается и отслеживается, и конкретно что происходит с релизами фич по мере траты бюджета и после его исчерпания — включая, кто решает и как снимается заморозка. Объясните, почему цель намеренно ниже 100%.
Выберите SLI из пользовательского успеха и latency, задайте SLO вроде 99.9% за 28 дней и определите бюджет ошибок как 1 − SLO. Пока бюджет есть — релизьте еженедельно; у нуля — тормозите риск; после исчерпания — заморозьте релизы фич (только фиксы надёжности и безопасности), пока не восстановится, по правилу dev и SRE. Цель ниже 100%, ведь вы закладываете сбои ради релизов.
Типичные ошибки
- ✗Целиться в 100% вместо SLO, намеренно поставленного ниже
- ✗Делать внутренний SLO мягче внешнего SLA
- ✗Не иметь согласованного правила заморозки релизов при потраченном бюджете
Уточняющие вопросы
- →Как обойтись с одним инцидентом, что прожигает почти весь бюджет разом?
- →Должен ли security-хотфикс быть исключён из заморозки и почему?
MiddleТеорияИногдаЧто делает постмортем безвинным и что он должен содержать?
Что делает постмортем безвинным и что он должен содержать?
Постмортем — это разбор после значимого инцидента: таймлайн по мониторингу и золотым сигналам, влияние на пользователей, причины и action items с владельцами. Безвинный означает, что он бьёт по системным и процессным пробелам, а не по людям — каждый действовал разумно в рамках известного, — поэтому люди докладывают честно, а команда учится.
Типичные ошибки
- ✗Сводить постмортем к поиску виноватого, а не системных пробелов
- ✗Опускать action items с владельцами, из-за чего ничего не чинится
- ✗Пропускать таймлайн, восстановленный по мониторингу и сигналам
Уточняющие вопросы
- →Почему поиск виноватого делает будущие таймлайны инцидентов менее точными?
- →Как убедиться, что action items постмортема действительно выполняются?
MiddleТеорияИногдаЧто такое toil в SRE и как команды его ограничивают и сокращают?
Что такое toil в SRE и как команды его ограничивают и сокращают?
Toil — это ручная, повторяющаяся, автоматизируемая, тактическая работа, что растёт линейно с сервисом и не создаёт ценности — вроде ручного рестарта. Совещания — не toil. Модель SRE ограничивает его около 50% ради инженерии, убирающей будущий toil.
Типичные ошибки
- ✗Звать toil любую нелюбимую работу, включая совещания и планирование
- ✗Оставлять toil без предела вместо примерно 50% времени
- ✗Не измерять toil, из-за чего крупнейшие источники не автоматизируют
Уточняющие вопросы
- →Почему toil, растущий линейно с сервисом, со временем захлёстывает команду?
- →Как бы вы выбрали, какой источник toil автоматизировать первым?
SeniorДизайнИногдаМаркетинговая кампания в известную дату даст ожидаемый всплеск трафика в 5 раз к вашему сервису. Спроектируйте план ёмкости, чтобы он остался в рамках latency SLO на пике. Опишите, как оцениваете пиковый спрос, как превращаете его в модель ёмкости на инстанс (нагрузочный тест для максимума throughput при целевой latency), сколько headroom добавляете и зачем, как вписываются autoscaling и его лимиты, и какие зависимости ниже по потоку (база, квоты, третьи стороны) надо проверить. Объясните, как проверите план до события.
Маркетинговая кампания в известную дату даст ожидаемый всплеск трафика в 5 раз к вашему сервису. Спроектируйте план ёмкости, чтобы он остался в рамках latency SLO на пике. Опишите, как оцениваете пиковый спрос, как превращаете его в модель ёмкости на инстанс (нагрузочный тест для максимума throughput при целевой latency), сколько headroom добавляете и зачем, как вписываются autoscaling и его лимиты, и какие зависимости ниже по потоку (база, квоты, третьи стороны) надо проверить. Объясните, как проверите план до события.
Оцените пиковый спрос (базовая нагрузка на множитель 5 плюс рост), нагрузочным тестом найдите максимум throughput инстанса при целевой latency — модель на единицу. Заложите пик с headroom (N+1 плюс запас на потерю зоны и всплески), а не работу на 100%. Настройте лимиты autoscaling, проверьте, что зависимости (база, квоты) масштабируются, и прогоните нагрузочный тест до события.
Типичные ошибки
- ✗Работать на 100% утилизации без headroom на всплески или потерю зоны
- ✗Масштабировать только сервис, пока зависимость (база, квота) станет узким местом
- ✗Не проверять план нагрузочным тестом в целевом масштабе до события
Уточняющие вопросы
- →Сколько headroom вы бы держали и как возможная потеря зоны это меняет?
- →Почему один autoscaling может не спасти при внезапном всплеске в 5x?
SeniorДизайнИногдаВаш сервис работает в одном регионе облака, и региональный сбой полностью выведет его из строя. Руководство хочет, чтобы он пережил потерю целого региона. Спроектируйте мультирегиональную posture надёжности. Сравните active-active и active-passive (тёплый резерв), опишите, как трафик переключается (глобальный балансировщик или DNS с health-check), как реплицируются данные и какие RPO/RTO это даёт, компромиссы по стоимости и консистентности, и как вы регулярно тестируете failover. Объясните главные риски — split-brain и межрегиональную задержку.
Ваш сервис работает в одном регионе облака, и региональный сбой полностью выведет его из строя. Руководство хочет, чтобы он пережил потерю целого региона. Спроектируйте мультирегиональную posture надёжности. Сравните active-active и active-passive (тёплый резерв), опишите, как трафик переключается (глобальный балансировщик или DNS с health-check), как реплицируются данные и какие RPO/RTO это даёт, компромиссы по стоимости и консистентности, и как вы регулярно тестируете failover. Объясните главные риски — split-brain и межрегиональную задержку.
Работайте минимум в двух регионах, чтобы потеря одного была переживаема. Active-active обслуживает из обоих за глобальным балансировщиком с health-check — максимум доступности, но нужна репликация; active-passive переключается на тёплый резерв — дешевле, с RTO и потерей данных до RPO. Sync ужимает RPO, async даёт лаг; следите за задержкой и split-brain и репетируйте failover.
Типичные ошибки
- ✗Путать active-active и active-passive и их компромиссы
- ✗Игнорировать репликацию данных и вытекающие RPO/RTO
- ✗Никогда не репетировать failover, из-за чего он падает в нужный момент
Уточняющие вопросы
- →Как синхронная против асинхронной репликации меняет ваш RPO?
- →Что такое split-brain и как не дать двум регионам обоим стать primary?
SeniorДизайнИногдаВаша команда берёт круглосуточное дежурство по растущему набору сервисов. Сейчас оно пейджит постоянно, большинство алертов неактуальны, а инженеры выгорают и начинают пропускать настоящие пейджи. Спроектируйте модель on-call и алертинга. Опишите ротацию и эскалацию (primary и secondary), что достойно пейджа против тикета или дашборда, как severity соотносятся с ожиданиями по реакции, роль runbook и incident commander при крупном инциденте, и как держать качество алертов высоким со временем. Объясните, почему усталость от алертов сама по себе проблема надёжности.
Ваша команда берёт круглосуточное дежурство по растущему набору сервисов. Сейчас оно пейджит постоянно, большинство алертов неактуальны, а инженеры выгорают и начинают пропускать настоящие пейджи. Спроектируйте модель on-call и алертинга. Опишите ротацию и эскалацию (primary и secondary), что достойно пейджа против тикета или дашборда, как severity соотносятся с ожиданиями по реакции, роль runbook и incident commander при крупном инциденте, и как держать качество алертов высоким со временем. Объясните, почему усталость от алертов сама по себе проблема надёжности.
Пейджите только на действенные пользовательские симптомы — прожигание SLO через burn-rate алерты — а причины и шум шлите в тикеты. Держите ротацию primary/secondary с эскалацией, свяжите severity с реакцией, дайте алерту runbook, крупный инцидент — incident commander. Вычищайте шумные алерты, ведь усталость заставляет пропускать настоящие пейджи и растит MTTR.
Типичные ошибки
- ✗Пейджить на причины и шум, а не действенные пользовательские симптомы
- ✗Считать усталость от алертов лишь моралью, а не риском надёжности
- ✗Нет severity, runbook или incident commander для крупного инцидента
Уточняющие вопросы
- →Какие сигналы говорят, что ротация on-call перегружена?
- →Как решить, что алерт не действенный и его надо убрать?
SeniorДебаггингИногдаЧастичное замедление превратилось в полный отказ после ретраев клиентов — найдите причину и фикс
Частичное замедление превратилось в полный отказ после ретраев клиентов — найдите причину и фикс
Это retry storm (шторм повторов). B потеряла реплику и замедлилась; A повторяла сразу без backoff и jitter, повторы наложились по слоям, и нагрузка на B подскочила в 5 раз (8k→41k QPS) — thundering herd, насытивший её и каскадом ударивший в общий пул потоков. Фикс: экспоненциальный backoff с jitter, retry budget, ограничивающий повторы, circuit breaker (открыть при ошибках, half-open для пробы), плюс timeout и bulkhead; повторять только идемпотентные вызовы.
Открыть задачу →Типичные ошибки
- ✗Винить только потерю реплики, упуская усиление повторами
- ✗Чинить агрессивнее повторяя или убрав timeout, усугубляя шторм
- ✗Забыть jitter, retry budget или что повторам нужна идемпотентность
Уточняющие вопросы
- →Почему jitter важен поверх экспоненциального backoff?
- →Чем retry budget отличается от лимита повторов на один запрос?
