Автор: Александр Луценко · HighLoad Channel

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

Александр Луценко рассказывает, как команда перенесла профилирование с dev-окружения в production и превратила его в постоянный observability-сигнал. Мотивация проста: stage отличается от production железом, данными и формой нагрузки. Даже хороший нагрузочный тест не воспроизводит все сочетания условий, которые возникают в реальной системе.

Для сбора команда выбрала sampling profiler в отдельном sidecar-контейнере. Он не требовал менять код приложения или устанавливать расширение внутрь процесса. Профили отправлялись в коллектор, фильтровались, агрегировались и дополнялись метками сервиса, окружения и транзакции. Так отдельный flame graph превращался в историю поведения приложения между релизами.

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

Кому смотреть: backend- и platform-командам, которые хотят профилировать production или уже собирают профили, но рассматривают их отдельно от метрик и distributed tracing.

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

Автор: Лёша Королёв · Яндекс для разработчиков

Лёша Королёв — техлид команды observability в Яндекс Go. В этом докладе он показывает, как команда строит единый дашборд для платформы, в которой больше тысячи микросервисов, тысячи подов, базы данных, балансировщики, очереди и сотни изменений в проде каждый день. Когда происходит мажорный инцидент, проблема не в том, что у команды нет метрик. Проблема в том, что среди этого масштаба нужно быстро найти короткий путь к причине.

Дальше он разбирает, как устроен единый дашборд платформы такси и какие требования к нему предъявляет команда. Его задача — не показать всё на одном экране, а помочь ответить на два вопроса: в какой части платформы проблема и как такси чувствует себя прямо сейчас.

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

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

Автор: Алексей Мерсон · Код Желтый

Алексей Мерсон работает в Sage — внутренней observability-платформе Т-Банка. Доклад открывает конференцию по надёжности и наблюдаемости, организованную той же командой: это намеренно вводный разговор — синхронизировать понятия, прежде чем идти глубже.

Центральная структура доклада — пирамида качества: в основании надёжность, выше опыт пользователя. Это не абстракция: если система ненадёжна, весь разговор про UX и satisfaction теряет смысл. Надёжность Мерсон определяет через SRE-буки Google — вероятность выполнить требуемые функции без отказов за заданный период. Из этого вырастают SLI (конкретная метрика, связанная с пользовательским опытом), SLO (целевое значение) и бюджет ошибок — то время, которое система может «лечь», не нарушив SLO. Ключевые метрики для оптимизации — MTBF (среднее время между отказами) и MTTR (среднее время восстановления): чем больше первое и меньше второе, тем лучше используется бюджет ошибок. Наблюдаемость нужна именно для того, чтобы обе величины улучшать — без неё, по словам Мерсона, «бежишь через горящий лес с закрытыми глазами».

Кому смотреть: инженерам и тимлидам, которые слышали слова SLO, observability и MTTR в разных контекстах, но хотят разложить их по полочкам и понять, как они связаны между собой — до того как разбираться с конкретными инструментами.

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

Автор: Олег Казаков · Spectr

Олег Казаков — CTO в Spectr, выступал на митапе Spectr в сентябре 2025 года. Spectr — продуктовая IT-компания, и Казаков рассказывает о внедрении observability изнутри: не как консультант, а как человек, который жил с проблемой и решал её в работающем продукте.

«Тушение пожаров» — это диагноз: команда реагирует на инциденты после того, как они случились, вместо того чтобы видеть деградацию заранее. Observability меняет режим работы с реактивного на проактивный. Казаков разбирает, как это сделать без enterprise-бюджета: стек Prometheus + Loki, который покрывает 90% потребностей продуктовой команды, и подход к внедрению в существующий продукт без остановки разработки. Центральный тезис: не нужен Datadog за сотни тысяч долларов в год. Нужны правильные метрики, алерты, которые срабатывают до того как пользователи пишут в поддержку, и процесс, который команда реально использует.

Кому смотреть: CTO и техлидам продуктовых компаний, у которых observability — это «когда-нибудь потом» или «слишком дорого», и которые хотят конкретный стек и подход для старта.

Из этого можно взять в работу: определи три метрики, которые лучше всего описывают здоровье твоего продукта (p95 latency, error rate, длина очереди задач). Настрой алерты только на них — всё остальное потом. Три правильных алерта лучше, чем 300 шумящих.