Алерт в 3 ночи: CPU 100% и рост задержек
Вопрос
Интервьюер: «3 ночи, burn-rate алерт по задержке, на всех подах сервиса CPU в потолке, трафик обычный, релизов не было. Что делаете?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Стабилизировать: добавить реплики или ресурсы, если есть запас, проверить HPA
Найти, что изменилось: данные, конкретные запросы, ночные задачи, флаги
Снять профиль с одного пода: py-spy, pprof, async-profiler
Проверить тяжёлые запросы по трейсам и логам: необычные параметры, большие объекты
Защититься: лимит на тяжёлый запрос, отключение функции, блокировка клиента
Постмортем: ограничения на вход, алерты, тест на такие данные
Что могут спросить следом
- Что если профиль показывает сборщик мусора?
- Как быть, если добавление реплик не помогает?
Разбор
Образцовый ответ: «Сначала даю сервису воздух: если HPA упёрся в максимум, а узлы есть, поднимаю лимит реплик, это покупает время. Трафик обычный и релизов нет, значит, изменился характер запросов или данные. Снимаю CPU-профиль с одного пода, для Go через pprof, для Python py-spy. Допустим, широкое плато в регулярном выражении валидации: катастрофический перебор на длинной строке. По логам и трейсам нахожу, что один клиент шлёт поле длиной 50 килобайт. Временно режу такие запросы на балансировщике лимитом размера и блокирую клиента. Задержка возвращается. Сообщаю статус. В постмортем: ограничение длины полей, безопасный движок регулярных выражений или таймаут, тест с длинными входными данными и алерт на троттлинг CPU. Если бы профиль показал GC, смотрел бы профиль аллокаций и рост кучи».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.