Присутствовал ли мониторинг межсервисного взаимодействия

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

Видели ли вы распределённую систему в работе, а не только в коде. Хороший ответ различает метрики, трассировку и логи и объясняет, на какой вопрос отвечает каждый из трёх слоёв.

Как отвечать

Опишите, как было устроено у вас, по этим слоям. Метрики: у каждого исходящего вызова считаются число запросов, доля ошибок и время ответа по перцентилям. В Spring это Micrometer плюс Actuator, сборщик снимает метрики по HTTP, поверх дашборды и алерты. Обязательно скажите про p95 и p99: среднее время ответа прячет ровно те запросы, из-за которых приходят жалобы.

Трассировка: сквозной идентификатор передаётся заголовком traceparent, каждый сервис заводит свой спан, и по одной трассе видно, какой вызов съел время. В свежих версиях Spring Boot за это отвечает Micrometer Tracing с экспортом по OpenTelemetry.

Логи: тот же идентификатор трассировки кладётся в MDC и попадает в каждую строку, поэтому из трассы можно провалиться в логи конкретного запроса.

Дальше скажите, что смотрят не только успех: таймауты клиента, срабатывания предохранителя и повторные попытки, состояние пула соединений, глубина очереди, отставание консьюмера. И что алерт вешается на симптом, заметный пользователю, а не на каждую метрику подряд. Если такого не было, честно опишите, что было, и чего не хватало.

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

Перечисляют инструменты вместо схемы. Фраза про то, что был сборщик метрик и дашборды, не отвечает на вопрос, что именно смотрели и как ловили проблему между двумя сервисами.

Приносят готовые цифры улучшения из шаблонного рассказа: время реакции упало на треть, надёжность выросла. Такие числа просят подтвердить: как мерили, с какого периода, кто считал, и подтвердить оказывается нечем.

Путают трассировку с логированием. Строка «вызвал соседний сервис» в логе это не трассировка: без общего идентификатора и спанов цепочку вызовов не собрать и не увидеть, на каком участке копились миллисекунды.