Пятничный деплой

Стрим о защите контейнеров, который нельзя пропустить Без лишних слов: 1. Обзор актуальных угроз для контейнерных сред 2. Kaspersky Container Security на практике — демонстрация новых фич в бою 3. ИИ функциональность для поиска неочевидных рисков в образах 4. Многое другое про защиту контейнеров от разработки до рантайма Настоящее и будущее контейнерных сред обсудят эксперты «Лаборатории Касперского» и платформы «Штурвал» 28 мая в 11:00. Смотреть и регистрироваться.

SELinux — Быстрый онбординг: типы, атрибуты, домены, политики и утилиты на практике

В статье пойдет речь о SELinux. Главная моя задача — провести быстрый онбординг о том, как работать с политиками доступов. Я хочу показать, что это вовсе не так сложно, как может показаться на первый взгляд. Буквально 15 минут ознакомления с базовыми понятиями дает 80% понимания как работать с SELinux более уверенно. Статья не совсем про написание политик, скорее про их понимание. Все описанное необходимо, чтобы уверенно пользоваться утилитами, более осмысленно работать с системой, решать проблемы и задачи, с которыми придется столкнуться в процессе эксплуатации SELinux.

Читать дальше на Хабре. @usr_bin_linux

Дочитал «Настоящий SRE» Дэвида Бланк-Эдельмана. Это третий пост из серии, я Алексей Крылов, менеджер продукта. Итоговые впечатления. Главная фишка книги — иерархия надёжности Дикерсона. Пирамида, построенная по той же логике, что и пирамида Маслоу. В основании лежат мониторинг и наблюдаемость. Дальше идут реагирование на инциденты, разбор последствий без поиска виноватых, тестирование и релизы, планирование ресурсов, разработка. На самом верху — проектирование продукта с учётом надёжности с самого начала. Нельзя перейти на следующий уровень, не отстроив предыдущий. Для тех, кто только начинает, это честная дорожная карта. Важный нюанс в том, что движение по этой пирамиде нелинейное. Команда может быть на высоком уровне зрелости и внезапно вернуться в режим «пожарных» из-за крупного инцидента. Это нормально, и книга честно об этом предупреждает. Книга отвечает на вопрос «с чего начать», а не просто описывает, как всё устроено в Google. Структура позволяет читать нелинейно: первая часть про менталитет обязательна, а дальше можно выбирать — вторая часть про личный карьерный путь, третья про внедрение в организацию. Автор так и говорит, выберите своё приключение. Он собрал опыт множества практиков, добавил реальные истории, здоровый юмор и неожиданно много внимания уделил человеческому фактору: этике, эмпатии, выгоранию. Для технической книги редкость. Из слабых мест: иерархия Дикерсона при всей полезности неполна, и сам автор это признаёт. В ней нет места для роли SRE-инженера в проектировании архитектуры на ранних стадиях и нет борьбы с рутиной как отдельного уровня. Местами книга перегружена сносками, а центральная метафора с дайвингом к концу, по словам самого автора, становится «всё более громоздкой». Но есть кое-что интереснее формальных недостатков книги. Ловушка самого подхода. Если система работает слишком хорошо и никогда не падает, все вокруг расслабляются и перестают готовиться к сбоям. Когда инцидент всё же случается — последствия непропорционально тяжёлые, потому что никто не ждал. Книга об этом честно предупреждает. Кому рекомендую: инженерам, которые хотят взглянуть на свою работу с точки зрения влияния на компанию. Тем, кто чувствует, что просто тушит пожары, но хочет понять, как выстроить систему, в которой пожаров становится меньше. P.S. Редакция канала благодарит издательство Питер за предоставленную физическую версию книги :)

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 г "Иронии автоматизации", проблемы те же

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

PII-Shield — open-source инструмент для защиты логов и данных от утечки персональной информации прямо в Kubernetes . Он работает как sidecar контейнер, перехватывает stdout/stderr, находит секреты и чувствительные данные до того, как они попадут в лог-системы. Сочетание Shannon Entropy для поиска неизвестных секретов (токены, API-ключи, пароли) и O(1) regex для точного детектирования известных паттернов снижает false positive и позволяет находить даже то, что не было заранее описано правилами. PII-Shield работает полностью локально, без API вызовов наружу, с почти нулевой нагрузкой на GC. Интересный проект, чтобы попробовать безопасно коррелировать логи между сервисами, не раскрывая реальные данные.

