Riepilogo

Completato

Contoso Shoes è un negozio di scarpe online che vuole essere facilmente reperibile in occasione di un lancio imminente. Due anni fa è stata effettuata la migrazione delle distribuzioni locali verso il cloud e sono stati ottenuti benefici grazie all'adozione del modello OpEx. Negli ultimi sei mesi si sono verificati problemi con la disponibilità e gli operatori non sono in grado di risolvere rapidamente i problemi. L'organizzazione vuole ora investire per rendere il carico di lavoro cruciale e concentrarsi sul miglioramento dell'affidabilità complessiva e dell'osservabilità del sistema.

Nell'architettura precedente l'applicazione è stata distribuita in una singola area e non è stata in grado di resistere alle interruzioni a livello di area. Il Servizio app di Azure e gli strumenti di monitoraggio esterni non hanno avuto un modo per controllare lo stato di integrità dell'applicazione stessa. Questo divario ha portato al traffico instradato a istanze di servizio app non integre, causando richieste non riuscite. Il team non ha potuto osservare l'effetto a catena di problemi derivante da un componente dell'API, che influenzava le dipendenze della piattaforma.

Completando questa sfida, è stata esaminata una progettazione cruciale a livello generale. Sono state applicate le informazioni tramite gli esercizi per soddisfare le esigenze di Contoso.

La progettazione migliorata rileva prestazioni ridotte di uno o più componenti usando un modello di integrità. Il team SRE può ora identificare e risolvere rapidamente i problemi prima di poter causare un'interruzione completa. Ora che la soluzione viene distribuita in più aree in un modello attivo-attivo, può resistere a un errore a livello di area completa, fornendo al contempo informazioni più dettagliate sull'integrità del sistema ai propri operatori. Contoso ha inoltre migliorato l'esperienza del cliente offrendo ai clienti una maggiore velocità in un'area geograficamente più vicina.

Congratulazioni per aver completato questo progetto di prova. Le competenze acquisite sono state validate analizzando una soluzione di esempio esistente e progettando un'architettura migliorata.

Passaggi successivi suggeriti

Gli esercizi completati sono un ottimo inizio, ma non riguardano tutti gli aspetti di un carico di lavoro cruciale. Continuare a esplorare i principi e le aree di progettazione forniti in carichi di lavoro di importanza cruciale di Well-Architected. È consigliabile usare queste aree chiave per i valori:

  • Convalida e test continui

    È necessario convalidare completamente la salute del codice dell'applicazione e dell'infrastruttura. L'ambito deve coprire i requisiti di affidabilità, prestazioni, disponibilità, sicurezza, qualità e dimensioni.

    Altre informazioni: Convalida e test continui

  • Usare più ambienti applicativi

    È consigliabile che gli ambienti di sviluppo/test non convidino le risorse con l'ambiente di produzione. Ogni ambiente ha i propri requisiti di affidabilità, capacità e sicurezza. È possibile identificare i servizi di questa architettura che sono condivisi tra gli ambienti? Come si modificherà la progettazione in modo che sia allineata a questa raccomandazione?

    Altre informazioni: Ambienti applicazione

  • Ambienti di distribuzione ampliati

    I sistemi cruciali richiedono rigorosi test preliminari e procedure solide del ciclo di vita dello sviluppo software (SDLC). Anziché un singolo ambiente di sviluppo condiviso, è possibile usare più ambienti temporanei più strettamente allineati alla gestione temporanea e alla produzione. È consigliabile usare un ambiente di staging dedicato per test di carico e prestazioni, test di chaos, test di accettazione utente (UAT) e test di sicurezza.

    Altre informazioni: Distribuzioni temporanee blu/verde

  • Aggiungere resilienza con broker di messaggi

    Introdurre un broker di messaggi per semplificare le transazioni complesse che richiedono il coordinamento con più endpoint. Le richieste possono essere accodate per l'elaborazione invece di rischiare la perdita di una vendita a causa di un singolo errore del componente.

    Altre informazioni: Architettura basata su eventi ad accoppiamento debole

Altre informazioni

Per altre informazioni sulla progettazione di soluzioni in Azure, vedere la guida di Azure Well-Architected Framework.

Esplorare queste architetture di riferimento nel Centro architetture di Azure come modo per espandere la progettazione: