DevOps для ДевоПсов

Docker Hub и GitHub Actions ломаются в Испании по выходным

Если инфра или часть команды в Испании — по субботам и воскресеньям до 24 мая 2026 ждите таймаутов на docker pull, падений CI и 5xx с Vercel. La Liga с декабря 2024-го по судебному приказу шлёт ISP списки IP на немедленную блокировку. Цель — пиратские стримы, но сидят они за Cloudflare, а один anycast-IP держит тысячи клиентов. Отваливается всё.

Cloudflare апелляцию проиграл, парламент вмешиваться отказался. Ещё около шести недель лотереи.

Что делать:

— pull-through mirror Docker Hub на сервере вне Испании;
— GitHub Actions runners в AWS/GCP/Yandex Cloud за пределами страны;
— VPN с выходом в Нидерландах;
— fallback на CloudFront на время матчей.

Корень — IP-блокировки в мире, где CDN раздают один IP тысячам сайтов. Технически не лечится, только обходом.

Marimo CVE-2026-39987 (CVSS 9.3): WebSocket без auth-чека, в Docker — сразу root

Если в инфраструктуре крутится Marimo — проверьте версию прямо сейчас. Эндпоинт /terminal/ws не вызывал validate_auth(), WebSocket-handshake отдаёт PTY. В официальном Docker-образе процесс работает от root, эксплуатация тривиальна.

Sysdig поймал первую атаку через 9 часов 41 минуту после advisory, без публичного PoC. До этого так же ловили Langflow (20 часов) и Flowise. Окно на патч — часы, не дни.

Что сделать:

— обновить до 0.23.0 (всё ниже 0.20.4 уязвимо);
— не выставлять наружу: --host 127.0.0.1, за reverse proxy с auth;
— сканировать ML-инфру на предмет «внутренних» дашбордов на 0.0.0.0;
— ротировать ключи облаков и LLM-провайдеров, если инстанс хоть раз торчал в интернет.

Мэн заморозил новые ЦОДы мощнее 20 МВт — закладывайте в GPU-бюджет

LD 307 запрещает штату и муниципалитетам выдавать разрешения на любые дата-центры с подключённой мощностью выше 20 МВт. Порог подобран прицельно: корпоративные и колокейшен-объекты проходят, а гиперскейлерные ИИ-кластеры (тысячи GPU легко уходят за 50–100 МВт) — нет. Мораторий действует до 1 ноября 2027 года.

По данным Data Center Watch, за два года по США заблокировано проектов примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане, на подходе Денвер и Детройт.

Что делать сейчас: следить за Вирджинией и Техасом как ранним индикатором (там основная масса ЦОДов), закладывать диапазон неопределённости в годовые GPU-бюджеты, мониторить spot-цены на H100/B200 у Yandex Cloud, VK Cloud и Cloud.ru — там эффект глобального дефицита виден первым.

Linux 7.0 берёт в mainline первый RVA23-чип — пора целить toolchain в новый профиль

SpacemiT K3, первый коммерческий SoC на RVA23, входит в mainline Linux 7.0 (релиз 12 апреля). В 7.1 добавят драйверы периферии и оптимизации под вектор. Ubuntu 26.04 LTS — одна из первых платформ с K3 из коробки.

Суть не в чипе, а в профиле: RVA23 фиксирует обязательный набор расширений — Vector 1.0, битовые манипуляции, крипто, для серверного RVA23S64 ещё и гипервизор. Один RISC-V бинарь теперь работает на любом сертифицированном железе, без угадывания feature-флагов.

Что делать: пересобрать toolchain под RVA23-таргет, прогнать CI через QEMU с -cpu max, для пилота взять Banana Pi BPI-F3 на K1. Production пока рано — серийных K3-плат нет, CI-раннеры на RISC-V в пять раз медленнее x86. Разбор и практические шаги.

Chrome 146 включил DBSC — пора добавить два эндпоинта, если не хотите, чтобы угнанные сессии жили вечно

DBSC (Device Bound Session Credentials) привязывает сессионные cookies к TPM-чипу клиента. Chrome генерирует пару ключей через TPM при логине, публичный отдаёт серверу, приватный остаётся в чипе. На каждом refresh сервер шлёт challenge — клиент подписывает его через TPM. Без оригинального железа подпись не сделать.

Что это значит на практике: если инфостилер (Lumma, Vidar, StealC) слил cookies и залил на свой хост, сессия умрёт на первом refresh. Никаких изменений на фронте — только два новых бэкенд-эндпоинта: регистрация устройства и refresh с верификацией подписи.

Спецификация открытая, W3C, пилили Google с Microsoft. macOS через Secure Enclave — в следующих релизах, Linux пока в пролёте, Firefox и Safari молчат.

Как внедрять на бэкенде — разбор на Tproger.

Flatpak: критическая уязвимость — побег из песочницы. Обновитесь.

CVE-2026-34078, рейтинг Critical. Любое Flatpak-приложение может полностью выйти из изоляции: читать и писать файлы хоста, выполнять произвольный код.

Фикс: flatpak 1.16.4. Большинство дистрибутивов уже доставляют патч через стандартные обновления — проверьте, что версия актуальна.

Если у вас в инфре крутятся Flatpak-приложения или вы используете их в CI — обновите пакет и убедитесь, что sandbox-политики не опираются на старое поведение.

Little Snitch вышел на Linux — мониторинг исходящих соединений на eBPF, бесплатно

Инструмент, который 20 лет был только на macOS, теперь работает на Linux. Показывает сетевую активность каждого процесса в реальном времени — без iptables-правил и без tcpdump | grep.

Работает на eBPF, веб-интерфейс на localhost:3031. Поддерживает блоклисты Hagezi и Steven Black. Полезно после деплоя нового образа, при отладке агента или при расследовании аномальной активности.

Лицензия: eBPF-модуль и веб-интерфейс — GPLv2, демон проприетарный, но бесплатный. Авторы честно предупреждают: это инструмент для приватности, не замена WAF.

Подробнее на Tproger

Microsoft заблокировала разработчиков WireGuard и VeraCrypt — без предупреждения

Microsoft отозвала доступ к Windows Hardware Program у мейнтейнеров WireGuard, VeraCrypt, MemTest86 и Windscribe. Причина — непройденная верификация, о которой никто не уведомил.

Без подписи Microsoft выпустить обновление драйвера для Windows невозможно. Если завтра в WireGuard найдут критическую RCE — патч до пользователей не дойдёт.

Мейнтейнер WireGuard так и написал: «А если бы нашли критическую уязвимость?» Разблокировка началась только после публичного шума — VP Scott Hanselman написал лично.

Supply chain риск: один сбой у вендора — и open source инструменты в вашем стеке не получают security-обновления.

Улучшаем Dockerfile: от примитивной базы к multi-stage-решению

Dockerfile можно составить по-разному, и даже самые примитивные его варианты могут работать, но это не значит, что их стоит использовать. Поэтому давайте разбираться, как сделать из Dockerfile конфетку. Для этого читайте статью. Там Dockerfile становится всё круче с каждым шагом:

🔘 Начинается с наивного подхода — всё работает, но образ тяжеленный, сборка занимает 10 минут, а результат непредсказуем.
🔘 Multi-stage — разделяем сборку и рантайм, финальный образ содержит только бинарник и необходимые runtime-зависимости.

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

Health Score для PostgreSQL: один показатель вместо 150 метрик

В традиционном мониторинге PostgreSQL сотни метрик, но нет ответа на вопрос «база здорова?». CPU 60%, connections 50%, idle in transaction 40% — ни один порог не пробит, но база тормозит. Health Score агрегирует пять категорий (Connections, Performance, Storage, Replication, Maintenance) в число от 0 до 100 с нелинейными штрафами за опасные комбинации и автодиагностикой: список проблем и готовые рекомендации.

Для дежурного инженера это первый экран вместо десятков дашбордов. Система учитывает исторический baseline, поэтому аномалия определяется не по жёсткому порогу, а по отклонению от обычного поведения. Подробнее о формуле и внедрении — в статье: https://habr.com/ru/articles/1016288/

База

jsongrep — быстрее чем jq, jmespath, jsonpath-rust и jql?

Студент вдохновился историей рипгрепа и сделал инструмент для поиска значений в JSON-документах. Концептуально он делает то же, что и grep для текста: скармливаете JSON, даёте паттерн, получаете все значения, пути к которым попадают под этот паттерн («достань мне все поля error из логов за сегодня»).

Язык запросов выглядит как смесь JSONPath и регулярных выражений. Если вы когда-нибудь писали регулярки для путей в файловой системе или URL, то тут всё очень похоже, только вместо символов у вас ключи и индексы.

