ch
Feedback
Библиотека собеса по DevOps | вопросы с собеседований

Библиотека собеса по DevOps | вопросы с собеседований

前往频道在 Telegram

Вопросы с собеседований по DevOps и ответы на них. Учиться у нас: https://clc.to/nLEtvA По рекламе: @proglib_adv Для обратной связи: @proglibrary_feeedback_bot

显示更多
3 443
订阅者
+124 小时
-27
+530
帖子存档
В многоарендном Kubernetes-кластере один «шумный сосед» периодически выедает CPU/IO и ломает SLA остальных сервисов. Как обеспечить изоляцию и предсказуемое качество без избыточного оверпровижининга? Дать критичным сервисам QoS Guaranteed (requests=limits), ввести LimitRange/ResourceQuota по namespace, приоритизацию через PriorityClass и развести пулы нод с taints/tolerations. Включить HPA/VPA + Cluster Autoscaler, задать корректные PDB и параметры RollingUpdate. Для «шумного» сервиса — жёсткие лимиты (CPU CFS), контроль IO/ephemeral-storage и при необходимости — вынести в отдельный node pool. Библиотека собеса по DevOps

Чем отличается COPY от ADD в Dockerfile? Инструкция COPY копируют файлы и директории с хостовой машины внутрь контейнера, инструкция ADD копирует файлы и директории с хостовой машины внутрь контейнера и может распаковывать .tar архивы. Библиотека собеса по DevOps

Что такое role/clusterRole? Роли определяют права с помощью наборов правил, которые включают: — Группы API, описанные в официальной документации по apiGroups и выводимые командой kubectl api-resources; — Ресурсы (например, pod, namespace, deployment и другие); — Глаголы (например, set, update и другие); — Имена ресурсов (resourceNames), которые используются в случае необходимости предоставления доступа к определенному ресурсу, а не ко всем ресурсам данного типа. Библиотека собеса по DevOps

Нужно выстроить end-to-end software supply chain для деплоя в Kubernetes: запрет неподписанных образов, проверка SBOM и уязвимостей, защита от дрейфа манифестов при GitOps. Как это реализовать от коммита до admission? Подписываем артефакты и коммиты (OIDC → Cosign/Sigstore), в CI собираем образ, генерируем SBOM (Syft) и аттестации (provenance), ставим vuln-gates (Trivy/Grype). Публикуем в immutable-registry, пин по digest. На кластере — Kyverno/OPA: verifyImages + проверка аттестаций/SBOM, allowlist registry, non-root/seccomp/capDrop. Деплой через Argo CD c верификацией подписи манифестов, drift-detection и policy-as-code; для аварий — контролируемый break-glass. Библиотека собеса по DevOps

Что такое публичный IP-адрес? В каких сценариях/проектах систем его следует использовать? Публичный IP-адрес — это общедоступный IP-адрес. Если вы размещали игровой сервер, к которому вы хотите, чтобы ваши друзья присоединились, вы дадите своим друзьям свой общедоступный IP-адрес, чтобы их компьютеры могли идентифицировать и определить местонахождение вашей сети и сервера для установления соединения. Единственный момент , когда вам не понадобится использовать общедоступный IP-адрес, это если вы играете с друзьями, которые были подключены к той же сети, что и вы, и в этом случае вы будете использовать частный IP-адрес. Чтобы кто-то мог подключиться к вашему внутреннему серверу, вам необходимо настроить переадресацию порта, чтобы сообщить маршрутизатору, что он разрешает трафик из общедоступного домена в вашу сеть и наоборот. Библиотека собеса по DevOps

У вас критичный API в Kubernetes. Нужно выкатывать версии без простоя и с возможностью быстрого отката. Какой подход выберете (rolling, blue-green, canary), чем его обоснуете и как реализуете (Ingress/Service переключение, health-checks, метрики/автооткат, миграции БД)? Canary через Argo Rollouts/Flagger с взвешенным трафиком, автооткат по SLO (5xx/p95), корректные пробы/preStop; миграции БД по схеме expand → migrate → contract. Библиотека собеса по DevOps

🔥 Последняя неделя перед стартом курса по AI-агентам Старт курса уже 15го числа! Если вы планировали вписаться — сейчас ПОСЛ
🔥 Последняя неделя перед стартом курса по AI-агентам Старт курса уже 15го числа! Если вы планировали вписаться — сейчас ПОСЛЕДНИЙ шанс забронировать место На курсе:разложим LLM по косточкам: токенизация, SFT, PEFT, инференс — соберём RAG и научимся оценивать его адекватно — построим настоящую мультиагентную систему — архитектуру, которая умеет расти — разберём CoPilot, сломаем через prompt injection (спасибо Максу) — и наконец, посмотрим, как это работает в MCP и реальных кейсах 📍 Это 5 живых вебинаров + раздатка + домашки + чат с преподавателями И главное — возможность реально разобраться, как проектировать системы на LLM, а не просто «поиграться с API» Промокод на 5.000₽: LASTCALL 👉 Курс здесь

Нужно выкатывать ломающее изменение схемы БД для микросервиса в Kubernetes без простоя. Деплой — RollingUpdate, трафик критичный. Как спланировать и выполнить релиз, чтобы избежать даунтайма и иметь безопасный откат? Применить стратегию expand → migrate → contract: Expand: сначала деплой приложения, совместимого со старой и новой схемой (feature-flag, двусторонняя совместимость чтения/записи). Migrate: выполнить онлайн-миграцию как Kubernetes Job (идемпотентная, с контролем lock timeout), порционно/батчами, с мониторингом SLO. Для MySQL — gh-ost/pt-online-schema-change, для Postgres — pg_repack. Contract: после валидации и прогрева трафика — удалить устаревшие поля/индексы. Параллельно — canary/blue-green, readinessProbe по версии схемы, бэкап/снэпшот, план отката (down-миграции/флаг отката), и блокировка релиза при нарушении error budget. Библиотека собеса по DevOps

Что такое Immutable Infrastructure и какие преимущества она даёт? Immutable Infrastructure — подход, при котором серверы/контейнеры не изменяются после деплоя: при апдейте создаётся новый инстанс, а старый удаляется. Плюсы: предсказуемость окружений, отсутствие "дрейфа конфигурации", простота отката и высокая надёжность. Библиотека собеса по DevOps

Какие стратегии деплоя поддерживает Kubernetes и когда ты применял каждую из них? RollingUpdate — по умолчанию, постепенно заменяет поды без даунтайма (чаще всего применяю). Recreate — останавливает все поды и потом поднимает новые (редко, если несовместимые изменения). Blue/Green, Canary — через отдельные Deployment/Service или с помощью Istio/Argo Rollouts, использовал для тестирования новых фич с ограниченной аудиторией. Библиотека собеса по DevOps

В CI/CD пайплайне деплой в Kubernetes часто занимает больше времени, чем ожидалось. Pod’ы создаются, но приложение не готово обслуживать трафик, и пользователи видят ошибки. Как вы будете искать и устранять проблему? Проверю стратегию деплоя (например, RollingUpdate), наличие корректных readinessProbe и livenessProbe, а также настройки maxUnavailable и maxSurge. Проанализирую логи Pod’ов и события кластера. Для решения — настрою health-check’и, добавлю preStop hook для graceful shutdown и оптимизирую пайплайн так, чтобы трафик шёл только на готовые Pod’ы. Библиотека собеса по DevOps

Иногда реально ощущение, что нас держат в Матрице. Большинство сидит, читает статьи про ML, смотрит ролики «как это работает»
Иногда реально ощущение, что нас держат в Матрице. Большинство сидит, читает статьи про ML, смотрит ролики «как это работает» — и всё. ❗ Сегодня последний день промокода Lastcall (−5000 ₽). Уже завтра стартует первый вебинар по Машинному обучению — полный набор для выхода из Матрицы. Кто готов вырваться из симуляции и ворваться в сезон найма? 👾 — я уже в команде Нео 👍 — хочу красную таблетку 🤔 — пока думаю, но интересно Забирай полный комплект для ML-разработки: Python + Математика + Машинное обучение. 🔥 Скидка 30% действует только до 9 сентября → забираем себе

Вы разворачиваете продакшн-инфраструктуру для AI-агентов (LLM, ML inference) в контейнерах Docker. В процессе эксплуатации замечаете проблемы: непредсказуемое потребление GPU/CPU, медленный cold start контейнеров и рост задержек при масштабировании. Как вы будете искать и устранять эти проблемы? Сначала соберу метрики (Prometheus, NVIDIA DCGM, cAdvisor) для анализа загрузки CPU/GPU/памяти. Проверю, что контейнеры используют правильные runtime (например, nvidia-docker2 или --gpus all). Для cold start оптимизирую образы (multi-stage build, минимальные base image, preloading моделей в volume или кеш), а для масштабирования — внедрю оркестрацию (Kubernetes + GPU scheduler, autoscaler) и подготовлю warm-pool контейнеров. Кстати, у нас скоро стартует курс AI-агенты для DS-специалистов: https://proglib.academy/ai-agents Библиотека собеса по DevOps

