Кто занимается развёртыванием и поддержкой инфраструктуры

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

Где проходит граница между вами и командой инфраструктуры и понимаете ли вы, что Go-сервис должен уметь сам, чтобы нормально жить в кластере. Следом часто спрашивают, дежурили ли вы и что делали при последнем инциденте.

Как отвечать

Сначала роли, как они были у вас:

• SRE или платформенная команда: Kubernetes, сеть, инфраструктура как код на Terraform, мониторинг и алерты уровня кластера, SLO;
• разработчики: код сервиса, Dockerfile, Helm-чарт или манифесты, метрики и логи приложения, иногда дежурство по своему сервису;
• общая зона: разбор инцидентов и постмортемы с участием обеих сторон.

Потом покажите, что знаете свою часть на Go:

• образ: многоэтапная сборка, CGO_ENABLED=0 для статического бинарника и минимальный базовый образ вроде distroless или scratch;
• остановка: signal.NotifyContext на SIGTERM и http.Server.Shutdown с таймаутом, чтобы дослать текущие запросы;
• ресурсы: начиная с Go 1.25 GOMAXPROCS учитывает лимит CPU контейнера, на старых версиях для этого подключали automaxprocs. GOMEMLIMIT помогает сборщику мусора не упираться в лимит памяти пода;
• наблюдаемость: метрики через prometheus/client_golang, структурные логи через log/slog, трейсы через OpenTelemetry, профилирование через net/http/pprof на отдельном порту;
• пробы: отдельные ручки liveness и readiness.

Если инфраструктуру полностью вела другая команда, скажите об этом и назовите, что умеете сами: прочитать манифест, найти причину рестарта через kubectl describe и логи.

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

Говорят «инфраструктурой занимаются девопсы» и не знают, как их сервис получает сигнал остановки. На вопросе о потерянных при деплое запросах такой ответ разваливается.

Открывают pprof на публичном порту. Это выставляет внутренности процесса наружу.

Задают лимит памяти пода без GOMEMLIMIT и удивляются OOMKilled на кратковременных пиках, хотя средняя загрузка низкая.