Как понять, что сервис в продакшн работает корректно

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

Различаете ли вы «процесс жив» и «сервис делает свою работу», и умеете ли выразить корректность в измеримых сигналах. Следом обычно спрашивают, на что вы повесили бы алерт и чем readiness-проба отличается от liveness.

Как отвечать

Начните с SLI и SLO: например, 99,9% запросов за 30 дней без 5xx и p99 времени ответа ниже 300 мс. Без таких целей «работает корректно» нечем проверить.

Дальше слои наблюдаемости Go-сервиса:

• метрики: client_golang и promhttp.Handler() на /metrics. По маршрутам считают RED: число запросов, долю ошибок и гистограмму длительности, чтобы получать перцентили. Рантайм сам отдаёт горутины, память и паузы GC, и число горутин, растущее без остановки, почти всегда утечка;
• бизнес-метрики: созданные заказы, платежи, обработанные сообщения. Сервис может отвечать 200 и ничего не записывать;
• логи: структурированные через log/slog, с trace id, собранные в Loki или ELK;
• трассировка: OpenTelemetry показывает, где теряется время между сервисами;
• пробы Kubernetes: liveness отвечает только на вопрос «процесс не завис», readiness говорит, готов ли под принимать трафик;
• синтетика: blackbox exporter ходит в сервис снаружи, как пользователь.

Алерты вешайте на симптомы, которые чувствует пользователь, например на скорость сгорания бюджета ошибок, а не на загрузку CPU. Выкатывайте канареечно, сравнивая метрики новой и старой версии, с быстрым откатом. Для разбора инцидентов держите net/http/pprof на внутреннем порту: профили CPU, heap и горутин снимаются с живого процесса.

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

Считают, что зелёный /health означает здоровый сервис. Эндпоинт, который всегда отвечает 200, ничего не проверяет.

Проверяют в liveness доступность базы. База моргнула, Kubernetes перезапустил все поды разом, и короткий сбой превратился в полный простой.

Открывают pprof на публичном порту. Импорт net/http/pprof регистрирует хендлеры в http.DefaultServeMux, и если основной сервер работает на нём, профили и дамп горутин видны всем снаружи.