Вы разворачиваете продакшн-инфраструктуру для AI-агентов (LLM, ML inference) в контейнерах Docker. В процессе эксплуатации замечаете проблемы: непредсказуемое потребление GPU/CPU, медленный cold start контейнеров и рост задержек при масштабировании. Как вы будете искать и устранять эти проблемы? Сначала соберу метрики (Prometheus, NVIDIA DCGM, cAdvisor) для анализа загрузки CPU/GPU/памяти. Проверю, что контейнеры используют правильные runtime (например, nvidia-docker2 или --gpus all). Для cold start оптимизирую образы (multi-stage build, минимальные base image, preloading моделей в volume или кеш), а для масштабирования — внедрю оркестрацию (Kubernetes + GPU scheduler, autoscaler) и подготовлю warm-pool контейнеров. Кстати, у нас скоро стартует курс AI-агенты для DS-специалистов: https://proglib.academy/ai-agents Библиотека собеса по DevOps

⚡️ Будь как этот гений с картинки — предлагай свои условия работодателю, а не наоборот! Кто нужен? Senior ML-Engineer с опыто
⚡️ Будь как этот гений с картинки — предлагай свои условия работодателю, а не наоборот! Кто нужен?
Senior ML-Engineer с опытом работы более 6 месяцев в FAANG компаниях. Требование: разработать кросс-платформенное приложение-трекер зарплат с AI-распознаванием вакансий по резюме.
Но если вы пока джун — я бы предложил: - Full-time контракт: 180к/мес после курса + опцион на карьеру в топ-компаниях - Либо фикс за проект: стань ML-инженером за 39к вместо 44к с промокодом LASTCALL 🔗 Старт 9 сентября

Чем отличается StatefulSet от Deployment? Deployment — ресурс Kubernetes предназнваенный для развертывания приложения без сохранения состояния. При использовании PVC все реплики будут использовать один и тот же том, и ни один из них не будет иметь собственного состояния. StatefulSet — поддерживают состояние приложений за пределами жизненного цикла отдельных модулей pod, например для хранилища. Используется для приложений с отслеживанием состояния, каждая реплика модуля будет иметь собственное состояние и будет использовать свой собственный том. Библиотека собеса по DevOps

🎮 КВЕСТОВАЯ ЛИНИЯ: «Путь Data Scientist'а» ⮕ Твой стартовый набор искателя данных: Python — твое легендарное оружие (урон по
🎮 КВЕСТОВАЯ ЛИНИЯ: «Путь Data Scientist'а» ⮕ Твой стартовый набор искателя данных:
Python — твое легендарное оружие (урон по багам +∞) Математика — твой базовый интеллект (влияет на понимание алгоритмов) Машинное обучение — твое дерево навыков (открывает новые способности)
⚡️ АКТИВЕН ВРЕМЕННЫЙ БАФФ: «Щедрость наставника» Эффект: –30% к цене полного набора ДСника Было: 121.800 ₽ → Стало: 84.900 ₽ ☞ Что ждет тебя в этом квесте
— Получение артефактов: портфолио проектов и сертификаты— Прокачка от новичка до Senior Data Scientist— Босс-файты с реальными задачами из индустрии— Доступ к гильдии единомышленников
📎 Забрать бафф Рассрочки: 3 мес | 6 мес | 12 мес

✍️ Почему мы используем тома в Docker? Мы используем тома Docker для безопасного хранения данных вне контейнеров Docker. Они предоставляют отдельное место на хостах, где данные живут, даже если контейнер удаляется. Кроме того, проще управлять, делать резервные копии и делиться томами между контейнерами. Библиотека собеса по DevOps

В Kubernetes-продакшене вы замечаете, что Pod периодически убивается и перезапускается, при этом в kubectl describe pod видно событие OOMKilled. Как будете диагностировать и устранять проблему? Проверю метрики памяти Pod’а (kubectl top pod, Prometheus), проанализирую requests/limits, логи приложения и профилировку на предмет утечек. Если приложение действительно потребляет больше памяти — оптимизирую код или увеличу лимиты. Если лимиты выставлены неправильно — подкорректирую их. Для критичных сервисов настрою HPA/VPA, чтобы они масштабировались под нагрузкой. Библиотека собеса по DevOps