Собеседование DevOps и SRE — это не про перечисление инструментов, а про решения в условиях ограничений: что откатывать первым, на что ставить алерт и что сознательно оставить сломанным до утра. Ниже — вопросы, которые задают чаще всего, каждый с эталонным ответом. Middle: более глубокое понимание, оптимизацию и реальные рабочие ситуации.
Сначала kubectl describe pod, потому что в секции событий лежат провалы вытягивания образа, неудавшиеся монтирования, OOMKilled и провалы проб — большая часть ответа до того, как прочитана хоть одна строка лога. Затем kubectl logs --previous, поскольку текущий контейнер может быть секунды от роду и не записать ничего. Затем код выхода, и если пахнет OOM — лимит памяти против фактического потребления.
Он сопоставляет вашу конфигурацию с реальными ресурсами, чтобы Terraform знал, чем владеет. Опасен тем, что авторитетен: потеряете — и Terraform предложит собрать всё заново, потому что перестал знать об этих ресурсах. Он же хранит секреты открытым текстом, а два одновременных apply без блокировки его портят — поэтому удалённый бэкенд с блокировкой, шифрованием и версионированием не опция.
SLI — то, что вы измеряете, SLO — цель на окне, error budget — та ненадёжность, которую вам разрешено потратить. Ценность не в метрике, а в переговорном инструменте: он превращает «надо притормозить и заняться надёжностью» из мнения, которое всегда проигрывает роадмапу, в арифметику, о которой обе стороны договорились заранее.
Rolling требует мало запаса, но одновременно работают две версии, поэтому миграция обязана быть обратно совместимой, нравится вам это или нет. Blue-green даёт мгновенный откат и удваивает инфраструктуру, а миграцию делает сложнее, а не легче, потому что обе среды делят одну базу. Canary ловит настоящие проблемы, но лишь если наблюдаемость успевает заметить внутри окна.
Внешнее хранилище — Vault, облачный менеджер секретов, — где нагрузка аутентифицируется по идентичности, а не по другому секрету, и именно это отличает решение от переноса проблемы. Подстановка во время работы лучше вшивания в образ, потому что образ копируется и кешируется повсюду. Ротация — то, что чаще всего исключают из дизайна и потом не могут добавить.
Метрика — число во времени, отвечает на вопрос, есть ли проблема. Лог — событие с деталями, отвечает, что произошло. Трейс следует за одним запросом через сервисы и отвечает, куда ушло время. Команды обычно переинвестируют в логи, которые дороже всего хранить и хуже всего годятся, чтобы заметить проблему, которую вы ещё не искали.
Достаточно, чтобы понять, что инстанс может обслуживать, и не более. Проверка общей базы означает, что одна проблема с базой выведет сразу все инстансы; проверка одного лишь процесса означает, что трафик продолжит приходить туда, где ответить не могут. Обычный ответ — неглубокий эндпоинт, подтверждающий, что приложение живо и его зависимости достижимы, отдельно от глубокой readiness.
Две обычные причины. Либо кончились не байты, а inode — миллионы мелких файлов, — это сразу видно по df -i. Либо процесс держит открытым уже удалённый файл, поэтому блоки не освобождены, а df файл уже не считает; находит lsof +L1, а освобождает перезапуск держателя. Третий вариант на ext — те самые 5%, зарезервированные под root, к которым пишущий не от root не подступится.
Только ключи — PasswordAuthentication no, — без прямого входа под root, с явным ограничением, кому вообще можно, через AllowUsers или группу, и с бастионом впереди вместо выставленного наружу каждого хоста. Ключи персональные, а не один общий: общий нельзя отозвать для одного уволившегося. Дальше: вместо проброса агента — ProxyJump, на ключи автоматизации — ограничение command=, а когда парк вырос настолько, что раздача ключей стала отдельной проблемой, — центр сертификации.
На собеседовании ты говоришь вслух под давлением. Кем задаст эти же вопросы, оценит каждый ответ и покажет, что именно подтянуть.
Пройти интервью Middle DevOps / SRE →