Panoramica

Confronto tra test di resilienza e ingegneria del caos

I test di resilienza sono deterministici. In altre parole, convalida le caratteristiche note dei meccanismi di resilienza, come interruttori automatici, nuovi tentativi, failover o fallback, che sono stati implementati nell'applicazione. Conferma come questi componenti dell'applicazione assorbano le interruzioni controllate con un impatto minimo o nullo sugli utenti. Pertanto, i test di resilienza si concentrano sulla convalida di modalità di errore note che vengono inserite nei componenti dell'applicazione con l'obiettivo di produrre risultati. pass/fail È consigliabile eseguire continuamente i test di resilienza come fase della pipeline per assicurarsi di non introdurre regressioni al proprio livello di resilienza. Nei test di resilienza, spesso non si eseguono test su componenti reali, ma si simulano un determinato componente. APIs Questo approccio consente di testare in modo coerente e riproducibile gli scenari di guasto in un ambiente controllato, rendendolo adatto per l'integrazione automatizzata delle pipeline e i test di regressione.

Al contrario, l'ingegneria del caos non è deterministica. In altre parole, si basa su ipotesi e verifica il modello mentale dell'utente in base al modo in cui l'applicazione e le sue dipendenze (persone, processi e tecnologia) assorbono, si adattano e alla fine si riprendono da situazioni di fallimento impreviste. Pertanto, l'ingegneria del caos si concentra sulla end-to-end verifica di modalità di guasto sconosciute, con l'obiettivo di individuare tempestivamente i difetti e correggerli prima che si trasformino in eventi su larga scala. L'ingegneria del caos favorisce l'apprendimento continuo e dovrebbe essere praticata attraverso una pipeline separata o esperimenti ad hoc che consentano di eseguire più esperimenti in qualsiasi momento senza ostacolare la produttività dello sviluppatore nell'implementazione del codice.

Il processo di ingegneria del caos spesso inizia con una caos game day, ossia un evento dedicato in cui i team inseriscono intenzionalmente errori o guasti controllati nelle proprie applicazioni. La giornata di gioco è progressiva: inizia in ambienti di livello inferiore (come lo sviluppo o il test) e passa gradualmente ad ambienti di livello superiore (come la messa in scena e la pre-produzione) man mano che aumenta la fiducia. Spostandosi sistematicamente in questi ambienti, i team possono verificare che i propri sistemi tollerino correttamente i guasti iniettati prima di entrare in produzione. Questa progressione metodica garantisce che, nel momento in cui vengono condotti esperimenti sul caos negli ambienti di produzione, i team abbiano acquisito una notevole fiducia nelle capacità di resilienza del sistema. Il processo del game day è un approccio proattivo per identificare punti deboli e vulnerabilità nell'architettura e nelle pratiche operative di un'applicazione, eliminando al contempo lo stress dell'apprendimento durante un'interruzione imprevista della produzione.

Il valore dell'ingegneria del caos

I sistemi complessi sono onnipresenti nel mondo di oggi. Svolgono un ruolo fondamentale in molti aspetti della nostra vita, dai mercati finanziari all'assistenza sanitaria. Ci aspettiamo che questi sistemi siano sempre operativi. Tuttavia, i sistemi complessi sono spesso vulnerabili a eventi e comportamenti imprevisti che possono avere conseguenze significative. Le organizzazioni devono pianificare le interruzioni invece di chiedersi se si verificheranno. Possono farlo applicando test di scenario a tutti i loro servizi aziendali critici o mission-critical. È qui che entra in gioco l'ingegneria del caos.

