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

У чому різниця між 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-проба із замалим початковим очікуванням.

Що робить постмортем корисним, а не ритуальним?

Корисний постмортем безобвинувальний, тому люди описують те, що справді робили, а не те, що виглядає захищено, і він зосереджений на умовах, які дозволили помилці перетворитися на аварію. У ньому є точний таймлайн, розділені тригер і коренева причина, і він народжує невелику кількість задач із власником і датою, а не список побажань. Перевірка проста: чи зрозуміє за цим документом новий інженер аварію через рік і чи були доведені до кінця самі наслідки.