> Как искать проблему, если после тестирования на тестовом стенде в продакшене что-то сломалось (Go)

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

Сначала фиксирую факт инцидента и его влияние на пользователей, затем стабилизирую систему через rollback или feature flag, и только потом ищу root cause. Сравниваю конфигурацию, версии, данные и нагрузку между стендом и продакшеном, смотрю метрики, логи, трейсы и недавние деплои. После устранения провожу blameless postmortem и закрываю пробел в тестах или процессе.

Пример по STAR

Ситуация: после релиза нового сервиса на Go в продакшене выросла latency на эндпоинте оформления заказа, хотя на тестовом стенде все тесты и нагрузочные прогоны проходили. Действие: я сразу откатил релиз через feature flag, чтобы вернуть SLO, затем поднял инцидент и собрал данные. Сравнил профили CPU и heap, метрики connection pool к Postgres и конфигурацию таймаутов. Оказалось, что на стенде pool был больше, а в продакшене под нагрузкой горутины блокировались на ожидании соединения. Результат: после тюнинга pool и добавления метрики ожидания latency вернулась в норму, а в CI добавили проверку конфигурации и нагрузочный тест с продовыми лимитами.

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

Покажите, что вы действуете по приоритетам: сначала impact и стабилизация, потом диагностика. Назовите конкретные инструменты для Go-бэкенда: pprof, expvar, OpenTelemetry, structured logs, метрики Prometheus. Объясните, как вы сужаете пространство гипотез через diff между окружениями, canary-релизы и анализ последних изменений. Подчеркните, что не ищете виноватого, а устраняете системную причину. В конце расскажите, как вы предотвращаете повторение: contract-тесты, chaos engineering, проверки конфигураций, алерты на saturation.

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

Умение сохранять хладнокровие и приоритизировать под давлением. Навык системной диагностики, а не хаотичного перебора. Понимание различий между тестовым стендом и продакшеном. Опыт работы с observability и инцидент-менеджментом. Способность доводить расследование до профилактики и делиться выводами с командой.

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

Сразу бросаться искать root cause, оставляя пользователей без сервиса. Обвинять коллег или тестировщиков. Ограничиваться одним предположением и не проверять альтернативы. Игнорировать данные о нагрузке, конфигурации и данных в продакшене. Заканчивать инцидент без postmortem и изменений в процессе.