Как соблюдать баланс работы и жизни

Привет, киты 🐳!

Смотрите есть хороший курс от Yale "The Science of Well-Being" (с материалами на русском даже), на Coursera он стоит 44 евры. Хотелось его почитать, посмотреть да ещё бы и за бесплатно. Он всего 7ч занимает.

Пошел искать - нашёл пост выжимку https://www.reddit.com/r/DecidingToBeBetter/comments/ghrgz5/summary_of_yales_famous_science_of_wellbeing/

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

Пришлось в этот раз запла... не пришлось 😂 И торренты тут не причем!

Нашёл на сайте Yele описание этого курса и там написано, что он Free если без сертификата и ссылка дана. Переходишь по ней и курс в Courcera выдается бесплатно!

Как получить: идем на сайт https://online.yale.edu/courses/science-well-being, крутим до (FREE) Coursera - Full course, no certificate и жмем. В ваш акк на Coursera добавится это курс 🧙‍♂

🏮А как вы поддерживаете баланс между работой и жизнью?

#работа #психология #курс #бесплатно #Coursera #work_life_balance

OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)

Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.

Версия 1.37.0 (Базовая)

- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method

Версия 1.38.0

- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.

Версия 1.39.0

- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.

Версия 1.40.0

- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).

Версия 1.41.0

- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.

Версия 1.42.0

- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).

Версия 1.43.0

- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.

Резюме ключевых изменений:

- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.

А как вы решаете вопрос с именами метрик и изменениями в OTEL?

#opentelemetry #observability #changelog #otel

Капец, МММ живее всех живых

Увидел на визитке QR код Vilavi, подумал что это какой-то турецкий мессенджер. Слышал, что люди какой-то используют.

Зашел я по нему и почуял что-то странное. Проверил основной сайт. На первый взгляд безобидно, но я полез почитать о компании и увидел там адрес на Кипре, при этом сама страница заявляет про какой-то продукт из Сибири и что они успешно растущая компания с 2009 года 🤔.

У них там сложная система вознаграждений, но основа - что должны покупать все подчиненные тебе агенты, один не покупает - ты в пролете. И упор на привод новых членов "клуба".

Вот если их файлик с условиями вознаграждения и с сайта раздел Бизнес дать на анализ нейросети, с вопросом "У меня подозрение на схему понзи, пирамидку. Проверь вот эти материалы" - ой там портянка будет...

Жаль, что не все люди это осознают и могут проверить.

А вы когда сомневаетесь, как проверяете подобное ?

#скам #пирамида #нейросети #неработа #финграмотность

Привет киты 🐳 . А нафиг вам оно надо?

Именно об этом позволят задуматься сей инструмент https://github.com/dominikhei/cardamon - он подключается к вашему хранилищу метрик Prometheus и определяет какие метрики вообще не запрашиваются и просто лежат без пользы засоряя диски.

Кроме того из него же можно сразу создать правила для drop-а таких метрик сразу.

Напомню, лишние метрики - это не только 2-3 килограмма лишних дисков, это еще и повышение нагрузки на CPU при выборке, и необходимость иметь больше CPU. Когда метрик много при выборке приходится обходить но гораздо больше данных и это замедляет работу с метриками, работу досок. И еще увеличивает вероятность сделать слишком общий запрос и забить нагрузкой поиска и выборки данных эти сервера.

Так зачем хранить, то что не требуется от вас хранить ни по закону, ни по здравому смыслу?

P.S. буду пробовать его на совместимость с Victoria Backham Metrics

#наблюдаемость #observability #инструментарий #метрики #оптимизация

Рубрика "Видео моих докладов".

Менее года назад впервые отобрался с докладом на HighLoad в Санкт-Петербурге. Это было нечто новое, ведь раньше я тут был только зрителем.

#Доклад на Saint HighLoad 2025
Как добыть SLO: источники и инструменты гномов SREдней полосы

-> Презентация и материалы к докладу

📺 #Видео
——————
* RuTube
* VkVideo
* YouTube

🤓 Угадайте сколько гномов было в докладе?

P.S. кому интересна тема SLO — вас уже ждут тут https://t.me/allslo_ru

#видео #доклад #devopsconf #sre #slo #спикер

Привет, киты 🐳🐳. Встречаемся в Петербурге!

Ребята. Буду в Петербурге с 20 по 23 июня 2026г.
22-23 на SaintHighLoad 2026.

Пишите в личку. Если будет желание пересечься и поговорить вживую - знаю отличное место с вкусной рыбой 🐟.

#sainthighload #петербуг

Завтра буду выступать на Gmonit Observability Day 2026 с небольшим докладом про развитие нашего стека наблюдаемости.

Если будете там, заходите поговорить и на доклад.

Пройдет по адресу:  Москва, ул Мясницкая 13, с20, лофт Quattro Space
с 10 до 21ч.

https://gmonit.ru/event/observabilityday2026

#конференция #выступление #доклад #наблюдаемость #gmonit

Работа с агентами в командах: AI-а-а-а-а-а генты и возвращение Джуна

Привет киты 🐳 !
Попалась интересная статья "Я уволил джуна, нанял AI-агента, через месяц нанял джуна обратно“


Сжато: Взяли джуна Антона - работал среде, продукт знал . Потом вкусили AI-агентов и Антона уволили - он дороже.

1–2 неднли: кайф. Модуль за 3 часа вместо 3 дней, 14 задач вместо 7, тесты +13% к покрытию .

Неделя 3: первые косяки. Агент применил скидку + промокод дважды - не знал негласного правила. Сломал retry-логику: rate-limit был описан только в Confluence.

Неделя 4: математика сломалась. На ревью трачу больше, чем экономлю. Агент не помнит контекст, два агента устроили конфликт в utils.py.

Но команда стала закрывать больше задач → руководство дало новые фичи. А для них нужен человек, который держит продукт в голове.

Вернул джуна Антона. Не потому что провалились - потому что выросли.

Итог: это эволюция, не замена. Формула: джун × AI = мидл. Антон пишет промпты, знает контекст, агенты — для шаблонов и тестов. Скорость ×2, качество — человеческое. Контекст продукта — всегда за человеком.

#ai #ai_агенты #практика #разработка #команды

🐋 Друзья, киты! Этим летом приму участие в Summer Merge и приглашаю вас присоединиться.

С 3 по 5 июля на берегу Волги, в эко-парке «Русский Берег» (Ульяновск), пройдёт Summer Merge — это не классическая конференция, а скорее большое летнее приключение для взрослых. Проживание в палаточном лагере, живое общение и насыщенная программа без формальных условностей.

Я впервые буду в новой роли, не докладчик как обычно, а амбассадор рисования набросков ✏️ - это мое хобби.
Будем отключать мозг и быстро рисовать, выхватывать детали за 5, 3, 1, 7 минут. Вам не нужно уметь рисовать - это как исследование себя. Оценок ставить никто не будет. В итоге у нас будет за 1ч около 10 набросков. Если вы в первый раз это делаете - вы удивитесь и себе и ощущениям после. Это очень интересный опыт.

Summer Merge объединяет тех, кто настроен на профессиональный рост, осмысленный нетворкинг и здоровую перезагрузку. Здесь можно не только послушать коллег, но и обсудить волнующие вопросы в неформальной обстановке, у костра или за чашкой кофе.

Буду рад всем!

Билеты и программа на сайте: summermerge.ru

По моему промокоду SINYAVSKY действует скидка 20%.

#конференция #merge #промокод #наброски #хобби

Привет, киты 🐳🐋! Ко мне обращаются люди с вопросами по теме SRE

Я выделил частые вопросы
1. СТО и лиды чаще интересуются:
- У нас всё горит, а мы только туштм, с чего начать внедрение SRE?
- Кого будить первым, когда продакшен упал?
- Кто отвечает за решение инцидента SRE или команда?
- Как компенсировать дежурства, чтобы команда не выгорела?

2. DevOps инженеры, которые хотят перейти в SRE спрашивают:
- Что мне учить, откуда начать?
- Это интересно?
- Как вкатываться в дежурства?
- Как научиться траблшутить?

Помогаю ответить на «глупые» вопросы, которые на самом деле решают всё.
Отвечаю на них в канале и на консультациях - мой опыт с примерами из практики.

Заметки с полей Yandex Infra Conf 2026 о выборе AI

Золотов Денис, ML-инженер - сделал важное наблюдение. Мне это приоткрыло дверцу в чуть более сложный мир нейросетей. Выбор сильно влияет на эффективность ваших AI-решений.

Вот что он пишет:

Наблюдение по итогам конференции.

На протяжении всего дня обсуждались LLM, инференс, деплой, телеметрия обучений.

Но ни разу чётко не прозвучало фундаментальное разделение которое определяет выбор инструмента.

Есть два принципиально разных типа данных — числа и слова.

LLM работает с токенами — она не знает что 1.45 > 1.44 в математическом смысле. Она знает что эти символы часто встречаются рядом в определённых контекстах.

Градиентный бустинг работает с числами как с числами — вычисляет, сравнивает, находит математические зависимости между величинами.

И это разделение не заканчивается на двух инструментах. Нейронные сети для временных рядов, классическая статистика, reinforcement learning, rule-based системы — каждый класс определяется природой данных и задачи, а не тем что сейчас у всех на слуху.

Большинство дискуссий про применение ИИ игнорируют этот фундамент. В итоге берут LLM там где нужен бустинг — и наоборот.

#ml #ai #эффективность #конференция #yandex_infraconf

Привет, киты 🐋! Как поддерживать наблюдаемость при изменении конвенций OpenTelemetry

Большая часть конвенций в OTEL все еще не помечена stable, а это значит что от версии к версии могут меняться названия метрик, лейблов, спанов, атрибутов логов (вот посмотрите https://t.me/letitkit/223). И как с этим жить? Ведь на это завязаны доски Grafana, алерты, расчет SLO.

Вариант 1. Закрепить версию библиотеки и просто на ней сидеть например год. Возможно? Да. Риски: CVE уязвимости, которые нужно закрыть в середине года.

Вариант 2. Обертки библиотек OTEL и свой "золотой набор" метрик, которые в требуете с приложений, а если их нет - не пускаете в прод. Т.к. вам нужна сквозная наблюдаемость и предсказуемость, чтобы не знать 10 вариантов одной и той же метрики.

Вариант 3. Гибридный. Принимать метрики от разных версий OTEL, но складывать это в одно представление.
Такой вариант предлагает HoneyComb https://www.honeycomb.io/blog/managing-opentelemetry-semantic-convention-migrations-collector
Для этого даже в OTEL Collector есть специальный schemaprocessor (правда только в alfa-версии). Непонятно, как он будет решать случаи, когда метрик просто не стало (удалили, например, метрик rpc было 10 в 1.37, а в 1.39 оставили 2).

Вариант 4. Skyscanner https://opentelemetry.io/blog/2026/devex-skyscanner/
Дропают большинство SDK-generated HTTP и RPC метрик по умолчанию. Генерируют свои метрики из Istio service mesh spans через spanmetrics connector
Используют transform processor для приведения к semantic conventions. Обновляются раз в 6 месяцев с постепенным rollout (Dev → Alpha → Beta → Production)

Как вы решаете эту проблему?

Эффективная работы с AI-агентами, как экономить токены

Привет, киты 🐳!

Наверно все уже видели ролик, где показан расход на токены при одинаковом наборе запросов к разным моделям AI.
Его тут не будет, а будет набор инструментов которые помогут экономить токены.

При работе с кодом (разработка)
- MCP для быстрой навигации по коду для агентов https://github.com/colbymchenry/codegraph — снижает использование токенов на 35%, утилит на 70%, работает локально
- Роутер для отправки простых задач и вопросов более дешевым моделям https://github.com/fendouai/CodexSaver
- Скилл для Calude.ai, что может сокращать использование токенов почти на 65% — https://github.com/juliusbrussee/caveman
- RTK прокси-сервер CLI, который снижает потребление токенов LLM на 60–90 % при выполнении стандартных команд для разработчиков — https://github.com/rtk-ai/rtk
- AgentMemory постоянная память для агентов https://github.com/rohitg00/agentmemory

Радикальные методы
Замена на локальную модель. Вот есть предобученный Qwen3 по базе Claude Sonet 4.6, пишет также хорошо — https://huggingface.co/hesamation/Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-GGUF

Дополнительно
- Утилита для улучшения вашего AI-скилла https://github.com/microsoft/SkillOpt - гоняет скилл, проверяет и улучшает. Да вы потратите токены на это, но после будете тратить меньше, так как результат будете получать быстрее.

❓А вы какие обвязки для своих AI-агентов используете ?

#эффективность #ai-агегнты #ai #claude #codex #skills #ai-skill