Вопросы по SRE на собеседовании: SLO, инциденты, отказоустойчивость

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

Что спрашивают

• +Цели: SLI, SLO и SLA, бюджет ошибок и его влияние на темп релизов, цена лишней девятки
• +Устойчивость: таймауты, ретраи с разбросом, предохранитель, деградация вместо отказа
• +Инциденты: митигация до расследования, роли на инциденте, постмортем без поиска виноватых
• +Ёмкость и восстановление: планирование по пикам, очередь и нелинейный рост задержек, RPO и RTO, проверка бэкапов

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Инциденты и постмортемы7
• SLI, SLO, error budget6
• Бэкапы и DR6
• Ёмкость и нагрузка6
• Отказоустойчивость6

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• SLI, SLO и бюджет ошибок6 вопросов
• Таймауты, ретраи и предохранитель6 вопросов
• Инциденты и постмортемы7 вопросов
• Ёмкость и планирование нагрузки6 вопросов
• RPO, RTO и проверка бэкапов6 вопросов

Примеры вопросов с разбором

1. #dvo_backup_dr1 / 9
   Что означают RPO и RTO в плане восстановления?

   A)RPO — потеря данных, RTO — время подъёма

   B)RPO — время восстановления, RTO — частота снятия резервных копий

   C)RPO — срок хранения копий, RTO — их количество

   D)RPO — доступность за год, RTO — допустимое число аварий

   показать ответ и разбор

   +A)RPO — потеря данных, RTO — время подъёма

   // разбор: RPO задаёт глубину потери данных: копия раз в сутки означает готовность потерять сутки работы. RTO задаёт время возвращения сервиса. Эти два числа определяют схему: RPO в минутах требует непрерывного архивирования журнала или репликации, RTO в минутах — тёплого резерва и отрепетированного переключения. Обе цифры берут из требований бизнеса, а не из возможностей текущей схемы.

2. #dvo_capacity2 / 9
   Планируем ёмкость по средней нагрузке за месяц. Что не так с этим подходом?

   A)Среднее считают по неверному окну: нужно брать неделю

   B)Средние по разным сервисам не складываются

   C)Систему кладут пики, а среднее их прячет

   D)Среднее не учитывает рост числа пользователей за месяц

   показать ответ и разбор

   +C)Систему кладут пики, а среднее их прячет

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

3. #dvo_incidents3 / 9
   Прод лежит, причина неясна. Что делают первым?

   A)Ищут причину: без неё лечение будет вслепую

   B)Восстанавливают работу: откат, переключение, отключение фичи

   C)Собирают всех причастных и распределяют зоны ответственности

   D)Пишут постмортем по горячим следам, пока детали свежие

   показать ответ и разбор

   +B)Восстанавливают работу: откат, переключение, отключение фичи

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

4. #dvo_resilience4 / 9
   Почему на каждый исходящий вызов ставят таймаут?

   A)Иначе внешний сервис сочтёт соединение мёртвым и разорвёт его

   B)Таймаут снижает нагрузку на сеть за счёт коротких соединений

   C)Без таймаута ответ приходит с задержкой и попадает не в тот запрос

   D)Иначе медленный сосед забирает потоки и роняет сервис целиком

   показать ответ и разбор

   +D)Иначе медленный сосед забирает потоки и роняет сервис целиком

   // разбор: Ожидание — это занятый поток, соединение и место в пуле. Если зависимость отвечает по десять секунд, очередь на входе растёт, пул кончается, и сервис перестаёт обслуживать даже те запросы, которым чужой ответ не нужен. Таймаут превращает чужую медлительность в свою управляемую ошибку: можно вернуть заглушку, отдать кэш или честный отказ и освободить ресурсы.

