Observability. С чего начать?

Observability. С чего начать? У моей команды много официального овнершипа разных компонентов системы, и все “должно быть” быть обложено мониторингом, алертами и метриками. Но как обычно бывает, между “должно быть” и “есть” лежит прод есть большая разница)+ Я делаю свой проект в котором тоже должен быть хороший Observability, чтобы понимать что происходит с проектом, что там делают пользователи, и как я узнаю если что-то пошло не так, помимо их прямого обращения ко мне/в поддержку. С чего начать было непонятно, но с чего-то я начал и вот что я определил.Оказалось это может работать и для моей команды в корпоративной среде, и для моего проекта где я пока что один.Я решил что надо трекать1️⃣Ошибки2️⃣Использование 3️⃣Основной workflow/path (проходят ли пользователи от начала - до конца, так как задумано)Метрики которые я начал собирать, или которые уже собирались но я их собрал в дашборд👉Кол-во вызовов / посещений (по endpoint, по action, по типу)👉Время отклика (p50, p95 API response time, page load time, function duration)👉Кол-во ошибок (по типу HTTP 4xx/5xx, Клиент ошибки типа от JavaScript, backend эксепшены)👉Конверсия / завершённость ключевых действий (типа 100% пользователей начали что-то, а дошли до конца 60%, что случилось с 40%)Алерты (на основе метрик)👉Кол-во ошибок резко выросло👉Время ответа стало медленнее👉Никто не вызывает endpoint последние X минут (если это подозрительно)👉Конверсия падает - кто-то не доходит до конца сценарияЯ только начал это выстраивать, но уже вижу первые результаты) вообще не представляю как раньше было без этогоА еще я сегодня шел по офису и у меня пробежала мысль что я работаю в Барселоне, пришел с обеда в кафе у моря, в международной компании, где все говорят по английски или испански - прикольно, но всегда хочется быстрее выше сильнее)) #программирование | @andreyposnov