Forwarded from DevOps&SRE Library
Hidden Kubernetes Bad Practices Learned the Hard Way During Incidents
https://hackernoon.com/hidden-kubernetes-bad-practices-learned-the-hard-way-during-incidents
This article distills incident-driven lessons on troubleshooting, configuration mistakes, and operational habits that make Kubernetes outages worse.
https://hackernoon.com/hidden-kubernetes-bad-practices-learned-the-hard-way-during-incidents
👍3
Forwarded from Мониторим ИТ
Distributed tracing: от 100% error rate до первопричины за 60 секунд
В статье пошаговый разбор расследования ошибок в микросервисах: граф сервисов, хронология трейсов, корреляция логов и структурированная отладка на примере Uptrace.
Репыч Uptrace на Гитхабе
@monitorim_it
В статье пошаговый разбор расследования ошибок в микросервисах: граф сервисов, хронология трейсов, корреляция логов и структурированная отладка на примере Uptrace.
Репыч Uptrace на Гитхабе
@monitorim_it
🔥2
Недавно думал, как может выглядеть действительно нормальное внедрение AI в работе компании и кажется что тут напрашивается целая команда AIOps, которая этим должна заниматься на постоянной основе, в список обязанностей которой должно входить:
1. Выработка единой модели-стандарта использования моделей и агентов в компании, куда входит:
- определение точного списка моделей по ролям-скилам в компании
- определение списка моделей-ролей для конкретных продуктов и команд в компании
- определение списка поддерживаемых инструментов - агентов, IDE (или плагинов для IDE)
- определение списка пресетов для моделей для разного рода технических специалистов
- пайплайны для обновления скилов/пресетов у инженеров
2. Мониторинг использования:
- дашборды с задачами, утилизацией моделей, бюджетом токенов и тд. Алертинг там где это необходимо
- мониторинг доступности моделей (особенно внешних)
- мониторинг эффективности - какие модели более, а какие менее эффективны и для каких задач (тут можно внедрить инструменты на этапе код ревью генерированного кода и сбор ОС от инженеров)
- мониторинг всех запросов (в том числе мониторинг использования моделей не по назначению или без соблюдения принятых практик или использование сторонних моделей, не принятых в компании в п.1)
3. Сопровождение:
- наблюдение за тем, чтобы сохранялся уровень эффективности и не было деградации, тюнинг скилов/пресетов, а если необходимо, то и моделей (в случае использования локальных)
- бенчмаркинг новых моделей и создание ворклоада для этого бенчмаркинга, выявление ключевых параметров и сравнение моделей по ним
- оценка финансовой эффективности (тарифы моделей и их потребление)
- обработка запросов от "внешних заказчиков" - добавление новых скилов/пресетов, изменение старых
- маркетплейс промптов с удобным поиском
- работа по внедрению практик для команд - презентация решений, удобный шэринг практик, консультации по использованию
вот такой получился список, придуманный за чашкой кофе, но, кажется, это прямо необходимый минимум, без которого в компании будет в лучшем случае локальный "вайбкодинг", при котором коллеги говнят друг друга за слоп и плодят энтропию.
#орижиналконтент
1. Выработка единой модели-стандарта использования моделей и агентов в компании, куда входит:
- определение точного списка моделей по ролям-скилам в компании
- определение списка моделей-ролей для конкретных продуктов и команд в компании
- определение списка поддерживаемых инструментов - агентов, IDE (или плагинов для IDE)
- определение списка пресетов для моделей для разного рода технических специалистов
- пайплайны для обновления скилов/пресетов у инженеров
2. Мониторинг использования:
- дашборды с задачами, утилизацией моделей, бюджетом токенов и тд. Алертинг там где это необходимо
- мониторинг доступности моделей (особенно внешних)
- мониторинг эффективности - какие модели более, а какие менее эффективны и для каких задач (тут можно внедрить инструменты на этапе код ревью генерированного кода и сбор ОС от инженеров)
- мониторинг всех запросов (в том числе мониторинг использования моделей не по назначению или без соблюдения принятых практик или использование сторонних моделей, не принятых в компании в п.1)
3. Сопровождение:
- наблюдение за тем, чтобы сохранялся уровень эффективности и не было деградации, тюнинг скилов/пресетов, а если необходимо, то и моделей (в случае использования локальных)
- бенчмаркинг новых моделей и создание ворклоада для этого бенчмаркинга, выявление ключевых параметров и сравнение моделей по ним
- оценка финансовой эффективности (тарифы моделей и их потребление)
- обработка запросов от "внешних заказчиков" - добавление новых скилов/пресетов, изменение старых
- маркетплейс промптов с удобным поиском
- работа по внедрению практик для команд - презентация решений, удобный шэринг практик, консультации по использованию
вот такой получился список, придуманный за чашкой кофе, но, кажется, это прямо необходимый минимум, без которого в компании будет в лучшем случае локальный "вайбкодинг", при котором коллеги говнят друг друга за слоп и плодят энтропию.
#орижиналконтент
🔥9
А вот и опыт какой-то. Ожидаемо, конечно, что бигтех тут уже что-то делает
Forwarded from Цифра Комягина (Valeri Komyagin)
ИИ в разработке — опыт российских бигтехов
В среду попросили выступить перед чужой командой. Поделиться нашим опытом внедрения ИИ в конвейер разработки. Сижу, готовлюсь к докладу, и тут наш техлид скидывает во внутренний чат ссылку на доклад Андрея Попова из Яндекса.
Доклад всего 23 минуты. Можно смотреть на ускоренном — и тогда вовсе 15 получится. Найдите эту четверть часа, если руководите разработкой или в вашей компании есть inhouse-отдел. Не пожалеете.
Несколько тезисов:
👍 Разработчик и до ИИ тратил на код всего 30–35% времени, ещё 30% — коммуникации, ещё 15% — поиск информации и планирование. Генерация кода — это хорошо, но для максимизации эффекта нужно оптимизировать и остальные участки работы.
👍 Вовлечение (adoption) выросло за полгода втрое — до 84%. 57% разработчиков используют агентский режим в регулярной работе. Фронтендеры — 75%, бэкендеры — 60%.
👍 Рост числа коммитов на 10%, в отдельных языках на 20–30%. Доля сгенерированного кода — 30%. Но не спешите с выводами. Дочитайте пост до конца.
👍 Наиболее используемая модель — предсказуемо Claude. Но opensource-модели не радикально отстают по эффективности.
👍 Наибольший эффект — поиск информации, получение быстрых ответов на сложные вопросы. Среднее время поиска ответа сократилось с 20 минут до 2. Другие эффективные области: ревью кода, генерация чек-листов и тест-кейсов, тестирование (вплоть до автовыполнения интерфейсных тестов).
👍 Суммарная измеренная экономия часов — пока всего 2%. Планируют довести до 10%. Это важно осознать заказчикам — не в 5 и не в 10 раз экономия, ребят. Если получается достигнуть 15–20% — это уже успешный успех.
👍 Рабочие практики: agents.md как стандартизованный формат, готовый набор SKILLS для стандартизации лучших практик (golden path), развитие MCP и концепция AI-first.
👍 Профессии сливаются — профессионалы всё чаще залезают в области, в которых профессионалами не являются: бэкенды фронтендят, фронтенды дизайнерят. Приятно, что мои выводы в предыдущих постах совпали с профессионалами из Яндекса.
👍 Языки разработки тоже сливаются — это из другого доклада (Авито). Уже не столь важно, на чём программировать — AI снимает барьеры.
Яндекс ещё заботливо сделал на Хабре пост с тезисами докладов других бихтехов (Авито, Озон, Сбер, и т.д.) — полистайте, если интересно углубиться в тему.
Ну, а если хотите, чтобы я выступил и перед вашей командой — пишите. Занимаюсь сейчас и этим в том числе. График плотный, но постараюсь найти подходящий слот.
Цифра Комягина
В среду попросили выступить перед чужой командой. Поделиться нашим опытом внедрения ИИ в конвейер разработки. Сижу, готовлюсь к докладу, и тут наш техлид скидывает во внутренний чат ссылку на доклад Андрея Попова из Яндекса.
Доклад всего 23 минуты. Можно смотреть на ускоренном — и тогда вовсе 15 получится. Найдите эту четверть часа, если руководите разработкой или в вашей компании есть inhouse-отдел. Не пожалеете.
Несколько тезисов:
Яндекс ещё заботливо сделал на Хабре пост с тезисами докладов других бихтехов (Авито, Озон, Сбер, и т.д.) — полистайте, если интересно углубиться в тему.
Ну, а если хотите, чтобы я выступил и перед вашей командой — пишите. Занимаюсь сейчас и этим в том числе. График плотный, но постараюсь найти подходящий слот.
Цифра Комягина
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
AI dev в Яндексе: стали ли мы продуктивнее за год? / Андрей Попов
На митапе от Яндекса AI Dev Day, Андрей Попов, лидер трека AI в разработке в Яндексе, рассказывает как в компании считают метрики AI Productivity, на какие показатели стоит смотреть и каких результатов достигли в Яндексе за год.
❤️ Подписывайтесь на телеграм…
❤️ Подписывайтесь на телеграм…
👎6❤1🔥1
Forwarded from Валера Ковальский
SkillsБД 😂
В нашем AI чатике друзей ребята накинули а чего нет такого аналога в РФ как skills.sh?
Где будут собранны скиллы вокруг наших РФ сервисов для любых агентов в знакомом формате установки для кодинг агентов
Представляю вашему вниманию https://skillsbd.ru/
Навыки для работы с Яндекс, Битрикс, 1С и другими российскими сервисами. Устанавливайте одной командой, делитесь с RU-комьюнити
Есть простые проверки безопасноти (буду развивать сканнеры)
Есть скиллл find-skills который упаковывает всю бд в мощный поисковик
Модерация новых навыков ручная (будем так же автоматизировать)
На сегодня залил топ 3 скилла
1C
Bittix24
Яндекс сервисов
Любой может зарегистрироваться через гитхаб и тут же залить свой скилл через гитхаб и формат claude-skill
Чем отличается и будет отличаться
С этого канала стартует комьюинити вокруг данной БД + я сам лично буду продолжать поддерживать ряд навыков + уже залил навыки от части блогеров кто специализируется на работе с ними эври дей!
Навайбкожено от части из за задержки рейса Сочи>СПБ на 6 часов
Stay Tuned!
В нашем AI чатике друзей ребята накинули а чего нет такого аналога в РФ как skills.sh?
Где будут собранны скиллы вокруг наших РФ сервисов для любых агентов в знакомом формате установки для кодинг агентов
Представляю вашему вниманию https://skillsbd.ru/
Навыки для работы с Яндекс, Битрикс, 1С и другими российскими сервисами. Устанавливайте одной командой, делитесь с RU-комьюнити
Есть простые проверки безопасноти (буду развивать сканнеры)
Есть скиллл find-skills который упаковывает всю бд в мощный поисковик
Модерация новых навыков ручная (будем так же автоматизировать)
На сегодня залил топ 3 скилла
1C
Bittix24
Яндекс сервисов
Любой может зарегистрироваться через гитхаб и тут же залить свой скилл через гитхаб и формат claude-skill
Чем отличается и будет отличаться
С этого канала стартует комьюинити вокруг данной БД + я сам лично буду продолжать поддерживать ряд навыков + уже залил навыки от части блогеров кто специализируется на работе с ними эври дей!
Навайбкожено от части из за задержки рейса Сочи>СПБ на 6 часов
Stay Tuned!
👎8👍3
Forwarded from Useful Tools | Linux | GitOps | DevOps (Dmitry Malinin)
This media is not supported in your browser
VIEW IN TELEGRAM
Nerdlog - быстрый, ориентированный на удаленное взаимодействие, многохостовый TUI-просмотрщик логов с временной гистограммой и без центрального сервера. Он создан по мотивам Graylog/Kibana, но без лишних функций. Практически не требует настройки.Он ориентирован на высокую эффективность при одновременном запросе журналов с нескольких удаленных машин, фильтрации их по временному диапазону и шаблонам, а также построении интерактивной временной гистограммы для быстрого визуального анализа.
Основной сценарий использования: чтение системных журналов (из файлов
/var/log/messages или /var/log/syslog, или непосредственно из journalctl) с одного или нескольких удаленных хостов. Очень эффективно даже при работе с большими файлами журналов (например, 1 ГБ и более).Он поддерживает некоторые другие форматы логов и может использовать любые файлы логов, но именно это и стало основной причиной внедрения: наш бэкэнд веб-сервиса работал как службы systemd на множестве экземпляров Linux, выводя большое количество логов, и мы хотели иметь возможность эффективно читать эти логи и получать гистограмму временной шкалы, как это делают такие инструменты, как
Graylog.https://github.com/dimonomid/nerdlog
Опубликовано в @gitgate
#moni #log #graylog #kibana #journalctl #journald
Для всех, кто интересуется высоконагруженными системами и хочет лучше разбираться в тонкостях построения и эксплуатации отказоустойчивых систем на конференции Тех.Диалог мы сделали день мастер классов по SRE
https://techdialogos.ru/#day2
Начнем с базы эксплуатации - мониторинга. Как построить мониторинг, который будет помогать понять что реально происходит с продом? Что важнее, мониторинг инфраструктуры или бизнес метрики и как долго нужно хранить данные. И это только первая лекция. А всего их семь.
Расписание и билеты по ссылке
https://techdialogos.ru/
https://techdialogos.ru/#day2
Начнем с базы эксплуатации - мониторинга. Как построить мониторинг, который будет помогать понять что реально происходит с продом? Что важнее, мониторинг инфраструктуры или бизнес метрики и как долго нужно хранить данные. И это только первая лекция. А всего их семь.
Расписание и билеты по ссылке
https://techdialogos.ru/
👎5
Forwarded from /usr/bin
witr (Why is this running?)
Утилита witr отвечает на один-единственный вопрос:
Почему это запущено?
Когда что-либо работает в системе, будь то процесс, служба или что-то, привязанное к порту, всегда есть причина. Эта причина часто бывает косвенной, неочевидной или распределена по нескольким уровням, таким как контейнеры, службы или оболочки.
Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.
Репыч на Гитхаб
@usr_bin_linux
Утилита witr отвечает на один-единственный вопрос:
Почему это запущено?
Когда что-либо работает в системе, будь то процесс, служба или что-то, привязанное к порту, всегда есть причина. Эта причина часто бывает косвенной, неочевидной или распределена по нескольким уровням, таким как контейнеры, службы или оболочки.
Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.
Репыч на Гитхаб
@usr_bin_linux
❤1
Forwarded from Downtime Bar&Grill
Mar 01 9:41 AM PST We want to provide some additional information on the power issue in a single Availability Zone in the ME-CENTRAL-1 Region. At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire. We are still awaiting permission to turn the power back on, and once we have, we will ensure we restore power and connectivity safely.
Прилетела тут очередная пачка новостей, которые в из раза в раз не устают нам напоминать: если у вас одна площадка/датацентр/хостинг провайдер - вам нужно думать о плане Б, который ответит на вопросы:
Если ответов на эти вопросы нет - рассказываем по шагам как этот план Б сделать:
Если проблемы (время недоступности, допустимая величина потери данных и т.п.) в рамках допустимых - поздравляю, у вас есть полноценный DRP! Через два месяца повторите, за одно увидите, насколько хороша у вас документация по переключению.
@downtime_bar #DRP #Disaster_recovery_plan
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from GitHub Open Sauce
hmans/beans
Beans — это трекер задач для вас, вашей команды и ваших агентов по написанию кода. Вместо того чтобы отслеживать задачи в отдельном приложении, Beans хранит их прямо рядом с вашим кодом. Вы можете использовать интерфейс командной строки Beans для взаимодействия со своими задачами, но что еще важнее — это может делать и ваш любимый агент по программированию
#golang
https://github.com/hmans/beans
Больше про программирование на https://kodikapusta.ru
Beans — это трекер задач для вас, вашей команды и ваших агентов по написанию кода. Вместо того чтобы отслеживать задачи в отдельном приложении, Beans хранит их прямо рядом с вашим кодом. Вы можете использовать интерфейс командной строки Beans для взаимодействия со своими задачами, но что еще важнее — это может делать и ваш любимый агент по программированию
#golang
https://github.com/hmans/beans
Больше про программирование на https://kodikapusta.ru
Forwarded from Мишка на сервере (Mikhail Savin)
UUID v4 vs UUID v7 — почему это важно для SRE?
Привет,
Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
Привет,
%username%! Сегодня поговорим о вещи, которая на первый взгляд кажется мелкой деталью — выборе версии UUID. Но если ты работаешь с высоконагруженными системами, эта "мелочь" влияет на производительность БД, I/O и даже на читаемость логов во время инцидентов.Что под капотом?
UUID v4 — это 128 бит чистой случайности (122 значимых бита). Красиво, уникально, предсказуемо. Но абсолютно хаотично с точки зрения порядка.
UUID v7 — первые 48 бит это Unix timestamp в миллисекундах, остальное — случайность. Идентификаторы монотонно возрастают, то есть более новые UUID всегда лексикографически больше старых.
Почему это критично для нас с тобой?
Проблема UUID v4 — это то, что происходит с B-tree индексом в твоей БД при вставке:
- Каждый новый UUID случаен → вставки идут в произвольные места индекса;
- Это вызывает page splits (расщепление страниц) и write amplification;
- Фрагментация листовых страниц индекса у v4 достигает ~50%, тогда как у v7 — около 0%;
- Бенчмарки показывают: вставка с UUID v7 до ~34.8% быстрее, чем с v4 на 10 млн строк;
- Запросы (point lookup и range scan) у v7 быстрее за счёт лучшей локальности индекса.
SRE-профит от перехода на v7
-
ORDER BY created_at становится менее актуальным — можно сортировать прямо по PK;- При разборе инцидента UUID в логах сразу показывает временной порядок событий — экономит время в постмортеме;
- Меньше фрагментации → меньше нагрузка на autovacuum в PostgreSQL → меньше сюрпризов в VACUUM-графиках;
- Снижается write amplification → меньше нагрузка на диск, особенно актуально для облачных managed БД с billing per I/O.
Когда v4 всё ещё ок?
- Токены сессий, CSRF-токены — там сортировка не нужна, максимальная случайность важнее;
- Системы, где раскрытие временнОго паттерна нежелательно по соображениям безопасности.
Переход с v4 на v7 в новых сервисах — это практически бесплатный перформанс буст. Библиотеки есть во всех основных языках, а PostgreSQL 18 получит нативную поддержку
uuidv7() из коробки.Делись в комментариях — используешь ли уже UUID v7 в своих системах? Сталкивался ли с фрагментацией индексов из-за v4 в проде? Как решал — автовакуум, партиционирование, или всё-таки миграция на v7?
#SRE #DevOps #Database #PostgreSQL #UUID #Performance #IndexOptimization #BackendEngineering
❤3👍2
Forwarded from DevOps&SRE Library
linnix
https://github.com/linnix-os/linnix
eBPF-powered Linux observability with AI incident detection.
https://github.com/linnix-os/linnix