Raccomandazioni per le procedure di distribuzione sicure

  • Articolo

Si applica a questo elenco di controllo di Eccellenza operativa di Azure Well-Architected Framework:

OE:11 Definire chiaramente le procedure di distribuzione sicure del carico di lavoro. Enfatizzare gli ideali dei metodi di rilascio piccoli, incrementali e qualitativi. Usare modelli di distribuzione moderni e tecniche di esposizione progressiva per controllare il rischio. Account per distribuzioni di routine e emergenza, o hotfix, distribuzioni.

Questa guida descrive i consigli per l'uso di procedure di distribuzione sicure (SDP). I processi e le procedure di distribuzione sicuri definiscono come apportare e distribuire in modo sicuro le modifiche al carico di lavoro. L'implementazione di SDP richiede di considerare le distribuzioni attraverso l'obiettivo di gestire i rischi. È possibile ridurre al minimo il rischio di errore umano nelle distribuzioni e limitare gli effetti delle distribuzioni problematiche sugli utenti implementando SDP.

Strategie di progettazione chiave

Esistono quattro linee guida importanti da tenere presente quando si implementano procedure di distribuzione sicure:

  • Sicurezza e coerenza: tutte le modifiche apportate al carico di lavoro di produzione sono intrinsecamente rischiose e devono essere eseguite con un'attenzione alla sicurezza e alla coerenza.

  • Esposizione progressiva: è possibile ridurre al minimo il potenziale raggio di esplosione dei problemi causati dalla distribuzione adottando un modello di distribuzione di esposizione progressiva.

  • Modelli di integrità: le distribuzioni devono superare i controlli di integrità prima che ogni fase di esposizione progressiva possa iniziare.

  • Rilevamento dei problemi: quando vengono rilevati problemi, la distribuzione deve essere interrotta immediatamente e avviata dal ripristino.

Le sezioni seguenti forniscono raccomandazioni dettagliate su ognuno di questi punti.

Sicurezza e coerenza

Indipendentemente dal fatto che si distribuisca un aggiornamento al codice dell'applicazione, all'infrastruttura come codice (IaC), al flag di funzionalità o a un aggiornamento di configurazione, si introduce il rischio per il carico di lavoro. Non sono presenti distribuzioni a basso rischio all'ambiente di produzione. Ogni distribuzione deve seguire un modello standard e deve essere automatizzato per applicare la coerenza e ridurre al minimo il rischio di errore umano. È fondamentale che la catena di fornitura del carico di lavoro e le pipeline di distribuzione siano affidabili, sicure e abbiano chiaramente definito gli standard di distribuzione. Considerare ogni distribuzione come un possibile rischio e sottoporre ogni distribuzione allo stesso livello di gestione dei rischi. Nonostante i rischi, è necessario continuare a distribuire modifiche regolari al carico di lavoro. Se non si distribuiscono aggiornamenti regolari, vengono introdotti altri rischi, ad esempio vulnerabilità di sicurezza che devono essere risolte tramite distribuzioni. Per altre informazioni, vedere Raccomandazioni per la progettazione di una catena di fornitura di carico di lavoro.

Le distribuzioni di piccole dimensioni frequenti sono preferibili a distribuzioni di grandi dimensioni rara. Le piccole modifiche sono più facili da risolvere quando si verificano problemi e le distribuzioni frequenti consentono al team di creare fiducia nel processo di distribuzione. È anche importante apprendere dall'ambiente di produzione esaminando i processi del carico di lavoro quando si verifica un'anomalia durante la distribuzione. È possibile trovare punti deboli nella progettazione dell'infrastruttura o dell'implementazione. Quando si verificano problemi durante le distribuzioni, assicurarsi che i postmorte senza colpa facciano parte del processo SDP per acquisire lezioni sull'evento imprevisto.

Distribuzione progressiva dell'esposizione

Quando si verificano problemi di distribuzione, l'obiettivo consiste nel rilevarli il prima possibile per ridurre al minimo l'effetto sugli utenti finali. Implementare un modello di distribuzione graduale, noto anche come modello di esposizione progressiva, per raggiungere questo obiettivo. Le distribuzioni Canary sono un esempio comune di esposizione progressiva. In questo modello di distribuzione un piccolo gruppo di utenti interni o esterni riceve prima la nuova funzionalità. Dopo che il primo gruppo esegue la nuova versione senza problemi, la funzionalità viene distribuita in gruppi più grandi in modo successivo fino a quando l'intero popolamento utente esegue la nuova versione. I flag di funzionalità vengono in genere usati per abilitare la nuova versione per gli utenti di destinazione nelle distribuzioni canary.

