Middle DevOps / SRE — Питання на співбесіді DevOps інженера

Як влаштовані шари Docker і як тримати образ малим?

Кожна інструкція створює read-only шар, шари кешуються і перевикористовуються, доки не змінювалося все, що було до них, — тому маніфест залежностей копіюють і ставлять залежності до копіювання вихідників. Розмір знижують багатоступеневою збіркою, що лишає компілятор позаду, slim- або distroless-базою та обʼєднанням команд, щоб проміжні файли взагалі не потрапили в шар. Видалення файлу в пізнішому шарі образ не зменшує — він усе ще лежить у ранньому шарі.

Поясніть звʼязок між Pod, Deployment і Service.

Pod — мінімальна планована одиниця: один або кілька контейнерів зі спільним мережевим простором і життєвим циклом. Deployment керує ReplicaSet, який тримає заявлену кількість однакових подів і забезпечує rolling-оновлення та відкати. Service дає цьому змінному набору подів стабільний віртуальний IP і DNS-імʼя, балансуючи між тими подами, що зараз підходять під селектор, тож викликаючій стороні не треба стежити за адресами окремих подів.

У чому різниця між liveness і readiness пробами?

Readiness-проба вирішує, чи йде на под трафік; її провал прибирає под з ендпоінтів сервісу, але лишає його працювати. Liveness-проба вирішує, чи перезапускати контейнер. Їх плутанина — класична аварія: якщо спрямувати liveness на залежність, то повільна база перезапустить усі репліки одночасно, перетворивши деградацію на повний простій. Liveness має перевіряти лише «чи не завис процес», readiness — «чи можу я обслуговувати просто зараз».

Що таке Terraform state і чим він небезпечний?

State зіставляє ресурси, оголошені в конфігурації, з реальними обʼєктами у провайдера, щоб Terraform розумів, що створити, змінити чи видалити. Небезпечний він тим, що є джерелом істини: втративши його, Terraform перестає знати, що володіє вашою інфраструктурою, і спробує створити її наново. Крім того, він часто містить секрети у відкритому вигляді. Тому state тримають у віддаленому бекенді з шифруванням, версіонуванням і блокуванням, щоб два інженери не зробили apply одночасно.

Коли використовувати Terraform, а коли Ansible?

Terraform — декларативний провіжинінг: він створює і видаляє інфраструктуру та приводить реальність до оголошеного стану. Ansible — процедурне керування конфігурацією: він виконує впорядковані задачі на вже наявних машинах. Чистий поділ такий: Terraform для всього, що має життєвий цикл у хмарному API, Ansible для того, що відбувається всередині віртуалки. На стеку з Kubernetes роль Ansible сильно стискається, бо образи контейнерів замінюють конфігурацію машин.

Що таке SLI, SLO і error budget?

SLI — вимірюваний показник здоровʼя сервісу, наприклад частка запитів, обслужених успішно швидше за 300 мс. SLO — ціль за цим показником на вікні, скажімо 99,9% за 30 днів. Error budget — допустимий недобір, ті самі 0,1% запитів, і він перетворює надійність на витратний ресурс: доки бюджет цілий, можна котити швидше, а коли вичерпано, фічі заморожують і лагодять надійність. Саме це перетворює суперечку «надійність проти швидкості» зі смаківщини на арифметику.

У чому різниця між метриками, логами і трейсами?

Метрики — дешеві числові агрегати в часі, відповідають на питання «щось зламалося?» і саме на них ставлять алерти. Логи — дискретні події з деталями, відповідають «що саме сталося» в конкретному запиті чи компоненті. Трейси простежують один запит крізь сервіси і відповідають «куди пішов час» у розподіленому ланцюжку викликів. Алертити за логами дорого й шумно, а налагоджувати за самими метриками — вгадування. Потрібні всі три, кожен за призначенням.

Порівняйте rolling, blue-green і canary викати.

Rolling замінює інстанси поступово, майже не потребує запасної потужності, але під час викату трафік обслуговують дві версії, а відкат повільний. Blue-green тримає повноцінне друге оточення і перемикає трафік разом, даючи миттєвий відкат ціною подвійної потужності й важкої проблеми міграцій бази. Canary спрямовує невелику частку трафіку на нову версію і дивиться метрики перед розширенням, що ловить проблеми на реальних користувачах, але окупається лише за доброї спостережуваності та автоматичного аналізу.

Як правильно поводитися з секретами в пайплайні?

Секрети не живуть ні в репозиторії, ні в шарах образу, ні у звичайних змінних оточення, зашитих на етапі збірки. Вони приходять із виділеного сховища — Vault, хмарний secret manager або зашифровані секрети CI — і підставляються в рантаймі з мінімально можливою областю дії та строком життя. Короткоживучі креди через OIDC-федерацію кращі за довгоживучі ключі, бо головний ризик не в крадіжці секрету, а в секреті, який лишається валідним роками.

Под у стані CrashLoopBackOff. Розберіть хід діагностики.

Починають з kubectl describe pod і дивляться події — там видно помилки завантаження образу, невдалі монтування, OOMKilled і провалені проби. Потім kubectl logs з --previous, бо поточний контейнер може бути надто молодий, щоб устигнути щось записати. Перевіряють код виходу на предмет OOM і порівнюють ліміт памʼяті з реальним споживанням. Якщо контейнер стартує і одразу вмирає, звичайні причини — відсутній конфіг чи секрет, міграція, що падає на старті, або liveness-проба із замалим початковим очікуванням.