Veille Technologique

2026-05-28

27 feeds · 75 articles traités · 20 sélectionnés · gemma4:e2b · 2026-05-28T09:10:56.400Z

Divers

The End of Alert Fatigue: How AI-Powered Observability is Transforming SRE Teams in 2026

DevOps.com (Tier 1) · Publié : 2026-05-28 · 51.8/10

Alert fatigue among Site Reliability Engineering (SRE) teams has reached a breaking point, with responders drowning in thousands of weekly notifications where only 3% genuinely warrant attention. This massive volume of noise—driven by fragmented monitoring tools and rigid, threshold-based alerting—stifles innovation, spikes on-call burnout, and compromises system reliability. Fortunately, AI-powered observability and AIOps platforms are transforming incident management. By unifying telemetry acr

Docker Hardened Images Are Free Now — Here's What You Still Need to Build

DZone DevOps (Tier 1) · Publié : 2026-05-27 · 48.8/10

The Problem Isn't the Image Hardened container images are no longer niche. Docker open-sourced major portions of the tooling behind Docker Hardened Images under Apache 2.0 in late 2025. Chainguard and Google's distroless variants sit in the same space. The pitch across all three: fewer packages, smaller attack surface, dramatically lower CVE counts. The pitch is accurate. It is also incomplete. Most container security failures are not image failures. They are governance failures:

5 Ways Agentic AI is Redefining DevOps Architecture for Self-Healing CI/CD Systems

DevOps.com (Tier 1) · Publié : 2026-05-28 · 47.6/10

The era of the flaky test as a simple annoyance is over. As enterprises shift from deterministic applications to agentic AI, flakiness has evolved into a structural bottleneck for traditional CI/CD pipelines reliant on rigid, binary assertions. Because AI agents produce "Y-like" rather than exact results, DevOps architecture must fundamentally change. This article explores the transition from simple pipeline automation to true autonomy—detailing how multi-agent networks utilize predictive failur

Connect docker swarm cluster with k8s

r/devops (Tier 1) · Publié : 2026-05-27 · 47.6/10

Is it possible in some way to connect a docker swarm cluster via vpn, for example wireguard or OpenVPN, to a kubernetes cluster, so the docker swarm container can reach kubernetes services? Don't ask why, because of legacy systems. submitted by /u/Long-Ad226 [link] [comments]

must attend for devops engineers — full day claude code bootcamp may 30

r/devops (Tier 1) · Publié : 2026-05-28 · 44.6/10

hey everyone if you're a devops engineer who hasn't gone deep on claude code yet, this is worth your time. final 2 days before we go live packt publishing is running a full day hands on claude code bootcamp on may 30 with luca berton — anthropic certified claude code instructor, former red hat engineer, creator of the ansible pilot project and speaker at kubecon 2026 and red hat summit 2026. 10 real projects built live on the day. no slides. no theory. every session ends with a shipped p

DevOps and Platform Engineering Readiness Checklist: Everything Needed for a Scalable, Secure, High-Velocity Delivery Platform

DZone DevOps (Tier 1) · Publié : 2026-05-27 · 44.6/10

Editor’s Note: The following is an article written for and published in DZone’s 2026 Trend Report,  Platform Engineering and DevOps: How Internal Platforms, Developer Experience, and Modern DevOps Practices Accelerate Software Delivery . High-performing engineering organizations don’t scale through heroics. They scale through repeatable platform capabilities backed by evidence. This checklist reflects the shift from tool‑centric DevOps to product‑oriented platform engineering, focused on sc

Votre bluetooth est en rade sur Linux ? Il existe une solution

Korben (Tier 1) · Publié : 2026-05-27 · 32.2/10

Une mise à jour récente du noyau Linux a cassé le support de certains adaptateurs Bluetooth MediaTek, ceux qui sont intégrés aux puces Wi-Fi qu'on trouve sur beaucoup de cartes mères modernes. Le résultat : votre clavier sans fil, votre souris ou votre casque Bluetooth ne se connectent plus après la mise à jour. Pour les utilisateurs Linux, c'est le genre de régression franchement pénible, pour rester poli. Al Williams raconte sur Hackaday avoir traqué le problème jusqu'à un fichier précis du no

Putting guardrails around llm calls before they become an incident

r/devops (Tier 1) · Publié : 2026-05-28 · 32.1/10

We had an internal support triage service call an llm to classify tickets and suggest next actions. Boring use case, low traffic, nobody considered it production risk. A bad deploy changed the retry condition from "retry on transport error" to "retry unless response has category", and one weird ticket format produced no category. The service politely burned through request after request until our alerting finally noticed spend velocity, not error rate. That was the awkward pa

JFrog Report Surfaces Need for Rapid DevSecOps Change in AI Era

DevOps.com (Tier 1) · Publié : 2026-05-27 · 30.3/10

A report published by JFrog finds that cybercriminals are now increasingly targeting the artificial intelligence (AI) tools and platforms used by application development teams. Based on an analysis of 18.2 billion artifacts managed via the JFrog Platform, security researchers discovered 969 AI agent skills carrying high-impact payloads in addition to 495 malicious AI models on […]

GPU autoscaling on Kubernetes with KEDA: Building an external scaler

