Запитання для інтерв’ю з SRE/DevOps: Допомога для обох сторін

Вступ

Проведення ефективних технічних інтерв'ю може бути складним, особливо для посад Site Reliability Engineer (SRE), що вимагають поєднання навичок програмування, усунення несправностей та управління інфраструктурою. Цей посібник надає корисні поради та приклади запитань для інтерв'ю, щоб допомогти рекрутерам ефективно оцінити кандидатів. Він охоплює ключові стратегії, від вправ на усунення несправностей на основі сценаріїв до оцінки знань Kubernetes, практик хмарної інфраструктури та процесів CI/CD. Незалежно від того, чи є ви досвідченим рекрутером, чи новачком, цей підхід спростить ваш процес найму та допоможе вам знайти адаптивних, високопродуктивних кандидатів, які здатні працювати під тиском. Цей посібник також підходить для молодших / середніх SRE-інженерів, щоб зрозуміти високорівневі концепції, які шукають рекрутери. Це спрощений набір запитань для інтерв'ю, який я використовував для найму чудових кандидатів, заснований на подібній структурі.

Поради та хитрості для рекрутерів

Що слід робити

• Інтерв'ю з «кодовими» завданнями, що проводяться особисто, зазвичай дають найкращі результати. Це включає в себе запитання для ходового пояснення при спільному перегляді екрану. Такі питання мають бути простими, наприклад, усунення несправностей невдачі Kubernetes pod (залишаючи це реалістичним). Живе налагодження та усунення несправностей під час таких завдань показують, як кандидат працює під тиском і демонструють його процес вирішення проблем. Навіть якщо вони не вирішують проблему одразу, важливо побачити, як вони працюють через складні питання.
• Оскільки штучний інтелект (GenAI) активно впроваджується в програмуванні, слід уникати завдань на дому. Посади SRE сильно зосереджені на здатності кандидата адаптуватися до нових викликів. Сценарії або питання середньої складності з leetcode працюють краще.
• Дозвольте більшості членів команди, а якщо можна, то всім, зустрітися з кандидатом, навіть молодшим членам команди, оскільки це саме ті люди, до яких нові кандидати звертаються на початку, і вони можуть вигорати через передачу знань.
• Розділіть інтерв'ю, запитання та інтерв'юерів навпіл (якщо можливо). Тобто одна половина запитує питання з області додатків / розробки, а інша половина — з інфраструктури.
• Отримайте резюме від менеджерів з найму заздалегідь, адже я багато разів стикався з компаніями, які очікують, що я проведу детальне інтерв'ю, не прочитавши резюме кандидата.
• Якщо кандидат має багато сертифікатів, прохання щодо усунення несправностей обов'язкові, а також більше конкретних запитань за сценаріями.

Що не слід робити

• Обережно ставте запитання на зразок HackerRank або задачі, орієнтовані на розробників програмного забезпечення, якщо кандидат не планує працювати з цією частиною технологічного стека. Я стикався з численними інтерв'ю та компаніями, які проводять великі тестування коду, тільки для того, щоб зрозуміти, що кандидат ніколи не буде працювати з цією частиною стека або буде невдало переведений на роль full-stack інженера. Це дарма витрачає час.
• Уникайте занадто великої кількості інтерв'ю та перешкод для кандидатів. Одне або два години сценарних запитань, а також можливе завдання для усунення несправностей — це достатньо, щоб оцінити сильного кандидата.
• Не задавайте багато запитань на кшталт «що робить ця команда», якщо це не критично важливо. Тримайте питання за сценаріями, відкритими, щоб побачити, як кандидат вирішував подібні ситуації в минулому. Початкове відкрито запитання, потім розширюйте його більш конкретними питаннями, щоб запобігти довгим відповідям чи визначити рівень досвіду кандидата.

Формат

• Загальний час: 1.5 години
• 3–4 члени команди
• 20 хвилин для кожного члена команди
• 15 хвилин для запитань наприкінці

Запитання для інтерв'ю

курсив = що має на меті це питання

цитата = саме питання

• маркери = додаткові підказки, загальні відповіді

Нижче наведено приклад посібника, який може змінюватися залежно від технологічного стеку компанії.
Широкі сценарії високого рівня, які працювали чудово у минулому, допомогли вибрати сильних кандидатів, здатних адаптуватися під тиском.

Інфраструктура

Запитання 1: Проектування інфраструктури (10 хв)

