<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>SRE | The .NET Blog</title><link>https://thedotnetblog.com/it/tags/sre/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>it</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Tue, 21 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/it/tags/sre/index.xml" rel="self" type="application/rss+xml"/><item><title>Il Chaos Testing Non è Più Opzionale: Perché Azure Chaos Studio Workspaces è Importante</title><link>https://thedotnetblog.com/it/news/emiliano-montesdeoca/proving-resilience-chaos-studio-workspaces/</link><pubDate>Tue, 21 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/it/news/emiliano-montesdeoca/proving-resilience-chaos-studio-workspaces/</guid><description>Azure Chaos Studio Workspaces trasforma la resilienza da intenzione architetturale a evidenza misurabile, e questo cambiamento dovrebbe influenzare come i team rilasciano software su Azure.</description><content:encoded>&lt;p&gt;La maggior parte dei team tratta ancora la resilienza come una checklist di design: multi-zona, failover abilitato, retry in-place, fatto. Questa mentalità è superata. Gli incidenti di produzione raramente falliscono come prevedono i diagrammi architetturali, e il nuovo Chaos Studio Workspaces di Azure è una risposta diretta a quella realtà.&lt;/p&gt;
&lt;p&gt;Fonte originale: &lt;a href="https://azure.microsoft.com/en-us/blog/proving-application-resilience-on-azure-with-chaos-studio/"&gt;https://azure.microsoft.com/en-us/blog/proving-application-resilience-on-azure-with-chaos-studio/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Il cambiamento più importante non è &amp;ldquo;più fault injection.&amp;rdquo; È la &lt;strong&gt;validazione scenario-first&lt;/strong&gt;. Invece di comporre manualmente failure casuali, Workspaces inizia con pattern di outage che i team vedono realmente: perdita di zona, outage DNS, failover del database, interruzione dell&amp;rsquo;identità, cache stampede e interruzione della messaggistica. Questo è un modello molto migliore perché il rischio operativo vive nelle combinazioni, non nei guasti isolati.&lt;/p&gt;
&lt;p&gt;La mia opinione è semplice: resilienza senza esercitazioni ricorrenti è resilienza teatrale. Se il tuo servizio non è mai stato eseguito attraverso una sequenza di failure realistica e cross-layer, non conosci il tuo comportamento di ripristino, lo assumi e basta. Workspaces abbassa quella barriera scoprendo automaticamente l&amp;rsquo;ambito e raccomandando scenari contro risorse reali, rimuovendo la scusa comune di &amp;ldquo;non sappiamo da dove iniziare.&amp;rdquo;&lt;/p&gt;
&lt;h3 id="cosa-dovrebbero-fare-ora-sviluppatori-e-platform-team"&gt;Cosa dovrebbero fare ora sviluppatori e platform team&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Definisci una pipeline di resilienza minima.&lt;/strong&gt; Almeno uno scenario per carico di lavoro critico, su una cadenza di rilascio, con un gate pass/fail legato agli obiettivi di ripristino.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Tratta i report degli scenari come artefatti di prima classe&lt;/strong&gt; nel change management. Dovrebbero essere allegati alle approvazioni di rilascio e alle revisioni post-incidente proprio come gli scan di sicurezza.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Includi asserzioni a livello applicativo&lt;/strong&gt;, non solo successo infrastrutturale. Un database può eseguire il failover correttamente mentre la tua app serve ancora letture stale o si blocca.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Un&amp;rsquo;altra mossa forte di Microsoft è esporre tutto questo attraverso Copilot skill e strumenti MCP. È strategicamente intelligente. Gli ingegneri operano sempre più attraverso workflow assistiti, e il testing di resilienza dovrebbe far parte di quel ciclo quotidiano, non un rituale trimestrale gestito da uno specialista di affidabilità.&lt;/p&gt;
&lt;p&gt;Se esegui carichi di lavoro AI su Azure, questo conta ancora di più. Gli agenti e le pipeline di retrieval dipendono ancora da primitivi cloud ordinari: rete, cache, identità, storage, database. La piattaforma non può dichiarare affidabilità se quelle fondamenta non sono testate sotto stress.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;In sintesi:&lt;/strong&gt; Chaos Studio Workspaces rende &amp;ldquo;dimostralo&amp;rdquo; il nuovo default per l&amp;rsquo;affidabilità. I team che lo adottano presto spediranno con fiducia. I team che rimanderanno continueranno a scoprire bug di resilienza in produzione, dove ogni test è costoso e pubblico.&lt;/p&gt;</content:encoded></item></channel></rss>