CNCF Blog (Tier 1) · Publié : 2026-05-27 · 22.4/10

If you run GPU workloads on Kubernetes — vLLM, Triton, training jobs, or the newer agentic inference stacks — you’ve probably hit a familiar problem: the default autoscaling path still reasons about CPU and memory, while...

Best Practice for retrieving external values?

r/devops (Tier 1) · Publié : 2026-05-28 · 21.8/10

How do you guys handle retrieving external data values from sources such as SSM and Vault in a pipeline? Do you let each individual terraform stack make a call or my CICD environmental variables and each stack can get the values via TF_VAR_*? Im thinking letting CICD handle it is best because you make the call once and export as environment variables. Would this also apply for secrets? submitted by /u/DeLoMioFoodie [link] [comments]

Burnt out by a lack of architecture decisions?

r/devops (Tier 1) · Publié : 2026-05-27 · 21.6/10

Title pretty much says it all. DevOps Engineer for the last 3 years, SysAdmin for 2 years before that. Been at this new place for a year, and tbh proud of my work. Since joining, done a pretty large migration of a monolithic application to a more micro service/ IaC based infra solution that performs much better. Put the Devs into a fully ephemeral container/pipeline driven SLDC (came from another software org but I'm at a MSP now so had some practice) and moved some hurdles. Enough hurdles f

Taphouse - La GUI Homebrew avec scanner CVE intégré

Korben (Tier 1) · Publié : 2026-05-28 · 21.3/10

Multimodal Solutions, une boîte grecque, vient de sortir Taphouse 1.5 qui est une GUI native macOS pour Homebrew. GUI c'est pas que le nom de votre collègue qui fout rien, c'est surtout un acronyme qui veut dire Graphic User Interface (Interface Graphique !). Et pour Homebrew, bah c'était pas du luxe. Parce que Homebrew, c'est le standard chez les développeurs Mac, mais tout passe par le terminal. Faut taper brew install , gérer les services, fouiller l'arbre de dépendances en CLI (Command Line

We stopped scoping db users for our agents and gave them our Runbooks instead

r/devops (Tier 1) · Publié : 2026-05-27 · 20.5/10

i work on an open-source access gateway, and we keep seeing the same pattern on customer calls: someone scopes a DB user for an agent, it works for a week, then it does something nobody planned for, and the security team pulls the plug. the agent ends up read-only. the work that needed it goes back to a human. the issue isn't the agent. it's that "DB user with these permissions" is the wrong shape of trust. an API key is open-ended by design, so review has to happen at runtime,

Lack of Devops jobs

r/devops (Tier 1) · Publié : 2026-05-27 · 20.4/10

is this role dead? I barely see any roles for this on linkedin,hiringcafe,etc. All i see are a lot of data engineering/swe jobs and im in the nyc area so is devops just not there anymore? submitted by /u/Mr_Average100 [link] [comments]

“There is no accountability”: AI coding agents are installing packages no one owns

The New Stack (Tier 1) · Publié : 2026-05-27 · 19.3/10

“There is no accountability.” It’s how Willem Delbare, co-founder, CTO, and CEO of Aikido Security, describes to The New Stack situations The post “There is no accountability”: AI coding agents are installing packages no one owns appeared first on The New Stack .

How AWS DevOps Agent uses multi-agent reasoning to find root causes

AWS DevOps Blog (Tier 1) · Publié : 2026-05-27 · 19.3/10

Confirmation bias is one of the most common reasons incident investigations take longer than they should. An on-call engineer gets alerted, forms a theory based on initial triage and experience, finds one piece of supporting evidence, and stops looking. The actual root cause — buried in a different service, a different signal, a different time […]

Snowflake commits $6B to AWS as it pushes deeper into AI

The New Stack (Tier 1) · Publié : 2026-05-27 · 17.8/10

Snowflake is committing $6 billion over five years to Amazon Web Services for Graviton compute and AI infrastructure, the data The post Snowflake commits $6B to AWS as it pushes deeper into AI appeared first on The New Stack .

Advice for automating AI agent QA post-deployment?

r/devops (Tier 1) · Publié : 2026-05-27 · 17.8/10

I’m at a mid-sized SaaS with a team of six. We’ve been doing manual testing for three years and we’ve gotten good in the way that anyone does with experience. Pattern recognition, intuition, and tribal knowledge basically. The problem is that all of the knowledge lives inside our heads. Test coverage decisions are essentially vibes. We trust things that haven’t broken recently and test things we’re scared of lol. Last quarter there were two production incidents our manual process missed. Both of

Le Canada coupe sa station radio horaire CHU après plus d'un siècle de service

Korben (Tier 1) · Publié : 2026-05-27 · 17.5/10

Le 22 juin prochain, le Canada va éteindre une voix qui parle sans interruption depuis 1923. La station CHU, opérée par le Conseil national de recherches (l'équivalent canadien du CNRS), cessera ses émissions sur ondes courtes après plus de cent ans de bons et loyaux services. Trois fréquences disparaîtront du spectre radio : 3330, 7850 et 14670 kHz. C'est la fin d'une époque. Pour ceux qui n'auraient jamais croisé son signal, CHU diffusait en continu l'heure officielle canadienne, calée sur une

Généré par veille-auto · Modèle : gemma4:e2b