Distribuzione e test per carichi di lavoro cruciali in Azure

Le distribuzioni non riuscite e le versioni errate sono cause comuni di interruzioni dell'applicazione. L'approccio alla distribuzione e ai test svolge un ruolo fondamentale nell'affidabilità complessiva di un'applicazione mission-critical.

La distribuzione e i test devono costituire la base per tutte le operazioni dell'applicazione e dell'infrastruttura per garantire risultati coerenti per i carichi di lavoro cruciali. Prepararsi a distribuire settimanalmente, ogni giorno o più spesso. Progettare le pipeline di integrazione continua e distribuzione continua (CI/CD) per supportare tali obiettivi.

La strategia deve implementare:

• Test rigorosi prima del rilascio. Gli aggiornamenti non devono introdurre difetti, vulnerabilità o altri fattori che potrebbero compromettere l'integrità delle applicazioni.

• Distribuzioni trasparenti. Dovrebbe essere possibile implementare gli aggiornamenti in qualsiasi momento senza influire sugli utenti. Gli utenti devono essere in grado di continuare le interazioni con l'applicazione senza interruzioni.

• Operazioni a disponibilità elevata. I processi e gli strumenti di distribuzione e test devono essere a disponibilità elevata per supportare l'affidabilità complessiva delle applicazioni.

• Processi di distribuzione coerenti. Gli stessi elementi e processi dell'applicazione devono essere usati per distribuire l'infrastruttura e il codice dell'applicazione in ambienti diversi. L'automazione end-to-end è obbligatoria. Gli interventi manuali devono essere evitati perché possono introdurre rischi di affidabilità.

Questa area di progettazione fornisce consigli su come ottimizzare i processi di distribuzione e test con l'obiettivo di ridurre al minimo i tempi di inattività e mantenere l'integrità e la disponibilità delle applicazioni.

Importante

Questo articolo fa parte della serie di carichi di lavoro mission-critical di Azure Well-Architected Framework. Se non hai familiarità con questa serie, è consigliabile iniziare con Che cos'è un carico di lavoro critico per missione?.

Distribuzione senza tempi di inattività

Per una panoramica della distribuzione senza tempi di inattività, vedere il video seguente.

Raggiungere implementazioni senza tempi di inattività è un obiettivo fondamentale per le applicazioni di importanza critica. L'applicazione deve essere disponibile tutto il giorno, ogni giorno, anche quando vengono implementate nuove versioni durante l'orario di ufficio. Investire gli sforzi iniziali per definire e pianificare i processi di distribuzione per prendere decisioni di progettazione chiave, ad esempio se trattare le risorse come temporanee.

Per ottenere una distribuzione senza tempi di inattività, implementare una nuova infrastruttura accanto a quella esistente, testarla accuratamente, trasferire il traffico degli utenti finali, e solo allora dismettere l'infrastruttura precedente. Anche altre procedure, come l'architettura delle unità di scala, sono fondamentali.

Le implementazioni di riferimento Mission-Critical Online e Azure Mission-Critical Connected illustrano questo approccio alla distribuzione, come illustrato in questo diagramma:

Ambienti di applicazione

Per una panoramica delle raccomandazioni per gli ambienti dell'applicazione, vedere il video seguente.

Sono necessari vari tipi di ambienti per convalidare e preparare le operazioni di distribuzione. I tipi hanno funzionalità e cicli di vita diversi. Alcuni ambienti potrebbero riflettere l'ambiente di produzione ed essere di lunga durata e altri potrebbero essere di breve durata e avere meno funzionalità rispetto alla produzione. La configurazione di questi ambienti all'inizio del ciclo di sviluppo consente di garantire agilità, separazione degli asset di produzione e preproduzione e test approfonditi delle operazioni prima del rilascio nell'ambiente di produzione. Tutti gli ambienti devono riflettere il più possibile l'ambiente di produzione, anche se è possibile applicare semplificazioni agli ambienti inferiori in base alle esigenze. Questo diagramma mostra un'architettura essenziale per la missione:

Esistono alcune considerazioni comuni:

• I componenti non devono essere condivisi tra ambienti. Le possibili eccezioni sono appliance di sicurezza downstream come firewall e posizioni di origine per i dati di test sintetici.

• Tutti gli ambienti dovrebbero utilizzare infrastruttura come codice (IaC) sotto forma di artefatti come i modelli Terraform o Azure Resource Manager (ARM).

Ambienti di sviluppo

Per informazioni sugli ambienti di sviluppo temporanei e sulla convalida automatica delle funzionalità, vedere il video seguente.

Considerazioni sulla progettazione

• Funzionalità. I requisiti più bassi per l'affidabilità, la capacità e la sicurezza sono accettabili per gli ambienti di sviluppo.

• Ciclo di vita. Gli ambienti di sviluppo devono essere creati in base alle esigenze ed esistono per un breve periodo di tempo. I cicli di vita più brevi consentono di evitare la deriva della configurazione dalla codebase e ridurre i costi. Inoltre, gli ambienti di sviluppo spesso condividono il ciclo di vita di un ramo di funzionalità.

• Densità. I team necessitano di più ambienti per supportare lo sviluppo di funzionalità parallele. Possono coesistere all'interno di una singola sottoscrizione.

Consigli per la progettazione

• Mantenere l'ambiente in una sottoscrizione dedicata con il contesto impostato per scopi di sviluppo.

• Usare un processo automatizzato per distribuire il codice da un ramo di funzionalità a un ambiente di sviluppo.

Ambienti di test o di preproduzione

Questi ambienti vengono usati per il test e la convalida. Vengono eseguiti molti cicli di test per garantire la distribuzione senza bug nell'ambiente di produzione. I test appropriati per un carico di lavoro critico sono descritti nella sezione Convalida e test continui .

Considerazioni sulla progettazione

• Funzionalità. Questi ambienti devono riflettere l'ambiente di produzione per affidabilità, capacità e sicurezza. In assenza di un carico di produzione, usare un carico utente sintetico per fornire metriche realistiche e input prezioso per la modellazione della salute.

• Ciclo di vita. Questi ambienti sono di breve durata. Devono essere eliminati definitivamente dopo il completamento delle convalide dei test.

• Densità. È possibile eseguire molti ambienti indipendenti in una sottoscrizione. È anche consigliabile usare più ambienti, ognuno in una sottoscrizione dedicata.

Annotazioni

Le applicazioni cruciali devono essere sottoposte a test rigorosi.

È possibile eseguire diverse funzioni di test in un singolo ambiente e in alcuni casi sarà necessario. Ad esempio, per il test chaos per ottenere risultati significativi, è prima necessario posizionare l'applicazione sotto carico in modo da poter comprendere in che modo l'applicazione risponde agli errori inseriti. Ecco perché i test di chaos e i test di carico vengono in genere eseguiti in parallelo.

Consigli per la progettazione

• Assicurarsi che almeno un ambiente di staging rifletta completamente la produzione per abilitare test e convalida simili alla produzione. La capacità all'interno di questo ambiente può essere flessibile in base all'esecuzione delle attività di test.

• Generare un carico utente sintetico per fornire un test case realistico per le modifiche in uno degli ambienti.

  Annotazioni

  L'implementazione di riferimento mission critical online fornisce un esempio di generatore di carico utente.

• Definire il numero di ambienti di staging e i relativi scopi all'interno del ciclo di sviluppo e rilascio.

Ambienti di produzione

Considerazioni sulla progettazione

• Funzionalità. Sono necessari i livelli più elevati di affidabilità, capacità e funzionalità di sicurezza per l'applicazione.

• Ciclo di vita. Anche se il ciclo di vita del carico di lavoro e dell'infrastruttura rimane invariato, tutti i dati, inclusi il monitoraggio e la registrazione, richiedono una gestione speciale. Ad esempio, la gestione è necessaria per il backup e il ripristino.

• Densità. Per alcune applicazioni, è possibile prendere in considerazione l'uso di ambienti di produzione diversi per soddisfare diversi client, utenti o funzionalità aziendali.

Consigli per la progettazione

Stabilire un chiaro confine di governance per gli ambienti di produzione e di test. Collocare ogni tipo di ambiente in una sottoscrizione dedicata per conseguire quell'obiettivo. Questa segmentazione garantisce che l'utilizzo delle risorse in ambienti inferiori non influisca sulle quote di produzione. Le sottoscrizioni dedicate impostano anche i limiti di accesso.

Distribuzioni temporanee blu/verde

Un modello di distribuzione blu/verde richiede almeno due distribuzioni identiche. La distribuzione blu è quella attiva che gestisce il traffico utente nell'ambiente di produzione. La distribuzione verde è quella nuova che è stata preparata e testata a ricevere traffico. Al termine e al test della distribuzione verde, il traffico viene gradualmente indirizzato dal blu al verde. Se il trasferimento del carico ha esito positivo, la distribuzione verde diventa la nuova distribuzione attiva. La distribuzione blu precedente può quindi essere rimossa tramite un processo in più fasi. Tuttavia, se si verificano problemi nella nuova distribuzione, può essere interrotto e il traffico può rimanere nella distribuzione blu precedente o essere reindirizzato a esso.

Azure Mission-Critical consiglia un approccio di distribuzione blu/verde in cui l'infrastruttura e le applicazioni vengono distribuite insieme come parte di un timbro di distribuzione. Di conseguenza, l'implementazione di una modifica all'infrastruttura o all'applicazione comporta sempre una distribuzione verde che contiene entrambi i livelli. Questo approccio consente di testare e convalidare completamente l'effetto della modifica rispetto all'infrastruttura e all'applicazione end-to-end prima di reindirizzare il traffico utente a esso. L'approccio aumenta la probabilità di rilasciare le modifiche e consente aggiornamenti senza tempi di inattività perché è possibile convalidare le compatibilità con dipendenze downstream come la piattaforma Azure, i provider di risorse e i moduli IaC.

Considerazioni sulla progettazione

• Funzionalità tecnologiche. Sfruttare le funzionalità di distribuzione predefinite nei servizi di Azure. Il servizio app di Azure, ad esempio, fornisce slot di distribuzione secondari che possono essere scambiati dopo una distribuzione. Con il servizio Azure Kubernetes è possibile usare una distribuzione di pod separata in ogni nodo e aggiornare la definizione del servizio.

• Durata della distribuzione. Il completamento della distribuzione potrebbe richiedere più tempo perché lo stamp contiene l'infrastruttura e l'applicazione anziché solo il componente modificato. Ciò, tuttavia, è accettabile perché il rischio che tutti i componenti non funzionino come previsto sostituiscono i problemi relativi al tempo.

• Impatto dei costi. È previsto un costo aggiuntivo a causa delle due implementazioni affiancate, che devono coesistere fino al completamento della distribuzione.

• Transizione del traffico. Dopo la convalida della nuova distribuzione, il traffico deve essere passato dall'ambiente blu a quello verde. Questa transizione richiede l'orchestrazione del traffico utente tra gli ambienti. La transizione deve essere completamente automatizzata.

• Ciclo di vita. I francobolli di distribuzione cruciali devono essere considerati temporanei. L'uso di timbri di breve durata crea un nuovo punto di partenza ogni volta, prima della distribuzione delle risorse disponibili.

Consigli per la progettazione

• Adottare un approccio di distribuzione blu/verde per rilasciare tutte le modifiche di produzione. Distribuire l'infrastruttura e l'applicazione ogni volta, per qualsiasi modifica, per garantire uno stato coerente e azzerare il tempo di inattività. Anche se è possibile riutilizzare gli ambienti, non è consigliabile per carichi di lavoro cruciali. Trattare ogni tag di distribuzione regionale come effimero, con un ciclo di vita legato a quello di un singolo rilascio.

• Usare un servizio di bilanciamento del carico globale, ad esempio Frontdoor di Azure, per orchestrare la transizione automatica del traffico utente tra gli ambienti blu e verde.

• Per eseguire la transizione del traffico, aggiungere un endpoint back-end verde che utilizzi una bassa percentuale di traffico, come ad esempio il 10%. Dopo aver verificato che il volume di traffico ridotto nella distribuzione verde funzioni e fornisca lo stato di integrità atteso dell'applicazione, aumentare gradualmente il traffico. Durante quest'operazione, applicare un breve periodo di rodaggio per rilevare gli errori che potrebbero non essere immediatamente evidenti.

  Una volta effettuata la transizione di tutto il traffico, rimuovere il back-end blu dalle connessioni esistenti. Ad esempio, rimuovere il back-end dal servizio di bilanciamento del carico globale, svuotare le code e scollegare altre associazioni. In questo modo è possibile ottimizzare i costi di gestione dell'infrastruttura di produzione secondaria e assicurarsi che i nuovi ambienti siano privi di deviazione della configurazione.

  A questo punto, dismettere l'ormai inattivo vecchio ambiente blu. Per la distribuzione successiva, ripetere il processo con il blu e il verde invertiti.

Implementazione a livello di sottoscrizione

A seconda dei requisiti di scalabilità dell'applicazione, potrebbero essere necessarie più sottoscrizioni di produzione da usare come unità di scala.

Vedere il video seguente per ottenere una panoramica delle raccomandazioni per la definizione dell'ambito delle sottoscrizioni per un'applicazione mission-critical.

Considerazioni sulla progettazione

• Scalabilità. Per scenari di applicazioni su larga scala con volumi significativi di traffico, progettare la soluzione per la scalabilità tra più sottoscrizioni di Azure in modo che i limiti di scalabilità di una singola sottoscrizione non vincolano la scalabilità.

  Importante

  L'uso di più sottoscrizioni richiede una complessità CI/CD aggiuntiva, che deve essere gestita in modo appropriato. È pertanto consigliabile usare più sottoscrizioni solo in scenari di scalabilità estrema, in cui è probabile che i limiti di una singola sottoscrizione diventino un limite.

• Limiti dell'ambiente. Distribuire ambienti di produzione, sviluppo e test in sottoscrizioni separate. Questa procedura garantisce che gli ambienti inferiori non contribuiscano ai limiti di scalabilità. Riduce inoltre il rischio di aggiornamenti dell'ambiente inferiore che inquinano la produzione fornendo un chiaro limite di gestione e identità.

• Governance. Quando sono necessarie più sottoscrizioni di produzione, è consigliabile usare un gruppo di gestione delle applicazioni dedicato per semplificare l'assegnazione dei criteri tramite un limite di aggregazione dei criteri.

Consigli per la progettazione

• Distribuire ogni istanza regionale di distribuzione in una sottoscrizione dedicata per garantire che i limiti della sottoscrizione si applichino solo all'interno del contesto di una singola istanza di distribuzione e non nell'intera applicazione. Se appropriato, è consigliabile usare più indicatori di distribuzione all'interno di una singola area, ma è consigliabile distribuirli tra sottoscrizioni indipendenti.

• Inserire le risorse condivise globali in una sottoscrizione dedicata per abilitare la distribuzione coerente delle sottoscrizioni a livello di area. Evitare di usare una distribuzione specializzata per l'area primaria.

Convalida e test continui

Il test è un'attività critica che consente di convalidare completamente l'integrità del codice e dell'infrastruttura dell'applicazione. In particolare, i test consentono di soddisfare gli standard per affidabilità, prestazioni, disponibilità, sicurezza, qualità e scalabilità. I test devono essere ben definiti e applicati come parte della progettazione dell'applicazione e della strategia DevOps. Il test è un problema fondamentale durante il processo di sviluppo locale (il ciclo interno) e come parte del ciclo di vita DevOps completo (ciclo esterno), ovvero quando il codice inizia nel percorso dai processi della pipeline di rilascio verso l'ambiente di produzione.

Per una panoramica della convalida e dei test continui, vedere il video seguente.

Questa sezione è incentrata sul test del ciclo esterno. Descrive vari tipi di test.

Prova	Descrizione
Test unitario	Conferma che la logica di business dell'applicazione funziona come previsto. Convalida l'effetto complessivo delle modifiche al codice.
Test di fumo	Identifica se i componenti dell'infrastruttura e dell'applicazione sono disponibili e funzionano come previsto. In genere, viene testata solo una singola sessione utente virtuale. Il risultato dovrebbe essere che il sistema risponde con i valori e il comportamento previsti. Gli scenari comuni di smoke testing includono il raggiungimento dell'endpoint HTTPS di un'applicazione Web, l'esecuzione di query su un database e la simulazione di un flusso utente nell'applicazione.
Test dell'interfaccia utente	Verifica che le interfacce utente dell'applicazione vengano distribuite e che le interazioni dell'interfaccia utente funzionino come previsto. È consigliabile usare gli strumenti di automazione interfaccia utente per favorire l'automazione. Durante un test dell'interfaccia utente, uno script deve simulare uno scenario utente realistico e completare una serie di passaggi per eseguire azioni e ottenere un risultato previsto.
Test di carico	Convalida la scalabilità e l'operazione dell'applicazione aumentando rapidamente il carico e/o gradualmente fino a raggiungere una soglia predeterminata. I test di carico vengono in genere progettati intorno a un flusso utente specifico per verificare che i requisiti dell'applicazione siano soddisfatti con un carico definito.
Test di stress	Applica attività che sovraccaricano le risorse esistenti per determinare i limiti della soluzione e verificare la capacità del sistema di riprendersi in modo efficace. L'obiettivo principale è identificare potenziali colli di bottiglia delle prestazioni e limiti di scalabilità. Al contrario, ridurre le risorse di calcolo del sistema e monitorare il comportamento in fase di caricamento e determinare se può essere ripristinato.
Test delle prestazioni	Combina gli aspetti dei test di carico e stress per convalidare le prestazioni sotto carico e stabilire comportamenti di benchmark per l'operazione dell'applicazione.
Test chaos	Inserisce errori artificiali nel sistema per valutare il modo in cui reagisce e per convalidare l'efficacia delle misure di resilienza, delle procedure operative e delle mitigazioni. L'arresto dei componenti dell'infrastruttura, la riduzione delle prestazioni e l'introduzione di errori dell'applicazione sono esempi di test che possono essere usati per verificare che l'applicazione reagisca come previsto quando si verificano effettivamente gli scenari.
Test di penetrazione	Garantisce che un'applicazione e il relativo ambiente soddisfino i requisiti di un comportamento di sicurezza previsto. L'obiettivo è identificare le vulnerabilità di sicurezza. I test di sicurezza possono includere dipendenze end-to-end della supply chain e del pacchetto del software, con analisi e monitoraggio per vulnerabilità ed esposizioni comuni note (CVE).

Considerazioni sulla progettazione

• Automazione. I test automatizzati sono essenziali per convalidare le modifiche all'applicazione o all'infrastruttura in modo tempestivo e ripetibile.

• Ordine di test. L'ordine in cui vengono eseguiti i test è una considerazione critica a causa di varie dipendenze, ad esempio la necessità di avere un ambiente dell'applicazione in esecuzione. La durata del test influenza anche l'ordine. I test con tempi di esecuzione più brevi devono essere eseguiti in precedenza nel ciclo quando possibile per aumentare l'efficienza dei test.

• Limiti di scalabilità. I servizi di Azure hanno limiti flessibili e rigidi diversi. Provare a usare i test di carico per determinare se un sistema rischia di superarli durante il carico di produzione previsto. Il test di carico può essere utile anche per impostare soglie appropriate per la scalabilità automatica. Per i servizi che non supportano la scalabilità automatica, i test di carico consentono di ottimizzare le procedure operative automatizzate.

  L'impossibilità dei componenti di sistema, ad esempio componenti di rete attivi/passivi o database, di ridimensionare in modo appropriato può essere restrittiva. I test di stress possono aiutare a identificare le limitazioni.

• Analisi della modalità di errore. L'introduzione di errori nell'applicazione e nell'infrastruttura sottostante e la valutazione dell'effetto è essenziale per valutare i meccanismi di ridondanza della soluzione. Durante questa analisi, identificare il rischio, l'impatto e l'ampiezza dell'impatto (interruzione parziale o completa). Per un'analisi di esempio creata per l'implementazione di riferimento mission critical online , vedere Rischi di interruzione dei singoli componenti.

• Monitoraggio. È necessario acquisire e analizzare i risultati dei test singolarmente e aggregarli anche per valutare le tendenze nel tempo. È consigliabile valutare continuamente i risultati dei test per l'accuratezza e la copertura.

Consigli per la progettazione

Vedere il video seguente per vedere come integrare i test di resilienza con le pipeline CI/CD di Azure DevOps.

• Garantire la coerenza automatizzando tutti i test sui componenti dell'infrastruttura e dell'applicazione. Integrare i test nelle pipeline CI/CD per orchestrarli ed eseguirli, se applicabile. Per informazioni sulle opzioni tecnologiche, vedere Strumenti DevOps.

• Considerare tutti gli artefatti di test come codice. Devono essere mantenuti e controllati attraverso il controllo di versione insieme ad altri artefatti di codice dell'applicazione.

• Allineare il contratto di servizio dell'infrastruttura di test al contratto di servizio per i cicli di distribuzione e test.

• Esegui test di smoke come parte di ogni implementazione. Eseguire anche test di carico estesi insieme a test di stress e chaos per verificare che le prestazioni e l'operabilità dell'applicazione vengano mantenute.

  • Usare i profili di caricamento che riflettono i modelli di utilizzo di picco reali.
  • Eseguire esperimenti di caos e test di inserimento degli errori contemporaneamente ai test di carico.

  Suggerimento

  Azure Chaos Studio è una suite nativa di strumenti di sperimentazione chaos. Gli strumenti semplificano l'esecuzione di esperimenti chaos e l'inserimento di errori all'interno di servizi e componenti dell'applicazione di Azure.

  Chaos Studio offre esperimenti chaos predefiniti per scenari di errore comuni e supporta esperimenti personalizzati destinati all'infrastruttura e ai componenti dell'applicazione.

• Se le interazioni del database, come la creazione di record, sono necessarie per i test di carico o fumo, usare account di test con privilegi ridotti e rendere i dati di test separabili dal contenuto utente reale.

• Analizzare e monitorare la catena di fornitura del software end-to-end e le dipendenze dei pacchetti per le vulnerabilità note (CVE).

  • Usare Dependabot per i repository GitHub per assicurarsi che il repository sia aggiornato automaticamente con le versioni più recenti di pacchetti e applicazioni da cui dipende.

Infrastruttura come distribuzioni di codice

L'infrastruttura come codice (IaC) tratta le definizioni dell'infrastruttura come codice sorgente, gestite tramite controllo di versione insieme ad altri artefatti dell'applicazione. L'uso di IaC promuove la coerenza del codice tra ambienti, elimina il rischio di errori umani durante le distribuzioni automatizzate e offre tracciabilità e rollback. Per le distribuzioni blu/verde, l'uso di IaC con distribuzioni completamente automatizzate è imperativo.

Un repository IaC di importanza fondamentale contiene due definizioni distinte mappate alle risorse globali e regionali. Per informazioni su questi tipi di risorse, vedere il modello di architettura principale.

Considerazioni sulla progettazione

• Infrastruttura ripetibile. Distribuire carichi di lavoro cruciali in modo da generare lo stesso ambiente ogni volta. IaC deve essere il modello primario.

• Automazione. Tutte le distribuzioni devono essere completamente automatizzate. I processi umani sono soggetti a errori.

Consigli per la progettazione

