Представьте, что вы владелец продукта (ну или вам даже не нужно это представлять😁), из всех утюгов пишут про метрики продукта, метрики бизнеса и всякие дау, мау, вау и тп., а про технические метрики как-то либо специфично, либо непонятно написано, либо непонятно как это применить и с чего начать, либо технари говорят, что нет ресурсов реализовать такое непотребство😁
Вот я столкнулась с подобным отсутствием опыта. Есть прод, который как-то работает, но здоров ли он, жив ли – непонятно, пока не прибежит бизнес с чайка-вайбом (хотя возможно это вы😆) и не накрутит айтишникам хвосты (настроение у меня игривое, пока пост пишу, ахаха).
Или есть у вас мау 100500 юзверей, а могло бы быть х10, если бэк/фронт не ломался где и когда попало, потому что вы и ваша ит-команда не в курсе что там на инфре происходит.
Вы можете сказать, что "я за продуктовые и бизнесовые метрики отвечаю, мне эта ваша техничка никуда не уперлась" и будете в целом правы😁 это пост для ненасытных, любопытных и тревожных😂
Так вот, давеча👵 я говорила с нашим ит-лидером трайба на тему мониторинга прода и что кажется, что много всего надо отслеживать, ресурса людей не хватает и тд и тп. И он классно разложил технический мониторинг на слои с учётом сложности реализации и глубины мониторинга и анализа
📄1 слой. Уровень логов
Тут всё максимально просто и наглядно: смотрим не на сами логи (их же читать никто не любит), а строим график роста ошибок и ворнингов. Если линия ползет вверх — это как температура у ребенка, сигнал, что где-то что-то начинает подгорать☕️. Ловим тренд, пока он не превратился в полноценный пожар.
💼2 слой. Метрика поломки бизнес-процесса
Это наша «красная кнопка». Реактивная метрика с бешеным откликом, чтобы понять: а клиенту-то сейчас вообще хорошо? Например,
% успешных регистраций
или
% оплат
Критерий жесткий: процесс для конкретного юзера отработал успешно или нет? Если нет — мы уже бежим чинить, потому что бизнес (тот самый, с чайка-вайбом) уже точит ножи🔪😁
🏘3 слой. Архитектура 🕵️♀️
Чтобы не бегать без фонарика в темной комнате, нужно понимать не только факт звездеца (о чем нам сигналят первые два слоя), но и где это произошло – локализовать проблему до компоненты, на которой произошёл сбой.
Для этого берем сиквенс-диаграмму (или вашего системного аналитика) и смотрим вызовы компонент и решаем какие алерты и где ставим😎
Например:
• Смотрим API: какие методы, какие ошибки и их динамику, сколько вызовов, какое время задержки.
• Смотрим Кафку (или что у вас там вместо нее): с какой скоростью мы туда насыпали событий, с какой разгребаем, и сколько там сейчас лежит неразобранных сообщений. Часто про неё непростительно забывают, а потом долго не могут найти проблему
🏗️ 4 слой. Инфра
Спускаемся в подвал. Тут мы отвечаем на вопрос «ПОЧЕМУ?».
Вот этот конкретный API тормозит — но почему? У нас CPU уперся в потолок, сеть легла, база данных захлебнулась от запросов или соседний сервис тупит? Тут мы видим железо и сети, чтобы понять, какой именно винтик в нашей большой машине требует смазки.
---
В итоге: мы прошли путь от «ой, что-то варнингов много» до «понятно, почему база легла». И всё это без необходимости нанимать армию аналитиков, если грамотно расставить приоритеты и начать с базы.
Начинайте строить систему мониторинга с 1 слоя и спускайтесь вниз по следующим слоям, постепенно усложняя и дополняя. На первый этап (при условии, что логи собираются), нужен часок-другой, но это спасёт всем нервные клеточки, а, возможно, и разработчиков😁
Это все про реактивный подход, когда звездец уже случился и вы просто разгребаете его быстрее, чем кто-нибудь его заметит.
Следующий этап – проактивный с предиктивной аналитикой по нагрузке и вероятностью скорой поломки
P.s.: на фото я крашу метрики😂
Вот я столкнулась с подобным отсутствием опыта. Есть прод, который как-то работает, но здоров ли он, жив ли – непонятно, пока не прибежит бизнес с чайка-вайбом (хотя возможно это вы😆) и не накрутит айтишникам хвосты (настроение у меня игривое, пока пост пишу, ахаха).
Или есть у вас мау 100500 юзверей, а могло бы быть х10, если бэк/фронт не ломался где и когда попало, потому что вы и ваша ит-команда не в курсе что там на инфре происходит.
Вы можете сказать, что "я за продуктовые и бизнесовые метрики отвечаю, мне эта ваша техничка никуда не уперлась" и будете в целом правы😁 это пост для ненасытных, любопытных и тревожных😂
Так вот, давеча👵 я говорила с нашим ит-лидером трайба на тему мониторинга прода и что кажется, что много всего надо отслеживать, ресурса людей не хватает и тд и тп. И он классно разложил технический мониторинг на слои с учётом сложности реализации и глубины мониторинга и анализа
📄1 слой. Уровень логов
Тут всё максимально просто и наглядно: смотрим не на сами логи (их же читать никто не любит), а строим график роста ошибок и ворнингов. Если линия ползет вверх — это как температура у ребенка, сигнал, что где-то что-то начинает подгорать☕️. Ловим тренд, пока он не превратился в полноценный пожар.
💼2 слой. Метрика поломки бизнес-процесса
Это наша «красная кнопка». Реактивная метрика с бешеным откликом, чтобы понять: а клиенту-то сейчас вообще хорошо? Например,
% успешных регистраций
или
% оплат
Критерий жесткий: процесс для конкретного юзера отработал успешно или нет? Если нет — мы уже бежим чинить, потому что бизнес (тот самый, с чайка-вайбом) уже точит ножи🔪😁
🏘3 слой. Архитектура 🕵️♀️
Чтобы не бегать без фонарика в темной комнате, нужно понимать не только факт звездеца (о чем нам сигналят первые два слоя), но и где это произошло – локализовать проблему до компоненты, на которой произошёл сбой.
Для этого берем сиквенс-диаграмму (или вашего системного аналитика) и смотрим вызовы компонент и решаем какие алерты и где ставим😎
Например:
• Смотрим API: какие методы, какие ошибки и их динамику, сколько вызовов, какое время задержки.
• Смотрим Кафку (или что у вас там вместо нее): с какой скоростью мы туда насыпали событий, с какой разгребаем, и сколько там сейчас лежит неразобранных сообщений. Часто про неё непростительно забывают, а потом долго не могут найти проблему
🏗️ 4 слой. Инфра
Спускаемся в подвал. Тут мы отвечаем на вопрос «ПОЧЕМУ?».
Вот этот конкретный API тормозит — но почему? У нас CPU уперся в потолок, сеть легла, база данных захлебнулась от запросов или соседний сервис тупит? Тут мы видим железо и сети, чтобы понять, какой именно винтик в нашей большой машине требует смазки.
---
В итоге: мы прошли путь от «ой, что-то варнингов много» до «понятно, почему база легла». И всё это без необходимости нанимать армию аналитиков, если грамотно расставить приоритеты и начать с базы.
Начинайте строить систему мониторинга с 1 слоя и спускайтесь вниз по следующим слоям, постепенно усложняя и дополняя. На первый этап (при условии, что логи собираются), нужен часок-другой, но это спасёт всем нервные клеточки, а, возможно, и разработчиков😁
Это все про реактивный подход, когда звездец уже случился и вы просто разгребаете его быстрее, чем кто-нибудь его заметит.
Следующий этап – проактивный с предиктивной аналитикой по нагрузке и вероятностью скорой поломки
Я знаю, меня читают и продакты, и разрабы, и аналитики разных мастей и есть 100% более опытные в этом деле, поэтому не держите в себе – делитесь случаями звездеца и/или что я недостаточно раскрыла в посте
Ну и голосуйте как вам контент
🗿– это я чайка-бизнес
🥲 – знакомо
😭 – ничего не понятно
🔥 – подгорело, пошел делать
P.s.: на фото я крашу метрики😂