Привет, киты 🐳🐋! Ко мне обращаются люди с вопросами по теме SRE
Я выделил частые вопросы
1. СТО и лиды чаще интересуются:
- У нас всё горит, а мы только туштм, с чего начать внедрение SRE?
- Кого будить первым, когда продакшен упал?
- Кто отвечает за решение инцидента SRE или команда?
- Как компенсировать дежурства, чтобы команда не выгорела?
2. DevOps инженеры, которые хотят перейти в SRE спрашивают:
- Что мне учить, откуда начать?
- Это интересно?
- Как вкатываться в дежурства?
- Как научиться траблшутить?
Помогаю ответить на «глупые» вопросы, которые на самом деле решают всё.
Отвечаю на них в канале и на консультациях - мой опыт с примерами из практики.
Я выделил частые вопросы
1. СТО и лиды чаще интересуются:
- У нас всё горит, а мы только туштм, с чего начать внедрение SRE?
- Кого будить первым, когда продакшен упал?
- Кто отвечает за решение инцидента SRE или команда?
- Как компенсировать дежурства, чтобы команда не выгорела?
2. DevOps инженеры, которые хотят перейти в SRE спрашивают:
- Что мне учить, откуда начать?
- Это интересно?
- Как вкатываться в дежурства?
- Как научиться траблшутить?
Помогаю ответить на «глупые» вопросы, которые на самом деле решают всё.
Отвечаю на них в канале и на консультациях - мой опыт с примерами из практики.
В Питере на SaintHighLoad 2026. Кто тут заходите поболтать.
Дали зелёные штаны гуру 🩳 ))
#конференция #highload
Дали зелёные штаны гуру 🩳 ))
#конференция #highload
👏1
Заметки с полей Yandex Infra Conf 2026 о выборе AI
Золотов Денис, ML-инженер - сделал важное наблюдение. Мне это приоткрыло дверцу в чуть более сложный мир нейросетей. Выбор сильно влияет на эффективность ваших AI-решений.
Вот что он пишет:
Наблюдение по итогам конференции.
На протяжении всего дня обсуждались LLM, инференс, деплой, телеметрия обучений.
Но ни разу чётко не прозвучало фундаментальное разделение которое определяет выбор инструмента.
Есть два принципиально разных типа данных — числа и слова.
LLM работает с токенами — она не знает что 1.45 > 1.44 в математическом смысле. Она знает что эти символы часто встречаются рядом в определённых контекстах.
Градиентный бустинг работает с числами как с числами — вычисляет, сравнивает, находит математические зависимости между величинами.
И это разделение не заканчивается на двух инструментах. Нейронные сети для временных рядов, классическая статистика, reinforcement learning, rule-based системы — каждый класс определяется природой данных и задачи, а не тем что сейчас у всех на слуху.
Большинство дискуссий про применение ИИ игнорируют этот фундамент. В итоге берут LLM там где нужен бустинг — и наоборот.
#ml #ai #эффективность #конференция #yandex_infraconf
Золотов Денис, 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)
Как вы решаете эту проблему?
Большая часть конвенций в 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)
Как вы решаете эту проблему?
Telegram
🚀🐳 Летит Кит: SRE и не только
OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей…
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей…
Эффективная работы с 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
Привет, киты 🐳!
Наверно все уже видели ролик, где показан расход на токены при одинаковом наборе запросов к разным моделям 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
GitHub
GitHub - colbymchenry/codegraph: Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini,…
Pre-indexed code knowledge graph, auto syncs on code changes, for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent — fewer tokens, fewer tool calls, 100% local - co...
В первый раз побывал на Summer Merge в Ульяновске. Лекции под соснами на кубиках из сена - это атмосферно.
Я выступал в роли Амбассадора набросков - это мое хобби. За два часа меня нарисовали более 100 раз 😄 Более 20 человек сначала стеснялись, а потом вместе смеялись, когда с 5 и 3 минут мы перешли к рисованию за минуту. Это было классно. Прикреплю несколько работ.
Было под 2000 человек, но это не ощущалось как давка, всем хватало места.
Это было как маленький отпуск в пионерском лагере 🏕️ Думаю поеду еще.
#summermerge #конференции
Я выступал в роли Амбассадора набросков - это мое хобби. За два часа меня нарисовали более 100 раз 😄 Более 20 человек сначала стеснялись, а потом вместе смеялись, когда с 5 и 3 минут мы перешли к рисованию за минуту. Это было классно. Прикреплю несколько работ.
Было под 2000 человек, но это не ощущалось как давка, всем хватало места.
Это было как маленький отпуск в пионерском лагере 🏕️ Думаю поеду еще.
#summermerge #конференции
❤🔥5
Попробовал разные IDE для Kubernetes
Для можно использовать всегда консольную kubectl, но так как я не постоянно там сижу - это забывается. В IDE же встроен и поиск и удобный переход.
Первой такой была Lens - коллега DevOps посоветовал, и действительно классная штука. Быстро работает.
Но в какой-то момент что-то поломалось в обновлении и при загрузке перестало появляться окно в Windows. Потому пошел искать альтернативы.
Первая FreeLens бесплатная и открытый код, повторяет Lens в большинстве функций, но есть баги - подгружает список конфигов только при старте, если добавишь, новые - перезапускай приложение.
Seabird - вообще еле завелось, тормозит ужасно, даешь ему куб конфиг сразу с токеном в теле, а он его не читает и надо руками указать еще раз при добавлении кластера.
HeadLamp - бага, на Windows не загружается полностью, конфликтует внутренний сервер с системными портам.
Короче пока самый надежный оказался консольный k9s.
#kubernetes #ide
Для можно использовать всегда консольную kubectl, но так как я не постоянно там сижу - это забывается. В IDE же встроен и поиск и удобный переход.
Первой такой была Lens - коллега DevOps посоветовал, и действительно классная штука. Быстро работает.
Но в какой-то момент что-то поломалось в обновлении и при загрузке перестало появляться окно в Windows. Потому пошел искать альтернативы.
Первая FreeLens бесплатная и открытый код, повторяет Lens в большинстве функций, но есть баги - подгружает список конфигов только при старте, если добавишь, новые - перезапускай приложение.
Seabird - вообще еле завелось, тормозит ужасно, даешь ему куб конфиг сразу с токеном в теле, а он его не читает и надо руками указать еще раз при добавлении кластера.
HeadLamp - бага, на Windows не загружается полностью, конфликтует внутренний сервер с системными портам.
Короче пока самый надежный оказался консольный k9s.
#kubernetes #ide
🔥1😁1
Forwarded from Мониторим ИТ
vmestimator
Утилита vmestimator отслеживает кардинальность и предоставляет результаты оценки в виде метрик . Это позволяет своевременно оповещать ответственных товарищей о скачках кардинальности и быстро идентифицировать проблему.
Отслеживание кардинальности — наиболее практичный вариант использования, но не единственный. vmestimator также можно использовать для измерения кардинальности по произвольным параметрам меток, что позволяет его применять для анализа использования каждого тенанта, отслеживать долгосрочные тренды и планировать мощности.
Репыч на Гитхаб
📱 Telegram | 📲 MAX
Утилита vmestimator отслеживает кардинальность и предоставляет результаты оценки в виде метрик . Это позволяет своевременно оповещать ответственных товарищей о скачках кардинальности и быстро идентифицировать проблему.
Отслеживание кардинальности — наиболее практичный вариант использования, но не единственный. vmestimator также можно использовать для измерения кардинальности по произвольным параметрам меток, что позволяет его применять для анализа использования каждого тенанта, отслеживать долгосрочные тренды и планировать мощности.
Репыч на Гитхаб
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Управление расходами на IT для CTO
Как FinOps помогает увидеть спрятанное, выключить ненужное, сэкономить деньги.
Да мы с вами строим большие и классные системы, которые дают много пользы, но чем больше объектов тем легче они теряются и про них забывают.
Помню как нашли сервер, который 3 года жил потреблял 0.1cpu при выделенных 2 - просто забыли Легаси сервис вывести.
С чего начинать? С инвентаризации, Зиночка! С инвентаризации! Да нам повезло, кажется, больше - не надо лазить и поднимать стулья и лампы, чтобы проверить номер. Но это не означает, что это проще, так как количество объектов растет с глубиной погружения.
Сначала мы начинаем с физических серверов, систем хранения, потом виртуальные машины, ноды kubernetes, сервисы и системы. Все это в итоге дает понимание какой сервис, что использует.
Можно ли это делать вручную, как Зина? Можно, только вам это предстоит делать постоянно, а не раз в год. Потом для ИТ-систем нужен автоматизированный сбор данных, разметка ресурсов в момент их создания и выделения. В итоге вы получите большой граф и понимание сколько у вас вычислительных ресурсов выделено 🤔
И это не все. Дальше вам нужны реальные метрики потребления ресурсов. Зачем?
Как раз для повышения эффективности утилизации. Мы с вами знаем, что разработчики часто любят выделить ресурсы про запас и забыть про это.
FinOps позволяет проводить регулярный аудит и управление ресурсами для сокращения затрат 💰.
Кроме того это позволяет затраты мониторить также и создавать FinOps инциденты с последующим расследованием и постмортемом. Как раз на SaintHighLoad 2026 ребята из Купер рассказывали случай, что отловили аномалию - за облако пришел счет на 20% больше, выяснили что скидки провайдера не применились в последнем месяце!
Подумаем вместе: как собирать данные инвентаризации, их хранить, объединять и анализировать?
Свои идеи и инструменты буду озвучивать в следующих постах.
#sre #FinOps #инциденты #cto
Как FinOps помогает увидеть спрятанное, выключить ненужное, сэкономить деньги.
Да мы с вами строим большие и классные системы, которые дают много пользы, но чем больше объектов тем легче они теряются и про них забывают.
Помню как нашли сервер, который 3 года жил потреблял 0.1cpu при выделенных 2 - просто забыли Легаси сервис вывести.
С чего начинать? С инвентаризации, Зиночка! С инвентаризации! Да нам повезло, кажется, больше - не надо лазить и поднимать стулья и лампы, чтобы проверить номер. Но это не означает, что это проще, так как количество объектов растет с глубиной погружения.
Сначала мы начинаем с физических серверов, систем хранения, потом виртуальные машины, ноды kubernetes, сервисы и системы. Все это в итоге дает понимание какой сервис, что использует.
Можно ли это делать вручную, как Зина? Можно, только вам это предстоит делать постоянно, а не раз в год. Потом для ИТ-систем нужен автоматизированный сбор данных, разметка ресурсов в момент их создания и выделения. В итоге вы получите большой граф и понимание сколько у вас вычислительных ресурсов выделено 🤔
И это не все. Дальше вам нужны реальные метрики потребления ресурсов. Зачем?
Как раз для повышения эффективности утилизации. Мы с вами знаем, что разработчики часто любят выделить ресурсы про запас и забыть про это.
FinOps позволяет проводить регулярный аудит и управление ресурсами для сокращения затрат 💰.
Кроме того это позволяет затраты мониторить также и создавать FinOps инциденты с последующим расследованием и постмортемом. Как раз на SaintHighLoad 2026 ребята из Купер рассказывали случай, что отловили аномалию - за облако пришел счет на 20% больше, выяснили что скидки провайдера не применились в последнем месяце!
Подумаем вместе: как собирать данные инвентаризации, их хранить, объединять и анализировать?
Свои идеи и инструменты буду озвучивать в следующих постах.
#sre #FinOps #инциденты #cto
Распределённая трассировка для 1С. ЧТО?
Привет, киты 🐳!
Разбирались с коллегами с распределенной трассировкой, писали как мы видим это у себя, чтобы люди делали одинаково и предсказуемо, а именно просто подключали бы нашу либу/пакет в проект и почти все уже было бы настроено.
Начали с того, что решили договориться. Стандарт по логам и метрикам у нас уже был, а по трассировке нет.
Подключились и коллеги разрабатывающие под 1С с вопросом, а нас сюда как?
Как ожидал, нет тут готовых решений и OTEL SDK 1C.
Что же можно сделать и как?
Нужно
1. отправлять спаны в коллектор из 1С
2. передавать контекст трассировки в вызовах из 1С, например, в HTTP или Kafka
3. извлечение контекста из входящих вызовов и прокидывание его внутри 1С
Как отправлять спаны
В1. Если не критичны задержки, то можно отправлять на HTTP endpoint OTEL Collector. Вызов будет в код синхронным, потому тут нужны короткие таймауты. Также можно, кстати и в PHP приложениях делать. А OTEL Collector лучше поставить сайдкаром прямо рядом с 1С, чтобы задержки были минимальные.
В2. Асинхронно. Через логи. Создаем файл 1с-traces.log (ротацию мы конечно не забыли включить) и в него скидываем готовые JSON со спанами, читает это файл агент типа Vector/FluentBit, готовит и отправляет в OTEL Collector
Как извлечь контекст трассировки
Читайте заранее определенные заголовки или метаданные, параметры фоновых задач (контекст трассировки в них надо явно передавать). Создавайте спан из них.
Как передавать контекст трассировки
В1. Линейный код (в рамках одго вызова). Добавьте доп параметр КонтекстТрассировки во все функции явно и передавайте.
В2. В рамках одного сеанса. Передавать через Параметры Сеанса (глобальное хранилище для текущего пользователя/сеанса HTTP). Работает только в рамках одного потока (сеанса). Если внутри кода вызывается фоновое задание, параметры сеанса туда автоматически не перенесутся.
В3. Передача в Фоновые задания. Самый частый сценарий в 1С: HTTP-сервис быстро принимает запрос, записывает документ и передает задачу фоновому заданию для отправки в Kafka. Передавайте структуру с TraceID и текущим SpanID внутрь массива параметров фонового задания. И доставайте в фоновом задании контекст для отправки спана если надо.
В4. Использование БСП (Библиотеки Стандартных Подсистем). БСП предоставляет готовые механизмы архитектуры, к которым можно «подцепиться», чтобы протащить TraceID от входа к выходу. Используйте ДополнительныеСвойства объектов, куда кладите контекст трассировки.
Интересно в реальности кто-нибудь делал такое у себя, ведь у многих компаний 1С часть бизнес-процессов многих?
#observability #1С #трейсинг #sre #distributed-tracing
Привет, киты 🐳!
Разбирались с коллегами с распределенной трассировкой, писали как мы видим это у себя, чтобы люди делали одинаково и предсказуемо, а именно просто подключали бы нашу либу/пакет в проект и почти все уже было бы настроено.
Начали с того, что решили договориться. Стандарт по логам и метрикам у нас уже был, а по трассировке нет.
Подключились и коллеги разрабатывающие под 1С с вопросом, а нас сюда как?
Как ожидал, нет тут готовых решений и OTEL SDK 1C.
Что же можно сделать и как?
Нужно
1. отправлять спаны в коллектор из 1С
2. передавать контекст трассировки в вызовах из 1С, например, в HTTP или Kafka
3. извлечение контекста из входящих вызовов и прокидывание его внутри 1С
Как отправлять спаны
В1. Если не критичны задержки, то можно отправлять на HTTP endpoint OTEL Collector. Вызов будет в код синхронным, потому тут нужны короткие таймауты. Также можно, кстати и в PHP приложениях делать. А OTEL Collector лучше поставить сайдкаром прямо рядом с 1С, чтобы задержки были минимальные.
В2. Асинхронно. Через логи. Создаем файл 1с-traces.log (ротацию мы конечно не забыли включить) и в него скидываем готовые JSON со спанами, читает это файл агент типа Vector/FluentBit, готовит и отправляет в OTEL Collector
Как извлечь контекст трассировки
Читайте заранее определенные заголовки или метаданные, параметры фоновых задач (контекст трассировки в них надо явно передавать). Создавайте спан из них.
Как передавать контекст трассировки
В1. Линейный код (в рамках одго вызова). Добавьте доп параметр КонтекстТрассировки во все функции явно и передавайте.
В2. В рамках одного сеанса. Передавать через Параметры Сеанса (глобальное хранилище для текущего пользователя/сеанса HTTP). Работает только в рамках одного потока (сеанса). Если внутри кода вызывается фоновое задание, параметры сеанса туда автоматически не перенесутся.
В3. Передача в Фоновые задания. Самый частый сценарий в 1С: HTTP-сервис быстро принимает запрос, записывает документ и передает задачу фоновому заданию для отправки в Kafka. Передавайте структуру с TraceID и текущим SpanID внутрь массива параметров фонового задания. И доставайте в фоновом задании контекст для отправки спана если надо.
В4. Использование БСП (Библиотеки Стандартных Подсистем). БСП предоставляет готовые механизмы архитектуры, к которым можно «подцепиться», чтобы протащить TraceID от входа к выходу. Используйте ДополнительныеСвойства объектов, куда кладите контекст трассировки.
Интересно в реальности кто-нибудь делал такое у себя, ведь у многих компаний 1С часть бизнес-процессов многих?
#observability #1С #трейсинг #sre #distributed-tracing