Ottenere e sostenere le prestazioni
 Proteggersi da una riduzione delle prestazioni mentre il sistema è in uso e man mano che si evolve. |
|---|
Lo sviluppo non rappresenta un impegno una tantum. È un processo continuo. Aspettarsi modifiche alle prestazioni man mano che cambiano le funzionalità. È presente una varianza nei pattern utente e nei profili, persino nelle modifiche apportate dalle ottimizzazioni in altri pilastri di Azure Well-Architected. Qualsiasi modifica può risultare onerosa per risorse del carico di lavoro.
Proteggere il sistema dalle modifiche in modo che non retroceda riguardo i target sulle prestazioni. Integrare test e monitoraggio nel processo di sviluppo. Testare le prestazioni del sistema nell'ambiente di produzione con carico reale e simulare il carico con test automatizzati prima di passare alla produzione. In entrambi i casi, è necessario disporre di procedure di monitoraggio per scopi di verifica.
Durante tutto il ciclo di vita dello sviluppo, eseguire vari tipi di test in fasi differenti. Nelle fasi iniziali testare il modello di verifica per assicurarsi che i risultati delle prestazioni non siano del tutto imprevisti. Man mano che lo sviluppo avanza, eseguire test manuali e a basso sforzo per stabilire benchmark. Nella fase di compilazione iniziare a sviluppare test sulle prestazioni di routine automatizzati che valutino latenza, livelli di stress, capacità di carico e altre caratteristiche definite nei piani di test.
Il monitoraggio deve essere parte integrante di tale impegno, piuttosto che un esercizio isolato. È possibile visualizzare le prestazioni del sistema e delle sue risorse nel tempo. È quindi possibile ottimizzarle per massimizzare il valore e assicurarsi che continuino a soddisfare gli standard di prestazioni.
Tenere presente che i target sulle prestazioni variano nel tempo, in risposta alle modifiche. Aggiornare il modello di prestazioni in base alle metriche testate e monitorate. Indicare chiaramente un aumento, una riduzione o nessun effetto sulle prestazioni dei flussi.
Essere sempre pronti a rinegoziare e ridefinire le aspettative con gli stakeholder aziendali.
Scenario di esempio
Contoso Event Solutions offre un prodotto che il personale addetto all'ingresso di eventi può usare per scansionare i biglietti su un dispositivo mobile e consentire rapidamente l'ingresso alle persone autorizzate agli eventi con biglietto. Il sistema è disponibile sia in modalità completamente offline che come versione connessa al cloud per le sedi di eventi che nutrono preoccupazioni circa la duplicazione dei biglietti. La modalità offline è altamente efficiente, mentre quella online mancava dei relativi target sulle prestazioni. Il team di sviluppo ha di recente investito un paio di cicli di sviluppo per lavorare a questo aspetto e ora le prestazioni sono notevolmente migliorate e soddisfano gli obiettivi. Gli stakeholder aziendali vorrebbero espandere la propria base clienti per supportare a breve sedi più grandi.
Testare le prestazioni nello sviluppo
Formalizzare i test delle prestazioni come controlli di qualità in grado di approvare o negare la promozione al rilascio e il passaggio finale alla produzione.
Questi checkpoint assicurano che ogni fase della distribuzione soddisfi gli standard di prestazioni necessari prima di procedere alla fase successiva. I checkpoint consentono di evitare la regressione imprevista delle prestazioni. Ad esempio, se le prestazioni sono significativamente inferiori alle aspettative, è possibile bloccare un rilascio fino a quando non vengono apportati miglioramenti.
Sfida di Contoso
- Il team ha investito molto tempo e impegno verso il raggiungimento di prestazioni accettabili per la versione online dell'applicazione, ma attualmente non dispone di alcun sistema per impedire una regressione.
- La funzionalità successiva che prevede di aggiungere è la possibilità per una sede di acconsentire esplicitamente al mostrare una foto del partecipante insieme alla scansione per una verifica aggiuntiva. C'è il rischio che la ricerca e il download di foto aggiuntivi rallentino il processo.
- Senza un processo formale, c'è il rischio che le prestazioni delle versioni online e offline siano influenzate negativamente dalla funzionalità aggiuntiva e possano scendere al di sotto dei loro target.
Applicazione dell'approccio e risultati
- Il team integra i test automatizzati delle prestazioni nella pipeline di compilazione. Implementando criteri rigorosi basati sulle prestazioni "go/no-go" nella pipeline di compilazione, il team è più sicuro che la nuova funzionalità non verrà rilasciata in caso di una regressione delle prestazioni.
- Il team è stato saggio a implementare questo test, perché ha rilevato un bug nella versione più recente della build. Il bug costringeva l'app a tentare di connettersi a Internet per scaricare un'immagine mentre lo scanner era impostato sulla modalità offline, causando un timeout a ogni scansione dei biglietti. Rilevare questo bug con il test automatizzato ha consentito al team di eliminarlo prima di rilasciare la nuova versione.
Ottimizzare attraverso l'osservabilità
Configurare un processo ripetibile per il monitoraggio delle transazioni reali nella produzione e delle deviazioni rispetto ai target sulle prestazioni. Inoltre, usare transazioni sintetiche nella produzione e configurare avvisi di monitoraggio sulle regressioni delle prestazioni.
Si desidera ottenere informazioni dettagliate sulle prestazioni effettive del sistema sottoposto a carico reale che non è stato possibile simulare tramite test. È quindi possibile identificare in modo proattivo i problemi e le aree di miglioramento, ad esempio potenziali colli di bottiglia, risorse sottoutilizzate e altre preoccupazioni.
Sfida di Contoso
- Durante un evento in cui si utilizza la convalida dei ticket online, il sistema back-end è soggetto a un utilizzo elevato.
- È disponibile un sistema di monitoraggio delle prestazioni applicative (APM), ma non è stato usato per monitorare l'integrità delle transazioni di produzione.
Applicazione dell'approccio e risultati
- Il team ha deciso di adottare processi aggiornati per acquisire meglio le metriche sull'integrità:
- Configura gli avvisi in base ai percentili delle prestazioni e agli outlier delle prestazioni. Nessun avviso indica che il sistema stia performando a intervalli accettabili per la maggior parte delle scansioni dei ticket.
- Al termine di un evento offline, i dati di telemetria per le scansioni dei biglietti vengono caricati in batch e tali metriche passano attraverso un processo di ricerca di eventuali deviazioni dalle prestazioni accettabili.
- Il team implementa anche test delle transazioni sintetiche per aumentare il monitoraggio delle prestazioni. Poiché quasi tutti gli eventi si svolgono nei fine settimana e la sera, il team usa test delle transazioni sintetiche durante la settimana per generare una baseline di prestazioni più coerente.
Gestire le modifiche del carico di lavoro in modo intelligente
Prendere in esame l'erosione delle prestazioni man mano che l'utilizzo aumenta, le funzionalità cambiano e i dati si accumulano nel tempo per sostenere le prestazioni. Reimpostare le aspettative e stabilire nuovi target, se l'ottimizzazione offre solo vantaggi a breve termine.
Adottando questo approccio, è possibile mantenere lo stato delle prestazioni prima che il degrado diventi un problema che influisce negativamente sull'esperienza utente oltre l'intervallo accettabile.
La modifica delle destinazioni reimposta il modello di prestazioni, per cui non si perde tempo nell'ottimizzazione del sistema che ha già raggiunto la propria capacità.
Sfida di Contoso
- Il team di vendita ha eseguito l'onboarding aggressivo di nuove sedi di eventi nel sistema. Gli affari vanno bene.
- Il sistema di monitoraggio del carico di lavoro ha iniziato a notare che il budget delle prestazioni viene consumato sempre di più nel tempo, anche senza l'introduzione di nuove funzionalità.
- Senza un cambiamento, questa tendenza può portare a una regressione inaccettabile nelle prestazioni, mettendo il carico di lavoro a rischio di subire un'interruzione se si verifica un incidente.
Applicazione dell'approccio e risultati
- Il team si rende conto che, man mano che più clienti eseguono l'onboarding, il meccanismo di ricerca dei dati per gli eventi online esegue una scansione molto grande sui dati per molte query.
- Alcune ottimizzazioni delle query hanno consentito di impedire all'aumento dell'utilizzo di causare altri danni. Nei prossimi mesi, il team prevede di suddividere diversi eventi in varie partizioni di dati per ridurre la necessità di scansione delle query. Ciò supporterà il continuo aumento del carico di lavoro.
- Si rende inoltre conto di poter ottimizzare ulteriormente l'espansione del sistema rimuovendo i dati sui biglietti dagli eventi passati. La ricerca di eventi obsoleti non è un'operazione che dovrebbe essere eseguita dal sistema di convalida dei biglietti, in modo che sia possibile trasferire i dati in un archivio dedicato per la creazione di report e la ricerca cronologica.