Forwarded from DevOps FM
Бодрый DevOps! Ранее мы разобрались в архитектуре модульного монолита, сегодня рассмотрим, как и зачем крупнейший сервис Shopify перешел на MySQL на этапе оформления заказов.
Нагрузки на Shopify всегда были высоки, особенно в Черную Пятницу. Прежде для резервирования и оформления товаров компания использовала Redis, но система сталкивалась с ограничениями консистентности между двумя БД. Тогда, инженеры Shopify решили перенести механизм резервирования целиком в MySQL.
В кейсе представили, как команда использовала:
SKIP LOCKED для совмещенных строк и ACID для обнаружения баговREAD COMMITTED для борьбы с блокировкой промежутковUNION ALL для сокращения времени обращенийИз интересного описали проблемы с пуллом соединений под нагрузкой в MySQL. Здесь можно узнать всё о переходе.
#девопс #БД #MySQL #Redis
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤2👎1
А Вы знали, что кроме постгресса есть другие базы данных? Быстрые, легко масштабируемые, с богатой экосистемой, поддерживаемые разными компаниями. Один из таких примеров - MySQL c форками MariaDB и Percona Server.
Если вы работаете с MySQL или хотели бы больше узнать об этой СУБД - добро пожаловать на единственный на данный момент в России интенсив, покрывающий все ключевые этапы эксплуатации MySQL в высоконагруженных приложениях: от установки до оптимизации запросов и масштабирования.
Два подряд интенсива проходят в разное время: вечерний для тружеников европейской части РФ пройдет с двадцать третьего по двадцать пятое июня ежедневно с 19:00 до 21:00 по Московскому времени в режиме онлайн. Утренний, для удобства жителей Сибири, Байкала и Дальнего Востока - с тридцатого июня по второе июля с 10:00 утра до 12:00 по Москве.
Каждая встреча посвящена одному большому разделу.
День 1: Ставим и тюним MySQL для работы с высокими нагрузками
Поговорим про версии и форки, про начальную настройку и общую архитектуру. Разберемся что и как нужно мониторить, что бы увидтеть проблемы раньше, чем база упадет.
День 2: Учимся писать самые быстрые в мире запросы MySQL и использовать ClickHouse для аналитики
Поговорим про оптимизацию запросов, про индексы и миграции. Отдельно зацепим внешние инструменты для работы с аналитическими и полнотекстовыми запросами
День 3: Строим отказоустойчивую инфраструктуру для MySQL
Часть интенсива, которая очень пригодится тем, кто работает с действительно высокими нагрузками: поговорим о масштабировании, горизонтальном и функциональном шардировании, разберемся в тонкостях работы репликации (асинхронной, синхронной и мастер-мастер) и научимся балансировать нагрузку.
Подробности и билеты по ссылке https://fournines.ru/mysql_workshop
Если вы работаете с MySQL или хотели бы больше узнать об этой СУБД - добро пожаловать на единственный на данный момент в России интенсив, покрывающий все ключевые этапы эксплуатации MySQL в высоконагруженных приложениях: от установки до оптимизации запросов и масштабирования.
Два подряд интенсива проходят в разное время: вечерний для тружеников европейской части РФ пройдет с двадцать третьего по двадцать пятое июня ежедневно с 19:00 до 21:00 по Московскому времени в режиме онлайн. Утренний, для удобства жителей Сибири, Байкала и Дальнего Востока - с тридцатого июня по второе июля с 10:00 утра до 12:00 по Москве.
Каждая встреча посвящена одному большому разделу.
День 1: Ставим и тюним MySQL для работы с высокими нагрузками
Поговорим про версии и форки, про начальную настройку и общую архитектуру. Разберемся что и как нужно мониторить, что бы увидтеть проблемы раньше, чем база упадет.
День 2: Учимся писать самые быстрые в мире запросы MySQL и использовать ClickHouse для аналитики
Поговорим про оптимизацию запросов, про индексы и миграции. Отдельно зацепим внешние инструменты для работы с аналитическими и полнотекстовыми запросами
День 3: Строим отказоустойчивую инфраструктуру для MySQL
Часть интенсива, которая очень пригодится тем, кто работает с действительно высокими нагрузками: поговорим о масштабировании, горизонтальном и функциональном шардировании, разберемся в тонкостях работы репликации (асинхронной, синхронной и мастер-мастер) и научимся балансировать нагрузку.
Подробности и билеты по ссылке https://fournines.ru/mysql_workshop
👎12
Forwarded from k8s (in)security (r0binak)
PII-Shield —
Сочетание
open-source инструмент для защиты логов и данных от утечки персональной информации прямо в Kubernetes . Он работает как sidecar контейнер, перехватывает stdout/stderr, находит секреты и чувствительные данные до того, как они попадут в лог-системы.Сочетание
Shannon Entropy для поиска неизвестных секретов (токены, API-ключи, пароли) и O(1) regex для точного детектирования известных паттернов снижает false positive и позволяет находить даже то, что не было заранее описано правилами.PII-Shield работает полностью локально, без API вызовов наружу, с почти нулевой нагрузкой на GC. Интересный проект, чтобы попробовать безопасно коррелировать логи между сервисами, не раскрывая реальные данные.🔥3👍1
Forwarded from Go Library
Zero-config Go heap profiling
https://coroot.com/blog/zero-config-go-heap-profiling
Coroot's node-agent already collects CPU profiles for any process on the node using eBPF, with zero integration from the application side. For Java, we dynamically inject async-profiler into the JVM to get memory and lock profiles. But Go processes were still a blind spot for non-CPU profiling unless the app exposed a pprof endpoint and the cluster-agent scraped it.
We wanted the same zero-config experience for Go heap profiles. This post is about how we got there.
https://coroot.com/blog/zero-config-go-heap-profiling
Forwarded from 🚀🐳 Летит Кит: SRE и не только
AI SRE Summit 2026: выжимка из заметок
Привет, киты 🐳.
Наткнулся на пост на реддите и решил поделиться.
AI в SRE - это уже не демо, а продакшен. Вопросы сместились с "как это работает" на "кто отвечает, когда оно ломается".
Ключевые тезисы
1. Стоимость и надёжность - это одно целое
ИИ-агент, который лечит инцидент автоскейлингом, может накрутить счёт за облако на $50K. Если в ваших SLO нет бюджета - вы не контролируете надёжность.
2. Нельзя наложить ИИ на сломанную платформу
Broken platform + AI = более сложный баг, который сложнее отладить. Сначала наведите порядок в конфигурациях, логировании и деплое. Потом добавляйте агентов.
3. Observability теперь для машин
ИИ-агенту нужна структурированная, семантически богатая телеметрия. Если логи - это "text/plain с примесью надежды", агент будет гадать. Гадание в продакшене = инцидент.
4. У ИИ-агента нет владельца
Кто отвечает, когда автономный агент неправильно интерпретировал метрику или запустил неверный скрипт? Пока это серая зона. Нужны чёткие рамки: что агент делает сам, а где нужен человеческий апрув.
5. Роль SRE трансформируется
Было: тушим пожары, пишем ранбуки, дежурим.
Становится: проектируем границы автономии, пишем политики, интерпретируем решения ИИ.
Что уже сделать бы надо
- Добавьте бюджетные лимиты (деньги) в error budgets. Нет денег - нет надёжности
- Структурируйте логи под ИИ: векторизуйте, тегируйте, давайте контекст. Logfmt лучше свободного текста
- Введите режимы для агентов: автономно / с апрувом / только рекомендации. Переключайте по уровню риска
- Документируйте решения ИИ для постмортема и обучения
- Тренируйте команду на гибридных сценариях: человек + ИИ, а не "или-или"
Что я думаю
Главный риск - не технология, а управленческая иллюзия: запустили агента и можно расслабиться. Не расслабляйтесь - Н, наблюдайте за наблюдателем.
ИИ - усилитель процессов. Хаос ускорит хаос. База + ИИ = масштабирование надёжности.
Вопрос: если агент чинит инциденты, кто чинит агента когда он сломался?
P.s. вспоминается статья 1982 г "Иронии автоматизации", проблемы те же
Привет, киты 🐳.
Наткнулся на пост на реддите и решил поделиться.
AI в SRE - это уже не демо, а продакшен. Вопросы сместились с "как это работает" на "кто отвечает, когда оно ломается".
Ключевые тезисы
1. Стоимость и надёжность - это одно целое
ИИ-агент, который лечит инцидент автоскейлингом, может накрутить счёт за облако на $50K. Если в ваших SLO нет бюджета - вы не контролируете надёжность.
2. Нельзя наложить ИИ на сломанную платформу
Broken platform + AI = более сложный баг, который сложнее отладить. Сначала наведите порядок в конфигурациях, логировании и деплое. Потом добавляйте агентов.
3. Observability теперь для машин
ИИ-агенту нужна структурированная, семантически богатая телеметрия. Если логи - это "text/plain с примесью надежды", агент будет гадать. Гадание в продакшене = инцидент.
4. У ИИ-агента нет владельца
Кто отвечает, когда автономный агент неправильно интерпретировал метрику или запустил неверный скрипт? Пока это серая зона. Нужны чёткие рамки: что агент делает сам, а где нужен человеческий апрув.
5. Роль SRE трансформируется
Было: тушим пожары, пишем ранбуки, дежурим.
Становится: проектируем границы автономии, пишем политики, интерпретируем решения ИИ.
Что уже сделать бы надо
- Добавьте бюджетные лимиты (деньги) в error budgets. Нет денег - нет надёжности
- Структурируйте логи под ИИ: векторизуйте, тегируйте, давайте контекст. Logfmt лучше свободного текста
- Введите режимы для агентов: автономно / с апрувом / только рекомендации. Переключайте по уровню риска
- Документируйте решения ИИ для постмортема и обучения
- Тренируйте команду на гибридных сценариях: человек + ИИ, а не "или-или"
Что я думаю
Главный риск - не технология, а управленческая иллюзия: запустили агента и можно расслабиться. Не расслабляйтесь - Н, наблюдайте за наблюдателем.
ИИ - усилитель процессов. Хаос ускорит хаос. База + ИИ = масштабирование надёжности.
Вопрос: если агент чинит инциденты, кто чинит агента когда он сломался?
P.s. вспоминается статья 1982 г "Иронии автоматизации", проблемы те же
👎3🔥1
Forwarded from DevOps Deflope News
Дочитал «Настоящий SRE» Дэвида Бланк-Эдельмана. Это третий пост из серии, я Алексей Крылов, менеджер продукта. Итоговые впечатления.
Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта.
Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает.
Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию.
Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость.
Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой».
Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает.
Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше.
P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)
Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта.
Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает.
Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию.
Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость.
Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой».
Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает.
Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше.
P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)
Forwarded from Мониторим ИТ
This media is not supported in your browser
VIEW IN TELEGRAM
cardamon
Да, интересные названия придумывают для открытых решений. В этом случае, возможно, имелась в виду секретная приправа, которой так не хватало Prometheus.
Это аудитор метрик для Prometheus. Он выявляет метрики, которые существуют в TSDB, но никогда не запрашиваются дашбордами, алерт рулами или просто пользователями. Здесь же вы можете сгенерировать правила удаления метрик Prometheus и снизить утилизацию хранилища.
Репыч на Гитхаб
📱 Telegram | 📲 MAX
Да, интересные названия придумывают для открытых решений. В этом случае, возможно, имелась в виду секретная приправа, которой так не хватало Prometheus.
Это аудитор метрик для Prometheus. Он выявляет метрики, которые существуют в TSDB, но никогда не запрашиваются дашбордами, алерт рулами или просто пользователями. Здесь же вы можете сгенерировать правила удаления метрик Prometheus и снизить утилизацию хранилища.
Репыч на Гитхаб
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
Forwarded from /usr/bin
SELinux — Быстрый онбординг: типы, атрибуты, домены, политики и утилиты на практике
Читать дальше на Хабре.
@usr_bin_linux
В статье пойдет речь о SELinux. Главная моя задача — провести быстрый онбординг о том, как работать с политиками доступов. Я хочу показать, что это вовсе не так сложно, как может показаться на первый взгляд. Буквально 15 минут ознакомления с базовыми понятиями дает 80% понимания как работать с SELinux более уверенно.
Статья не совсем про написание политик, скорее про их понимание. Все описанное необходимо, чтобы уверенно пользоваться утилитами, более осмысленно работать с системой, решать проблемы и задачи, с которыми придется столкнуться в процессе эксплуатации SELinux.
Читать дальше на Хабре.
@usr_bin_linux
🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Стрим о защите контейнеров, который нельзя пропустить
Без лишних слов:
1. Обзор актуальных угроз для контейнерных сред
2. Kaspersky Container Security на практике — демонстрация новых фич в бою
3. ИИ функциональность для поиска неочевидных рисков в образах
4. Многое другое про защиту контейнеров от разработки до рантайма
Настоящее и будущее контейнерных сред обсудят эксперты «Лаборатории Касперского» и платформы «Штурвал» 28 мая в 11:00.
Смотреть и регистрироваться.
Без лишних слов:
1. Обзор актуальных угроз для контейнерных сред
2. Kaspersky Container Security на практике — демонстрация новых фич в бою
3. ИИ функциональность для поиска неочевидных рисков в образах
4. Многое другое про защиту контейнеров от разработки до рантайма
Настоящее и будущее контейнерных сред обсудят эксперты «Лаборатории Касперского» и платформы «Штурвал» 28 мая в 11:00.
Смотреть и регистрироваться.
👎4
Forwarded from about:performance
О бенчмаркинге, часть 1
Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения.
По сути, это способ оценить производительность системы под нагрузкой.
Брендан Грегг в своё время ввёл наглядную терминологию:
* Passive Benchmarking
* Active Benchmarking
———
Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься.
Но это как раз тот случай, когда «просто» не значит «лучше».
Проблемы таких замеров:
* риск измерить не то, что планировалось изначально
* непонятно, что именно ограничивает производительность
* нельзя отличить систематическое отклонение от шума (об этом позже)
* остаемся без ответа, почему получены именно такие результаты
* сами бенчмарки могут содержать баги, что останется от нас скрыто
В итоге решения на основе таких данных могут оказаться даже хуже, чем если бы данных не было вовсе.
———
В противовес ему стоит Active Benchmarking (AB).
Помимо настройки окружения требуется активное наблюдение за системой во время прогона.
Задача понять:
* то ли мы меряем, что планировали
* что ограничивает производительность
* согласуется ли наблюдаемое поведение с нашей моделью системы
* что нужно изменить, чтобы улучшить результат
AB способен дать более надёжный результат.
Цена этого: более высокие требования к проведению эксперимента. Нужно не только уметь настроить окружение, но и верно интерпретировать наблюдаемое.
Алгоритм:
1. Собрать данные о работе системы, тулинг в помощь (perf, bcc, iostat, bpftrace, tcpdump, ...)
2. Интерпретировать, как реагирует система (методологии USE, RED, off-CPU, TSA, ...)
3. Применять в цикле:
Каждый пункт по отдельности даёт ограниченный эффект, зато вместе позволяет быстрее и увереннее продвигаться вперёд.
———
Вывод
Сырые цифры от Passive Benchmarking могут выглядеть правдоподобно и при этом вести к неверным и дорогим решениям.
Слепо доверяясь им, мы фактически надеемся, что угадали с сетапом с первого раза и учли все нюансы.
Не похоже на надёжную стратегию
Active Benchmarking напротив, позволяет избежать ловушки «бенчмаркаешь A, измеряешь B, делаешь выводы о C».
Цифры, полученные таким методом, поддаются объяснению, их можно оспорить и воспроизвести.
И на них уже можно опираться при принятии инженерных решений.
———
Что почитать
- Active Benchmarking
- CPU Benchmarks and Bad Tinder Dates
- Performance Methodologies
- Producing Wrong Data Without Doing Anything Obviously Wrong (тут может помочь заметка о чтении white paper)
To be continued...
———
Поддержать лайком на Linkedin.
Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения.
По сути, это способ оценить производительность системы под нагрузкой.
Брендан Грегг в своё время ввёл наглядную терминологию:
* Passive Benchmarking
* Active Benchmarking
———
Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься.
Но это как раз тот случай, когда «просто» не значит «лучше».
Проблемы таких замеров:
* риск измерить не то, что планировалось изначально
* непонятно, что именно ограничивает производительность
* нельзя отличить систематическое отклонение от шума (об этом позже)
* остаемся без ответа, почему получены именно такие результаты
* сами бенчмарки могут содержать баги, что останется от нас скрыто
«Бенчмаркаешь A, на самом деле измеряешь B, а выводы делаешь о C». ©
В итоге решения на основе таких данных могут оказаться даже хуже, чем если бы данных не было вовсе.
———
В противовес ему стоит Active Benchmarking (AB).
Помимо настройки окружения требуется активное наблюдение за системой во время прогона.
Задача понять:
* то ли мы меряем, что планировали
* что ограничивает производительность
* согласуется ли наблюдаемое поведение с нашей моделью системы
* что нужно изменить, чтобы улучшить результат
AB способен дать более надёжный результат.
Цена этого: более высокие требования к проведению эксперимента. Нужно не только уметь настроить окружение, но и верно интерпретировать наблюдаемое.
Алгоритм:
1. Собрать данные о работе системы, тулинг в помощь (perf, bcc, iostat, bpftrace, tcpdump, ...)
2. Интерпретировать, как реагирует система (методологии USE, RED, off-CPU, TSA, ...)
3. Применять в цикле:
запустил
└─ пронаблюдал
└─ сформулировал гипотезу во что упираемся
└─ проверил в следующем прогоне
└─ повторил
Каждый пункт по отдельности даёт ограниченный эффект, зато вместе позволяет быстрее и увереннее продвигаться вперёд.
———
Вывод
Сырые цифры от Passive Benchmarking могут выглядеть правдоподобно и при этом вести к неверным и дорогим решениям.
Слепо доверяясь им, мы фактически надеемся, что угадали с сетапом с первого раза и учли все нюансы.
Не похоже на надёжную стратегию
Active Benchmarking напротив, позволяет избежать ловушки «бенчмаркаешь A, измеряешь B, делаешь выводы о C».
Цифры, полученные таким методом, поддаются объяснению, их можно оспорить и воспроизвести.
И на них уже можно опираться при принятии инженерных решений.
———
Что почитать
- Active Benchmarking
- CPU Benchmarks and Bad Tinder Dates
- Performance Methodologies
- Producing Wrong Data Without Doing Anything Obviously Wrong (тут может помочь заметка о чтении white paper)
To be continued...
———
Поддержать лайком на Linkedin.
👍2👎1
Forwarded from Библиотека Go-разработчика | Golang
В Go 1.26
go fix переписан с нуля. Теперь это полноценный движок модернизации: заменяет if/else на min/max, переписывает циклы на range-over-int, подставляет strings.Cut вместо strings.Index — и ещё десятки трансформаций за один запуск.Звучит удобно. Но после
go fix ./... код может сломаться или, хуже, молча изменить поведение.Два типа конфликтов
Синтаксические —
go fix ловит сам и просит запустить повторно.Семантические — опаснее. Две независимые правки вместе могут сделать переменную неиспользуемой — и это уже ошибка компиляции. Лишние импорты инструмент уберёт сам, но с переменными придётся разбираться вручную.
Тихие изменения поведения
appendclipped заменяет append([]T(nil), s...) на slices.Clone(s). Если s пустой — Clone вернёт nil. Для JSON это разница между null и []. Анализатор по умолчанию выключен, но показательно.slicescontains заменяет цикл на slices.Contains. Если выражение для искомого элемента имело побочные эффекты — поведение изменится. Этот баг попал в трекер и был исправлен в 1.26.3.Как работать безопасно
Сначала смотрите diff без применения:
go fix -diff ./...
Запускайте из чистого git-состояния, в отдельной ветке.
Если сломалось — изолируйте анализатор:
go fix -slicescontains=false ./...
go fix -minmax ./...
Не забывайте про платформы: один запуск обрабатывает только текущую конфигурацию сборки. Для мультиплатформенных проектов запускайте с разными
GOOS/GOARCH.go fix — мощный инструмент, но не автопилот.📍 Навигация: Вакансии • Задачи • Собесы • Канал в Max
#GoDeep
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2
Forwarded from Мониторим ИТ
Choosing a Python Logging Library in 2026
Python использует стандартную библиотеку
В этой статье рассматриваются следующие вопросы: какие библиотеки существуют, как они соотносятся друг с другом, где они пересекаются со стандартной библиотекой и когда каждая из них имеет смысл.
📱 Telegram | 📲 MAX
Python использует стандартную библиотеку
logging, что означает, что большая часть существующего кода на Python уже использует её на том или ином уровне, и каждая альтернатива от сторонних разработчиков строится на её основе, оборачивает его или намеренно заменяет её.В этой статье рассматриваются следующие вопросы: какие библиотеки существуют, как они соотносятся друг с другом, где они пересекаются со стандартной библиотекой и когда каждая из них имеет смысл.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎1
Forwarded from Админим с Буквой (Aleksandr Kondratev)
cis.pdf
557.7 KB
Поздравляю всех подписчиков с началом лета! И вручаю вам тёплый летний подарок: методичку по харденингу Ubuntu 24.04 на русском.
Методичка - моего авторства (@bykva)
Долгие и нудные часы чтения 1000-страничного CIS и публичной ansible роли зародили во мне идею - вот бы была готовая выжимка, по которой можно было бы настроить автоматизацию, при этом понимать что именно она выполняет. и сделать это за 1 день, а не за несколько недель.
В итоге родилась она - сжатая выжимка тысячестраничного CIS Benchmark: по каждому пункту коротко - что и зачем настраивать, с выделенными нюансами и ссылками на источники.
Внутри - более подробное описание что это и зачем.
З.Ы. саммаризация была сделана полностью без ИИ, но вот цветовое оформление, фактчекинг и правки орфографии и пунктуации я уже делал с помощью него, поэтому что-то могло поехать. Буду благодарен за ОС.
Методичка - моего авторства (@bykva)
Долгие и нудные часы чтения 1000-страничного CIS и публичной ansible роли зародили во мне идею - вот бы была готовая выжимка, по которой можно было бы настроить автоматизацию, при этом понимать что именно она выполняет. и сделать это за 1 день, а не за несколько недель.
В итоге родилась она - сжатая выжимка тысячестраничного CIS Benchmark: по каждому пункту коротко - что и зачем настраивать, с выделенными нюансами и ссылками на источники.
Внутри - более подробное описание что это и зачем.
З.Ы. саммаризация была сделана полностью без ИИ, но вот цветовое оформление, фактчекинг и правки орфографии и пунктуации я уже делал с помощью него, поэтому что-то могло поехать. Буду благодарен за ОС.
👍4🔥3❤2👎1
Forwarded from HABR FEED + OPENNET
5 слоев кэширования в веб-приложениях: Полное руководство для Python-разработчиков #habr
https://habr.com/ru/articles/1031748/
Tags: кэширование, http-заголовки, cdn, local storage
Author: artemshumeiko
https://habr.com/ru/articles/1031748/
Tags: кэширование, http-заголовки, cdn, local storage
Author: artemshumeiko
Хабр
5 слоев кэширования в веб-приложениях: Полное руководство для Python-разработчиков
Содержание Введение в кэширование: что это и зачем нужно Когда применять и когда избегать кэширования Внутренний кэш приложения: преимущества и ограничения Внешний кэш: использование Redis и стратегия...
👍1
Forwarded from DevOps FM
В эфире DevOps FM с первой летней подборкой новостей!
⏺ Стало известно о масштабном инциденте провайдера MIRhosting. Платформа nLighten без предупреждения отключила оборудование, и часть инфраструктуры компаний в европейских ДЦ стала недоступна.
На момент публикации остановлена работа серверов в Германии и Нидерландах. Также недоступны THE.Hosting, UFO.Hosting, Alexhost.com, Vdsina.com и другие. Накануне инцидента MIRhosting подвергся проверкам регуляторов, были предъявлены обвинения в обходе санкций.
⏺ Codex обнаружил новую уязвимость. HTTP/2 Bomb позволяет провести удалённую DoS-атаку на серверы с включённым HTTP/2. Проблема затрагивает NGINX, Apache HTTPD, Microsoft IIS, Envoy и Cloudflare Pingora в конфигурации по умолчанию.
Атака сочетает две известные техники:
• Первая использует особенности HPACK, сжатия HTTP-заголовков в HTTP/2, из-за которого расходуется больше памяти сервера.
• Вторая техника работает на задержке через flow control, из-за которого ресурсы не освобождаются.
Весь PoC – здесь, а список затронутых серверов и рекомендации – тут.
⏺ Шон Вэбб отчитался о прогрессе HardenedBSD за апрель и май 2026.
Основная часть усилий ушла на миграцию с GitLab на Radicle. Ключевые репозитории уже перенесены, хотя Вэбб сообщил, что часть интеграций ещё дорабатывается вручную. За два месяца вышло несколько рекомендаций по безопасности для FreeBSD и новые сборки FreeBSD 16, FreeBSD 15.
⏺ Вслед за обзором инцидентов атак ИИ-агентов блоге Docker вышло 2 практических гайда по безопасности в песочнице.
В первой Шрини Секаран разбирает набор из 5-ти практик обеспечения безопасности: ограничение процессов, контроль сети, лимиты ресурсов и постоянный мониторинг поведения во время выполнения.
Во второй части даёт схему внедрения принципов в жизненный цикл работы ИИ-агента и оставляет подробный чек-лист для проверки.
⏺ В блоге CNCF вышел подробный разбор архитектуры платформы разработки на базе Kubernetes. Автор показывает, как объединить принципы нативных облачных технологи, IaC, GitOps и практики безопасности цепочки поставок. Логика построена на работе трёх уровней – архитектуры, платформы и приложения.
⏺ На Medium рассказали о сетях Kubernetes, от базовых принципов до практических сценариев. В статье описали логику работы pod IP, роль CNI-плагинов и особенности ClusterIP, NodePort и LoadBalancer. Отдельно вынесли частые вопросы и сценарии отладки проверок селекторов Service, бесконечным <pending> и проблемами в работе CNI.
#новостная_подборка #девопс #Docker #Kubernetes #HardenedBSD
На момент публикации остановлена работа серверов в Германии и Нидерландах. Также недоступны THE.Hosting, UFO.Hosting, Alexhost.com, Vdsina.com и другие. Накануне инцидента MIRhosting подвергся проверкам регуляторов, были предъявлены обвинения в обходе санкций.
Атака сочетает две известные техники:
• Первая использует особенности HPACK, сжатия HTTP-заголовков в HTTP/2, из-за которого расходуется больше памяти сервера.
• Вторая техника работает на задержке через flow control, из-за которого ресурсы не освобождаются.
Весь PoC – здесь, а список затронутых серверов и рекомендации – тут.
Основная часть усилий ушла на миграцию с GitLab на Radicle. Ключевые репозитории уже перенесены, хотя Вэбб сообщил, что часть интеграций ещё дорабатывается вручную. За два месяца вышло несколько рекомендаций по безопасности для FreeBSD и новые сборки FreeBSD 16, FreeBSD 15.
В первой Шрини Секаран разбирает набор из 5-ти практик обеспечения безопасности: ограничение процессов, контроль сети, лимиты ресурсов и постоянный мониторинг поведения во время выполнения.
Во второй части даёт схему внедрения принципов в жизненный цикл работы ИИ-агента и оставляет подробный чек-лист для проверки.
#новостная_подборка #девопс #Docker #Kubernetes #HardenedBSD
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Forwarded from Технологический Болт Генона
Материалы и слайды своего мастер-класса на CodeFest выложил на GitHub (продублирую в комменты)
Open source на страже Kubernetes Runtime Security
https://github.com/rusdacent/codefest-2026
Open source на страже Kubernetes Runtime Security
https://github.com/rusdacent/codefest-2026
👍1
Forwarded from /usr/bin
Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет
Подробности в статье на Хабре.
@usr_bin_linux
Автор оригинальной статьи, Пьер Мане, рассказывает, как его команда столкнулась с на первый взгляд необъяснимым поведением Cilium и как поиск решения привёл его к конфигурации ядра Linux.
Отладка сродни археологии: ты пробираешься сквозь слои абстракций, пока не доберёшься до коренной породы — ядра. Это история о том, как скрытая в коде Linux логика работы со степенями двойки приводила к случайным и загадочным падениям Cilium, из-за чего мы не могли выкатиться в production.
Подробности в статье на Хабре.
@usr_bin_linux
👍4🔥3
Forwarded from 🚀🐳 Летит Кит: SRE и не только
OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики:
- Единица измерения: Секунды (
- Атрибуты:
- RPC (включая gRPC и JSON-RPC):
- Метрики:
- Единица измерения: Миллисекунды (
- Атрибуты:
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (
- RPC:
- Начало перехода от
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики
- Единица измерения: Переход с миллисекунд (
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация:
- Атрибуты: Уточнены требования к атрибутам
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики
- Единица измерения: Строго секунды (
- gRPC/JSON-RPC:
- Значения атрибута
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например,
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию
- HTTP:
- Незначительные корректировки в семантике атрибутов
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (
- Имена метрик RPC: Переход от
- Атрибуты: Стандартизация значений для
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу 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
nfraDev Community приглашает на InfraDev Meetup #4: про AI и не только
Прямо сейчас мы наблюдаем как AI в SDLC меняет процесс разработки — об удачных примерах и кейсах поговорим в этот раз. Обсудим, как разрабатывать инфраструктурные сервисы с помощью AI и как построить MLOps-платформу для обучения моделей. И не только: пока AI не перестроил DevOps-цикл, классические вызовы сборки образов для виртуальных машин остаются актуальными.
Спикеры
▫️Кирилл Фролов, эксперт-разработчик в отделе разработки базовых сервисов, VK Cloud, VK Tech
▫️Павел Шипилов, Старший разработчик ML Платформы в Avito
▫️Александр Александров, системный архитектор в направлении разработки и управления инфраструктурой, VK Cloud, VK Tech
Подробнее о докладах читайте на странице мероприятия.
Когда: 10 июня, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
Прямо сейчас мы наблюдаем как AI в SDLC меняет процесс разработки — об удачных примерах и кейсах поговорим в этот раз. Обсудим, как разрабатывать инфраструктурные сервисы с помощью AI и как построить MLOps-платформу для обучения моделей. И не только: пока AI не перестроил DevOps-цикл, классические вызовы сборки образов для виртуальных машин остаются актуальными.
Спикеры
▫️Кирилл Фролов, эксперт-разработчик в отделе разработки базовых сервисов, VK Cloud, VK Tech
▫️Павел Шипилов, Старший разработчик ML Платформы в Avito
▫️Александр Александров, системный архитектор в направлении разработки и управления инфраструктурой, VK Cloud, VK Tech
Подробнее о докладах читайте на странице мероприятия.
Когда: 10 июня, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
👎1
Forwarded from 🚀🐳 Летит Кит: SRE и не только
OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики:
- Единица измерения: Секунды (
- Атрибуты:
- RPC (включая gRPC и JSON-RPC):
- Метрики:
- Единица измерения: Миллисекунды (
- Атрибуты:
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (
- RPC:
- Начало перехода от
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики
- Единица измерения: Переход с миллисекунд (
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация:
- Атрибуты: Уточнены требования к атрибутам
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики
- Единица измерения: Строго секунды (
- gRPC/JSON-RPC:
- Значения атрибута
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например,
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию
- HTTP:
- Незначительные корректировки в семантике атрибутов
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (
- Имена метрик RPC: Переход от
- Атрибуты: Стандартизация значений для
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу 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