L'ingegneria del caos offre un approccio alla gestione di sistemi complessi che può aiutare a mitigare i rischi e migliorare la resilienza. Il processo di preparazione agli esperimenti sul caos richiede ai team di sviluppare ipotesi sul comportamento del sistema, il che approfondisce la comprensione di come i sistemi sono costruiti e di come funzionano. Questa preparazione spesso rivela lacune mentali, approfondimenti architettonici e conoscenze operative che altrimenti potrebbero rimanere sconosciute. Promuovendo la comprensione di come i sistemi complessi reagiscono ai guasti, l'ingegneria del caos promuove una maggiore trasparenza e responsabilità nella progettazione e nella gestione dei sistemi. Quanto più spesso l'organizzazione pratica l'ingegneria del caos, tanto meglio si prepara a operare. L'ingegneria del caos consente di stabilire le migliori pratiche per la progettazione di applicazioni resilienti in grado di resistere ai guasti dei componenti con un impatto minimo o nullo sull'utente. Ciò garantisce che le applicazioni critiche operino entro i livelli di servizio e la tolleranza all'impatto previsti, migliorando al contempo la conoscenza dei sistemi da parte del team.

Prepararsi a condizioni avverse

Quando si sviluppa AWS, si utilizzano diversi tipi di servizi, tra cui servizi zonali come Amazon Elastic Compute Cloud (Amazon EC2), servizi regionali come Amazon Simple Storage Service (Amazon S3), servizi globali come (IAM), servizi software AWS Identity and Access Management as a service (SaaS) di terze parti e servizi locali. Ogni tipo di servizio espone diversi domini di errore di cui devi tenere conto. Come ci si prepara agli eventi autoinflitti o agli eventi causati da terze parti su cui l'organizzazione non ha alcun controllo?

Per capire in che modo l'applicazione potrebbe rispondere a condizioni avverse, puoi usare AWS Fault Injection Service ().AWS FIS AWS FIS è un servizio completamente gestito per l'esecuzione di esperimenti di iniezione dei guasti in modo controllato. È possibile utilizzare questo servizio per inserire scenari AWS forniti, ad esempio interruzioni dell'alimentazione nella zona di disponibilità e problemi di connettività tra regioni, oppure creare esperimenti personalizzati concatenando un'ampia gamma di azioni di guasto fornite dal servizio. AWS FIS consente ai vostri team di esercitarsi e imparare continuamente in che modo la loro applicazione reagirebbe ai guasti più comuni e correggerebbe i difetti non appena li rilevano.

Praticare l'ingegneria del caos controllato

I principi chiave degli esperimenti sul caos controllato sono:

Per scalare con successo l'ingegneria del caos, è necessario implementare esperimenti sul caos in modo controllato. Quando lo usi AWS FIS, puoi creare condizioni di arresto utilizzando gli CloudWatchallarmi Amazon. Puoi incorporare queste condizioni in un modello di esperimento per assicurarti che gli esperimenti vengano interrotti se superano i limiti e ripristinati all'ultimo stato noto. AWS FIS fornisce anche leve di sicurezza. Quando attivi queste leve, AWS FIS interrompe e ripristina tutti gli esperimenti in corso nell'account in the Regione AWS, compresi gli esperimenti con più account, e impedisce l'avvio di nuovi esperimenti. In questo modo si evita l'insorgenza di errori durante determinati periodi di tempo, ad esempio durante gli orari di negoziazione, gli eventi di vendita o il lancio di prodotti, o in risposta agli allarmi sullo stato dell'applicazione. La leva di sicurezza rimane innestata finché non viene disinnestata manualmente.

Quando si conduce un esperimento basato sul caos, è necessario definire misure di protezione per prevenire effetti collaterali indesiderati sull'ambiente, soprattutto se esiste la possibilità che l'esperimento influisca sulle applicazioni in produzione. Quando pianificate l'esperimento, anticipate gli eventuali effetti negativi che potrebbe avere su altre applicazioni dell'ambiente. Ad esempio, altre applicazioni potrebbero ricevere messaggi errati dall'applicazione che fa parte dell'esperimento, registrare elevati volumi di richieste o riscontrare un conflitto di risorse se condividono l'infrastruttura. Documenta questi rischi e risolvi eventuali problemi noti o inaccettabili prima di eseguire l'esperimento.