Чек-лист продакшена для Go-сервиса

Прогресс

Отметки сохраняются в вашем браузере: можно пройти чек-лист частями и вернуться позже.

Запрос без таймаута — это зависший воркер, съеденный connection pool и падение.

• У HTTP-клиента задан таймаутЗначение http.Client.Timeout ограничивает всю операцию, включая чтение тела ответа. Без него клиент может висеть до разрыва соединения.

  client := &http.Client{
      Timeout: 10 * time.Second,
  }

• Каждый внешний вызов получает context с дедлайномКонтекст прокидывается вниз по цепочке вызовов: база, HTTP-запрос, чтение файла. Благодаря этому отмена запроса клиента действительно отменяет работу.

  ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
  defer cancel()
  
  if err := repo.Save(ctx, order); err != nil {
      return err
  }

• У пула соединений к базе есть лимит жизни соединенияВ pgx задайте MaxConnLifetime: база может закрыть соединение, и следующий запрос получит ошибку. Именно MaxConnLifetime, а не MaxConnIdleTime, защищает от этого.

  pool, err := pgxpool.New(ctx, dsn)
  pool.Config().MaxConnLifetime = 30 * time.Minute

• Нет select без таймаута и без defaultОжидание канала без ветки таймаута и без default — это способ навсегда заблокировать горутину. Пустой select{} блокирует всегда.

Сервис должен уметь завершиться, не оборвав запросы на полуслове.

• Обработка SIGTERM и SIGINTСервис должен ловить сигнал остановки. В Go это делает signal.NotifyContext — контекст, который отменяется по сигналу.

  ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
  defer stop()

• HTTP-сервер останавливается через Shutdownhttp.Server.Shutdown ждёт завершения текущих запросов и закрывает listener. Простое os.Exit обрывает запросы на полуслове.

  ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
  defer cancel()
  
  if err := srv.Shutdown(ctx); err != nil {
      log.Error("shutdown", "err", err)
  }

• Воркеры дожидаются завершенияПосле остановки HTTP-сервера нужно дождаться фоновых горутин: WaitGroup.Wait() перед выходом из main.
• Ресурсы закрываются в обратном порядке открытияСоединения с базой, файлы, каналы и клиенты внешних сервисов закрываются через defer сразу после открытия — тогда порядок не важно.

Оркестратор должен понимать, жив ли процесс и готов ли он принимать трафик.

• Есть эндпоинт livenessLiveness отвечает «процесс жив» и не должен ходить в базу: иначе при временной недоступности базы оркестратор перезапустит healthy-сервис.
• Есть эндпоинт readiness с проверкой зависимостейReadiness отвечает «можно ли принимать трафик». Во время деплоя или миграции он должен возвращать отказ, чтобы новые поды не получали запросы.
• Health-check слушает отдельный портОтдельный порт для служебных эндпоинтов упрощает сетевые правила: внешний балансировщик не должен достучаться до /debug/pprof.

Ограничение тела запроса, числа соединений и частоты — базовая гигиена сервиса.

• Ограничен размер тела запросаhttp.MaxBytesReader защищает от запроса на гигабайты, который съест память сервиса. Лимит задавайте осознанно, а не по умолчанию «на всякий случай».

  r.Body = http.MaxBytesReader(w, r.Body, 1<<20) // 1 МБ

• У сервера заданы таймауты чтения заголовков и записиReadHeaderTimeout и WriteTimeout защищают от клиента, который открыл соединение и молчит. Без них соединения копятся и съедают пул.

  srv := &http.Server{
      ReadHeaderTimeout: 5 * time.Second,
      WriteTimeout:      30 * time.Second,
  }

• Есть ограничение частоты запросовRate limiter на входе (Redis, nginx или middleware) защищает и сервис, и соседние сервисы, к которым он ходит.
• Ограничено число одновременных операцийПул соединений к базе и лимит горутин на обработку запроса не дают одному всплеску трафика обрушить всё остальное.

Логи должны быть пригодны для чтения человеком и для агрегации машиной.

• Логи структурированныеКлючи и значения вместо склейки строк: так логи агрегируются и ищутся. В стандартной библиотеке это log/slog.

  slog.Info("order created",
      "order_id", id,
      "amount", amount,
  )

• В логи не попадают секреты и персональные данныеПароли, токены и карты не пишутся в лог: логи уезжают в агрегатор и часто читаются шире, чем хотелось бы.
• У запроса есть идентификатор, он попадает в логиИдентификатор запроса связывает логи разных сервисов и позволяет ответить на вопрос «где именно застрял пользователь».
• Ошибки логируются с контекстом и оборачиваютсяfmt.Errorf с %w сохраняет цепочку для errors.Is, а в лог попадает понятное человеку сообщение вместе с причиной.

Метрики отвечают на вопрос «что сломалось» до того, как об этом узнал пользователь.

• Есть метрика времени ответаГистограмма latency с разрезом по endpoint и статус-коду — базовый сигнал деградации сервиса.
• Есть счётчик ошибокОтдельно считайте 5xx и бизнес-ошибки: они лечатся по-разному, и в одном счётчике их не различить.
• Собираются метрики рантаймаЧисло горутин, использование памяти, работа GC: в Go это стандартные метрики prometheus/client_golang, подключаемые одним импортом.
• Метрики не содержат бесконечных значенийИдентификатор пользователя или полный URL в метке — это взрыв кардинальности: система метрик разрастается и тормозит. Ограничивайте набор значений.

Конфигурация проверяется при старте, а не в середине рабочего дня.

• Конфигурация валидируется при стартеЕсли порт или DSN не заданы, сервис должен упасть сразу с понятным сообщением, а не работать на дефолтах и падать позже.

  if cfg.Addr == "" {
      return errors.New("ADDR is required")
  }

• Конфигурация приходит извне, а не зашита в кодПеременные окружения или флаги: иначе под каждый набор значений нужен отдельный бинарник.
• Секреты не хранятся в репозиторииПароли и токены приходят из окружения или секрет-хранилища. Файл с секретами в git — самая дорогая ошибка этого списка.

Секреты, TLS, ввод пользователя и заголовки ответов.

• TLS настроен и сертификаты обновляютсяHTTP-схема в продакшене означает открытые пароли и токены. Не забудьте про перезагрузку сертификатов без остановки сервиса.
• SQL-запросы параметризованыИспользуйте плейсхолдеры ($1, ?) и не собирайте запрос склейкой строк. Иначе ваш сервис станет инструментом в чужих руках.
• Ввод пользователя валидируетсяДлина строк, формат, диапазоны. Валидация на границе сервиса дешевле, чем разбор последствий в базе и в логах.
• У ответов выставлены защитные заголовкиX-Content-Type-Options, X-Frame-Options или CSP, корректный Cache-Control. Для API чаще всего важнее всего запрет кэширования приватных ответов.

Проверки, которые ловят проблемы до релиза, а не после.

• Тесты проходят с детектором гонокgo test -race ./... ловит гонки данных, которые обычно проявляются на продакшене под нагрузкой и почти никогда — на тестах.
• В CI есть go vet и gofmtМинимальная проверка перед мержем: go vet ./... и проверка форматирования. Это ловит опечатки в Printf и споры о форматировании.
• Есть тесты на критичные сценарии с внешними зависимостямиtestcontainers поднимает настоящий PostgreSQL или Redis в тестах: проверки становятся ближе к боевым, а ручная рутина исчезает.
• В сборку попадает версия и коммитВерсия в /version и в логах нужна, чтобы по логу понять, какой код работает. Обычно это делают через -ldflags с переменными сборки.