Представьте, что вы владелец продукта (ну или вам даже не нужно это представлять😁), из всех утюгов пишут про метрики продукта, метрики бизнеса и всякие дау, мау, вау и тп., а про технические метрики как-то либо специфично, либо непонятно написано, либо непонятно как это применить и с чего начать, либо технари говорят, что нет ресурсов реализовать такое непотребство😁

Вот я столкнулась с подобным отсутствием опыта. Есть прод, который как-то работает, но здоров ли он, жив ли  – непонятно, пока не прибежит бизнес с чайка-вайбом (хотя возможно это вы😆) и не накрутит айтишникам хвосты (настроение у меня игривое, пока пост пишу, ахаха).

Или есть у вас мау 100500 юзверей, а могло бы быть х10, если бэк/фронт не ломался где и когда попало, потому что вы и ваша ит-команда не в курсе что там на инфре происходит.

Вы можете сказать, что “я за продуктовые и бизнесовые метрики отвечаю, мне эта ваша техничка никуда не уперлась” и будете в целом правы😁 это пост для ненасытных, любопытных и тревожных😂

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

📄1 слой. Уровень логов Тут всё максимально просто и наглядно: смотрим не на сами логи (их же читать никто не любит), а строим график роста ошибок и ворнингов. Если линия ползет вверх — это как температура у ребенка, сигнал, что где-то что-то начинает подгорать☕️. Ловим тренд, пока он не превратился в полноценный пожар.

💼2 слой. Метрика поломки бизнес-процесса Это наша «красная кнопка». Реактивная метрика с бешеным откликом, чтобы понять: а клиенту-то сейчас вообще хорошо? Например, % успешных регистраций

или % оплат

Критерий жесткий: процесс для конкретного юзера отработал успешно или нет? Если нет — мы уже бежим чинить, потому что бизнес (тот самый, с чайка-вайбом) уже точит ножи🔪😁

🏘3 слой. Архитектура 🕵️‍♀️ Чтобы не бегать без фонарика в темной комнате, нужно понимать не только факт звездеца (о чем нам сигналят первые два слоя), но и где это произошло – локализовать проблему до компоненты, на которой произошёл сбой. Для этого берем сиквенс-диаграмму (или вашего системного аналитика) и смотрим вызовы компонент и решаем какие алерты и где ставим😎

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

🏗️ 4 слой. Инфра Спускаемся в подвал. Тут мы отвечаем на вопрос «ПОЧЕМУ?».

Вот этот конкретный API тормозит — но почему? У нас CPU уперся в потолок, сеть легла, база данных захлебнулась от запросов или соседний сервис тупит? Тут мы видим железо и сети, чтобы понять, какой именно винтик в нашей большой машине требует смазки.

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

Начинайте строить систему мониторинга с 1 слоя и спускайтесь вниз по следующим слоям, постепенно усложняя и дополняя. На первый этап (при условии, что логи собираются), нужен часок-другой, но это спасёт всем нервные клеточки, а, возможно, и разработчиков😁

Это все про реактивный подход, когда звездец уже случился и вы просто разгребаете его быстрее, чем кто-нибудь его заметит. Следующий этап – проактивный с предиктивной аналитикой по нагрузке и вероятностью скорой поломки

Я знаю, меня читают и продакты, и разрабы, и аналитики разных мастей и есть 100% более опытные в этом деле, поэтому не держите в себе – делитесь случаями звездеца и/или что я недостаточно раскрыла в посте

Ну и голосуйте как вам контент 🍾– это я чайка-бизнес 💜– знакомо 😭 – ничего не понятно 🔥 – подгорело, пошел делать

P.s.: на фото я крашу метрики😂