Какой деплоймент вы использовали: Docker, Kubernetes или другое
Что проверяют
Настоящий опыт эксплуатации, а не знание слов. По ответу видно, доходила ли ваша ответственность до прода или заканчивалась на мерже. Уточняющий вопрос предсказуем: как выкатываете без простоя, что делаете при падении пода и почему приложение убивают по памяти.
Как отвечать
Идите по слоям и на каждом отмечайте свою роль:
- образ: многостадийный
Dockerfile, базовыйeclipse-temurinили distroless, запуск от непривилегированного пользователя, слоёная раскладка Spring Boot черезlayertoolsили сборка через buildpacks, чтобы зависимости не пересобирались на каждый коммит; - JVM в контейнере: не фиксированный
-Xmx, а-XX:MaxRAMPercentage, потому что лимит пода меняется; лимит CPU влияет на число потоков GC и на общий пул; с Java 24 доступен кеш AOT (-XX:AOTCache), заметно ускоряющий старт; - оркестрация:
Deployment,Service,Ingress,ConfigMapиSecret, requests и limits,startupProbeпод медленный старт JVM,readinessProbeчтобы трафик не пришёл раньше готовности,livenessProbeмаксимально дешёвая; - выкатка: rolling update с
maxSurgeиmaxUnavailable, корректное завершение черезpreStopи graceful shutdown приложения,PodDisruptionBudget, автомасштабирование по метрике; - доставка конфигурации: Helm или Kustomize, GitOps через Argo CD, миграции базы отдельным шагом, а не при старте всех реплик разом.
Если Kubernetes у вас не было, скажите прямо: docker compose на виртуалке, systemd, Nomad, PaaS. Честный рассказ про compose с описанием его ограничений выглядит сильнее выдуманного кластера.
Где спотыкаются
Приписывают себе чужую инфраструктуру и рассыпаются на первом уточнении про манифесты или про то, кто дежурил по инцидентам.
Не знают, откуда берётся код завершения 137. Это OOMKill по лимиту контейнера, а не OutOfMemoryError в JVM, и хип тут может быть вообще ни при чём.
Вешают livenessProbe на health-check, который ходит в базу. Просела база, кластер начал перезапускать исправные поды, и локальная проблема превратилась в полный отказ.