> Как решаются вопросы инфраструктуры и поддержки (Go)

Короткий ответ

Вопросы инфраструктуры и поддержки в Go-проектах решаются через комбинацию: автоматизация CI/CD (GitHub Actions, GitLab CI), контейнеризация (Docker, Kubernetes), observability (Prometheus, Grafana, OpenTelemetry), structured logging и централизованный сбор ошибок (Sentry). Поддержка включает SLA, on-call ротацию, runbooks и postmortem-процессы. Ключевой принцип - инфраструктура как код (Terraform, Helm), чтобы окружения были воспроизводимы, а изменения проходили code review.

Подробное объяснение

Инфраструктура для Go-сервисов обычно строится вокруг нескольких слоёв:

• Сборка и доставка: multi-stage Docker build (образ на scratch или distroless для уменьшения размера), артефакты версионируются, деплой через rolling update или blue-green.
• Конфигурация: 12-factor подход - конфиг через env vars, секреты в Vault или Kubernetes Secrets, feature flags через отдельный сервис (LaunchDarkly, Unleash).
• Наблюдаемость: метрики (Prometheus + custom metrics через expvar или client_golang), трейсинг (OpenTelemetry, Jaeger), логи в JSON-формате для парсинга в Loki/ELK.
• Поддержка: алерты по SLO (latency, error rate), дашборды для дежурных, runbook для типовых инцидентов, эскалация по severity.

Для Go специфичны: профилирование (pprof) в проде через отдельный порт, graceful shutdown, обработка сигналов SIGTERM, контроль утечек горутин через runtime metrics.

На практике

Senior-инженер отвечает за:

• Проектирование деплой-пайплайна: сборка, тесты (unit, integration, race detector), статический анализ (golangci-lint), сканирование зависимостей (govulncheck).
• Настройку observability: middleware для HTTP/gRPC, экспорт метрик, алерты с правильными порогами.
• On-call процессы: документация, эскалация, бламелесс postmortem.
• Capacity planning: нагрузочное тестирование (k6, vegeta), автоскейлинг на основе метрик.

Пример реального кейса: сервис падает по OOM - сначала смотришь pprof heap, потом добавляешь лимиты памяти в Kubernetes, настраиваешь алерт по RSS, добавляешь в runbook команды для дампа heap.

Пример кода

GO
// middleware для метрик и трейсинга
func MetricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        httpRequests.WithLabelValues(r.Method, r.URL.Path).Observe(time.Since(start).Seconds())
    })
}

// graceful shutdown
func main() {
    srv := &http.Server{Addr: ":8080"}
    go srv.ListenAndServe()
    
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)
    <-quit
    
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    srv.Shutdown(ctx)
}

Как отвечать на собеседовании

Структурируй ответ по слоям: сборка → деплой → наблюдение → поддержка. Начни с конкретики вашего проекта, затем обобщай. Упомяни trade-off: например, почему выбрали Kubernetes, а не Nomad, или почему Prometheus, а не InfluxDB. Покажи понимание полного цикла: от коммита до инцидента и postmortem. Если спрашивают про конкретный инструмент - опиши сценарий его использования, а не просто определение.

Что проверяет интервьюер

• Понимание жизненного цикла сервиса, а не только написания кода.
• Умение проектировать отказоустойчивые системы (graceful shutdown, retries, circuit breaker).
• Знание практик observability и алертинга (SLO, SLI, burn rate).
• Опыт работы с инфраструктурой как кодом и автоматизацией.
• Навыки дежурства: как действует при инциденте, как проводит postmortem.

Типичные ошибки

• Ответ только про Docker и CI, без упоминания мониторинга и алертов.
• Игнорирование специфики Go: pprof, race detector, runtime metrics.
• Отсутствие конкретики: "настраиваем Prometheus" без деталей про метрики и алерты.
• Непонимание разницы между logging и tracing, когда что использовать.
• Забывают про безопасность: сканирование образов, секреты, сетевые политики.