Distribuzione e test per carichi di lavoro cruciali in Azure

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

La distribuzione e i test devono costituire la base per tutte le operazioni di applicazione e 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 di versioni non definitive. Aggiornamenti non devono introdurre difetti, vulnerabilità o altri fattori che potrebbero compromettere l'integrità dell'applicazione.

• 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. È necessario evitare interventi manuali 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 cruciali di Azure Well-Architected Framework . Se non si ha familiarità con questa serie, è consigliabile iniziare con Che cos'è un carico di lavoro mission-critical?.

Distribuzione senza tempi di inattività

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

Raggiungere distribuzioni senza tempi di inattività è un obiettivo fondamentale per le applicazioni cruciali. 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 guidare decisioni di progettazione chiave, ad esempio se trattare le risorse come temporanee.

Per ottenere una distribuzione senza tempi di inattività, distribuire una nuova infrastruttura accanto all'infrastruttura esistente, testarla accuratamente, eseguire la transizione del traffico degli utenti finali e rimuovere solo le autorizzazioni dell'infrastruttura precedente. Anche altre procedure, come l'architettura dell'unità di scala, sono fondamentali.

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

Ambienti dell'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 capacità 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 cruciale:

Esistono alcune considerazioni comuni:

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

• Tutti gli ambienti devono usare artefatti dell'infrastruttura come codice (IaC), ad esempio Terraform o modelli di 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 relative alla progettazione

• Funzionalità. I requisiti inferiori 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à. Teams necessita di più ambienti per supportare lo sviluppo di funzionalità parallele. Possono coesistere all'interno di una singola sottoscrizione.

Suggerimenti per la progettazione

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

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

Ambienti di test o gestione temporanea

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

Considerazioni relative alla 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 un prezioso input di modellazione dell'integrità.

• 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.

Nota

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 ottenere risultati significativi, è necessario innanzitutto posizionare l'applicazione sotto carico in modo da poter comprendere in che modo l'applicazione risponde agli errori inseriti. Ecco perché i test di caos e i test di carico vengono in genere eseguiti in parallelo.

Suggerimenti per la progettazione

• Assicurarsi che almeno un ambiente di gestione temporanea 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.

  Nota

  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 relative alla 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, incluso il monitoraggio e la registrazione, necessitano di una gestione speciale. Ad esempio, la gestione è necessaria per il backup e il ripristino.

• Densità. Per alcune applicazioni, è consigliabile usare ambienti di produzione diversi per soddisfare diversi client, utenti o funzionalità aziendali.

Suggerimenti per la progettazione

Avere un limite di governance chiaro per gli ambienti di produzione e inferiori. Inserire ogni tipo di ambiente in una sottoscrizione dedicata per raggiungere tale 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 preparata e testata per ricevere il traffico. Al termine e al test della distribuzione verde, il traffico viene gradualmente indirizzato da blu a 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. L'implementazione di una modifica all'infrastruttura o all'applicazione comporta quindi 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 le dipendenze downstream, ad esempio la piattaforma Azure, i provider di risorse e i moduli IaC.

Considerazioni relative alla progettazione

• Funzionalità tecnologiche. Sfruttare le funzionalità di distribuzione predefinite nei servizi di Azure. Ad esempio, Servizio app di Azure fornisce slot di distribuzione secondari che possono essere scambiati dopo una distribuzione. Con servizio Azure Kubernetes (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 distribuzioni side-by-side, 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. Gli indicatori di distribuzione cruciali devono essere considerati temporanei. L'uso di indicatori di breve durata crea un nuovo inizio ogni volta, prima del provisioning delle risorse.

Suggerimenti per la progettazione

• Adottare un approccio di distribuzione blu/verde per rilasciare tutte le modifiche di produzione. Distribuire tutte le infrastrutture e l'applicazione ogni volta, per qualsiasi tipo di modifica, per ottenere uno stato coerente e un tempo di inattività pari a zero. Sebbene sia possibile riutilizzare gli ambienti, non è consigliabile per carichi di lavoro cruciali. Considerare ogni indicatore di distribuzione a livello di area come temporaneo con un ciclo di vita associato a quello di una singola versione.

• 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 usa un traffico basso per il peso del volume, ad esempio il 10%. Dopo aver verificato che il volume di traffico basso nella distribuzione verde funzioni e fornisca l'integrità prevista dell'applicazione, aumentare gradualmente il traffico. In questo caso, applicare un breve periodo di rampa per rilevare gli errori che potrebbero non essere immediatamente evidenti.

  Dopo 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 garantire che i nuovi ambienti siano privi di deviazione della configurazione.

  A questo punto, rimuovere la vecchia e ora inattiva ambiente blu. Per la distribuzione successiva, ripetere il processo con blu e verde invertito.

Distribuzione con ambito sottoscrizione

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

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

Considerazioni relative alla 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 con 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 più bassi non contribuiscano ai limiti di scalabilità. Riduce inoltre il rischio di aggiornamenti dell'ambiente inferiore che inquinano la produzione fornendo una gestione chiara e un limite di identità.

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

Suggerimenti per la progettazione

• Distribuire ogni indicatore di distribuzione a livello di area in una sottoscrizione dedicata per garantire che i limiti della sottoscrizione si applichino solo all'interno del contesto di un singolo timbro 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 (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 versione verso l'ambiente di produzione.

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

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

Test	Descrizione
Testing unità	Conferma che la logica di business dell'applicazione funziona come previsto. Convalida l'effetto complessivo delle modifiche al codice.
Smoke testing	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 deve 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 il carico rapidamente e/o gradualmente fino a quando non viene raggiunta una soglia predeterminata. I test di carico sono 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 le attività che eseguono l'overload delle risorse esistenti per determinare i limiti della soluzione e verificare la capacità del sistema di eseguire il ripristino normalmente. 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 in fase di carico e stabilire comportamenti di benchmark per l'operazione dell'applicazione.
Test di 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	Assicura 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 la supply chain e le dipendenze dei pacchetti software end-to-end, con analisi e monitoraggio per vulnerabilità ed esposizioni comuni note (CVE).

Considerazioni relative alla progettazione

• Automazione. I test automatizzati sono essenziali per convalidare le modifiche dell'applicazione o dell'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. È consigliabile usare i test di carico per determinare se un sistema rischia di superarli durante il carico di produzione previsto. I test di carico possono essere utili 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 consentono di 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 di Mission Critical Online , vedere Rischi di interruzione dei singoli componenti.

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

Suggerimenti 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 dalla versione insieme ad altri artefatti del codice dell'applicazione.

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

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

  • Usare i profili di carico che riflettono modelli di utilizzo di picco reali.
  • Eseguire esperimenti chaos 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 test di carico o smoke test, usare account di test con privilegi ridotti e rendere i dati di test separabili dal contenuto utente reale.

• Analizzare e monitorare la supply chain e le dipendenze dei pacchetti software end-to-end per le cve note.

  • 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) considera le definizioni dell'infrastruttura come codice sorgente controllate 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 fornisce tracciabilità e rollback. Per le distribuzioni blu/verde, l'uso di IaC con distribuzioni completamente automatizzate è fondamentale.

Un repository IaC mission-critical ha due definizioni distinte mappate alle risorse globali e regionali. Per informazioni su questi tipi di risorse, vedere il modello di architettura principale.

Considerazioni relative alla 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.

Suggerimenti per la progettazione

• Applicare IaC, assicurandosi che tutte le risorse di Azure siano definite nei modelli dichiarativi e gestite in un repository del controllo del codice sorgente. I modelli vengono distribuiti e le risorse vengono sottoposte automaticamente a provisioning 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 dell'applicazione. 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 cruciale.

Considerazioni relative alla 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.

  Ad esempio, si supponga che il traffico venga distribuito in due aree: Area 1 e Area 2. Region 2 ospita l'istanza degli strumenti di Azure DevOps. Si supponga che si verifichi un'interruzione nell'area 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 i metadati, le pipeline e il codice sorgente, devono essere replicati tra aree.

Suggerimenti 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 potrebbero non essere disponibili 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 set di strumenti di distribuzione diventa non 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 alla produzione e supporta versioni veloci.

Considerazioni relative alla progettazione

• Ridurre al minimo l'accesso. Gli sviluppatori devono svolgere il proprio lavoro nei rami feature/* e fix/* . 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 agli amministratori di creare rami di versione o applicare 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 pratico. In questo modo, le versioni future contengono la correzione e la ricorrenza del problema viene evitata. Usare questo processo solo per le modifiche minori che affrontano problemi urgenti e usarlo con moderazione.

Suggerimenti 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 descrive in dettaglio il funzionamento e le versioni delle funzionalità come minimo e usare i criteri e le autorizzazioni dei rami 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. I membri del team devono anche esaminare le modifiche.

• Considerare il ramo principale come un ramo in avanti continuo e stabile usato principalmente per i test di integrazione.

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

• Usare rami di rilascio/* dedicati creati dal ramo principale e usati per la distribuzione negli ambienti di produzione. I rami release/* devono rimanere nel repository e possono essere usati per applicare patch a una versione.

• Documentare un processo hotfix e usarlo solo quando necessario. Creare hotfix in un ramo fix/* per l'unione successiva nel ramo di rilascio e nella distribuzione nell'ambiente di 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 delle prestazioni e consentire alle distribuzioni di essere arrestate in modo preemptive per evitare potenziali impatti negativi.

Considerazioni relative alla 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 variano dai risultati dei test e dai risultati della distribuzione ai dati operativi sui componenti di test dalle fasi di distribuzione composita.

• 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 LTL 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.

Suggerimenti 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 da ambienti di gestione temporanea, 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 la progettazione automatica delle funzionalità per risolvere le modifiche dello schema e del comportamento.

• Rendere operativi i modelli registrando e distribuendo i modelli con training migliore all'interno delle pipeline di distribuzione.

Passaggio successivo

Esaminare le considerazioni sulla sicurezza.

Sicurezza