Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Azure Chaos Studio spiegato semplice: chaos engineering, iniezione di guasti e app Azure resilienti (Doppiaggio IA)

Transcript

Azure Chaos Studio spiegato semplice: chaos engineering, iniezione di guasti e app Azure resilienti (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Siete pronti per 10 giorni di Microsoft 365, Copilot, EA,
0:04
Speaker 2: Azure e per le persone che stanno plasmando il futuro
0:06
Speaker 2: del lavoro? Questo gennaio, M365 con ritorna e puntiamo ancora più,
0:11
Speaker 2: in alto. Unitevi a noi per sessioni live, demo reali
0:14
Speaker 2: e conoscenze pratiche condivise da MVP ed esperti del settore
0:17
Speaker 2: da tutto il mondo. Niente slide generiche, niente gergo infinito.
0:22
Speaker 2: Affronteremo le sfide reali. Copilot Studio, agenti EA, Fabric, Sicurezza,
0:27
Speaker 2: Governance e Automazione. Che siate professionisti IT, sviluppatori o leader aziendali,
0:32
Speaker 2: ci sono sessioni pensate apposta per voi. Con 10 giorni
0:36
Speaker 2: a disposizione potrete esplorare diverse tecnologie e connettervi con una
0:39
Speaker 2: community globale. Seguite le dirette e portate approfondimenti pratici nella
0:43
Speaker 2: vostra organizzazione. Gennaio 2027, 10 giorni, comunica Community Microsoft. Le
0:49
Speaker 2: registrazioni sono aperte. Andate su m365con. net e assicuratevi il vostro
0:55
Speaker 2: posto oggi stesso. Il sito è m365con. net. Iscrivetevi ora su m3665con. net.
1:01
Speaker 2: Ci vediamo in diretta a gennaio. Benvenuti a un altro
1:05
Speaker 2: episodio di Microsoft Knowledge Nuggets. Sono il vostro host, Milko Peters.
1:09
Speaker 2: E se poteste rompere le vostre app cloud di proposito
1:11
Speaker 2: in modo controllato per renderle più robuste? Sembra controintuitivo, ma
1:14
Speaker 2: è la stessa logica che usano i vigili del fuoco
1:16
Speaker 2: con gli incendi controllati. Appiccano piccoli fuochi intenzionalmente per eliminare
1:19
Speaker 2: la starpaglia, così che in caso di un vero incendio
1:21
Speaker 2: non resti nulla da bruciare. È esattamente ciò che Azure
1:23
Speaker 2: Cloud Studio fa per le vostre app cloud. Alla fine
1:25
Speaker 2: di questo episodio capirete cos'è il servizio, perché usarlo è
1:28
Speaker 2: come vi aiuti a creare sistemi che non crollano quando
1:30
Speaker 2: qualcosa va storto. Quindi prendete un caffè e partiamo dal problema. Problema.
1:36
Speaker 2: Perché i test tradizionali non sono sufficienti. Ecco il punto
1:39
Speaker 2: sui test tradizionali. Verificano se il software funziona come previsto
1:42
Speaker 2: in condizioni normali. Scrivete un test, lo eseguite e se
1:45
Speaker 2: l'output corrisponde il test è superato. Ottimo per trovare bug,
1:49
Speaker 2: ma non rileva come il sistema regisce a guasti imprevisti
1:51
Speaker 2: come un timeout di rete, una macchina virtuale che muore
1:54
Speaker 2: o un'intera zona di disponibilità che va offline. Le moderne
1:57
Speaker 2: app cloud non sono più semplici. Sono sistemi distribuiti che
2:00
Speaker 2: comunicano con database, cache, servizi d'identità, api di terze parti
2:03
Speaker 2: e altri microservizi. Tutti questi elementi hanno dipendenze nascoste. Un
2:07
Speaker 2: piccolo guasto può propagarsi a cascata nell'intero sistema. Un database rallenta,
2:10
Speaker 2: l'app va in timeout, il bilanciatore di carico la segnala
2:12
Speaker 2: come non integra, il traffico viene reindirizzato, altre stanze sovraccaricano
2:15
Speaker 2: e improvvisamente l'intera applicazione è offline. I test tradizionali non
2:18
Speaker 2: lo rilevano perché operano in condizioni perfette, con tutto disponibile,
2:21
Speaker 2: latenza di rete zero e nessuno che spegne le VM
2:23
Speaker 2: durante l'esecuzione del test. Così distribuiti in produzione sentendovi sicuri,
2:27
Speaker 2: poi arriva la realtà. Questa falsa sicurezza è pericolosa perché
2:30
Speaker 2: rappresenta la differenza tra sapere che il tuo sistema funziona
2:32
Speaker 2: e sapere che sopravvive. Ed è qui che entra in
2:35
Speaker 2: gioco l'ingegneria del caos. Cos'è davvero l'ingegneria del caos? L'ingegneria
2:38
Speaker 2: del caos è un metodo pratico. Inserisci guasti reali e
2:41
Speaker 2: controllati nel tuo sistema e asservi come reagisce. Ciò non
2:44
Speaker 2: avviene in un laboratorio o in una simulazione. Accade sulle
2:46
Speaker 2: tue risorse effettive. L'idea è semplice. Si parte da un'ipotesi,
2:49
Speaker 2: come se perdiamo una macchina virtuale il bilanciatore di carico
2:52
Speaker 2: dovrebbe continuare a instradare il traffico verso le istanze rimanenti.
2:55
Speaker 2: Esegui un esperimento. Spendi quella VM e guardi cosa succede.
2:58
Speaker 2: Il bilanciatore di carico fa il suo lavoro. L'applicazione rimane attiva.
3:01
Speaker 2: I tuoi abisi si attivano correttamente. Misuri tutto, poi correggi
3:04
Speaker 2: ciò che si rompe. Ecco il punto. L'ingegneria del caos
3:08
Speaker 2: non è distruzione casuale. Non è uno sviluppatore che entra
3:10
Speaker 2: nella sala server e stacca cavi per divertimento. È scientifica,
3:13
Speaker 2: ripetibile e vincolata alla sicurezza. Definisci il raggio d'azione e
3:16
Speaker 2: controlli esattamente cosa fallisce, quando e per quanto tempo. E
3:19
Speaker 2: soprattutto impari da questo. Ogni esperimento ti fornisce delle prove.
3:22
Speaker 2: O la tua ipotesi era corretta e il sistema è resiliente,
3:25
Speaker 2: o era sbagliata e hai trovato una debolezza da correggere.
3:28
Speaker 2: In entrambi i casi ne ci vince. La sfida è
3:29
Speaker 2: che creare i propri strumenti di ingegneria del caos è difficile.
3:32
Speaker 2: Dovresti scrivere script per spegnere VM, iniettare carico sulla CPU,
3:36
Speaker 2: bloccare il traffico di rete e orchestrare tutto in modo
3:38
Speaker 2: sicuro e ripetibile. È molto lavoro ed è esattamente per
3:40
Speaker 2: questo che Azure ha creato un servizio gestito per gestito.
3:42
Speaker 2: Vi presentiamo Azure Chaos Studio. Azure Chaos Studio è un
3:46
Speaker 2: servizio completamente gestito per eseguire esperimenti di caos direttamente sulle
3:49
Speaker 2: tue risorse Azure. Nessuno script personalizzato, nessun strumento di terze parti,
3:52
Speaker 2: nessuna necessità di costruire una propria piattaforma di iniezione di guasti.
3:55
Speaker 2: È tutto nel portale Azure pronto per l'uso. Ecco come funziona.
3:58
Speaker 2: Chaos Studio ti offre due modi per iniettare i guasti.
4:00
Speaker 2: I guasti diretti al servizio vengono eseguiti tramite il piano
4:02
Speaker 2: di controllo di Azure. Dice a Chaos Studio di spegnere
4:05
Speaker 2: una VM e lui lo fa tramite le API di Azure.
4:07
Speaker 2: Nessun agente necessario. Guasti basati su agenti installano un piccolo
4:10
Speaker 2: agente all'interno della tua macchina virtuale. quindi può portare la
4:14
Speaker 2: CPU al 100%, riempire la memoria o terminare un processo specifico.
4:17
Speaker 2: Questi ti permettono di simulare problemi che accadono all'interno del
4:20
Speaker 2: sistema operativo, non solo a livello di risorsa. Ecco un'analogia.
4:23
Speaker 2: Immagina di possedere un grande edificio per ufficio. Vuoi sapere
4:25
Speaker 2: se le tue uscite di sicurezza funzionano davvero? Aspettare un
4:28
Speaker 2: incendio reale è un'idea terribile, quindi assumi una squadra dedicata all'emergenza. Arrivano,
4:31
Speaker 2: bloccano una tromba delle scale, simulano il fumo al terzo
4:33
Speaker 2: piano e osservano le reazioni delle persone. Questo è Chaos Studio,
4:36
Speaker 2: la tua squadra d'emergenza. Li chiami, eseguono l'esercitazione e scopri
4:40
Speaker 2: se il tuo edificio è sicuro prima che si verifichi
4:42
Speaker 2: una vera emergenza. Chaos Studio supporta un'ampia gamma di risorse
4:46
Speaker 2: Azure macchine virtuali. Set di scalabilità, VM cluster del servizio
4:50
Speaker 2: Azure Kubernetes, Azure Cosmos DB, Azure Cache for Redis, gruppi
4:53
Speaker 2: di sicurezza di rete e altro ancora. La libreria di
4:57
Speaker 2: errori continua a creare. Quindi che tu stia eseguendo una
4:59
Speaker 2: semplice app a due livelli o una complessa architettura Mixed
5:01
Speaker 2: Services su AKS, puoi testarlo. Eccola buona notizia. Non hai
5:02
Speaker 2: bisogno di creare strumenti personalizzati. Tutto è disponibile tramite il
5:07
Speaker 2: portale Azure, la CLA, le APRS, i modelli ARM o BCAP.
5:11
Speaker 2: Puoi definire i tuoi esperimenti come codice integrale nel tuo
5:13
Speaker 2: pipeline di distribuzione. Ma non corriamo troppo. Per prima cosa
5:16
Speaker 2: analizziamo come sono effettivamente strutturati questi esperimenti. I componenti di base, target, passaggi, rami, azioni.
5:22
Speaker 2: Ogni esperimento di Chaos inizia con i target. Cos'è un target?
5:25
Speaker 2: È semplicemente una risorsa Azure su cui vuoi testare degli errori.
5:28
Speaker 2: Apri Chaos Studio, trovi la tua risorsa, una VM, un
5:30
Speaker 2: set di scalabilità, un cluster HKS e la integri. Questo
5:34
Speaker 2: significa dire a Chaos Studio Questa risorsa è disponibile per
5:37
Speaker 2: gli esperimenti, quel punto chiave. Quando integri un target, scegli
5:40
Speaker 2: anche quali errori vuoi consentire su quella risorsa. Non abiliti tutto.
5:44
Speaker 2: Scegli tu. Pressionesi più. Spegnimento completo della voce. Forse non produzione.
5:48
Speaker 2: Decidi tu. Una volta integrati i target, crei un esperimento.
5:52
Speaker 2: Pensa un esperimento come un progetto. Descrivi esattamente quali errori iniettare,
5:56
Speaker 2: in quale ordine, contro quali target e per quanto tempo.
5:58
Speaker 2: Non ti limiti a dire rompi qualcosa. Definisci l'intero scenario
6:01
Speaker 2: in anticipo. Gli esperimenti hanno una struttura semplice, passaggi, rami
6:04
Speaker 2: e azioni. I passaggi vengono eseguiti uno dopo l'altro. Il
6:07
Speaker 2: primo passaggio termina, poi inizia il secondo, poi il terzo.
6:10
Speaker 2: È così che modelli una sequenza temporale. Prima degradi la rete,
6:12
Speaker 2: poi metti sotto stress la CPU, poi spingi una VM.
6:15
Speaker 2: Ogni passaggio è una fase del tuo scenario. All'interno di
6:17
Speaker 2: ogni passaggio puoi avere uno o più rami. Ecco dove
6:20
Speaker 2: le cose si fanno interessanti. I rami vengono eseguiti in parallelo.
6:22
Speaker 2: Quindi all'interno del primo passaggio potresti avere il ramo A
6:25
Speaker 2: che aggiunge latenza al database e il ramo B che
6:27
Speaker 2: aumenta la CPU sui server web, entrambi contemporaneamente. Questo ti
6:30
Speaker 2: permette di simulare scenari complessi con più errori che rispecchiano
6:32
Speaker 2: incidenti del mondo reale. Infine le azioni. Le azioni sono
6:35
Speaker 2: i guasti veri e propri. Pressione sulla CPU, esaurimento della memoria,
6:38
Speaker 2: arresto di VM, ritardo di rete, blocco DNS, trenazione di processi.
6:41
Speaker 2: Ogni azione ha come obiettivo una risorsa specifica a un
6:44
Speaker 2: gruppo di risorse. E ancora, puoi usare solo le azioni
6:46
Speaker 2: che hai abilitato su quella destinazione. Questa è la tua
6:48
Speaker 2: rete di sicurezza. Se non hai abilitato l'arresto della VM
6:51
Speaker 2: su una destinazione, l'esperimento non eseguerà semplicemente quell'azione. Quindi il
6:53
Speaker 2: flusso di lavoro è questo. Configura le tue destinazioni. Abilita
6:56
Speaker 2: i guasti con cui ti senti a tuo agio. Crea
6:58
Speaker 2: un esperimento con passaggi, rami e azioni, quindi eseguilo. Ma
7:01
Speaker 2: prima di iniziare a eseguirne uno, c'è qualcosa di importante
7:03
Speaker 2: da capire. Quando Chaos Studio esegue un esperimento non sta
7:06
Speaker 2: simulando nulla, sta effettivamente facendo queste cose alle tue risorse.
7:09
Speaker 2: La pressione sulla CPU è una pressione reale sulla GPU.
7:11
Speaker 2: L'arresto di una VM è un vero arresto. È proprio
7:13
Speaker 2: questo il punto. Stai testando come si comporta il tuo
7:15
Speaker 2: sistema in condizioni di guasto reali. E questo significa che
7:17
Speaker 2: devi prestare attenzione. Quindi analizziamo un esperimento reale e vediamo
7:20
Speaker 2: come tutto si unisce. Esecuzione del tuo primo esperimento di Chaos.
7:23
Speaker 2: Rendiamolo reale. Immagina di avere un'applicazione web in esecuzione su
7:26
Speaker 2: tre macchine virtuali all'interno di un set di scalabilità. Ogni
7:29
Speaker 2: VM si trova in una zona di disponibilità diversa. Hai
7:32
Speaker 2: un bilanciatore del carico davanti che distribuisce il traffico su
7:34
Speaker 2: tutte e tre. L'ipotesi è semplice. Se perdiamo un'intera zona
7:38
Speaker 2: di disponibilità, il bilanciatore del carico dovrebbe reindirizzare il traffico
7:41
Speaker 2: alle due VM rimanenti e l'applicazione rimane disponibile. Quindi progetti
7:45
Speaker 2: un esperimento con due passaggi. Passaggio 1. Metti sotto stress
7:48
Speaker 2: due delle tre VM con i 95 per 5 minuti.
7:51
Speaker 2: Ciò simula uno scenario di vicino rumoroso o un processo
7:54
Speaker 2: fuori controllo. Passaggio 2. Arresta bruscamente tutte le VM nella
7:57
Speaker 2: zona 2. Ciò simula un'interruzione reale della zona. Esegui l'esperimento
8:01
Speaker 2: e poi osservi cosa succede. E cosa vedresti? Nei primi
8:04
Speaker 2: 5 minuti, due VM arrivano al 100% di CPU. La
8:07
Speaker 2: terza rimane normale perché non l'hai presa come obiettivo. I
8:09
Speaker 2: tuoi dashboard di monitoraggio si illuminano, gli avvisi scattano, il
8:12
Speaker 2: bilanciatore del carico nota che quelle due VM sono in difficoltà,
8:14
Speaker 2: ma poiché sono ancora tecnicamente in esecuzione, come anche in esecuzione,
8:16
Speaker 2: continua in esecuzione, continua a inviare lo traffico. La tua
8:18
Speaker 2: app rallenta ma non va offline. Interessante. Hai già imparato qualcosa.
8:22
Speaker 2: Entra in gioco il passaggio 2. Le VM nella zona
8:24
Speaker 2: 2 vengono bruscamente arrestate, non in modo graduale, senza alcun avviso.
8:27
Speaker 2: Scompaiono semplicemente. Una di quelle due VM sotto stress si
8:29
Speaker 2: trovava in quella zona, quindi è sparita. Il bilanciatore del
8:31
Speaker 2: carico vede il fallimento del controllo di integrità, la rimuove
8:33
Speaker 2: dal pool di backend e installa da tutto il traffico
8:35
Speaker 2: alle VM sane e rimanenti. La tua app rimane attiva.
8:37
Speaker 2: L'ipotesi è confermata. Ma ecco cosa potresti non aspettarti. Le
8:41
Speaker 2: VM rimanenti devono ora gestire il 100% del traffico. Se
8:44
Speaker 2: non avessi abbastanza capacità per assorbire quel carico, vedresti picchi
8:46
Speaker 2: di latenza. Magari l'app rimane tecnicamente online, ma gli utenti
8:49
Speaker 2: ne risentono. Questa è una scoperta. Ora sai che ti
8:52
Speaker 2: serve più margine o un autoscaling più rapido. E ricorda,
8:55
Speaker 2: questa non è una simulazione. Quando Chaos Studio esegue questo esperimento,
8:58
Speaker 2: quelle VM raggiungono davvero il 95% di CPU. Quello spegnimento
9:02
Speaker 2: da zona 2 è un arresto reale. La VM si ferma,
9:04
Speaker 2: il bilanciatore di carico si riequilibra e la tua applicazione
9:06
Speaker 2: sopravvive o meno. E' proprio questo, non stai tirando a indovinare.
9:09
Speaker 2: Stai osservando il comportamento reale, in condizioni di guasto reali.
9:12
Speaker 2: Impari se la tua app rimane attiva o si blocca.
9:15
Speaker 2: E se si blocca, la sistemi prima che i tuoi
9:16
Speaker 2: clienti possano mai vederla. Ma questo potere comporta delle responsabilità.
9:20
Speaker 2: Devi fare attenzione. La sicurezza prima di tutto, evitando interruzioni
9:24
Speaker 2: in pianificato. Chaos Studio ha molteplici meccanismi di sicurezza integrati.
9:27
Speaker 2: E prima di eseguire il tuo primo esperimento devi comprenderli tutti.
9:31
Speaker 2: Il primo livello di sicurezza è l'identità e l'autorizzazione. Ogni
9:34
Speaker 2: esperimento che crei ottiene la sua identità gestita assegnata dal sistema.
9:37
Speaker 2: Poi l'identità inizia con zero autorizzazioni per impostazione pre. Devi
9:40
Speaker 2: concedere esplicitamente l'accesso alle risorse necessarie fornendo solo i permessi
9:44
Speaker 2: minimi richiesti. Se un esperimento deve solo stressare la CPU
9:47
Speaker 2: su 2WM limita strettamente le autorizzazioni invece di permettergli di
9:51
Speaker 2: spegnere tutto nel gruppo di risorse. Poi c'è l'abilitazione dei
9:54
Speaker 2: guasti che ho menzionato prima. Quando integri un obiettivo, scegli
9:57
Speaker 2: esattamente quali guasti sei disposto a consentire. Se non abiliti
10:00
Speaker 2: mai lo spegnimento delle WM su un set di scalabilità
10:02
Speaker 2: di produzione, nessun esperimento potrà spegnerle, anche se qualcuno ci provasse.
10:06
Speaker 2: È un blocco rigido che richiede di scegliere deliberatamente ogni
10:09
Speaker 2: tipo di guasto. Ora da dove cominciare? La risposta è semplice.
10:13
Speaker 2: Inizia in piccolo in un ambiente non di produzione. Esegui
10:15
Speaker 2: i tuoi primi esperimenti in Devostaging. fai dei test con
10:18
Speaker 2: una singola VM, un singolo guasto, e verifica che il
10:21
Speaker 2: monitoraggio funzioni, gli avvisi partano e che tu possa annullare
10:23
Speaker 2: l'esperimento se qualcosa va storto. Solo dopo aver costruito questa
10:26
Speaker 2: fiducia in un ambiente sicuro dovresti pensare di toccare la produzione.
10:30
Speaker 2: Microsoft ha un avvertimento a riguardo che voglio condividere direttamente.
10:33
Speaker 2: Lo chiamano un evento, da aggiornamento del curriculum. Se esegui
10:36
Speaker 2: un esperimento di caos in produzione senza le dovute precauzioni,
10:39
Speaker 2: questo fa cadere l'intera applicazione e il tipo di errore
10:41
Speaker 2: che potrebbe farti licenziare. Non esagerazione. Chaos Studio è potente
10:45
Speaker 2: perché agisce realmente sulle tue risorse, quindi usa questo potere
10:47
Speaker 2: con saggezza. L'ultima rete di sicurezza è il monitoraggio dell'annullamento.
10:52
Speaker 2: Mentre un esperimento è in corso, puoi seguirne l'avanzamento in
10:54
Speaker 2: tempo reale. Vedi quali passaggi sono completati, quali rami sono
10:57
Speaker 2: attivi e quali azioni in esecuzione. Se qualcosa sembra non andare,
11:01
Speaker 2: premi Annulla e l'esperimento si ferma immediatamente. Le risorse coinvolte
11:04
Speaker 2: rimangono nello stato in cui si trovano, ma non vengono
11:07
Speaker 2: iniettati nuovi guasti. Quindi tieni aperti i tuoi dashboard e
11:09
Speaker 2: il dito sul pulsante Annullamento. Inizia in piccolo e agisci
11:12
Speaker 2: con cautela rispetto alla potenza dello strumento. Ora che sai
11:14
Speaker 2: come restare al sicuro, la domanda è, dove dovresti eseguire
11:17
Speaker 2: questi esperimenti? Spostarsi a sinistra contro spostarsi a destra. Quindi,
11:21
Speaker 2: dove si eseguono effettivamente questi esperimenti? Ci sono due approcci
11:24
Speaker 2: principali e la maggior parte dei timori sono tre. Il
11:26
Speaker 2: primo è spostarsi a sinistra. Esegui esperimenti di Chaos Engineering
11:30
Speaker 2: presto nel ciclo di vita dello sviluppo. Appena il codice
11:32
Speaker 2: viene distribuito in un ambiente di test, lo colpisci con
11:35
Speaker 2: dei guasti e lo rendi parte della tua pipeline CICCD.
11:38
Speaker 2: La pipeline distribuisce l'app. Esegue un esperimento di caos per stressarla,
11:41
Speaker 2: verifica che sopravvive e solo allora promuove la build alla
11:43
Speaker 2: fase successiva. Pensala come un controllo di qualità, esattamente come
11:46
Speaker 2: in i test o le scansioni di sicurezza. Se l'app
11:49
Speaker 2: non gestisce lo spegnimento di una VM in staging, non
11:51
Speaker 2: va in produzione. Il secondo approccio è spostarsi a destra,
11:54
Speaker 2: che significa eseguire esperimenti in produzione. E sì, suona terrificante,
11:58
Speaker 2: ma ascoltami bene. Non si inizia da lì. Ti sposti
12:00
Speaker 2: a destra solo dopo aver acquisito fiducia negli ambienti non
12:03
Speaker 2: di produzione. Inizia con esperimenti piccoli e limitati. Magari stressi
12:07
Speaker 2: la CPU su un'istanza durante un periodo di scarso traffico.
12:10
Speaker 2: Osservi attentamente, impari il PaceBank. Magari spegni una singola VM
12:13
Speaker 2: in produzione durante l'orario lavorativo e convalidi che il tuo
12:16
Speaker 2: bilanciatore di carico reindirizzi il traffico, che gli utenti non
12:19
Speaker 2: notino nulla e che il monitoraggio rilevi tutto. Col tempo
12:23
Speaker 2: passi a esperimenti più aggressivi. C'è un terzo approccio che
12:26
Speaker 2: sta nel mezzo, i game days. Un game day è
12:28
Speaker 2: un'esercitazione di caos programmata in cui riunisci il team di sviluppo,
12:31
Speaker 2: quello operativo, quello di sicurezza, tutti coloro che sarebbero coinvolti
12:34
Speaker 2: in un incidente reale. Esegui un esperimento di caos e
12:36
Speaker 2: metti in pratica la tua risposta agli incidenti. Chi riceve l'avviso?
12:39
Speaker 2: Chi decide di scalare il problema? Qual è la catena
12:41
Speaker 2: di comunicazione? Quanto velocemente riesci ad agnosticare il problema? I
12:43
Speaker 2: game day testano la tecnologia, ma soprattutto le persone e
12:46
Speaker 2: i processi che le ruotano attorno. L'idea chiave in tutti
12:48
Speaker 2: e tre gli approcci è che il cast engineering non
12:50
Speaker 2: è un test, una tantum. Non si esegue un esperimento,
12:53
Speaker 2: si dichiara resiliente, il sistema si passa oltre. I sistemi cambiano,
12:56
Speaker 2: il codice cambia, le configurazioni cambiano, le dipendenze cambiano. Ciò
12:59
Speaker 2: che era resiliente il mese scorso potrebbe essere fragile. L'obiettivo
13:02
Speaker 2: è la convalida continua della resilienza. Si eseguono esperimenti regolarmente,
13:07
Speaker 2: li si integra nel processo di rilascio e li si
13:08
Speaker 2: rende parte del ritmo operativo. Quindi qual è il vero
13:11
Speaker 2: valore di tutto questo sforzo? Il vero valore è costruire fiducia.
13:15
Speaker 2: Il caso engineering fa molto più che trovare bug. Costruisce fiducia,
13:18
Speaker 2: questa è una cosa completamente diversa. Un bug è un
13:20
Speaker 2: difetto specifico. Lo si corregge e si passa all'ultimo. Alla
13:22
Speaker 2: fiducia c'è una sensazione. È sapere che il tuo sistema
13:25
Speaker 2: può sopravvivere all'imprevisto e non puoi ottenerlo solo dai unit
13:27
Speaker 2: test o dai test di integrazione. Lo tieni osservando il
13:31
Speaker 2: tuo sistema gestire un guasto reale e uscirne indenne Questo
13:34
Speaker 2: processo ti costringe a migliorare aspetti che altrimenti ignoreresti. Il
13:37
Speaker 2: tuo monitoraggio, per esempio. Quando esegui un esperimento di caos,
13:40
Speaker 2: scopri rapidamente se i tuoi dashboard mostrano le metriche giuste,
13:43
Speaker 2: se gli avvisi scattano alle soglie corrette e se il
13:45
Speaker 2: team di reperibilità viene avvisato in tempo. Se non riesci
13:48
Speaker 2: a vedere il guasto in corso, non puoi reagire. Gli
13:51
Speaker 2: esperimenti di caos e lacune rivelano anche presupposti nascosti. Ogni
13:55
Speaker 2: architetto ha detto qualcosa com'è. Se il database va giù,
13:57
Speaker 2: l'app dovrebbe semplicemente mettere in cache gli ultimi dati noti
13:59
Speaker 2: e continuare a funzionare. Sembra buono sulla lavagna, ma funziona davvero?
14:03
Speaker 2: L'hai mai testato? Gli esperimenti di caos rispondono a questa
14:06
Speaker 2: domanda con prove reali. Spegni i database e osservi cosa succede.
14:09
Speaker 2: Forse l'app lo gestisce correttamente. Forse va in crash.