Шукаємо найкращі практики щодо проектування та впровадження інфраструктури в середовищі публічної хмари. Це включає такі речі, як питання безпеки та висока доступність. Просте початкове питання, щоб розкрити досвід з хмарними платформами. Підштовхуйте кандидата до опису налаштувань, які вони використовували раніше, наприклад, безсерверні рішення, Kubernetes мікросервіси тощо.

Розкажіть, будь ласка, про ваші обов'язки щодо хмарної інфраструктури на попередніх посадах?

• Чи брали ви участь у плануванні нових хмарних середовищ та основної інфраструктури?
• Якби ви могли згадати, які найкращі практики ви б врахували при впровадженні нової інфраструктури? (підштовхуйте до прикладів конкретних хмарних ресурсів, якщо потрібно. Обчислювальні інстанси, бази даних, pub/sub, кешування тощо.)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 2: Проектування на масштаб (5 хв)

Шукаємо більш глибокі знання з інструментів IAC, як керувати IAC з великою кількістю команд, що використовують повторно код IAC. Декілька конкретних наступних запитань, наприклад, щодо команд Terraform, оновлення провайдерів тощо, будуть доречними.

Як би ви спроектували інфраструктурну систему для (~10 команд? ~100 додатків?), щоб конфігурації були масштабовані? Що щодо інфраструктурних ресурсів?

• Як ви ставитесь до поділу на команди або додатки?
• Чи має інфраструктуру керувати команда розробників чи SRE/DevOps?
• (якщо кандидат згадав Terraform і не згадав модулі) яке використання мають модулі в Terraform?
• Чи має інфраструктуру керувати монорепозиторій чи окремі репозиторії?
• Чи використовували ви інфраструктуру, що вимагає схвалення (наприклад, Atlantis, Terraform Enterprise тощо)?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 3: Хмарні мережі (5 хв)

Шукаємо загальні мережеві концепції на рівні хмарних ресурсів. Не прив’язано до конкретної платформи, ці навички можна застосувати в будь-якому хмарному провайдері. Базовий тест для визначення найкращих практик для балансування високої доступності та безпеки при відкритті додатків для публіки.

Як би ви налаштували хмарне середовище для обробки вхідного та вихідного трафіку до хмарних ресурсів, наприклад обчислювальних інстансів, баз даних тощо?

• Балансування навантаження
• NAT
• Сегментація мережі
• Міжмережеві екрани / Групи безпеки

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 4: Мережі контейнерів (5 хв)

Це питання трохи складніше, не задавайте його, якщо ви не використовуєте ці інструменти/ресурси. Шукаємо концепції обробки трафіку всередині кластера або мережі сервісів. Не ставте всі наступні питання одразу, вони є додатковими підказками.

Які можливі рішення, інструменти та найкращі практики ви б впровадили для обробки трафіку в контейнерних мережах? Це включає трафік до і з кластера, а також міжконтейнерний трафік.

• API Gateways
• Ingress
• Сервіси K8s, порти
• Мережа сервісів
• Балансування навантаження
• Наступні питання, залежно від відповіді:

1. У чому різниця між NodePort та ClusterIP?

2. Як сервіс маршрутизує трафік до pod'ів?

3. Для чого ви б використовували мережу сервісів?

4. Недоліки або мінуси: коли ви б уникали або не рекомендували використовувати мережу сервісів?

5. Для чого використовується virtualservice в Istio?

6. Як ви можете відкрити pod для трафіку ззовні кластера?

7. Як безпечно відкрити внутрішній інструмент, який сидить на вашому кластері, для ваших інженерних команд?
   Де ви б здійснили завершення HTTPS та як би ви це реалізували?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 5: Управління секретами + RBAC (5 хв)

Шукаємо найкращі практики при налаштуванні секретів для різних команд + управлінням деяким RBAC, щоб команди не могли отримати доступ до секретів один одного. Також досліджуємо, як запобігти витокам секретів у CI/CD потоки або в git репозиторії (це сталося в багатьох компаніях).

Як ви керували секретами між кількома командами, що працюють в одному кластері? Наприклад, команда повинна мати можливість шифрувати/дешифрувати свої власні секрети, але не чужі.

• GSM, SSM, Kubernetes секрети, Vault тощо
• sops?
• KMS ключі для кожної команди для шифрування лише їхніх секретів
• Використання RBAC для KMS ключів та секретів
• Pre-commits або gitleak дії для запобігання витокам у VCS / CI-CD

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 6: Процеси команди

