Один навык сделает вас ценным в любой команде — умение находить и устранять узкие места производительности.

Скорость приложения — это не просто «хорошо иметь».
Это деньги, стабильность и доверие пользователей.

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

Почему так происходит?

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

Но есть хороший инструмент, который решает эту проблему — трейсинг с OpenTelemetry.
Он позволяет пройти вместе с запросом через всю цепочку сервисов и увидеть, где именно начинается задержка.

Это настоящий рентген системы.

Если вы хотите внедрить распределённый трейcинг, автор подготовил пошаговый гайд, который можно адаптировать под любой .NET-проект.

Вот отличная отправная точка:
milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet