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 è un impegno una tantum. È un processo in corso. Aspettatevi modifiche alle prestazioni man mano che cambiano le funzionalità. Esistono varianza nei modelli utente e nei profili, anche le modifiche apportate dalle ottimizzazioni in altri pilastri di Azure Well-Architected. Qualsiasi modifica può filtrare le risorse del carico di lavoro.
Cassaforte guarda il sistema dalle modifiche in modo che non torni indietro sugli obiettivi di 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 dell'ambiente di 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 diverse fasi. 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 di prestazioni di routine automatizzati che valutano latenza, livelli di stress, capacità di carico e altre caratteristiche definite nei piani di test.
Il monitoraggio deve essere parte integrante di tale sforzo, invece di essere un esercizio isolato. È possibile vedere come il sistema e le relative risorse eseguono nel tempo. È quindi possibile ottimizzarli per massimizzare il valore e assicurarsi che continuino a soddisfare gli standard di prestazioni.
Tenere presente che gli obiettivi di 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 reimpostare le aspettative con gli stakeholder aziendali.
Scenario di esempio
Contoso Event Solutions offre un prodotto che il personale dell'ingresso di eventi può usare per analizzare i biglietti su un dispositivo mobile e consentire rapidamente l'ingresso a un luogo ticket per quelli autorizzati. Il sistema è disponibile sia in modalità completamente offline che come versione connessa al cloud per le sedi preoccupate per la duplicazione dei ticket. La modalità offline è altamente efficiente, ma la modalità online mancava dei relativi obiettivi di prestazioni. Il team di sviluppo ha recentemente investito un paio di cicli di sviluppo per lavorare su di esso e ora le prestazioni sono notevolmente migliorate e soddisfano gli obiettivi. Gli stakeholder aziendali vogliono espandere la propria base clienti per supportare presto sedi più grandi.
Testare le prestazioni nello sviluppo
Formalizzare i test delle prestazioni come controlli di qualità che possono approvare o negare la promozione del rilascio e la distribuzione finale nell'ambiente di produzione.
Questi checkpoint assicurano che ogni fase della distribuzione soddisfi gli standard di prestazioni necessari prima di procedere con quella successiva. I checkpoint consentono di evitare la regressione imprevista delle prestazioni. Ad esempio, se le prestazioni sono significativamente inferiori alle aspettative, è possibile bloccare una versione fino a quando non vengono apportati miglioramenti.
Sfida di Contoso
- Il team ha investito molto tempo e impegno per ottenere 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 un luogo di acconsentire esplicitamente alla visualizzazione di un'immagine del partecipante insieme all'analisi per una verifica aggiuntiva. C'è il rischio che la ricerca e il download di foto aggiuntivi rallentano il processo.
- Senza un processo formale, c'è il rischio che le prestazioni delle versioni online e offline potrebbero essere influenzate negativamente dalle funzionalità aggiuntive e possono scendere al di sotto dei loro obiettivi.
Applicazione dell'approccio e dei 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 con una regressione delle prestazioni.
- Il team è stato saggio di implementare questo test, perché ha rilevato un bug nella versione più recente della build. Il bug ha costretto l'app a tentare di connettersi a Internet per scaricare un'immagine mentre lo scanner è stato impostato sulla modalità offline, causando un timeout con ogni analisi del ticket. Rilevare questo bug con il test automatizzato ha consentito al team di correggere il bug prima di rilasciare la nuova versione.
Ottimizzare attraverso l'osservabilità
Configurare un processo ripetibile per il monitoraggio delle transazioni reali in produzione e deviazioni rispetto agli obiettivi di prestazioni. Inoltre, usare transazioni sintetiche nell'ambiente di produzione e configurare avvisi di monitoraggio sulle regressioni delle prestazioni.
Si vogliono ottenere informazioni dettagliate sulle prestazioni effettive del sistema con 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 usano la convalida dei ticket online, viene usato molto il sistema back-end.
- È disponibile un sistema di monitoraggio delle prestazioni delle applicazioni (APM), ma non è stato usato per monitorare l'integrità delle transazioni di produzione.
Applicazione dell'approccio e dei risultati
- Il team ha deciso di adottare processi aggiornati per acquisire meglio le metriche di integrità:
- Configurano gli avvisi in base ai percentili delle prestazioni e agli outlier delle prestazioni. Nessun avviso indica che il sistema esegue intervalli accettabili per la maggior parte delle analisi dei ticket.
- Al termine di un evento offline, i dati di telemetria per le analisi dei ticket vengono caricati in batch e anche queste metriche passano attraverso un processo per cercare le 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
Risolvere l'erosione delle prestazioni man mano che aumentano l'utilizzo, le funzionalità cambiano e i dati si accumulano nel tempo per sostenere le prestazioni. Reimpostare le aspettative e stabilire nuovi obiettivi, se l'ottimizzazione offre solo vantaggi a breve termine.
Adottando questo approccio, è possibile mantenere lo stato delle prestazioni prima che il degrado si sviluppi in problemi che influiscono negativamente sull'esperienza utente oltre l'intervallo accettabile.
La modifica delle destinazioni reimposta il modello di prestazioni e non si perde tempo nell'ottimizzazione del sistema che ha già raggiunto la capacità.
Sfida di Contoso
- Il team di vendita ha eseguito l'onboarding aggressivo di nuovi eventi nel sistema. Il business è buono.
- 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 una modifica, questa traiettoria può portare a una regressione inaccettabile nelle prestazioni, mettendo il carico di lavoro a rischio di subire un'interruzione se si verifica un evento imprevisto.
Applicazione dell'approccio e dei 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 un'analisi molto grande sui dati per molte query.
- Alcune ottimizzazioni delle query hanno consentito di mantenere l'aumento dell'utilizzo da parte di altri danni. Nei prossimi mesi, il team prevede di suddividere diversi eventi in diverse partizioni di dati per ridurre la necessità di analisi delle query. Questo supporterà il continuo aumento del numero di istanze del carico di lavoro.
- Si rendono inoltre conto che possono ottimizzare ulteriormente il sistema per crescere rimuovendo i dati di creazione di ticket dagli eventi precedenti. La ricerca di eventi obsoleti non è un'operazione che deve essere eseguita dal sistema di convalida dei ticket, in modo che i dati possano essere spostati in un archivio dedicato per la creazione di report e la ricerca cronologica.