Співбесіда 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 →