Собеседование DevOps и SRE — это не про перечисление инструментов, а про решения в условиях ограничений: что откатывать первым, на что ставить алерт и что сознательно оставить сломанным до утра. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Senior: архитектуру, трейд-оффы, менторство и принятие решений.
Сделав каждый деплой обратимым независимо, а это в основном ограничивает базу: расширять до сужения, никогда не удалять в том же релизе, в котором перестали писать. Второе требование — откат должен использоваться: путь, который проходят раз в квартал во время инцидента, — это путь, который не работает. Фиче-флаги разводят релиз и деплой и превращают большинство откатов в правку конфигурации.
Сначала восстановить сервис, диагностировать вторым: откат, перевод трафика или масштабирование не требуют знания первопричины. Кто-то владеет координацией и при этом сам не отлаживает, а хронология пишется по ходу, потому что память потом восстанавливает её неверно. Разбор спрашивает, что сделало отказ возможным и что сделало его долго незамеченным, а не кто набрал команду.
На симптомы, которые чувствует пользователь: доля ошибок, задержка, недоступность, — а не на причины, потому что причин много и большинство безвредны. У каждого алерта должно быть действие; тот, который регулярно подтверждают и игнорируют, обучает людей игнорировать алерты. Мера качества — сколько срабатываний были лишними, и это число надо регулярно смотреть.
Сначала на requests против фактического потребления, потому что завышенные requests резервируют мощность, которой никто не пользуется, и это крупнейший источник потерь. Затем на размер узлов и упаковку, затем на то, что работает и никому не принадлежит: старые среды, забытые балансировщики, снапшоты. Хранилище и исходящий трафик — строки, которые растут тихо и никогда не попадают в первую оценку.
Импортируя, а не пересоздавая, по одному ограниченному куску, начиная с малорискового, чтобы процесс обкатался до того, как станет важен. Трудность не в инструменте, а в правиле, что ручные правки прекращаются: код, разошедшийся с реальностью, хуже отсутствия кода — ему доверяют, и он неверен. Проверку расхождений надо запускать по расписанию.
Относясь к количеству срабатываний как к числу дефектов с владельцем, а не как к погоде. Ротация, которая будит по ночам, выжигает людей, и текучка обходится дороже инженерного времени на устранение причин. Конкретные практики: задача-последствие с каждого срабатывания, потолок допустимой рутины и время в следующем спринте, зарезервированное под то, что вскрыло прошлое дежурство.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Senior DevOps / SRE →