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

У чому різниця між continuous integration, delivery і deployment?

Continuous integration означає, що кожен коміт вливається і перевіряється автоматичною збіркою й тестами, тому гілка не розходиться з main. Continuous delivery означає, що кожна зелена збірка дає артефакт, готовий до продакшену, а фінальний викат лишається людським рішенням. Continuous deployment прибирає це рішення — кожна зелена збірка їде в прод. Різниця важлива на співбесіді, бо більшість команд, які заявляють CD, насправді практикують delivery.

Як влаштовані шари 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 спрямовує невелику частку трафіку на нову версію і дивиться метрики перед розширенням, що ловить проблеми на реальних користувачах, але окупається лише за доброї спостережуваності та автоматичного аналізу.