А Вы знали, что кроме постгресса есть другие базы данных? Быстрые, легко масштабируемые, с богатой экосистемой, поддерживаемые разными компаниями. Один из таких примеров - 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

👩‍💻 Зачем Shopify отказались от Redis в пользу MySQL Бодрый DevOps! Ранее мы разобрались в архитектуре модульного монолита, сегодня рассмотрим, как и зачем крупнейший сервис Shopify перешел на MySQL на этапе оформления заказов. Нагрузки на Shopify всегда были высоки, особенно в Черную Пятницу. Прежде для резервирования и оформления товаров компания использовала Redis, но система сталкивалась с ограничениями консистентности между двумя БД. Тогда, инженеры Shopify решили перенести механизм резервирования целиком в MySQL. В кейсе представили, как команда использовала: ⏺ SKIP LOCKED для совмещенных строк и ACID для обнаружения багов ⏺ составные первичные ключи для уменьшения числа блокировок ⏺ READ COMMITTED для борьбы с блокировкой промежутков ⏺ UNION ALL для сокращения времени обращений ⏺ а также собственную систему наблюдаемости для анализа соединений Из интересного описали проблемы с пуллом соединений под нагрузкой в MySQL. Здесь можно узнать всё о переходе. 💻Что используете для высоконагруженных систем – Redis или MySQL? #девопс #БД #MySQL #Redis

Lies, damned lies, and Elastic's benchmarks https://www.gouthamve.dev/lies-damned-lies-and-elastics-benchmarks #elasticsearch #clickhouse #prometheus #benchmarks #mimir

boring Простой менеджер SSH-туннелей. Управляется из командной строки. Репыч на Гитхаб @usr_bin_linux

SLO как чертёж архитектуры Как SLO становится чертежом архитектуры: один поиск маркетплейса на трёх уровнях SLO порождает три разные системы и error budget как валюту в спорах. https://jtprog.ru/slo-as-architecture-blueprint/ Идея этого материала должна была превратиться в мое выступление для @system_design_world (Вова, привет), так исторически сложилось, что я не смог. А материал уж очень вкусный получился, так что запасайся напитками и иди читать лонгридище! #SRE #SLO #SLI #SystemDesign #ErrorBudget #Архитектура

☁️ ITENTIS CLOUD: как на инфраструктуре начинают зарабатывать Реальные цифры: системный администратор перешел на Itentis Cloud по реферальной программе, изначально — просто попробовать: перевести несколько клиентов, посмотреть, как работает облако. Сейчас он зарабатывает 70–100 тыс. руб. в месяц на партнерской комиссии. И растет дальше — с каждым новым клиентом. 📣 Вы можете так же: подключаете клиентов к ITENTIS CLOUD — получаете процент с их инфраструктуры. ITENTIS CLOUD — это тот же уровень технологий (VPC, Kubernetes, S3, Tier III), но без переплаты за бренд и с прозрачными тарифами. Плюс — живая поддержка 24/7, которая реально помогает довести проекты до результата. 💥 Попробуйте сами: перенесите часть проектов — первые 14 дней бесплатно. Переходите на страницу ITENTIS CLOUD, чтобы посмотреть условия и начать зарабатывать. Партнерская программа ITENTIS CLOUD

👉 Linux - strace: один из самых недооценённых инструментов Он нужен в тот момент, когда приложение падает, не видит конфиг, не может найти библиотеку или ругается на файл, которого “вроде бы нет”. Обычно в такой ситуации начинают гадать: путь не тот, прав не хватает, переменная окружения сломалась, сервис запущен не от того пользователя. Но strace позволяет не гадать. Он показывает, к каким файлам процесс реально обращается во время работы. Не то, что написано в документации. Не то, что вы предполагаете. А то, что программа делает на самом деле. И вот тут часто всё становится очевидно: приложение ищет config не в той директории, лезет за библиотекой по старому пути, не может открыть сертификат или получает отказ из-за прав доступа. Это особенно полезно при отладке сервисов, Docker-контейнеров, странных production-багов и бинарников, у которых нет нормальных логов. Главная идея простая: когда Linux-программа ведёт себя непонятно, сначала посмотри её системные вызовы. https://www.youtube.com/shorts/iRnNQWKozSA

