Когда обращаться к другой команде при ошибках сервера?

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

Умеете ли вы локализовать серверную ошибку до передачи дальше и не застреваете ли на ней в одиночку. Следом обычно просят показать, что именно вы напишете другой команде, и спрашивают, когда проблему пора эскалировать.

Как отвечать

Стройте ответ как порядок действий. Сначала минут за пятнадцать выясните, чья это зона:

• код ответа: 500 чаще всего ошибка в самом сервисе, 502 и 504 указывают на связку шлюза и вышестоящего сервиса, 503 на недоступность или перегрузку;
• повтор без клиента: тот же запрос через Postman или curl, чтобы отсечь фронтенд;
• логи и трейсы: запрос ищется по request id или trace id в Kibana, Grafana Loki, Sentry, Jaeger. Стектрейс обычно сразу показывает, какой сервис упал первым;
• окружение: жив ли стенд, не идёт ли деплой, совпадают ли версии сервисов, не протухли ли тестовые данные и токены.

Идти к другой команде нужно, когда ошибка воспроизводится и цепочка ведёт в их сервис, в общую инфраструктуру (шлюз, база, брокер) или в их данные на стенде. Сразу, без долгой локализации, если это инцидент на проде или блокер релиза: тогда действуете по процессу управления инцидентами и ищете причину параллельно.

Обращение оформляйте так, чтобы его взяли в работу без уточнений: эндпоинт, запрос и ответ, время с часовым поясом, стенд, trace id, частота воспроизведения и что уже проверено. Пишите в их очередь в трекере или дежурный канал, а не в личку конкретному разработчику. Приведите свой пример и срок, за который проблему закрыли.

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

Пишут «у вас 500» без идентификатора запроса и времени. Другая команда тратит час на поиск того, что вы нашли бы за пять минут.

Идут слишком рано: своё окружение не проверили, а причина оказалась в неверно настроенном стенде или в собственных тестовых данных.

Идут слишком поздно: полдня молча ждут, пока «само починится», и срывают сроки тестирования. Блокер поднимают сразу, а в тикете отмечают, что тестирование стоит.