Мок-интервью DevOps-инженера: инциденты, Linux и Kubernetes

Коротко о видео

В живом мок-собеседовании кандидат сначала рассказывает об опыте с геораспределённым Proxmox-кластером и MySQL Galera. Затем интервьюер предлагает практические DevOps-сценарии: скачок API-ошибок после релиза, несовместимую миграцию БД, I/O bottleneck, место после удаления открытого файла, inode, сбой egress, DNS или TLS в Kubernetes и OOMKilled. Во второй половине разбирают реагирование на компрометацию self-hosted GitHub Actions runner, восстановление PostgreSQL через PITR и WAL, GPU в Kubernetes, блокировки Terraform, DevSecOps-пайплайн, XZ Utils и защиту цепочки поставок. После основной части обсуждают EXT4, домашнюю лабораторию и карьеру.

Затронутые темы

Что взять на заметку

• При скачке ошибок после релиза сопоставляют метрики и логи с изменениями, ограничивают ущерб и только затем выбирают rollback или hotfix.
• Высокий load average при неполной загрузке CPU может указывать на I/O wait. Процесс бэкапа сначала диагностируют, а при необходимости снижают его приоритет и меняют расписание.
• Место после удаления файла не освободится, пока процесс держит его открытым. Такой дескриптор находят через lsof; при ошибке No space left при свободном месте также проверяют inode.
• При таймауте из пода к внешнему HTTPS API проверяют egress NetworkPolicy, DNS, маршрутизацию, TLS-цепочку и время на ноде.
• При компрометации self-hosted runner замораживают деплой, изолируют среду, исследуют сетевую и облачную активность, отзывают учётные данные и пересоздают runner.
• PITR PostgreSQL требует согласованной базовой копии и WAL-архива. Восстановление проводят на точку перед ошибочной транзакцией с учётом RPO и RTO.
• Terraform force-unlock нельзя выполнять вслепую: нужно проверить оборванный apply и состояние, связаться с работающим инженером и только затем снимать блокировку.
• SBOM и подписи образов нужно перевыпустить после компрометации среды сборки, поскольку доверие к ним зависит от целостности CI/CD.