🔍 Наблюдаемость начинается не с метрик

➡️ В феврале я подавал заявки на Saint HighLoad, одной из тем было Observability. Об этом я писал выше. Когда я в итоге сел прорабатывать собственное понимание этой темы - находки меня впечатлили, хотя казались достаточно очевидными
Моя цель на год звучала классно - любой инженер локализует проблему за 10–15 минут. Для этого нам нужна наблюдаемость в своем стандартном виде, т.е.: "Observability = Metrics + Alerts + Traces". Классика. Бери и делай... Но делай что?

🛑 Когда я сел за дорожную карту - начал буксовать. Пытался раскрутить: Как выставить правильные пороги? Какие метрики вообще являются хорошими, а от каких стоит избавиться? С метриками, кстати, понятно - наш архитектор приучил меня к очень правильному вопросу: «Какой алерт я повешу на эту метрику»
Отсюда возникает и главный вопрос - а какие алерты нас вообще интересуют? Как понять, что система работает корректно?

💡 Ответ оказался не техническим. Система работает корректно тогда, когда приносит деньги. Всё.
10–15 минут реакции - это следствие, точнее, реализуемое действие, для того, чтобы снизить потери бизнеса. Но причина в том, что мы не умеем считать потери. Когда падает сервис, никто не может сказать: «за последние 40 минут мы потеряли примерно X рублей». Только в случае полного отказа всех наших сервисов, боже дай мне сил...

❗️ Когда я переформулировал цель, и сделал целью ДК автоматизацию подсчёта потерь - ДК начала вырисовываться в моей голове, причем очень последовательными шагами. Сразу стало понятно:
• Для подсчёта потерь нужны SLI/SLO/SLA сервисов
• Для SLI нужны метрики и алерты - конкретные, привязанные к бизнес-процессам
• Для сокращения времени реакции нужны трассировки по которым можно отследить, где нарушаются эти самые SLA

Те же самые Metrics + Alerts + Traces - но теперь каждый элемент отвечает на конкретный вопрос, а не висит в вакууме

✅ Ошибка была не в инструментах, а в целеполагании. Я пытался строить наблюдаемость от инструментов к результату. Но без учета бизнес-контекста результат оставалось только высасывать из пальца. В очередной раз процессы оказались важнее технических костылей)

🔜 Дальше расскажу, с чего мы начали практически: аудит алертов и логирования. Спойлер - то, что мы нашли, нас не обрадовало

🔍 Как прошла AI Conf в Москве

Конференция собрана как «конференция развития» с 40% интерактивных форматов. Было 4 основных трека - из них я и собрал свой личный маршрут

🎤 Доклады
На доклады изначально не планировал идти - их можно посмотреть в записи. Но с утра хотелось неспешно добраться до Технограда, ознакомиться с локацией, пройтись по этажам. В итоге на один из двух утренних докладов я попал. Два открывающих доклада рассказывали об изучении китайского для AI-карьеры. Логика спикеров проста:

Промтить на родном для моделей языке и общаться с инженерами на китайских аналогах Хабра => карьерное преимущество

🧪 Мастер-классы
Сходил на несколько: Schema Guided Reasoning и Agent Observability via Langfuse. Понравился формат, спикеры и организаторы постарались сделать качественно и интересно. Но, видимо, из-за смены формата конференции не было времени на «обкатку» материала с mock-залом, оба МК не уложились в тайминги. А инструменты сугубо специализированные, чтобы начать их использовать нашей команде потребуется менять подход к работе с AI в процессах и продукте - что маловероятно сейчас

🗣 Открытые столы
Еще один живой-мастер класс, с разделением на команды: Стол по теме «Как продавать AI-фичу бизнесу». Разбивались на 7 команд с 7 разными AI-проектами, я взял ближайшую тему - AI Code Reviewer. Из-за нехватки людей в итоге объединились в 3 команды. Прорабатывали emotional map для C-Level: о чём думают, чего хотят и чего боятся CEO, CTO, CISO. Было весело, но не шибко полезно - имея опыт продавать AI-фичи бизнесу знаю: разговор всегда о бабках. О бабках через эффективность, через автоматизацию, через смену парадигмы разработки - но не через эмоции. В бизнесе вообще нет эмоций. Только деньги

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

🎉 Афтерпати
Проходило на этаже со стендами, когда активности закончились. Шведский стол, алкоголь, закуски. Безалкогольное пиво для меня. Поболтал с ребятами со стендов, которые понравились больше всего, об айтишке, о технологиях, о процессах - приятный нетворкинг в конце дня. Уходя, наткнулся на неанонсированный доклад от HR, видимо, Сбера про рынок труда: «рынок сломан, чинить никто не будет» - это если кратко

Уже провели командный обмен опытом после конфы - в следующих постах расскажу о том, как это было

🧠 Уже два месяца перетряхиваю свою базу знаний в Obsidian — но главную ценность от этого нащупал лишь сейчас

Вот и я поигрался со своим Obsidian. Размышлял про какой-то локальный RAG над базой — пока размышлял, сообщество уже всё решило и выкатило в обкатку Obsidian Wiki
Есть готовые скиллы для пересборки Obsidian в «Wiki-мозг» — хотя, какой это мозг? Просто хорошо структированная база знаний, с агентами над ней. Тем не менее — с первого взгляда были отличные ощущения
На своей базе применил этот skill

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

🔍 Целый вечер и 40% пятичасовых токенов Claude ушли на знакомство агентов с моими записками. Радовало, когда он спрашивал про отрывки заметок, которые я сам давно уже забыл, но о которых стоило помнить. Потом составил скоуп — где-то 120 вопросов по оборванным заметкам — сагрегировал мои ответы и собрал мой персональный граф знаний

➡️ А дальше — просто. Пишу заметки в Daily Notes, разделяю на блоки работы и личного, выделяю что-то формулярами Markdown. Раз в неделю, минут за 30–60 в выходной, запускаю сессию: «актуализируй базу по последним заметкам» — он вытаскивает свежие заметки, находит пересечения с базой, обновляет ноды графа и подкидывает новые вопросы. Никакой сортировки на входе — вот это и сняло главную головную боль

💡 Но я долго не понимал, какую ценность отсюда вытащить, кроме красиво структурированных файликов. Понял неделе на 5–6, когда тестово перегнал в базу два года истории ван-ту-ванов с сотрудниками. Теперь перед ван-ту-ваном один простой запрос даёт достаточно актуальный контекст по человеку — напоминания про мотивацию, обещания, незакрытые вопросы

⚠️ Естественно, такие манипуляции необходимо обсуждать с людьми своевременно, правда, до меня это дошло уже после. Ходил на ван-ту-ваны и заходил издалека: «Представим, что твой лид — и это точно не я — слил историю взаимодействия с тобой в LLM, чтобы улучшить опыт проведения ван-ту-ван'ов. Как ты к этому отнесёшься?»
Все дали добро. А дальше мы вместе открывали «их портрет», нарисованный LLMкой, оценивали его и полировали

✅ В целом я думал, что такая модель поможет мне именно с структурой ведения заметок, с поддержанием порядка в них. А получил помощника, в виде Агента, который помогает мне пушить мои проекты и не даёт забывать важное — и чем точнее граф отражает твою реальную загруженность, чем больше там контекста по твоим текущим проекта — тем больше от него пользы
Говорят же люди, в разных вариантах: «Ценность рождается на пересечениях — технологий, подходов, сфер»

Находка отличная. Правда, мне самому она скоро не пригодится — почему, расскажу в ближайших постах