Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Guida introduttiva all'ingegneria del caos
Prima di condurre un esperimento, ti consigliamo di mettere in atto alcuni elementi essenziali per sfruttare al meglio le tue pratiche di ingegneria del caos. Questi elementi essenziali includono:
+ Osservabilità (metriche, registrazione, tracciamento delle richieste)
+ Un elenco di eventi o guasti del mondo reale che vorresti esplorare
+ Sponsorizzazione della resilienza organizzativa tramite il consenso della leadership
+ Assegnazione di priorità ai risultati critici, in base al potenziale impatto aziendale, rispetto alle nuove funzionalità che vengono scoperte durante gli esperimenti sul caos
## Osservabilità per esperimenti sul caos
L'osservabilità, che comprende metriche, registrazione e tracciamento delle richieste, svolge un ruolo chiave nell'ingegneria del caos. Quando esegui un esperimento, vorrai comprendere le metriche aziendali, le metriche lato server, le metriche dell'esperienza del cliente e le metriche operative. Senza osservabilità, non sarete in grado di definire il comportamento allo stato stazionario o creare un esperimento significativo per verificare se le vostre ipotesi sull'applicazione sono vere.
### Metriche
Il diagramma seguente mostra i tipi di metriche che è possibile monitorare per esperimenti di caos per diversi tipi di applicazioni.
+ **Metriche aziendali**: *lo stato stazionario* indica il normale funzionamento del sistema ed è definito dalle metriche aziendali. Può essere rappresentato da transazioni al secondo (TPS), flussi di clic al secondo, ordini al secondo o una misurazione simile. L'applicazione mostra uno stato stazionario quando funziona come previsto. Pertanto, verificate che l'applicazione sia integra prima di eseguire gli esperimenti. Lo stato stazionario non significa necessariamente che non vi sarà alcun impatto sull'applicazione quando si verifica un errore, poiché una percentuale di errori potrebbe rientrare nei limiti accettabili. Lo stato stazionario è la linea di base. Ad esempio, lo stato stazionario di un sistema di pagamenti potrebbe essere definito come l'elaborazione di 300 TPS con una percentuale di successo del 99 percento e un tempo di andata e ritorno di 500 ms. Visivamente, pensate allo stato stazionario come a un elettrocardiogramma (ECG). Se lo stato stazionario del sistema cambia improvvisamente, sai che c'è un problema con il tuo servizio.
+ **Metriche lato server**: per comprendere le prestazioni delle risorse durante l'esperimento, è necessario approfondire le loro prestazioni prima, durante e dopo l'esperimento. Per misurare l'impatto delle tue risorse AWS, puoi usare [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). CloudWatch è un servizio che monitora le applicazioni, risponde ai cambiamenti delle prestazioni, ottimizza l'uso delle risorse e fornisce informazioni sullo stato operativo. Durante i tuoi esperimenti, ti consigliamo di acquisire metriche lato server come saturazione, volumi di richieste, tassi di errore e latenza.
+ **Metriche sull'esperienza del cliente**: attivo AWS, puoi acquisire metriche utente reali utilizzando [CloudWatchRUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) per simulare le richieste degli utenti tramite strumenti come Locust, Grafana k6, Selenium o Puppeteer. Le metriche relative agli utenti reali sono fondamentali per le organizzazioni che conducono esperimenti di ingegneria del caos. Monitorando l'impatto sugli utenti reali durante un esperimento, i team possono ottenere un quadro preciso di come i guasti e le interruzioni influiranno sui clienti durante la produzione. Le metriche chiave relative all'esperienza del cliente sono Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Total Blocking Time (TBT).
+ **Metriche operative**: gli interventi misurano l'efficacia della mitigazione degli errori in modo automatizzato, ad esempio la corretta latenza delle richieste dei client durante il riavvio di pod, attività o istanze EC2 con meccanismi come il controller di replica o la scalabilità automatica. La possibilità di intervenire automaticamente durante un guasto è direttamente correlata a una buona esperienza utente. Capire se nel tempo questi meccanismi di mitigazione subiscano variazioni è fondamentale. Definendo le metriche per le mitigazioni automatiche riuscite e fallite, si creano linee guida che aiutano a identificare potenziali regressioni in tutto il sistema.
### Registrazione dei log
La registrazione centralizzata è fondamentale per comprendere lo stato dei componenti dell'applicazione prima, durante e dopo un esperimento basato sul caos. Ti consigliamo di raccogliere i log di tutti i componenti dell'applicazione per creare una visione consolidata di ciò che stava facendo ogni componente al momento dell'iniezione dell'esperimento. Ciò fornisce un quadro chiaro del flusso dell' end-to-endesperimento.
### Tracciamento delle richieste
Il tracciamento delle richieste consente di osservare il flusso di ogni singola richiesta tra i componenti dell'applicazione per ottenere una comprensione completa dell'impatto che l'errore iniettato ha sul sistema e sulle sue dipendenze. Tracciando le richieste, è possibile vedere come l'errore si propaga attraverso diversi servizi e componenti, in modo da poter valutare meglio la portata dell'interruzione. Per tracciare le tue richieste AWS, puoi usare. [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
## Scenari di fallimento da iniettare nel caos: esperimenti
L'obiettivo dell'inserimento dei guasti più comuni nell'applicazione è capire come l'applicazione reagisce a questi eventi imprevisti, in modo da poter creare meccanismi di mitigazione e rendere il sistema resiliente a tali errori. Inoltre, è consigliabile utilizzare l'ingegneria del caos per riprodurre gli scenari di errore cronologici per verificare che i meccanismi di mitigazione funzionino ancora come previsto e non abbiano subito variazioni nel tempo.
Considerate i seguenti eventi quando pianificate i vostri esperimenti di ingegneria del caos.
| Modalità di guasto | Description |
| --- | --- |
| Compromissione del server | Riavvia le istanze EC2, elimina i pod Kubernetes o le attività di Amazon Elastic Container Service (Amazon ECS) per capire come reagisce l'applicazione a tali arresti anomali. |
| errori API | Inserisci i guasti nel tuo servizio per comprendere il comportamento dell'applicazione. AWS APIs |
| Problemi di rete | Introduci latenza o congestione o blocca le connessioni per simulare i problemi di rete del mondo reale. |
| AWS Compromissione della zona di disponibilità | Riproduci la compromissione di un'intera zona di disponibilità per verificare il ripristino tra le zone. |
| Regione AWS compromissione della connettività | Riproduci un problema di rete Regioni AWS per verificare in che modo le risorse della regione secondaria reagiscono a tale evento. |
| Errori del database | Esegui il failover delle repliche del database o danneggia i dati o rendi irraggiungibili le istanze del database, per comprendere l'impatto sulle applicazioni e sulle strategie di ripristino. |
| Sospensione della replica del database e di Amazon S3 | Metti in pausa la replica del database o di Amazon Simple Storage Service (Amazon S3) tra le zone di disponibilità o Regioni AWS per comprendere l'impatto delle applicazioni a valle. |
| Degrado dello storage | Metti in pausa l'I/O, rimuovi i volumi Amazon Elastic Block Store (Amazon EBS) o elimina i file per verificare la durabilità e il ripristino dei dati. |
| Compromissione della dipendenza | Riduci o riduci le prestazioni dei servizi downstream o upstream da cui dipendi, compresi i servizi di terze parti, per comprenderne il end-to-end flusso e l'impatto sui tuoi clienti. |
| Sbalzi di traffico | Genera picchi nel traffico degli utenti per testare le funzionalità di scalabilità automatica e scopri come il tempo di avvio a freddo potrebbe influire sullo stato generale dell'applicazione. |
| Esaurimento delle risorse | Massimizza CPU, memoria e spazio su disco per verificare il corretto degrado dell'applicazione. |
| Guasti a cascata | Avvia guasti primari che si ripercuotono in cascata su applicazioni e componenti a valle. |
| Implementazioni errate | Implementa modifiche o configurazioni problematiche per verificare i meccanismi di rollback. |
## Sponsorizzazione della resilienza organizzativa
L'ingegneria del caos offre il massimo valore quando viene applicata in tutta l'organizzazione. Ti consigliamo di collaborare con uno sponsor esecutivo che possa aiutarti a stabilire obiettivi di resilienza all'interno dell'organizzazione, a rimuovere la paura, l'incertezza e i dubbi sul dominio e ad avviare il processo di trasformazione per rendere la resilienza una responsabilità di tutti.
Per sostenere l'idea aziendale di creare uno studio di ingegneria del caos, associa le attività di ingegneria del caos ai tuoi progetti aziendali critici. Fare della resilienza una risorsa e un fattore di accelerazione vi aiuterà a monitorare il successo nel tempo. Inizia con un conteggio degli incidenti critici al mese o al trimestre, il tempo medio di ripristino e l'impatto che questi incidenti hanno causato sui clienti e sull'organizzazione. Stabilisci con i tuoi team l'obiettivo di ridurre il numero di incidenti in un periodo da 6 a 12 mesi, grazie ai miglioramenti apportati a tutti gli stack di applicazioni in risposta agli esperimenti di ingegneria del caos.
Misura se gli incidenti sono altamente ripetitivi. Ad esempio, supponiamo che un certificato TLS scaduto porti a tempi di inattività perché i client non riescono a stabilire una connessione affidabile. Se si verificano più incidenti in un anno a causa di più scadenze di certificati TLS, puoi eseguire un esperimento sulla scadenza di un certificato TLS e verificare che i tuoi team ricevano avvisi o siano in grado di mitigare automaticamente tali problemi. Ciò contribuirà a garantire la resilienza a tali errori.
Per tenere traccia dei progressi dell'ingegneria del caos nel tempo, acquisisci le seguenti metriche per evidenziare il valore dell'ingegneria del caos durante il ciclo di vita di un'applicazione:
+ **Tasso di incidenti ridotto**: monitora il numero di incidenti di produzione nel tempo e correla questo numero con l'adozione dell'ingegneria del caos. Si prevede che il tasso di incidenti gravi diminuirà.
+ **Tempo medio di risoluzione (MTTR) migliorato**: calcola il tempo medio necessario per risolvere gli incidenti e monitora questi dati per vedere se, grazie all'ingegneria del caos, migliorano nel tempo.
+ **Maggiore disponibilità delle applicazioni**: utilizza le metriche a livello di servizio per mostrare i miglioramenti della disponibilità man mano che aumenta la resilienza delle applicazioni attraverso esperimenti di caos.
+ **Tempi di commercializzazione più rapidi**: Chaos Engineering può fornire la sicurezza necessaria per lanciare offerte innovative più rapidamente, perché sapete che le vostre applicazioni sono resilienti. Tieni traccia degli aumenti della velocità di rilascio dei prodotti.
+ **Riduzione dei costi operativi**: quantifica se indicatori come il rumore di allarme, il carico operativo e lo sforzo manuale per gestire le applicazioni diminuiscono con l'adozione di pratiche basate sul caos.
+ **Incremento della fiducia**: intervistate sviluppatori, ingegneri dell'affidabilità del sito (SREs) e altro personale tecnico per valutare se l'ingegneria del caos abbia rafforzato la loro fiducia nella resilienza delle applicazioni. Le percezioni contano.
+ **Esperienze clienti migliorate** ‒ Connect Chaos Engineering a risultati positivi per i clienti, come un minor numero di interruzioni del servizio, rollback e interruzioni.
## Dare priorità alla riparazione
Quando si eseguono esperimenti di caos, è probabile che si identifichino aree di miglioramento in cui l'applicazione non funziona come previsto. La correzione di tali elementi diventerà parte integrante del vostro backlog, a cui dovrete dare priorità insieme ad altre attività, come lo sviluppo di funzionalità. Ti consigliamo di dedicare del tempo a questi miglioramenti per evitare futuri errori. Valuta la possibilità di dare priorità a queste attività di apprendimento e correzione in base al livello di impatto che potrebbero causare. I risultati che hanno un impatto diretto sulla resilienza o sulla sicurezza dell'applicazione dovrebbero avere la priorità sulle nuove funzionalità, per evitare l'impatto sui clienti. Se il team ha difficoltà a dare priorità alle azioni correttive rispetto allo sviluppo delle funzionalità, prendi in considerazione la possibilità di contattare il tuo sponsor esecutivo per garantire che le priorità siano stabilite in base alla tolleranza al rischio aziendale.