Где вы запускаете проекты: на серверах или в контейнерах
Что проверяют
Есть ли у вас реальный опыт эксплуатации своего кода и понимаете ли вы, как JVM ведёт себя в контейнере. Следом обычно спрашивают, как вы задавали память, как были устроены health-чеки и как выкатывали новую версию без простоя.
Как отвечать
Отвечайте от своего опыта, но с деталями, по которым видно, что вы этим занимались:
- где и как: Docker-образ и Kubernetes, fat jar Spring Boot под
systemdна виртуалке или сервер приложений вроде WildFly. Уточните, кто писал манифесты и пайплайн: вы, DevOps или платформенная команда; - сборка образа: многоступенчатый
Dockerfile, Jib илиspring-boot:build-imageс buildpacks. Слоистый jar позволяет не перекачивать зависимости при каждом релизе, а базовый образ лучше брать с JRE, а не с полным JDK; - память: современная JVM видит лимиты cgroups, но размер кучи по умолчанию обычно всего четверть лимита. Его задают через
-XX:MaxRAMPercentage, оставляя запас на метаспейс, стеки потоков и off-heap, иначе контейнер убьёт OOM killer; - пробы: Spring Boot Actuator отдаёт
/actuator/health/livenessи/actuator/health/readiness, их и подключают к Kubernetes. Для долгого старта естьstartupProbe; - остановка: получив
SIGTERM, приложение должно доделать текущие запросы, в Spring Boot за это отвечаетserver.shutdown=graceful.
Если работали только на серверах, так и скажите и опишите, как был устроен деплой: скрипты, Ansible, откат. Затем покажите, что понимаете, что изменили бы контейнеры: одинаковое окружение от ноутбука до прода, откат по тегу образа, горизонтальное масштабирование.
Где спотыкаются
Отвечают «везде Docker», но не могут объяснить, откуда берётся образ и как он попадает на прод. Интервьюер быстро понимает, что всё делал кто-то другой.
Не знают про память JVM в контейнере. Классика: -Xmx, равный лимиту пода, после чего под регулярно уходит в OOMKilled.
Подменяют ответ шаблоном с выдуманным результатом вроде «ускорили деплой на 50%». Лучше честная цифра из своего проекта или описание вовсе без процентов.