Как происходит взаимодействие с девопс командой

Что проверяют

Считаете ли вы эксплуатацию своей зоной ответственности или «отдал бинарник, дальше девопсы». Go-разработчику почти всегда задают следом практический вопрос: что сервис должен уметь, чтобы его было удобно деплоить и мониторить.

Как отвечать

Расскажите о своём процессе: кто владеет пайплайном, кто пишет Dockerfile и Helm-чарты, как проходит ревью инфраструктурного кода, кто дежурит. Потом покажите, что вы делаете со своей стороны:

• образ: multi-stage Dockerfile, статический бинарник с CGO_ENABLED=0, минимальный базовый образ вроде distroless;
• конфигурация: через переменные окружения и секреты, один образ на все окружения;
• пробы: отдельные /healthz и /readyz. Readiness сообщает, что сервис готов принимать трафик, например поднял соединение с базой;
• остановка: по SIGTERM сервис перестаёт брать новые запросы и дорабатывает текущие. В Go это signal.NotifyContext и http.Server.Shutdown(ctx);
• наблюдаемость: метрики для Prometheus через promhttp, структурированные логи через log/slog, трассировка через OpenTelemetry;
• ресурсы: лимиты CPU и памяти согласуют с девопсами. С Go 1.25 рантайм сам учитывает лимит CPU контейнера при выборе GOMAXPROCS, раньше для этого брали automaxprocs. Под лимит памяти выставляют GOMEMLIMIT.

Цифры приводите свои: как часто деплоите, сколько идёт пайплайн, что изменилось после ваших правок. Если отдельной DevOps-команды не было и CI вы писали сами, это даже сильнее, так и скажите.

Где спотыкаются

Воспринимают девопсов как сервис, которому ставят задачи. На вопрос про падение в проде рассказывают, как ждали, пока «девопсы разберутся».

Не обрабатывают SIGTERM и не делают readiness. На каждом деплое часть запросов обрывается, а в логах это выглядит как случайные 502.

Называют круглые проценты ускорения без базы сравнения. Интервьюер спросит, как мерили, и ответа не будет.