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à.
Implementazione del caos engineering su AWS
L'ingegneria del caos fa parte della fase di valutazione e test del ciclo di vita della AWS resilienza, come illustrato nel diagramma seguente. Le applicazioni distribuite non funzionano in modo isolato da altre applicazioni o client, quindi consigliamo di esaminare l'intero ciclo di vita della resilienza. Il cambiamento è costante per le applicazioni distribuite man mano che la rete si evolve, le applicazioni upstream e downstream subiscono cambiamenti e l'utilizzo dei client cambia nel tempo.
Per capire in che modo queste modifiche all'applicazione potrebbero influire sulla sua resilienza, includi l'ingegneria del caos nelle tue operazioni. day-to-day Puoi implementare esperimenti sul caos in diversi modi:
-
Ad hoc: puoi eseguire esperimenti sul caos come esperimenti singoli per risolvere un problema o una domanda specifici.
-
Chaos game days: si tratta di eventi strutturati e ricorrenti progettati per verificare l'affidabilità e la resilienza di un'applicazione. Lo scopo di un Chaos Game Day è identificare potenziali problemi o carenze di resilienza tra persone, processi e tecnologie e mettere in pratica i processi e le procedure per identificare, mitigare e rispondere agli incidenti.
-
Chaos pipeline: integrazione continua e distribuzione continua (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDpipeline che inietta una crescente perdita di pacchetti per i componenti a valle). L'esperimento viene eseguito 3 volte e richiede 5 minuti per essere completato ogni volta. La perdita di pacchetti aumenta dal 10% al 20% al 30% ad ogni esecuzione e il completamento dell'esperimento richiede complessivamente 15 minuti. Se disponi di 100 implementazioni parallele, dovrai attendere 1500 minuti per il completamento di un singolo esperimento. Se dovessi eseguire 10 esperimenti, l'impatto sugli sviluppatori sarebbe insopportabile. Su larga scala, l'ingegneria del caos necessita di una propria pipeline che consenta di eseguire esperimenti parallelamente al processo del ciclo di vita dello sviluppo del software (SDLC).
-
Implementazioni Canarie: le isole Canarie forniscono un ambiente di test per esperimenti sul caos. Indirizzando una piccola percentuale del traffico verso un servizio Canary o utilizzando metodi come il mirroring o il replay del traffico, è possibile verificare nuove infrastrutture o modifiche al codice senza impatto sul sistema di produzione stabile. Potete eseguire esperimenti contro il canarino e iniettare eventuali errori, se necessario, in modo da limitare la portata dell'impatto sull'utente finale.
-
Esperimenti pianificati: è possibile pianificare esperimenti per verificare i meccanismi di ripristino prevedibili per l'applicazione. Usa esperimenti pianificati per riprodurre eventi noti di frequente per comprendere in che modo i tuoi sistemi possono riprendersi da eventi come la chiusura di un' EC2 istanza basata su un gruppo di scalabilità automatico, la rimozione di un pod Kubernetes o l'eliminazione di un'attività Amazon ECS.