Un altro modello di distribuzione comune è un approccio blu-verde. In questo modello vengono distribuiti due set o pool identici dell'infrastruttura del carico di lavoro. Entrambi i pool sono in grado di gestire un carico di produzione completo. Il primo pool (blu) esegue la versione corrente della distribuzione in cui tutti gli utenti vengono eseguiti. Il secondo pool (verde) viene aggiornato con la nuova funzionalità e testata internamente. Dopo il test interno, viene instradato un subset del traffico di produzione dal pool blu al pool verde. Come le distribuzioni canary, l'implementazione è progressiva man mano che si sposta più del traffico verso il pool verde in successive onde di implementazione più grandi. Al termine dell'implementazione, il pool di aggiornamenti diventa il pool blu e il pool verde è pronto per la distribuzione successiva. I due pool sono logichemente separati tra loro per proteggere da malfunzionamenti. È possibile distribuire una variante del modello blu-verde in un carico di lavoro che usa il modello di progettazione Di stamp di distribuzione distribuendo in un solo stamp alla volta.

In entrambi questi modelli il tempo compreso tra ogni fase dell'implementazione deve essere abbastanza lungo per consentire di monitorare le metriche di integrità del carico di lavoro. È necessario fornire tempo di bake ampio, tempo tra gruppi di implementazione, per garantire che gli utenti provenienti da aree diverse o utenti che eseguono attività diverse abbiano tempo per usare il carico di lavoro nella loro capacità normale. I tempi di bake devono essere misurati in ore e giorni anziché minuti. I tempi di bake dovrebbero aumentare anche per ogni gruppo di implementazione in modo che sia possibile tenere conto di diversi fusi orari e modelli di utilizzo nel corso del giorno.

Modelli di integrità

Sviluppare un modello di integrità affidabile come parte della piattaforma di osservabilità e delle strategie di affidabilità. Il modello di integrità deve fornire visibilità approfondita sui componenti e sull'integrità complessiva del carico di lavoro. Durante un'implementazione, se si riceve un avviso relativo a una modifica dell'integrità relativa a un utente finale, l'implementazione deve interrompere immediatamente e un'indagine sulla causa dell'avviso deve essere eseguita per determinare il corso successivo dell'azione. Se non sono presenti problemi segnalati dagli utenti finali e tutti gli indicatori di integrità rimangono verdi durante il tempo di bake, l'implementazione dovrebbe continuare. Assicurarsi di includere le metriche di utilizzo nel modello di integrità per garantire che una mancanza di problemi segnalati dall'utente e segnali di integrità negativi non nasconde un problema. Per altre informazioni, vedere Creazione di un modello di integrità.

Rilevamento dei problemi

Quando la distribuzione causa un problema in uno dei gruppi di implementazione, l'implementazione deve arrestarsi immediatamente. Un'indagine sulla causa del problema e la gravità degli effetti devono essere eseguite non appena viene ricevuto l'avviso. Il ripristino dal problema può includere:

  • Eseguire il rollback della distribuzione annullando le modifiche apportate nella distribuzione e ripristinando l'ultima configurazione di lavoro nota.

  • Implementazione della distribuzione risolvendo il problema nel corso dell'implementazione. È possibile risolvere i problemi durante l'implementazione a metà applicando un hotfix o riducendo al minimo il problema.

  • Distribuzione di una nuova infrastruttura usando l'ultima configurazione di lavoro nota.

È possibile eseguire il rollback delle modifiche, in particolare del database, dello schema o di altri componenti con stato. Le linee guida SDP devono fornire istruzioni chiare su come gestire le modifiche ai dati in base alla progettazione del data estate per il carico di lavoro. Analogamente, il roll forward deve essere gestito con attenzione per garantire che SDP non sia trascurato e che l'hotfix o altre operazioni di riduzione al minimo vengano eseguite in modo sicuro.

