Condividi tramite

Raccomandazioni per procedure di distribuzione sicure

  • Articolo

Si applica a questa raccomandazione per l'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 di controllo qualitativo. Usare modelli di distribuzione moderni e tecniche di esposizione progressiva per controllare i rischi. Tenere conto delle distribuzioni di routine e delle distribuzioni di emergenza o hotfix.

Questa guida descrive le raccomandazioni 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 la lente di gestione dei rischi. È possibile ridurre al minimo il rischio di errori umani nelle distribuzioni e limitare gli effetti delle distribuzioni problematiche per gli utenti implementando SDP.

Strategie di progettazione chiave

Esistono quattro linee guida importanti da tenere presenti 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 apportate con particolare 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 immediatamente interrotta e avviata dal ripristino.

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

Garantire la sicurezza e la coerenza delle distribuzioni

Sia che si distribuisca un aggiornamento del codice dell'applicazione, dell'infrastruttura come codice (IaC), un flag di funzionalità o un aggiornamento della configurazione, si sta introducendo un rischio nel carico di lavoro. Non esistono distribuzioni a basso rischio nell'ambiente di produzione. Ogni distribuzione deve seguire un modello standard e deve essere automatizzata per applicare la coerenza e ridurre al minimo il rischio di errore umano. È fondamentale che la supply chain del carico di lavoro e le pipeline di distribuzione siano affidabili, sicure e abbiano standard di distribuzione chiaramente definiti. Considerare ogni distribuzione come un possibile rischio e sottoporre ogni distribuzione allo stesso livello di gestione dei rischi. Nonostante i rischi, è consigliabile continuare a distribuire modifiche regolari al carico di lavoro. Se non si distribuiscono aggiornamenti regolari, vengono introdotti altri rischi, ad esempio le vulnerabilità di sicurezza che devono essere risolte tramite distribuzioni. Per altre informazioni, vedere Raccomandazioni per la progettazione di una supply chain di sviluppo del carico di lavoro.

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

Adottare un modello di esposizione progressiva

Quando si verificano problemi di distribuzione, l'obiettivo è quello di intercettarli 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 di dimensioni successive fino a quando l'intero popolamento utente non 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 identici, o pool, 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 vengono eseguiti tutti gli utenti. Il secondo pool (verde) viene aggiornato con la nuova funzionalità e testato internamente. Dopo il test interno, un subset del traffico di produzione viene instradato 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 onde di implementazione successive 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 separati logicamente l'uno dall'altro per evitare malfunzionamenti. È possibile distribuire una variante del modello blu-verde in un carico di lavoro che usa il modello di progettazione Stamp di distribuzione distribuendo su un timbro alla volta.

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

Sviluppare modelli di integrità affidabili del carico di lavoro

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

Implementare meccanismi di rilevamento degli errori

Quando la distribuzione causa un problema in uno dei gruppi di implementazione, l'implementazione deve essere interrotta 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 funzionante nota.

  • Roll forward della distribuzione risolvendo il problema durante l'implementazione. È possibile risolvere i problemi durante l'implementazione applicando un hotfix o riducendo al minimo il problema.

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

Il rollback delle modifiche, in particolare il database, lo schema o altre modifiche del componente con stato, può essere complesso. Le linee guida SDP devono fornire istruzioni chiare su come gestire le modifiche dei dati in base alla progettazione del patrimonio di dati per il carico di lavoro. Analogamente, il roll forward deve essere gestito con attenzione per assicurarsi che SDP non venga trascurato e che l'hotfix o altre operazioni di riduzione al minimo vengano eseguite in modo sicuro.

Stabilire protocolli per le distribuzioni di emergenza

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

  • Usare un flusso di rilascio o una struttura di diramazione basata su trunk, che impone una collaborazione strettamente sincronizzata tra il team di sviluppo, anziché una struttura di diramazione basata sull'ambiente o Gitflow.

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

  • Usare le procedure di integrazione continua 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 staging che rispecchiano 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 pre-distribuzione, 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 interruttori di circuito per interrompere automaticamente il traffico verso un servizio che riscontra problemi. In questo modo è possibile evitare ulteriori degradi del sistema.

Protocolli SDP di emergenza

Stabilire protocolli prescrittivi che definiscono il modo in cui il provider di servizi può essere regolato 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 controlli, ma i cancelli devono essere eseguiti il più rapidamente possibile come esercizio fuori banda. Assicurarsi di definire chi può approvare l'accelerazione SDP in caso di emergenza e i criteri che devono essere soddisfatti per l'approvazione dell'accelerazione. Allineare i protocolli SDP di emergenza con il piano di risposta alle emergenze per garantire che tutte le emergenze vengano gestite in base agli stessi protocolli.

Considerazioni

La compilazione e la gestione di procedure di distribuzione sicure è complessa. Il successo nell'implementazione completa di standard affidabili dipende dalla maturità delle proprie 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 una 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 distribuzioni in più fasi usando controlli di approvazione, che consentono di progettare l'implementazione progressiva dell'esposizione per le distribuzioni.

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

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

  • Distribuire 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 ricerca in un endpoint dell'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 servizio Azure Kubernetes del servizio Azure Kubernetes (AKS) blu-verde.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa