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. Разбор и практические шаги.

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

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

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

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

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-провайдеров, если инстанс хоть раз торчал в интернет.

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 тысячам сайтов. Технически не лечится, только обходом.

Постоянный доступ в Kubernetes: как атакующие закрепляются в кластере и остаются незамеченными

Вы думаете, что если злоумышленник получил доступ к ноутбуку администратора на пять минут — это не страшно? А зря.

Чтобы изменить мнение, советуем почитать перевод статьи Рори Маккьюна «Beyond the Surface» — детальный разбор одного реального вектора атаки на Kubernetes. Автор показывает, как с помощью встроенных механизмов (kubectl debug, containerd, статические манифесты, CSR API, Token Request API) можно:
— получить root-доступ к узлу;
— запустить скрытый контейнер в обход API;
— организовать удалённое управление через Tailscale;
— создать вечные учётные данные, которые невозможно отозвать без ротации корневого сертификата.

В статье — не только техники атак, но и чёткие признаки обнаружения, а главное — меры защиты: изоляция API-сервера от интернета, минимальные привилегии RBAC, централизованные логи узлов.

Полный текст: https://tprg.ru/gfJ6

Как сделать развертывание в Kubernetes умным

Helm, Kustomize, Argo CD работают, пока ваше приложение простой stateless-сервис. А если нужен строгий порядок запуска, готовая база данных, последовательный пайплайн?

Тут либо приходится писать своего оператора (дорого, сложно, долго), либо надеяться на итоговую согласованность и молиться.

Есть и третий путь. Yoke + Air Traffic Controller (ATC) предлагают логику приложения как код, скомпилированный в WASM.

Вот что вы узнаете из перевода статьи Дэвида Демаре-Мишо:
— как построить пайплайн из трёх задач, где каждая следующая стартует только после успешного завершения предыдущей.
— как организовать координацию с внешними ресурсами.

Если вы еще не знакомы с Yoke и Air Traffic Controller самое время познакомиться.

Kubernetes: от kubectl до полного стека из 10+ инструментов

K9s → Argo CD → KEDA → Karpenter → Network Policies → Istio → Secrets Store CSI → Kyverno → Prometheus → Jaeger...

Почему каждый из них появился и какую проблему решает: https://tprg.ru/XcMT

AI-генерированный код проходит CI и роняет прод под нагрузкой

AI-агент написал модуль скоринга транзакций за 15 минут: 400 строк, тесты зелёные, ревью прошло. Через три месяца аудит нашёл race condition при параллельной обработке транзакций одного клиента — вторая транзакция не видела результат первой, оборот занижался, подозрительные паттерны не детектировались.

Корень проблемы: разработчик не разобрался в модели параллелизма, ревью провёл другой агент с теми же слепыми зонами. CI проверил синтаксис и покрытие unit-тестами — но race condition под нагрузкой ловится только concurrent-сценарием или инженером, который понимает модель.

Для SRE это означает конкретное требование к пайплайну: AI-генерированный код в нагруженных сервисах нуждается в ручном ревью модели параллелизма и нагрузочных тестах до деплоя в prod. Разбор на Tproger — про то, как выстраивать контроль.

317 npm-пакетов скомпрометированы через взломанный аккаунт atool

19 мая за 22 минуты опубликовано 637 вредоносных версий 317 пакетов с десятками млн загрузок/мес. Под ударом echarts-for-react, size-sensor, 250+ пакетов @antv.

Полезная нагрузка Mini Shai-Hulud: кража AWS-ключей, GitHub PAT, npm-токенов, SSH-ключей, секретов 1Password/Bitwarden, токенов Kubernetes/Vault. Эксфильтрация через зашифрованные Git-объекты и HTTPS под видом OpenTelemetry-трейсов.

Тег latest не переставлен, но npm берёт наибольший semver — зависимость ^3.0.6 подтянет вредоносную 3.2.7. Запуск через preinstall.

Что делать: проверить lock-файлы, заблокировать диапазоны версий затронутых пакетов, аудировать секреты в CI.

AIOps в мониторинге: почему ML чаще галлюцинирует, чем помогает

Вендоры продают AIOps как «подключи телеметрию — ИИ сам найдёт причину инцидента». На деле под капотом обычно движок правил в обёртке, а LLM сверху собирает правдоподобный, но не всегда верный RCA: финальный вывод о причине сбоя всё равно приходится сверять с трассировками, метриками и событиями деплоя.

Разбор Centicore Group на Tproger: как реально устроен ML в мониторинге (сбор, нормализация, группировка, корреляция), три причины деградации в проде (нет истории по новому типу сбоя, дрейф данных, выдумки LLM), где он всё-таки полезен (шумоподавление и ускорение triage) и чек-лист вопросов вендору про cold start и переобучение.

https://tproger.ru/articles/aiops-eto-novaya-chernaya-magiya-pochemu-ml-v-monitoringe-chashhe-gal

CodeQL быстрее сканирует Go и C/C++ в pull request'ах

GitHub включил инкрементальный анализ для CodeQL по Go и C/C++. Вместо полного прохода по репозиторию скан смотрит на изменения и переиспользует предыдущий результат. Для больших монореп это как раз та разница, из-за которой security job перестаёт быть самым долгим этапом CI.

На github.com фича включена по умолчанию для проектов с build mode none в default setup и advanced setup. Для сторонних CI нужен CodeQL CLI 2.25.5 или новее.

Если CodeQL у вас давно «временно» вынесен из обязательных checks из-за скорости, есть повод вернуть его в pipeline и сравнить время прогона.

Golden images теперь можно держать на поводке в HCP Packer

Если образы собирают разные команды, security baseline быстро начинает жить на честном слове: где-то забыли агент мониторинга, где-то не включили hardening, где-то compliance-шаг остался в локальном пайплайне.

HashiCorp добавила enforced provisioners в HCP Packer. Platform-команда задаёт обязательные provisioning-шаги централизованно, а отдельные сборки уже не могут их отключить. Это касается AMI, VM, Docker-образов и других golden images.

Практический смысл простой: если у вас Packer разъехался по командам, стоит вынести обязательные security/compliance шаги из локальных шаблонов в enforced policy.

Контейнерный supply chain стоит проверять не только на этапе registry

Docker собрал чеклист по безопасности цепочки поставки для контейнеров. Там не про один волшебный сканер, а про всю дорогу образа: base image, зависимости, secrets в CI, SBOM, provenance, подписи и runtime monitoring.

Хороший минимум для своей платформы: закрепить digest вместо плавающих тегов, генерировать SBOM на сборке, ограничить scope секретов в pipeline, проверять provenance перед deploy и не считать successful build доказательством безопасности.

Материал удобно открыть рядом с CI/CD и registry-настройками. Не как теорию, а как список мест, где обычно тихо накапливается риск.

Сервис должен уметь сказать, какая версия сейчас запущена

Michael Stapelberg в заметке формулирует простое правило: все программы должны репортить свою версию. Не «мы вроде деплоили коммит утром», а конкретный build id, commit, timestamp или package version, которые можно получить из бинаря или runtime.

Для incident response это не косметика. Когда алерт горит, команда должна быстро понять, какие инстансы уже на новом билде, где остался старый артефакт и какой образ реально крутится в pod'е или systemd unit.

Практический шаг: проверьте свои CLI, сервисы и health/debug endpoints. Если версия не достаётся одной командой, расследование уже начинается с лишней неопределённости.

В большинстве компаний 1С и облачная инфраструктура живут в параллельных мирах: DevOps смотрит в Grafana, финдиректор — в 1С, а когда падает оплата, все смотрят друг на друга. На самом деле подружить 1С с современными инструментами мониторинга вполне реально всего за один спринт. В блоге Centicore рассказали, как это сделать.

В статье разбирается, как вытащить метрики из 1С через OData без единой строчки кода, написать Prometheus Exporter на Python и собрать бизнес- и технические метрики на одном дашборде. А заодно — где интеграция обычно ломается и как это пережить.

GKE standby buffers: запас capacity без постоянного overprovisioning

Google Cloud показал standby buffers для GKE. Идея в том, чтобы держать подготовленные, но suspended-ноды: они уже прошли init, DaemonSet'ы и preload, но не жгут полный compute как обычный запас.

Для кластеров со всплесками это замена balloon pods и ручному overprovisioning. Standby-ноды возобновляются в 2-3 раза быстрее, чем создаётся свежая нода, а buffer описывается через CapacityBuffer. В статье есть YAML-пример и проверка через kubectl get nodes с condition Suspended.

Если у вас latency SLO страдает именно на scale-up, это стоит тестировать на отдельном node pool.

Нагрузочный тест лучше собирать не из фантазии, а из telemetry

Grafana показывает подход, где сценарий для k6 строится из production telemetry. Вместо «давайте поставим 100 virtual users» берутся реальные RPS, p95/p99, распределение endpoint'ов и форма трафика из Grafana Cloud.

Это полезно для SRE-команд, которые уже хранят метрики в Prometheus/Mimir, но нагрузочные тесты всё ещё пишут вручную. Такой тест ближе к боевому профилю: он проверяет не абстрактную пропускную способность, а конкретные пики и маршруты, которые уже видны в проде.

Хороший кандидат для следующего performance review: взять неделю нормального трафика и превратить её в k6-сценарий.

Self-hosting дома, где ломается всё самое сетевое

В авторском разборе блог хостится дома, но с обычными бытовыми ограничениями: динамический IPv4, меняющийся IPv6 prefix, OpenWRT, DNS-обновления и WireGuard как связка для доступа извне.

Материал полезен не как рецепт «делайте прод дома», а как компактная лаборатория по сети. Тут сразу видно, где заканчивается красивый self-hosting и начинается реальность провайдера: prefix delegation, firewall rules, DDNS, туннели и восстановление после смены адресов.

Хорошее чтение для тех, кто хочет руками потрогать networking без облачного abstraction layer. После такого проще понимать, что именно скрывают managed load balancer и static IP.

Linux page cache для тех, кто смотрит на память в проде

У Viacheslav Biriukov есть большой разбор page cache для SRE. Это материал про ту самую память, которая в top выглядит занятой, но не всегда означает утечку в приложении.

Внутри: как Linux кэширует страницы файлов, что меняется с cgroup v2, как читать smaps, где помогают mincore, mmap, fsync, vmtouch, perf и strace. Практический фокус хороший: не «ядро сложное», а как не ошибиться при разборе memory pressure.

Если у вас были алерты вида «RAM почти кончилась», а потом всё само проходило, этот текст стоит сохранить в runbook по Linux diagnostics.

CoreDNS в Kubernetes можно патчить Terraform'ом, не через kubectl edit

Jérôme Petazzoni разбирает практичную боль: кластер сам создал CoreDNS ConfigMap, но править Corefile руками не хочется, потому что потом это невозможно нормально повторить и проверить в IaC.

Решение строится вокруг Terraform/OpenTofu: прочитать существующий ConfigMap, применить patch к нужному фрагменту и оставить изменение в коде, а не в истории команд администратора. Это особенно полезно, если нужно добавить upstream, rewrite, cache-настройки или внутренние DNS-правила.

Материал стоит открыть тем, у кого в кластере ещё есть «один раз поправили руками». CoreDNS обычно как раз из таких мест, где ручная правка потом всплывает в самый неудобный момент.

SELECT в Postgres тоже может выглядеть как запись

Dan Slimmon разбирает странный инцидент: в Postgres появлялись пики WALWrite, хотя нагрузка была read-only. Виновником оказался не внезапный write-запрос, а hint bits и full page writes.

Для SRE это хороший пример, почему «чтения не пишут» в базах не всегда безопасное упрощение. Первый SELECT после изменений может пометить tuple metadata, а если страница ещё не была записана после checkpoint, Postgres отправит full page image в WAL.

Практический вывод: когда видите write spikes на read-heavy workload, не останавливайтесь на поиске INSERT/UPDATE. Смотрите checkpoints, hint bits, buffer dirties и то, что реально происходит на уровне storage.