Isopolicy — CLI инструмент от разработчиков Cilium для упрощения управления, проверки и тестирования Network Policy от Cilium в Kubernetes. Основные функции: - Статический анализ и проверка синтаксиса: Выполняет статический анализ политик для выявления распространенных ошибок конфигурации, таких как отсутствующие labels или непреднамеренные наложения. - Моделирование политик: Включает команду моделирования, которая создает среду «что если». Это позволяет операторам предварительно оценить, как новые, измененные или удаленные политики повлияют на доступ к сети для разных идентификаторов или namespaces, не затрагивая работающий кластер. - Историческая проверка: При подключении к Hubble Timescape может воспроизводить исторические потоки трафика, чтобы показать, как различные политики обрабатывали бы прошлый трафик, повышая общую «чистоту политик». - Интеграция с GitOps: Может быть интегрирован в конвейеры CI/CD для автоматической проверки синтаксиса политик во время PR, блокируя мерджи, содержащие неподдерживаемые конструкции или очевидные ошибки. Примеры использование можно посмотреть тут и тут.

Fail2Ban больше не нужен? Разбираем PerSourcePenalties в OpenSSH на Ubuntu 26.04 Начиная с OpenSSH 9.7, sshd умеет автоматически ограничивать на время подозрительные IP без Fail2Ban и iptables. В Ubuntu 26.04 эта функция уже включена по умолчанию — даже если в sshd_config про неё ничего не написано. Автор этой статьи предлагает разобраться с тем, как это работает. @usr_bin_linux

otel-cardinality-processor

An OpenTelemetry Collector processor that catches metric cardinality explosions before they reach your TSDB.

https://github.com/YElayyat/otel-cardinality-processor

Grafana 13 release А вот и он. Что нового: 🚀 встроенные pre-built дашборды. На основе выбранного датасорса, графана предложит подходящие дашборды. 🚀 выдача предложений по выбору панелей дашбордов 🚀 улучшен дизайн поля для ввода запроса для визулизации в панели 🚀 появилась возможность переиспользования запросов при помощи функционала Saved queries 🚀 появилась возможность копирования стиля панели 🚀 Git Sync теперь доступен для всех редакций Grafana (импорт дашбордов и других объектов напрямую из репо) Подробнее в блоге Grafana 📱 Telegram | 📲 MAX

Ubuntu 26.04 LTS: на что смотреть перед миграцией с 24.04

23 апреля Canonical выпустил Ubuntu 26.04 LTS — Resolute Raccoon. Про сам релиз уже написали все, поэтому не будем повторяться — и посмотрим на релиз с другой стороны. 26.04 — это не косметическое обновление. cgroup v1 удален, DSA-ключи в OpenSSH больше не работают, apt-key окончательно убран, классический sudo заменен на Rust-реализацию, формат конфигов Dovecot изменился, Postfix больше не работает в chroot по умолчанию. Запустить do-release-upgrade и уйти на обед уже не получится: часть систем после такого обновления просто не поднимется.

В статье небольшой список того, на что обратить внимание при миграции, и краткий обзор изменений, которые на эту миграцию влияют. @usr_bin_linux

KubeUser — это Kubernetes оператор для управления пользователями, доступами и kubeconfig без Keycloak, Dex и других тяжёлых IAM решений. Вместо ручной выдачи сертификатов и RBAC всё описывается декларативно через User CRD, а оператор сам создаёт доступы и готовый kubeconfig. Проект может быть полезен для небольших DevOps команд, где полноценный IdP — это избыточно, а ручное управление доступами быстро превращается в хаос. KubeUser использует стандартный Kubernetes CSR API, автоматически создаёт RoleBinding и ClusterRoleBinding, а kubeconfig сохраняет как Secret внутри кластера.