Внедрить SLO в продуктовой команде
Вопрос
Интервьюер: «Продукт хочет выпускать фичи каждый день, а эксплуатация жалуется на нестабильность. Как вы примените SLO, чтобы снять конфликт?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Выбрать ключевые пользовательские сценарии и SLI вместе с продуктом
Цель по истории и ожиданиям пользователей, а не «пять девяток»
Политика бюджета, согласованная заранее всеми сторонами
Burn-rate алерты и видимый всем дашборд бюджета
Регулярный пересмотр и связь с инцидентами и постмортемами
Пример решения: когда бюджет есть, ускоряемся; когда нет, чиним
Что могут спросить следом
- Что делать, если продукт требует релиз при пустом бюджете?
- Как поступать, если бюджет съел сбой внешнего провайдера?
Разбор
Образцовый ответ: «Конфликт возникает, потому что у сторон разные метрики успеха. SLO даёт одну. Вместе с продуктом выбираю 2-3 сценария, важных деньгами: вход, поиск, оплата. SLI доля успешных и быстрых запросов на балансировщике. Цель ставлю по истории последних трёх месяцев и по тому, что реально чувствуют пользователи. Затем политика: пока бюджета больше половины, релизы без ограничений; меньше 25%, только с канарейкой; бюджет исчерпан, заморозка рискованного и задачи надёжности в спринт. Подписывают её продукт и техдиректор заранее. Дашборд бюджета видят все, алерты по burn rate. Исключения при пустом бюджете возможны, но решение принимает человек с полномочиями и записывает. Сбои провайдера считаем честно: пользователю всё равно, чья вина, а это аргумент за резервирование».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.