Зачем это нужно

Если вы работаете с большими JSON-файлами, то рано или поздно сталкиваетесь с задачей «достань мне все значения по такому-то пути». jq для этого подходит, но он тяжеловесный: это полноценный язык трансформации, интерпретатор, который на каждом шаге оценивает выражения, проверяет условия, рекурсивно обходит дерево. Для простого поиска это оверкилл.

jsongrep сознательно ограничен: он не умеет трансформировать данные, нет арифметики, нет фильтров, нет строковой интерполяции. Зато за счёт этого он работает на порядок быстрее на больших документах, что подтверждают бенчмарки автора: на 190-мегабайтном GeoJSON файле он обходит jq в end-to-end тестах с внушительным отрывом.

Кейсы применения

— Анализ логов в JSON-формате. jsongrep с флагом -F делает рекурсивный поиск поля на любой глубине одной командой.

— Работа с API-ответами. curl + jsongrep быстрее, чем открывать Postman или писать jq-ванлайнер для простой выборки.

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

Почему так быстро

Автор учил теорию автоматов, технические детали можно почитать в статье. Если упростить, нет никаких if-else цепочек, нет рекурсивного спуска с проверкой условий на каждом узле. Неподходящая ветка дерева отсекается за O(1) — просто нет перехода в таблице.

Есть и цена за эту скорость: компиляция запроса в DFA занимает время. На маленьких документах jq может оказаться быстрее просто потому, что не тратит время на построение автомата. Но на документах от мегабайта и выше jsongrep начинает выигрывать.

Инструмент новый, студенческий, в бою ещё не протестирован, но как минимум ставим лайк за научный подход.

https://github.com/micahkepe/jsongrep

Channel photo updated

Подъехал обзор по Trivy с инструкциями

https://tproger.ru/articles/ataki-na-trivy--kak-skaner-uyazvimostej-stal-vektorom-ataki-i-chto

Псам предлагаю проверить, всё ли вы учли и обновили
А пёсикам разобраться, что вообще происходит 🥺

Линуксоид с гигантским стажем решил волевым усилием поломать свои привычки и заменить coreutils на фэнси тулзы. В комментарии набежали холиварить про надёжность vs эргономичность, но сначала вот пять замен, которые коллективно сочли достойными:

cat → bat ибо встроенная подсветка синтаксиса, нумерация строк и адекватный пейджинг;
ls → eza, потому что позволь себе уже полюбить цветовое кодирование и иконки;
find → fd за интуитивный синтаксис и быструю выдачу;
grep → ripgrep опять же из-за скорости;
top → btop для комплексного мониторинга ресурсов, хоть btop и перегружен визуально.

Дальше на ночь пятничная сказка про холивар.

Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими, а ресурсов не хватало ни на что лишнее. Синтаксис классического find до сих пор вызывает нервный тик, а чтение логов через cat без подсветки пора признать формой легкого мазохизма. Современный подход предлагает инструменты, которые написаны преимущественно на Rust и делают ровно то же самое, но с человеческим лицом. А ещё они работают быстрее и прямо из коробки понимают правила .gitignore.

В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?

Пожалуй, единственное здравое правило, которое можно вынести из этого противостояния: как только дело доходит до автоматизации и bash-скриптов, надо возвращаться к POSIX-совместимым конструкциям и классическим coreutils, иначе автоматизация сломается на первой же машине.

Вообще этот нудный пост о старой статье был ради подводки к ещё более старому мему

Тут снова всплыла та самая статья про исход из облаков от создателя Ruby on Rails. Если не читали, основная мысль сводится к тому, что для компаний среднего размера со стабильным ростом аренда чужих серверов обходится неоправданно дорого.

По логике Дэвида облако незаменимо только в двух случаях:

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

В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.

Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.

Оказывается, людей всё ещё просят инвертировать бинарные деревья на доске при найме на позиции DevOps или Platform Engineer. Видимо, мы в 2026 должны уметь поисковики с нуля писать. Хотя куда показательнее попросить написать скрипт для парсинга логов или сортировки тысяч файлов в S3 по бакетам.

Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:

— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов

И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.

Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта.

Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.

Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.

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

Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.

Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.

Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/

Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198

Как ML помогает тестировать то, что нельзя предсказать вручную?

В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.

В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.

Как он там оказался, читайте в статье.