🚀🐳 Летит Кит: SRE и не только

Эффективная работы с 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

Привет, киты 🐋! Как поддерживать наблюдаемость при изменении конвенций 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

В Питере на SaintHighLoad 2026. Кто тут заходите поболтать.

Дали зелёные штаны гуру 🩳 ))

#конференция #highload

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

https://gmonit.ru/event/observabilityday2026

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

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

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

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

#sainthighload #петербуг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите есть хороший курс от 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

17 лет назад HTML и CSS был суров и был еще в ходу ужасный Internet Explorer 6

Я тогда увлекался экспериментами с ними, даже сайт помню css-trics был. Сейчас на CSS без js можно делать мультики!

А тогда я заморочился сделать разметку аккордов для гитары, было интересно.

Оно до сих пор работает 😎 https://www.r3code.ru/projects/accord-v2/accord.html

А чего я это вспомнил? Мне от хабра пришло письмо, что то кто-то меня упомянул в статье от 2010 года! Археолог не иначе, подумал я и пошел проверить, но комментов от 2026 свежих не нашел - видать глюк. Ну что ж спасибо ему - поностальгировал )

Читал тут LinkedIn.

Многие пишут про AI и риск, что разработчики отвыкнут и разучатся, а если доступ к Ai отключат, то они не сумеют сделать ничего.

Ai тут непричем - это иронии любой автоматизации. Я как-то брал сноуборд на Красной поляне в прокат и у них заглючил сайт, знаете через сколько они в помнили о "древнем" раьочем обходном решении - можно договор на бумаге прямо тут подписать.? Через час. а через 70 минут сайт подняли.

Как можно было сообразить раньше?
Только тренировать этот отказ.

Но тут есть одно но - иногда информационная система настолько сильно встроена в процесс, что дешевле час недоступности, чем перекладка из бумаги потом.

Как понять когда использовать обходные решения? Когда это не станет дороже простоя?!

#SRE #иронии #эффективность

1:1 - это не терапия, а место, где можно по-человечески поговорить не только о работе.

Уйдем чуть-чуть от технички в более простые, но не менее важные вещи.
Раньше я воспринимал 1:1 довольно утилитарно.

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

Потом в Додо мне показали другой формат.

Оказалось, что 1:1 - это не только про задачи, перформанс и “что у тебя по проекту”. Иногда это маленький safe space, где можно сказать:
- “я устал”
- “я не вывожу”
- “меня бесит вот эта штука”
- “я не понимаю, куда дальше расти”
- “у меня сейчас сложный период вне работы”

И нормальный руководитель в этот момент не становится психологом, спасателем или мамой. Но он начинает видеть контекст.

А контекст решает.

Если руководитель видит только карточки в трекере, он управляет карточками.
Если он видит человека и контекст вокруг него, он может управлять нагрузкой, ожиданиями, ростом и рисками.

Для меня это прям поменяло отношение к 1:1. Это перестало быть встречей ради встречи и стало нормальным инструментом управления.

Что, на мой взгляд, делает 1:1 полезным:

1. Регулярность
Лучше стабильные 30 минут раз в 1-2 недели, чем “созвонимся, когда будет тема”.
Потому что “темы нет” - это тоже состояние. Иногда самое важное всплывает не в начале, а на 17-й минуте после стандартного “да вроде всё нормально”.

2. Это не статус-митинг
1:1 - это не место, куда надо переносить весь таск-трекер.
Статусы должны жить в таск-трекере, стендапах, PR, документах - где угодно, но не съедать весь 1:1.
Задачи можно обсуждать, но обычно за ними должна быть настоящая тема: блокер, конфликт, перегруз, непонятные ожидания, потеря мотивации.

Если весь 1:1 - это “ну что там по тикету?”, то поздравляю, вы изобрели плохой дейлик на двоих.

3. Повестка должна быть с двух сторон

Хорошо, когда и руководитель, и человек заранее накидывают темы.

Если повестку всегда приносит только руководитель, встреча быстро превращается в “начальник что-то хотел”. А 1:1 всё-таки должен быть местом, где человек тоже может принести то, что ему важно.

4. Safe space создаётся поведением, а не словами

Недостаточно сказать “у нас тут безопасное пространство”.
Безопасность появляется, когда тебя не перебивают, не обесценивают, не используют личное против тебя через месяц и не превращают каждую честную фразу в performance issue.

Доверие строится медленно, а ломается очень быстро. Классика, ничего нового.

5. Личное можно обсуждать, но аккуратно

1:1 - не исповедь и не терапия. Руководитель не должен лезть человеку в душу.

Но если человек сам говорит “у меня сейчас дома тяжело” или “я не вывожу”, нормальная реакция - не копаться в деталях, а понять, как это влияет на работу и чем можно помочь.

Где-то это пересборка нагрузки. Где-то отпуск. Где-то более чёткие ожидания. Где-то просто “окей, я понял, давай в ближайшие пару недель не будем накидывать сверху”.

6. Нужны follow-up’ы

Если на 1:1 договорились что-то сделать - это надо потом вспомнить.
“Я поговорю с командой”, “посмотрю промо-план”, “помогу разгрузить”, “вернусь с ответом” - это не декоративные фразы, а action items.

Нет follow-up’а - нет доверия. Всё очень просто и очень больно.

Хороший 1:1 после себя оставляет чуть больше ясности, спокойствия или движения вперёд.

Для человека - это место, где его слышат не только как исполнителя задач.
Для руководителя - это ранний мониторинг состояния команды.
Только вместо CPU, latency и error rate у тебя мотивация, усталость, ясность, доверие и рост.

И если после 1:1 ничего не меняется ни в голове, ни в действиях, ни в отношениях - возможно, это был просто ещё один календарный алерт без runbook’а.

А у вас 1:1 больше про задачи, про людей или “ну надо же иногда созваниваться”?

#sre #teamhealth #onetoone #leadership

Ребят, не по теме SRE, а по теме контактов. Знакомый ищет спеца кто делает SEO продвижение в Google по России. Если у вас есть проверенные люди — прошу накидать контактов в личку @r3code.

#запрос #контакты #неформат