Моє улюблене питання, немає правильних чи неправильних відповідей, але воно показує, як кандидат справляється зі стресовими ситуаціями та міжкомандною комунікацією. Сильний/старший кандидат відкладе свої амбіції на другий план, розуміє потребу в конкретній ситуації та здатний адаптуватися до вимог.

Сценарій: Ваша команда знайшла нові інструменти та хоче інтегрувати їх у свою платформу, наприклад, сканування коду. Як ви будете координувати цю роботу з іншими командами? Які виклики ви мали з цим у минулому?

• Вплив vs Зусилля, тобто чи є інструмент просто гарним, чи він допомагає досягати бізнес-цілей (покращення безпеки, покращення DevEX, зменшення "блоту" тощо). Найкраще — це пропозиційні документи, що описують ці аспекти.
• Огляд/Опитування: визначення проблеми, співпраця з інженерами для отримання їхньої точки зору / потреб
• Управління toil і відгуки: як вони справляються з цим?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 7: Управління інцидентами

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

Сценарій: Нова функція, робочий процес або інструмент, який ви інтегрували, спричинили деякий простій на платформі. Як ви вирішили цю ситуацію, щоб це не сталося знову?

• Документ постмортему, розбитий на такі пункти:

1. Опис помилки (що пішло не так)
2. Вплив помилки
3. Виявлення помилки (титули, повідомлення, сповіщення)
4. Відгук і відновлення (послідовність подій)
5. Подальші завдання + уроки, які ми засвоїли

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 8: Kubernetes

Шукаємо основи Kubernetes, це може змінюватися в залежності від технічного стека компанії.

Опишіть деякі кращі практики для запуску нового розгортання в Kubernetes для продакшн-середовища?

1. Liveness і Readiness probes, коли ви б використовували одну з них?

2. Як діагностувати pod, що перевищив доступну пам'ять?

3. Чи використовуєте ви Kubernetes секрети, чи порекомендували б іншу альтернативу?

4. Коли ви б використовували sidecar проти init контейнера?

5. Різниця між replicaset і daemonset?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 8: Спостережуваність

Шукаємо не просто перелік інструментів, а теорію, що стоїть за моніторингом.
Як знайти сигнал серед шуму, провідні індикатори проти запізнілих індикаторів, Золоті метрики (Latency, Traffic, Errors, Saturation)

Як ви налаштовуєте моніторинг для типової служби? Які метрики важливі? Які інструменти ви використовуєте для збору та відображення цих метрик?

• Як ви обробляли сповіщення, які надсилали забагато хибних тривог?
• Які моніторингові стеки ви налаштовували і який ваш вклад у цей процес?
• Що б ви зробили, щоб уникнути того, щоб вас попереджали через один повільний/невдалий запит посеред ночі (під час низького трафіку)?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Запитання 9: CICD

Шукаємо, як кандидат визначав проєкт і його вимоги, та як він їх виконував. Розуміння глибини знань щодо повних CICD процесів і як безпечно виконати деплой/відкат.

Опишіть конфігурацію CI/CD, якою ви пишаєтеся? Які вимоги були поставлені і як ви їх виконали? Які інструменти ви використовували?

• Що відбувається, коли хтось відкриває pull request?
• Що відбувається, коли хтось зливає pull request?
• Як реліз просувається з середовища розробки до продакшн середовища?
• Як змінюється схема бази даних перед релізом?
• Що робити, якщо реліз потрібно відкотити (але схема була змінена)?

Висновки

Набір правильного SRE вимагає не лише технічних оцінок; потрібно оцінювати здатність до адаптації, комунікації та вирішення проблем в умовах реального світу. Орієнтуючись на запитання, засновані на сценаріях, і уникаючи занадто теоретичних завдань, ви можете створити процес інтерв'ю, який ідентифікує не лише технічну компетентність, але й здатність кандидата співпрацювати і справлятися зі стресом. Використовуйте цей посібник для створення структурованого, справедливого та ефективного процесу інтерв'ю, що допоможе вашій команді залучити найкращі таланти, готові вирішувати складні інженерні завдання. Пам'ятайте, що добре підготовлений процес інтерв'ю позитивно позначається на вашій організації та дає кандидатам можливість досягти успіху.

Перекладено з: SRE/DevOps Interview Questions: Help for Both Sides