# Affidabilità Il principio dell'affidabilità comprende la capacità di un carico di lavoro di eseguire la funzione attesa in modo corretto e coerente quando previsto. Include la possibilità di utilizzare e testare il carico di lavoro per tutto il ciclo di vita. Questo documento fornisce linee guida dettagliate sulle best practice per l'implementazione di carichi di lavoro affidabili in AWS. Il principio dell'affidabilità offre una panoramica dei principi di progettazione, delle best practice e delle domande. È possibile trovare linee guida prescrittive sull'implementazione nel [Whitepaper sul principio dell'affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp). **Topics** + [ # Principi di progettazione ](rel-dp.md) + [ # Definizione ](rel-def.md) + [ # Best practice ](rel-bp.md) + [ # Risorse ](rel-resources.md) # Principi di progettazione Esistono cinque principi di progettazione per l'affidabilità nel cloud: + **Adotta un approccio di ripristino automatico dagli errori**: monitorando gli indicatori chiave di prestazione (KPI) di un carico di lavoro, è possibile attivare l'automazione in caso di superamento di una soglia. Questi KPI dovrebbero essere una misura del valore aziendale, non degli aspetti tecnici del funzionamento del servizio. Ciò consente la notifica e il tracciamento automatici degli errori e i processi di recupero automatizzati che aggirano o riparano l'errore. Con un'automazione più sofisticata è possibile anticipare e correggere gli errori prima che si verifichino. + **Collauda le procedure di ripristino**: in un ambiente in locale, spesso vengono eseguiti test per dimostrare che il carico di lavoro funziona in uno scenario specifico. I test non vengono generalmente utilizzati per convalidare le strategie di recupero. Nel cloud, puoi testare il modo in cui il carico di lavoro incorre nell'errore e convalidare le procedure di ripristino. È possibile utilizzare l'automazione per simulare diversi errori o per ricreare scenari che in precedenza hanno portato a errori. Questo approccio presenta percorsi di errore che è possibile testare e correggere prima che si verifichi uno scenario di errore reale, riducendo così il rischio. + **Dimensiona orizzontalmente per aumentare la disponibilità dei carichi di lavoro aggregati**: sostituisci una risorsa grande con più risorse piccole per ridurre l'impatto di un singolo guasto sul carico di lavoro complessivo. Distribuisci le richieste su molteplici risorse più piccole per garantire che non condividano un punto di errore comune. + **Smetti di fare congetture sulla capacità**: una causa comune di guasti nei carichi di lavoro in locale è la saturazione delle risorse, quando le richieste assegnate a un carico di lavoro superano la capacità di quel carico di lavoro (questo è spesso l'obiettivo di attacchi di tipo Denial of Service). Nel cloud, è possibile monitorare la domanda e l'utilizzo dei carichi di lavoro, nonché automatizzare l'aggiunta o la rimozione di risorse per mantenere il livello ottimale, al fine di soddisfare la domanda senza un provisioning eccessivo o inferiore. Esistono ancora dei limiti, ma alcune quote possono essere controllate e altre possono essere gestite (consulta Gestisci vincoli e Service Quotas). + **Gestisci il cambiamento nell'automazione**: le modifiche all'infrastruttura dovrebbero essere apportate utilizzando l'automazione. Le modifiche che devono essere gestite includono le modifiche all'automazione, che possono quindi essere monitorate e revisionate. # Definizione Esistono quattro aree di best practice per l'affidabilità nel cloud: + **Fondamenti** + **Architettura del carico di lavoro** + **Gestione delle modifiche** + **Gestione degli errori** Per ottenere affidabilità, è necessario iniziare dalle basi: un ambiente in cui le quote di servizio e la topologia di rete sono in grado di supportare il carico di lavoro. L'architettura del carico di lavoro del sistema distribuito deve essere progettata per prevenire e mitigare gli errori. Il carico di lavoro deve gestire le variazioni nella domanda o nei requisiti e deve essere progettato per rilevare l'errore e correggersi automaticamente. # Best practice **Topics** + [ # Fondamenti ](rel-found.md) + [ # Architettura del carico di lavoro ](rel-workload-arch.md) + [ # Gestione delle modifiche ](rel-chg-mgmt.md) + [ # Gestione degli errori ](rel-failmgmt.md) # Fondamenti I requisiti di base sono quelli il cui ambito si estende oltre un singolo carico di lavoro o progetto. Prima di progettare qualsiasi sistema, devono essere stabiliti i requisiti fondamentali che influenzano l'affidabilità. Ad esempio, è necessario disporre di una larghezza di banda di rete sufficiente verso il data center. Con AWS, la maggior parte di questi requisiti di base è già incorporata o può essere affrontata in base alle esigenze. Il cloud è progettato per essere quasi illimitato, perciò è responsabilità di AWS soddisfare i requisiti di capacità di rete e di elaborazione sufficienti, lasciandoti libero di modificare le dimensioni delle risorse e le allocazioni on demand. Le seguenti domande si concentrano su queste considerazioni relative all'affidabilità. (Per l'elenco completo delle domande e delle best practice relative all'affidabilità, consulta l' [Appendice](a-reliability.md).). | REL 1 In che modo gestisci quote e vincoli di servizio? | | --- | | Per le architetture di carichi di lavoro basate sul cloud, esistono quote di servizio (definite anche come restrizioni dei servizi). Queste quote sono presenti per evitare di effettuare accidentalmente il provisioning di più risorse di quelle necessarie e limitare i tassi di richiesta sulle operazioni API in modo da proteggere i servizi da un uso illecito. Esistono anche vincoli di risorse, ad esempio la velocità con cui è possibile trasferire i bit su un cavo in fibra ottica o la quantità di storage su un disco fisico. | | REL 2 In che modo pianifichi la topologia di rete? | | --- | | I carichi di lavoro sono spesso presenti in più ambienti. Questi includono più ambienti cloud (sia pubblicamente accessibili sia privati) e, possibilmente, l'infrastruttura del data center esistente. I piani devono includere considerazioni di rete, ad esempio connettività intrasistema e intersistema, gestione di indirizzi IP pubblici, gestione di indirizzi IP privati e risoluzione dei nomi di dominio. | Per le architetture di carichi di lavoro basate sul cloud, esistono quote di servizio (definite anche come restrizioni dei servizi). Queste quote sono presenti per evitare di effettuare accidentalmente il provisioning di più risorse di quelle necessarie e limitare i tassi di richiesta sulle operazioni API in modo da proteggere i servizi da un uso illecito. I carichi di lavoro sono spesso presenti in più ambienti. È necessario monitorare e gestire queste quote per tutti gli ambienti dei carichi di lavoro. Questi includono più ambienti cloud (sia pubblicamente accessibili sia privati) e possono includere l'infrastruttura del data center esistente. I piani devono includere considerazioni di rete, ad esempio connettività intrasistema e intersistema, gestione di indirizzi IP pubblici, gestione di indirizzi IP privati e risoluzione dei nomi di dominio. # Architettura del carico di lavoro Un carico di lavoro affidabile comincia con decisioni iniziali di progettazione sia per il software sia per l'infrastruttura. Le tue scelte architetturali avranno un impatto sul comportamento del carico di lavoro su tutti e cinque i pilastri del Well-Architected Framework. Per l'affidabilità, è necessario seguire modelli specifici. Con AWS, gli sviluppatori di carichi di lavoro possono scegliere i linguaggi e le tecnologie da utilizzare. Gli SDK AWS semplificano la scrittura di codici fornendo API specifiche dei linguaggi per i servizi AWS. Questi SDK, oltre alla scelta dei linguaggi, consentono agli sviluppatori di implementare le best practice di affidabilità elencate qui. Gli sviluppatori possono anche leggere e scoprire come Amazon crea e gestisce software nella [Amazon Builders' Library](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp). Le seguenti domande si concentrano su queste considerazioni relative all'affidabilità. | REL 3 In che modo progetti l'architettura del servizio di carico di lavoro? | | --- | | Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici. | | REL 4 In che modo progetti le interazioni in un sistema distribuito per evitare errori? | | --- | | I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati in queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice prevengono gli errori e migliorano il tempo medio tra errori (MTBF). | | REL 5 In che modo progetti le interazioni in un sistema distribuito per mitigare o affrontare gli errori? | | --- | | I sistemi distribuiti si basano sulle reti di comunicazione per interconnettere i componenti (ad esempio server o servizi). Il carico di lavoro deve funzionare in modo affidabile nonostante la perdita o la latenza dei dati su queste reti. I componenti del sistema distribuito devono funzionare in modo da non influire negativamente su altri componenti o sul carico di lavoro. Queste best practice consentono ai carichi di lavoro di affrontare stress o guasti, recuperare più rapidamente e mitigare l'impatto di tali problemi. Il risultato è un miglioramento del tempo medio di ripristino (MTTR). | # Gestione delle modifiche Le modifiche apportate al carico di lavoro o al relativo ambiente devono essere previste e gestite affinché il carico di lavoro funzioni in modo affidabile. Certe modifiche al carico di lavoro sono imposte da fattori esterni, quali i picchi di domanda, altre modifiche dipendono da fattori interni, quali le distribuzioni delle funzionalità e le patch di sicurezza. Utilizzando AWS, puoi monitorare il comportamento di un carico di lavoro e automatizzare la risposta ai KPI. Ad esempio, il carico di lavoro può aggiungere ulteriori server man mano che il carico di lavoro acquisisce più utenti. È possibile controllare chi dispone dell'autorizzazione per apportare modifiche al carico di lavoro e controllare la cronologia di tali modifiche. Le seguenti domande si concentrano su queste considerazioni relative all'affidabilità. | REL 6 In che modo monitori le risorse del carico di lavoro? | | --- | | I log e i parametri sono strumenti molto efficaci per ottenere informazioni sullo stato del tuo carico di lavoro. È possibile configurare il carico di lavoro in modo da monitorare i log e i parametri e inviare notifiche quando vengono superate le soglie o si verificano eventi significativi. Il monitoraggio consente al carico di lavoro di riconoscere quando vengono superate le soglie di prestazioni basse o si verificano errori, in modo che possa essere ripristinato automaticamente di rimando. | | REL 7 In che modo progetti il carico di lavoro per adattarti ai cambiamenti della domanda? | | --- | | Un carico di lavoro scalabile fornisce elasticità per aggiungere o rimuovere risorse automaticamente, in modo che vi sia una stretta corrispondenza con la domanda attuale in un dato momento. | | REL 8 In che modo implementi le modifiche? | | --- | | Per distribuire nuove funzionalità e garantire che i carichi di lavoro e l'ambiente operativo eseguano software noti e che sia possibile applicare patch o sostituirli in modo prevedibile, sono necessarie modifiche controllate. Se invece non sono controllate, risulta difficile prevederne l'effetto o risolvere eventuali problemi che causano. | Progettando un carico di lavoro in grado di aggiungere e rimuovere automaticamente le risorse in risposta ai cambiamenti della domanda, non solo si aumenta l'affidabilità, ma ci si assicura anche che il successo aziendale non diventi un peso. Con il monitoraggio attivo, il tuo team verrà avvisato automaticamente quando gli indicatori KPI si discostano dalle norme previste. La registrazione automatica delle modifiche al proprio ambiente consente di controllare e identificare rapidamente le azioni che potrebbero avere influito sull'affidabilità. I controlli sulla gestione delle modifiche assicurano la possibilità di applicare le regole che garantiscono l'affidabilità di cui hai bisogno. # Gestione degli errori In qualsiasi sistema di ragionevole complessità è previsto che si verifichino errori. L'affidabilità richiede che il carico di lavoro venga a conoscenza degli errori nel momento in cui si verificano e intervenga per evitare conseguenze sulla disponibilità. I carichi di lavoro devono essere in grado di affrontare errori e risolvere automaticamente i problemi. Con AWS, puoi sfruttare l'automazione per reagire ai dati di monitoraggio. Ad esempio, quando un determinato parametro supera una soglia, è possibile attivare un'azione automatica per risolvere il problema. Inoltre, anziché tentare di diagnosticare e correggere una risorsa guasta che fa parte del tuo ambiente di produzione, puoi sostituirla con una nuova ed eseguire l'analisi sulla risorsa guasta fuori banda. Poiché il cloud consente di creare versioni temporanee di un intero sistema a basso costo, è possibile utilizzare i test automatizzati per verificare i processi di recupero completi. Le seguenti domande si concentrano su queste considerazioni relative all'affidabilità. | REL 9 In che modo esegui il backup dei dati? | | --- | | Esegui il backup dei dati, delle applicazioni e della configurazione per soddisfare i tuoi requisiti relativi agli obiettivi di tempo di ripristino (recovery time objective, RTO) e agli obiettivi di punto di ripristino (recovery point objective, RPO). | | REL 10 In che modo utilizzi l'isolamento dei guasti per proteggere il carico di lavoro? | | --- | | Le barriere per l'isolamento dei guasti limitano l'effetto di un errore all'interno di un carico di lavoro a un numero limitato di componenti. I componenti al di fuori della barriera non subiscono gli effetti del guasto. Utilizzando più barriere per l'isolamento dei guasti, puoi limitare l'impatto sul carico di lavoro. | | REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti? | | --- | | I carichi di lavoro con requisiti di disponibilità elevata e MTTR (Mean Time To Recovery) basso devono essere progettati per garantire la resilienza. | | REL 12 In che modo testi l'affidabilità? | | --- | | Dopo aver progettato il carico di lavoro in modo da essere resiliente alle sollecitazioni della produzione, i test sono l'unico modo per garantire il funzionamento corretto e offrire la resilienza prevista. | | REL 13 Come pianifichi il disaster recovery (DR)? | | --- | | Avere backup e componenti del carico di lavoro ridondanti in loco è l'inizio della strategia di disaster recovery. [RTO e RPO sono i tuoi obiettivi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) per il ripristino del carico di lavoro. Imposta questi valori in base alle esigenze aziendali. Implementa una strategia per raggiungere questi obiettivi, prendendo in considerazione le posizioni e la funzione delle risorse e dei dati del carico di lavoro. La probabilità di interruzione e il costo del ripristino sono fattori chiave che aiutano a comunicare il valore aziendale che può avere il ripristino di emergenza per un carico di lavoro. | Esegui regolarmente il backup dei dati e testa i file di backup per assicurarti di poter effettuare il ripristino dopo errori sia logici che fisici. Una chiave per la gestione dei guasti è il test frequente e automatico dei carichi di lavoro che causano gli errori e quindi osservare come si ripristinano. Esegui questa operazione regolarmente e assicurati che tali test vengano attivati ​​anche dopo importanti cambiamenti del carico di lavoro. Traccia attivamente i KPI, oltre a Obiettivo del tempo di ripristino (RTO) e Obiettivo del punto di ripristino (RPO), per valutare la resilienza di un carico di lavoro (specialmente in scenari di test degli errori). Il monitoraggio dei KPI ti aiuterà a identificare e mitigare i singoli punti di errore. L'obiettivo è testare a fondo i processi di ripristino del carico di lavoro in modo da avere la certezza di poter recuperare tutti i dati e continuare a servire i propri clienti, anche di fronte a problemi prolungati. I processi di recupero dovrebbero essere testati tanto quanto i normali processi di produzione. # Risorse Consulta le seguenti risorse per ulteriori informazioni sulle best practice per l'affidabilità. ## Documentazione + [Documentazione di AWS](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp) + [Infrastruttura globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp) + [AWS Auto Scaling: come funzionano i piani di dimensionamento](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp) + [Che cos'è AWS Backup?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp) ## Whitepaper + [Pilastro dell'affidabilità: Well-Architected AWS](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp) + [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)