5. #dvo_slo5 / 9
   Как соотносятся SLI, SLO и SLA?

   A)SLI — измеряемый показатель, SLO — наша цель по нему, SLA — обещание клиенту

   B)SLI — соглашение с клиентом, SLO — внутренний отчёт, SLA — метрика сервиса

   C)Это три названия одного и того же в разных методологиях

   D)SLI и SLO задаёт бизнес, SLA считает система мониторинга

   показать ответ и разбор

   +A)SLI — измеряемый показатель, SLO — наша цель по нему, SLA — обещание клиенту

   // разбор: SLI — что измеряем: доля успешных запросов, доля ответов быстрее 300 мс. SLO — внутренняя цель по этому показателю: не ниже 99.9% за месяц. SLA — внешнее обязательство с последствиями за нарушение, обычно с запасом относительно SLO, чтобы штрафы не наступали от каждой мелочи. Работают в этом порядке: сначала измеримый показатель, потом цель, и лишь потом обещания наружу.

6. #dvo_backup_dr6 / 9
   База реплицируется на две реплики. Достаточно ли этого вместо резервных копий?

   A)Достаточно: реплики хранят полную копию данных

   B)Нет: ошибочное удаление доедет до реплик за секунды

   C)Достаточно, если реплики стоят в разных зонах доступности

   D)Нет, но хватит снапшотов дисков раз в неделю

   показать ответ и разбор

   +B)Нет: ошибочное удаление доедет до реплик за секунды

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

7. #dvo_capacity7 / 9
   При загрузке 60% сервис отвечает за 100 мс, при 85% — за 800 мс, хотя ресурсы ещё есть. Почему так резко?

   A)Ошибка измерений: на высокой нагрузке метрики запаздывают

   B)У предела очередь растёт нелинейно

   C)Сборщик мусора включается только под нагрузкой и добавляет паузы

   D)Балансировщик при высокой загрузке переключается на резервные узлы

   показать ответ и разбор

   +B)У предела очередь растёт нелинейно

   // разбор: Время ответа складывается из обработки и ожидания в очереди. Пока утилизация невелика, очередь пуста и виден только сам расчёт; ближе к пределу каждая новая единица нагрузки добавляет всё больше ожидания — рост гиперболический. Потому целятся не в стопроцентную загрузку, а в 60-70% с запасом: он оплачивает всплески, деплои и отказ части мощностей.

8. #dvo_incidents8 / 9
   На крупном инциденте разводят роли: командир, связной, исполнители. Зачем такая формальность?

   A)Чтобы распределить ответственность за последствия между людьми

   B)Чтобы соблюсти требования аудита и внешних проверок

   C)Чтобы дежурный не занимался задачами вне своей зоны

   D)Чинящий не отвлекается, решает один человек

   показать ответ и разбор

   +D)Чинящий не отвлекается, решает один человек

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

9. #dvo_resilience9 / 9
   Клиенты повторяют неудачные запросы сразу и по три раза. Сервис прилёг и не поднимается. Что произошло?

   A)Ретраи утроили нагрузку и держат сервис внизу синхронной волной

   B)Повторы забили пул соединений на балансировщике до истечения таймаутов

   C)Сервис принимает дубликаты и падает на конфликтах записи

   D)Кэш заполнился ошибочными ответами и отдаёт их новым клиентам

   показать ответ и разбор

   +A)Ретраи утроили нагрузку и держат сервис внизу синхронной волной

   // разбор: Мгновенные повторы превращают просадку в лавину: нагрузка растёт втрое ровно тогда, когда сервис слабее всего, а клиенты бьются синхронно, потому что стартовали от одного сбоя. Лечится экспоненциальной паузой со случайным разбросом, ограничением общего числа попыток и бюджетом ретраев на клиента. И отдельно: повторять можно только идемпотентные операции, иначе получите дубли платежей.

Частые вопросы

• Что такое бюджет ошибок простыми словами?

  Это допустимая доля отказов, обратная сторона цели. При 99.9 процента в месяце остаётся около 43 минут. Пока бюджет цел, команда катит изменения смело. Когда он сгорел, приоритет смещается на надёжность, и спор про фичи превращается в арифметику.

• Что отвечать на вопрос про действия при аварии?

  Сначала вернуть сервис: откат, переключение, выключение фичи флагом, ограничение трафика. Причину ищут после восстановления по сохранённым логам, метрикам и трассам. Обратный порядок стоит пользователям минут простоя.