Ощущение — не факт
В разработке очень легко обмануть себя. Ты открываешь сайт, кликаешь, ждёшь, и думаешь "что-то медленно работает". Проблема в том, что это не факт. Это ощущение. У меня был конкретный кейс. Я видел, что добавление товара в корзину работает медленно, прямо чувствовалось. Хотел сразу идти оптимизировать. Пошёл к CTO. Ответ был простой: "пока не покажешь цифры, ничего трогать не будем". Правильный ответ. Без цифр ты не решаешь проблему, ты угадываешь.

Первые метрики
На тот момент у нас вообще не было нормальных метрик: ни latency, ни ошибок, ни понимания, где именно проблема. Мы начали с базового: подключили Prometheus, подняли Grafana, начали собирать данные. Только после этого стало видно, где именно проседает система. Дальше подключили продуктовую команду и посмотрели на воронку: где пользователи отваливаются, как это влияет на конверсию. Технически система работала, ошибок немного, ничего не падает. Но по метрикам было видно: задержка есть, пользователи теряются, деньги теряются. После этого уже можно было принимать решения, а не угадывать. В итоге конверсия выросла в 2-3 раза.
Что смотреть
Среднее значение latency почти бесполезно. Важно смотреть на p95 и p99, что происходит у "худших" пользователей, потому что именно они уходят и не покупают. Error rate это не только 500-е ошибки, это таймауты, неуспешные операции, частичные сбои. И самое важное продуктовые метрики: как техническое состояние системы влияет на конверсию и деньги. Без метрик архитектура превращается в мнение: "кажется, это быстрее", "давай перепишем", "мне не нравится". Это не инженерия. Это угадывание.

Метрики и рост
Если хочешь расти, нужно перестать думать только кодом. На уровне middle и выше от тебя ждут не "написать код", а улучшить систему с измеримым результатом. Это значит, уметь поставить метрику, прочитать её, связать с проблемой, предложить решение. Если у тебя в проекте нет метрик, ты работаешь вслепую. Даже если кажется, что всё нормально.