• Applicare IaC, assicurandosi che tutte le risorse di Azure siano definite nei modelli dichiarativi e mantenute in un repository di controllo del codice sorgente. I template vengono distribuiti e le risorse vengono fornite automaticamente dal controllo del codice sorgente tramite pipeline CI/CD. Non è consigliabile usare script imperativi.

• Impedire operazioni manuali su tutti gli ambienti. L'unica eccezione è ambienti di sviluppo completamente indipendenti.

Strumenti DevOps

L'uso efficace degli strumenti di distribuzione è fondamentale per l'affidabilità complessiva perché i processi DevOps influiscono sulla funzione complessiva e sulla progettazione delle applicazioni. Ad esempio, le operazioni di failover e scalabilità possono dipendere dall'automazione fornita dagli strumenti DevOps. I team di progettazione devono comprendere l'effetto dell'indisponibilità di un servizio di distribuzione rispetto al carico di lavoro complessivo. Gli strumenti di distribuzione devono essere affidabili e a disponibilità elevata.

Microsoft offre due set di strumenti nativi di Azure, GitHub Actions e Azure Pipelines, in grado di distribuire e gestire in modo efficace un'applicazione mission-critical.

Considerazioni sulla progettazione

• Funzionalità tecnologiche. Le funzionalità di GitHub e Azure DevOps si sovrappongono. È possibile usarli insieme per ottenere il meglio di entrambi. Un approccio comune consiste nell'archiviare i repository di codice in GitHub.com o in GitHub AE durante l'uso di Azure Pipelines per la distribuzione.

  Tenere presente la complessità aggiunta quando si usano più tecnologie. Valutare un set di funzionalità avanzato rispetto all'affidabilità complessiva.

• Disponibilità a livello di area. In termini di affidabilità massima, la dipendenza da una singola area di Azure rappresenta un rischio operativo.

  Si supponga, ad esempio, che il traffico venga distribuito in due aree: Area 1 e Area 2. L'area 2 ospita l'istanza degli strumenti di Azure DevOps. Supponiamo che ci sia un'interruzione nella Regione 2 e che l'istanza non sia disponibile. L'area 1 gestisce automaticamente tutto il traffico e deve distribuire unità di scala aggiuntive per offrire un'esperienza di failover ottimale. Ma non sarà possibile a causa della dipendenza di Azure DevOps nell'area 2.

• Replica dei dati. I dati, inclusi metadati, pipeline e codice sorgente, devono essere replicati tra aree.

Consigli per la progettazione

• Entrambe le tecnologie sono ospitate in una singola area di Azure, che potrebbe rendere restrittiva la strategia di ripristino di emergenza.

  GitHub Actions è particolarmente adatto per le attività di compilazione (integrazione continua), ma potrebbe non avere funzionalità per attività di distribuzione complesse (distribuzione continua). Dato il set avanzato di funzionalità di Azure DevOps, è consigliabile per le distribuzioni cruciali. Tuttavia, è consigliabile scegliere dopo aver valutato i compromessi.

• Definire un contratto di servizio di disponibilità per gli strumenti di distribuzione e garantire l'allineamento ai requisiti di affidabilità delle applicazioni più ampi.

• Per gli scenari in più aree che usano una configurazione di distribuzione attiva/passiva o attiva/attiva, assicurarsi che le operazioni di orchestrazione e ridimensionamento del failover possano continuare a funzionare anche se l'area primaria che ospita i set di strumenti di distribuzione non è più disponibile.

Strategia di diramazione

Esistono molti approcci validi per la diramazione. È consigliabile scegliere una strategia che garantisce la massima affidabilità. Una buona strategia consente lo sviluppo parallelo, fornisce un chiaro percorso dallo sviluppo all'ambiente di produzione e supporta le versioni rapide.

Considerazioni sulla progettazione

• Ridurre al minimo l'accesso. Gli sviluppatori devono svolgere il proprio lavoro in feature/* e fix/* rami. Questi rami diventano punti di ingresso per le modifiche. Le restrizioni basate sui ruoli devono essere applicate ai rami come parte della strategia di diramazione. Ad esempio, consentire solo agli amministratori di creare branche di rilascio o imporre convenzioni di denominazione per i rami.

• Processo accelerato per le emergenze. La strategia di diramazione deve consentire l'unione di hotfix in main non appena possibile. In questo modo, le versioni future contengono la correzione e la ricorrenza del problema viene evitata. Utilizzare questo processo solo per piccole modifiche che risondono problemi urgenti e usarlo con moderazione.

Consigli per la progettazione

• Classificare in ordine di priorità l'uso di GitHub per il controllo del codice sorgente.

  Importante

  Creare una strategia di diramazione che dettagli, al minimo, il lavoro sulle feature e le versioni, e implementare criteri e autorizzazioni dei branch per garantire che la strategia venga applicata in modo appropriato.

• Attivare un processo di test automatizzato per convalidare i contributi di modifica del codice prima che vengano accettati. Anche i membri del team devono esaminare le modifiche.

• Trattare il main ramo come un ramo costantemente avanzante e stabile, utilizzato principalmente per i test di integrazione.

  • Assicurarsi che le modifiche vengano apportate a main solo tramite pull request. Usare un criterio di branch per impedire commit diretti.
  • Ogni qualvolta una richiesta pull viene unita in main, deve avviare automaticamente un processo di distribuzione in un ambiente di integrazione.
  • Il main ramo deve essere considerato stabile. Dovrebbe essere sicuro creare una versione da main in qualsiasi momento.

• Usare rami dedicati release/* che sono creati dal ramo main e usati per distribuire negli ambienti di produzione. release/* i rami devono rimanere nel repository e possono essere usati per applicare patch a una versione.

• Documentare un processo hotfix e usarlo solo quando necessario. Creare correzioni urgenti in un fix/* ramo per la successiva fusione nel ramo di rilascio e per il rilascio in produzione.

Intelligenza artificiale per DevOps

È possibile applicare metodologie AIOps nelle pipeline CI/CD per integrare gli approcci di test tradizionali. In questo modo è possibile rilevare potenziali regressioni o riduzioni e consentire alle distribuzioni di essere arrestate in modo preemptive per evitare potenziali impatti negativi.

Considerazioni sulla progettazione

• Volume di dati di telemetria. Le pipeline CI/CD e i processi DevOps generano un'ampia gamma di dati di telemetria per i modelli di Machine Learning. I dati di telemetria vanno dai risultati di test e distribuzione ai dati operativi per quanto riguarda i componenti di test nelle fasi di distribuzione composte.

• Scalabilità. Gli approcci tradizionali per l'elaborazione dei dati, ad esempio Extract, Transform, Load (ETL) potrebbero non essere in grado di ridimensionare la velocità effettiva per mantenere il passo con la crescita dei dati di telemetria della distribuzione e dell'osservabilità delle applicazioni. È possibile usare approcci di analisi moderni che non richiedono ETL e lo spostamento dei dati, ad esempio la virtualizzazione dei dati, per abilitare l'analisi continua da parte dei modelli AIOps.

• Modifiche alla distribuzione. Le modifiche nella distribuzione devono essere archiviate per l'analisi automatizzata e la correlazione ai risultati della distribuzione.

Consigli per la progettazione

• Definire i dati del processo DevOps da raccogliere e come analizzarli. La telemetria, ad esempio le metriche di esecuzione dei test e i dati delle serie temporali delle modifiche all'interno di ogni distribuzione, è importante.

  • Esporre i dati di osservabilità delle applicazioni dagli ambienti di staging, test e produzione per l'analisi e la correlazione all'interno dei modelli AIOps.

• Adottare il flusso di lavoro MLOps.

• Sviluppare modelli analitici con riconoscimento del contesto e con riconoscimento delle dipendenze per fornire stime con progettazione automatizzata delle funzionalità per gestire le modifiche dello schema e del comportamento.

• Rendere operativi i modelli registrando e distribuendo i modelli meglio addestrati all'interno delle pipeline di deployment.

Passo successivo

Esaminare le considerazioni sulla sicurezza.

sicurezza