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à.
Il processo di revisione
La revisione delle architetture va eseguita in modo coerente, con un approccio che non colpevolizza nessuno, ma che incoraggia ad approfondire gli argomenti. Dovrebbe essere un processo leggero (di ore, non di giorni) più simile a una conversazione che non a un audit. Lo scopo della revisione di un'architettura è identificare dei problemi critici da affrontare o aree di miglioramento. Il risultato della revisione è un insieme di azioni volte a migliorare l'esperienza di utilizzo del carico di lavoro del cliente.
Come discusso nella sezione "Architettura", ogni membro del team deve prendersi la responsabilità della qualità della sua architettura. Consigliamo che i membri del team che hanno sviluppato l'architettura usino il Framework Well-Architected per eseguire costantemente la revisione della loro architettura, piuttosto che fare una riunione di revisione formale. Un approccio quasi continuo permette ai membri del team di aggiornare le risposte man mano che l'architettura evolve e migliorare l'architettura di pari passo alle funzionalità.
Il AWS Well-Architected Framework è allineato al modo in cui esamina sistemi e servizi AWS internamente. Si basa su una serie di principi di progettazione che influenzano l'approccio architettonico e su domande volte a verificare che le persone non trascurino le aree spesso presenti in Root Cause Analysis (). RCA Ogni volta che si verifica un problema significativo con un sistema, un AWS servizio o un cliente interno, lo esaminiamo RCA per vedere se possiamo migliorare i processi di revisione che utilizziamo.
Le revisioni vanno applicate nelle tappe fondamentali del ciclo di vita del prodotto, nelle prime fasi di progettazione per evitare porte a un senso difficili da cambiare e prima della data di lancio. Molte decisioni sono porte reversibili a doppio senso e possono utilizzare un processo leggero. Le porte a un senso sono difficili o impossibili da invertire e richiedono ulteriori ispezioni prima della loro realizzazione. Una volta entrato in produzione, il carico di lavoro continuerà ad evolversi man mano che si aggiungono nuove funzionalità e si modificano le implementazioni tecnologiche. L'architettura del carico di lavoro cambia nel tempo. Devi seguire le best practice di igiene informatica per interrompere il degrado delle caratteristiche man mano che fai evolvere l'architettura. Man mano che l'architettura cambia, dovresti seguire un insieme di processi di igiene informatica tra cui la revisione Well-Architected.
Se vuoi utilizzare la revisione come snapshot una tantum o misura indipendente, dovrai verificare che alla conversazione partecipino tutte le persone appropriate. Spesso ci rendiamo conto che le revisioni sono il primo momento in cui il team comprende per davvero quello che ha implementato. Un approccio che funziona bene per la revisione dei carichi di lavoro di un altro team consiste in una serie di conversazioni informali sull'architettura in cui ottenere le risposte alla maggior parte delle domande. Quindi puoi fare una o due riunioni di follow up in cui puoi fare chiarezza o approfondire le aree ambigue e il rischio percepito.
Ecco alcuni elementi suggeriti per le tue riunioni:
-
Una sala riunioni con una lavagna
-
Le stampe di tutti i grafici o delle note di progettazione
-
Elenco di azioni a cui è necessaria una out-of-band ricerca per rispondere (ad esempio, «abbiamo attivato la crittografia o no?»)
Dopo avere completato la revisione, dovresti avere un elenco di problemi a cui assegnare delle priorità sulla base del contesto aziendale. Dovrai anche tenere conto dell'impatto di tali problemi sul day-to-day lavoro del tuo team. Se affronti questi problemi in anticipo puoi liberare del tempo per lavorare sulla creazione di valore aziendale anziché dedicarlo a risolvere i problemi ricorrenti. Man mano che affronti i problemi, puoi aggiornare la revisione per vedere in che modo l'architettura sta migliorando.
Il valore di una revisione è evidente dopo averne eseguita una, ma all'inizio un nuovo team potrebbe essere contrario. Ecco alcune obiezioni da gestire per istruire il team sui vantaggi di una revisione:
-
"Siamo troppo occupati!" Spesso si sente questa frase quando il team si sta preparando a un grande lancio.
-
Se ti stai preparando per un grande lancio, desidererai che tutto vada bene. La revisione ti permetterà di individuare qualsiasi problema che potresti esserti perso.
-
Ti raccomandiamo di eseguire le revisioni all'inizio del ciclo di vita del prodotto per scoprire i rischi e sviluppare un piano di mitigazione allineato con la roadmap delle funzionalità.
-
-
"Non abbiamo tempo per fare nulla per i risultati!" Spesso questo viene detto quando c'è un evento fisso, come il Super Bowl, di cui si sta occupando il team.
-
Questi eventi non possono essere spostati. Vuoi davvero affrontare l'evento senza conoscere i rischi della tua architettura? Anche se non ti occupi di tutti i problemi in questione, puoi comunque disporre di playbook per affrontarli se si dovessero presentare.
-
-
"Non vogliamo che altri scoprano i segreti della nostra implementazione di soluzioni!"
-
Se poni le domande del Framework Well-Architected, il team noterà che nessuna di esse rivela informazioni proprietarie commerciali o tecniche.
-
Eseguendo più revisioni con i team della tua organizzazione, potresti identificare delle aree tematiche. Ad esempio, potresti notare che un gruppo di team ha gruppi di problemi in un pilastro o un argomento specifico. Puoi gestire tutte le tue revisioni in modo olistico e identificare tutti i meccanismi, la formazione o le riunioni con gli ingegneri responsabili che possono aiutare a risolvere i problemi tematici.