Suggerimenti generali su SDP

  • Implementare il controllo delle versioni tra gli artefatti di compilazione per garantire che sia possibile eseguire il rollback e il roll forward quando necessario.

  • Usare una struttura di branching basata su trunk o flusso di rilascio, che applica una collaborazione strettamente sincronizzata tra il team di sviluppo, anziché una struttura di branching basata su gitflow o basata sull'ambiente.

  • Automatizzare il maggior numero possibile di SDP. Per indicazioni dettagliate sull'automazione dei processi di integrazione continua e integrazione continua dell'applicazione (CI/CD), vedere Raccomandazioni per l'implementazione dell'automazione.

  • Usare le procedure ci per integrare regolarmente le modifiche del codice nei repository. Le procedure ci consentono di identificare i conflitti di integrazione e ridurre la probabilità di merge rischiosi e di grandi dimensioni. Per altre informazioni, vedere la guida all'integrazione continua.

  • Usare i flag di funzionalità per abilitare o disabilitare in modo selettivo nuove funzionalità o modifiche nell'ambiente di produzione. I flag di funzionalità consentono di controllare l'esposizione del nuovo codice e di eseguire rapidamente il rollback della distribuzione in caso di problemi.

  • Distribuire le modifiche agli ambienti di gestione temporanea che mirrora l'ambiente di produzione. Gli ambienti di pratica consentono di testare le modifiche in un'impostazione controllata prima della distribuzione nell'ambiente live.

  • Stabilire controlli di predistribuzione, tra cui la revisione del codice, le analisi di sicurezza e i controlli di conformità, per garantire che le modifiche siano sicure per la distribuzione.

  • Implementare i breaker di circuito per arrestare automaticamente il traffico a un servizio che riscontra problemi. In questo modo è possibile evitare un ulteriore degrado del sistema.

Protocolli SDP di emergenza

Stabilire protocolli prescrittivi che definiscono il modo in cui il SDP può essere modificato per un hotfix o per problemi di emergenza, ad esempio una violazione della sicurezza o un'esposizione di vulnerabilità. Ad esempio, i protocolli SDP di emergenza possono includere:

  • Accelerazione della fase di promozione e approvazione.

  • Test di fumo e accelerazione dei test di integrazione.

  • Riduzione del tempo di bake.

In alcuni casi, l'emergenza potrebbe limitare la qualità e i test dei cancelli, ma i cancelli devono comunque essere eseguiti il più rapidamente possibile come esercizio fuori banda. Assicurarsi di definire chi può approvare l'accelerazione SDP in un'emergenza e i criteri che devono essere soddisfatti per l'accelerazione da approvare. Allineare i protocolli SDP di emergenza al piano di risposta di emergenza per garantire che tutte le emergenze vengano gestite in base agli stessi protocolli.

Considerazioni

La creazione e la gestione di procedure di distribuzione sicure è complessa. Il successo nell'implementazione completa di standard affidabili dipende dalla maturità delle procedure in molte aree di sviluppo software. L'uso dell'automazione, solo IaC per le modifiche dell'infrastruttura, la coerenza nelle strategie di diramazione, l'uso dei flag di funzionalità e molte altre procedure possono contribuire a garantire la distribuzione sicura. Usare questa guida per ottimizzare il carico di lavoro e informare i piani di miglioramento man mano che le procedure si evolvono.

Facilitazione di Azure

  • Azure Pipelines e GitHub Actions supportano le distribuzioni in più fasi usando i controlli di approvazione, che consentono di progettare l'implementazione progressiva dell'esposizione per le distribuzioni.

  • Usare Servizio app di Azure slot di staging per scambiare facilmente le versioni del codice. Gli slot di staging sono utili per i test negli ambienti di gestione temporanea e possono essere usati per le distribuzioni blu-verde.

  • Archiviare e gestire i flag di funzionalità dell'app Web in Configurazione app di Azure. Usando questo servizio, è possibile creare, modificare e distribuire funzionalità in un piano di gestione unificato.

  • Distribuire le applicazioni del carico di lavoro nella macchina virtuale usando le applicazioni vm.

  • Usare i servizi di bilanciamento del carico di Azure per implementare strategie di distribuzione ed esporre l'integrità delle applicazioni del carico di lavoro usando risorse native.

  • Usare l'estensione Integrità applicazione per segnalare l'integrità dell'applicazione dall'interno di un'istanza del set di scalabilità di macchine virtuali. L'estensione esegue il probe in un endpoint applicazione locale e aggiorna lo stato di integrità in base alle risposte TCP/HTTP(S) ricevute dall'applicazione.

  • Usare App per la logica di Azure per creare una nuova versione dell'applicazione ogni volta che viene eseguito un aggiornamento. Azure gestisce una cronologia delle versioni dell'applicazione e può ripristinare o alzare di livello qualsiasi versione precedente.

  • Molti servizi di Database di Azure offrono funzionalità di ripristino temporizzato che consentono di eseguire il rollback. I servizi che supportano il ripristino temporizzato includono:

Esempio

Per un esempio di come usare questo modello di distribuzione, vedere la guida all'architettura dei cluster di servizio Azure Kubernetes (servizio Azure Kubernetes).

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa