Procedure operative per carichi di lavoro cruciali in Azure

Le operazioni affidabili ed efficaci devono essere basate sui principi di automazione, ovunque possibile e di configurazione come codice. Questo approccio richiede un notevole investimento di ingegneria nei processi DevOps. Le pipeline automatizzate vengono usate per distribuire gli artefatti di codice dell'applicazione e dell'infrastruttura. I vantaggi di questo approccio includono risultati operativi coerenti e accurati con procedure operative manuali minime.

Questa area di progettazione illustra come implementare procedure operative efficaci e coerenti.

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 What is a mission-critical workload?.

Processi DevOps

DevOps combina processi operativi e di sviluppo in una singola funzione di progettazione. Include l'intero ciclo di vita dell'applicazione e usa gli strumenti di automazione e DevOps per condurre operazioni di distribuzione in modo rapido, efficiente ed affidabile. I processi DevOps supportano e supportano l'integrazione continua e il recapito continuo (CI/CD) promuovendo una cultura di miglioramento continuo.

Il team DevOps per un'applicazione mission-critical deve essere responsabile di queste attività:

• Creazione e gestione delle risorse dell'applicazione e dell'infrastruttura tramite automazione CI/CD.
• Monitoraggio delle applicazioni e osservabilità.
• Controllo degli accessi in base al ruolo di Azure e gestione delle identità per i componenti dell'applicazione.
• Gestione di rete per i componenti dell'applicazione.
• Gestione dei costi per le risorse dell'applicazione.

DevSecOps espande il modello DevOps integrando il monitoraggio della sicurezza, i controlli delle applicazioni e la garanzia di qualità con lo sviluppo e le operazioni nel ciclo di vita dell'applicazione. I team DevOps sono necessari per scenari sensibili alla sicurezza e altamente regolamentati per garantire che la sicurezza sia incorporata nel ciclo di vita dello sviluppo anziché in una fase di rilascio o un gate specifici.

Considerazioni relative alla progettazione

• Processo di rilascio e aggiornamento. Evitare processi manuali per qualsiasi modifica ai componenti dell'applicazione o all'infrastruttura sottostante. I processi manuali possono causare risultati incoerenti.

• Dipendenze dei team IT centrali. I processi DevOps possono essere difficili da applicare quando sono presenti dipendenze difficili dalle funzioni centralizzate perché queste dipendenze impediscono operazioni end-to-end.

• Gestione delle identità e degli accessi. I team DevOps possono considerare ruoli di controllo degli accessi in base al ruolo di Azure granulari per varie funzioni tecniche, ad esempio AppDataOps per la gestione del database. Applicare un modello zero-trust tra i ruoli DevOps.

Suggerimenti per la progettazione

• Definire le impostazioni di configurazione e gli aggiornamenti come codice. Applicare la gestione delle modifiche tramite il codice per abilitare processi di rilascio e aggiornamento coerenti, incluse attività come la rotazione delle chiavi o la rotazione dei segreti e la gestione delle autorizzazioni. Usare processi di aggiornamento gestiti dalla pipeline, ad esempio esecuzioni della pipeline pianificate, anziché meccanismi di aggiornamento automatico predefiniti.

• Non usare processi centrali o pipeline di provisioning per l'istanza o la gestione delle risorse dell'applicazione. In questo modo vengono introdotte dipendenze di applicazioni esterne e vettori di rischio aggiuntivi, ad esempio quelli associati a scenari vicini rumorosi.

  Se è necessario usare i processi di provisioning centralizzati, assicurarsi che i requisiti di disponibilità delle dipendenze siano completamente allineati ai requisiti cruciali. I team centrali devono fornire trasparenza in modo che venga raggiunta l'operatività olistica dell'applicazione end-to-end.

• Dedicare una percentuale di capacità di ingegneria durante ogni sprint per guidare i miglioramenti fondamentali della piattaforma e rafforzare l'affidabilità. È consigliabile allocare il 20-40% della capacità a questi miglioramenti.

• Sviluppare criteri di progettazione comuni, architetture di riferimento e librerie allineate ai principi di progettazione di base. Applicare una configurazione di base coerente per affidabilità, sicurezza e operazioni tramite un approccio basato su criteri che usa Criteri di Azure.

  È anche possibile usare i criteri di progettazione comuni e gli artefatti associati, ad esempio criteri di Azure e risorse Terraform per modelli di progettazione comuni, in altri carichi di lavoro all'interno dell'ecosistema di applicazioni più ampio dell'organizzazione.

• Applicare un modello zero-trust negli ambienti applicazioni critici. Usare tecnologie come Microsoft Entra Privileged Identity Management per garantire che le operazioni siano coerenti e si verifichino solo tramite processi CI/CD o procedure operative automatizzate.

  I membri del team non devono avere accesso in scrittura permanente a qualsiasi ambiente. È possibile creare eccezioni negli ambienti di sviluppo per facilitare il test e il debug.

• Definire i processi di emergenza per l'accesso just-in-time agli ambienti di produzione. Assicurarsi che gli account di vetro di interruzione esistano in caso di gravi problemi con il provider di autenticazione.

• Prendere in considerazione l'uso di AIOps per migliorare continuamente le procedure operative e i trigger.

Operazioni dell'applicazione

La progettazione dell'applicazione e le raccomandazioni della piattaforma influiscono sulle procedure operative. Esistono anche funzionalità operative fornite da vari servizi di Azure, in particolare per la disponibilità elevata e il ripristino.

Considerazioni relative alla progettazione

• Operazioni predefinite dei servizi di Azure. I servizi di Azure offrono funzionalità predefinite (abilitate per impostazione predefinita) e piattaforme configurabili, ad esempio ridondanza zonale e replica geografica. L'affidabilità di un'applicazione dipende da queste operazioni. Alcune funzionalità configurabili comportano costi aggiuntivi, ad esempio la configurazione di distribuzione multi-scrittura per Azure Cosmos DB. Evitare di creare soluzioni personalizzate a meno che non sia assolutamente necessario.

• Tempo di accesso operativo ed esecuzione. Le operazioni più necessarie sono esposte e accessibili tramite l'API di Azure Resource Manager o l'portale di Azure. Tuttavia, alcune operazioni richiedono assistenza da parte dei tecnici di supporto. Ad esempio, un ripristino da un backup periodico di un database Azure Cosmos DB o il ripristino di una risorsa eliminata, può essere eseguito solo da supporto tecnico di Azure ingegneri tramite un caso di supporto. Questa dipendenza potrebbe influire sul tempo di inattività dell'applicazione. Per le risorse senza stato, è consigliabile ridistribuire invece di attendere che i tecnici di supporto tentino di recuperare le risorse eliminate.

• Applicazione dei criteri. Criteri di Azure fornisce un framework per applicare e controllare le baseline di sicurezza e affidabilità per garantire la conformità con criteri di progettazione comuni per applicazioni cruciali. In particolare, Criteri di Azure costituisce una parte fondamentale del piano di controllo di Azure Resource Manager, integrando il controllo degli accessi in base al ruolo limitando le azioni che gli utenti autorizzati possono eseguire. È possibile usare Criteri di Azure per applicare convenzioni di sicurezza e affidabilità vitali tra i servizi della piattaforma.

• Modifica ed eliminazione delle risorse. È possibile bloccare le risorse di Azure per impedire la modifica o l'eliminazione delle risorse di Azure. Tuttavia, i blocchi introducono il sovraccarico di gestione nelle pipeline di distribuzione. Per la maggior parte delle risorse, è consigliabile un processo di controllo degli accessi in base al ruolo affidabile con restrizioni limitate anziché i blocchi delle risorse.

Suggerimenti per la progettazione

• Automatizzare le procedure di failover. Per un modello attivo/attivo, usare un modello di integrità e operazioni di scalabilità automatizzate per garantire che non sia necessario alcun intervento di failover. Per un modello attivo/passivo, assicurarsi che le procedure di failover siano automatizzate o almeno codificate all'interno delle pipeline.

• Assegnare priorità all'uso della scalabilità automatica nativa di Azure per i servizi che lo supportano. Per i servizi che non supportano la scalabilità automatica nativa, usare processi operativi automatizzati per ridimensionare i servizi. Usare le unità di scalabilità con più servizi per ottenere la scalabilità.

• Usare funzionalità native della piattaforma per il backup e il ripristino, assicurandosi che siano allineate ai requisiti di conservazione dei dati e RTO/RPO. Definire una strategia per la conservazione dei backup a lungo termine in base alle esigenze.

• Usare funzionalità predefinite per la gestione e il rinnovo dei certificati SSL, ad esempio quelle fornite da Frontdoor di Azure.

• Per i team esterni, stabilire un processo di ripristino per le risorse che richiedono assistenza. Ad esempio, se la piattaforma dati viene modificata o eliminata in modo errato, i metodi di ripristino devono essere ben compresi e un processo di ripristino deve essere eseguito. Analogamente, stabilire procedure per gestire le immagini dei contenitori rimosse nel Registro di sistema.

• Praticare le operazioni di ripristino in anticipo, su risorse e dati non di produzione, come parte dei preparativi di continuità aziendale standard.

• Identificare gli avvisi critici e definire destinatari e sistemi di destinazione. Definire canali chiari per raggiungere gli stakeholder appropriati. Inviare solo avvisi utilizzabili per evitare il rumore bianco e impedire agli stakeholder operativi di ignorare gli avvisi e le informazioni importanti mancanti. Implementare un miglioramento continuo per ottimizzare l'avviso e rimuovere il rumore bianco osservato.

• Applicare la governance basata sui criteri e Criteri di Azure per garantire l'uso appropriato delle funzionalità operative e una baseline di configurazione affidabile in tutti i servizi applicazione.

• Evitare l'uso di blocchi di risorse sulle risorse temporanee. Si basano invece sull'uso appropriato delle pipeline RBAC e CI/CD per controllare gli aggiornamenti operativi. È possibile applicare blocchi di risorse per evitare l'eliminazione di risorse globali di lunga durata.

Gestione degli aggiornamenti

La progettazione critica approva fortemente il principio delle risorse dell'applicazione senza stato temporaneo. Se si applica questo principio, in genere è possibile eseguire un aggiornamento usando una nuova pipeline di distribuzione e distribuzione standard.

Considerazioni relative alla progettazione

• Allineamento con le roadmap di Azure. Allineare il carico di lavoro con le roadmap di Azure in modo che le risorse della piattaforma e le dipendenze di runtime vengano aggiornate regolarmente.

• Rilevamento automatico degli aggiornamenti. Configurare i processi per monitorare e rilevare automaticamente gli aggiornamenti. Usare strumenti come GitHub Dependabot.

• Test e convalida. Testare e convalidare nuove versioni di pacchetti, componenti e dipendenze in un contesto di produzione prima di qualsiasi versione. Le nuove versioni potrebbero contenere modifiche di rilievo.

• Dipendenze di runtime. Trattare le dipendenze di runtime come qualsiasi altra modifica all'applicazione. Le versioni precedenti potrebbero introdurre vulnerabilità di sicurezza e potrebbero avere un effetto negativo sulle prestazioni. Monitorare l'ambiente di runtime dell'applicazione e mantenerlo aggiornato.

• Igiene dei componenti e pulizia. Rimuovere o rimuovere risorse non usate. Ad esempio, monitorare i registri contenitori ed eliminare le versioni precedenti dell'immagine che non si usa.

Suggerimenti per la progettazione

• Monitorare queste risorse e mantenerle aggiornate:

  • Piattaforma di hosting dell'applicazione. Ad esempio, è necessario aggiornare regolarmente la versione di Kubernetes in servizio Azure Kubernetes (Servizio Azure Kubernetes), in particolare dato che il supporto per le versioni precedenti non è supportato. È anche necessario aggiornare i componenti eseguiti in Kubernetes, ad esempio cert-manager e Azure Key Vault CSI e allinearli alla versione Kubernetes nel servizio Azure Kubernetes.
  • Librerie esterne e SDK (.NET, Java, Python).
  • Provider Terraform.

• Evitare modifiche operative manuali per aggiornare i componenti. Prendere in considerazione l'uso delle modifiche manuali solo nelle situazioni di emergenza. Assicurarsi di avere un processo per riconciliare le modifiche manuali nel repository di origine per evitare la deriva e la ricorrenza dei problemi.

• Stabilire una procedura automatizzata per rimuovere le versioni precedenti delle immagini da Registro Azure Container.

Gestione dei segreti

Le scadenze di chiave, segreto e certificato sono una causa comune di interruzione dell'applicazione. La gestione dei segreti per un'applicazione critica deve fornire la sicurezza necessaria e offrire un livello di disponibilità appropriato per allinearsi ai requisiti di affidabilità massima. È necessario eseguire la rotazione di chiavi, segreti e certificati regolarmente usando un servizio gestito o come parte della gestione degli aggiornamenti e applicare processi per le modifiche al codice e alla configurazione.

Molti servizi di Azure supportano l'autenticazione Microsoft Entra anziché basarsi sulle stringhe di connessione/chiavi. L'uso di Microsoft Entra ID riduce notevolmente il sovraccarico operativo. Se si usa una soluzione di gestione privata, deve integrarsi con altri servizi, supportare ridondanza zonale e a livello di area e fornire l'integrazione con l'ID Microsoft Entra per l'autenticazione e l'autorizzazione. Key Vault offre queste funzionalità.

Considerazioni relative alla progettazione

Esistono tre approcci comuni alla gestione dei segreti. Ogni approccio legge i segreti dall'archivio segreto e li inserisce nell'applicazione in un momento diverso.

• Recupero in fase di distribuzione. Il vantaggio di questo approccio è che la soluzione di gestione dei segreti deve essere disponibile solo in fase di distribuzione perché non sono presenti dipendenze dirette dopo tale periodo. Gli esempi includono l'inserimento di segreti come variabili di ambiente in una distribuzione Kubernetes o in un segreto Kubernetes.

  Solo l'entità servizio di distribuzione deve essere in grado di accedere ai segreti, semplificando le autorizzazioni di controllo degli accessi in base al ruolo all'interno del sistema di gestione dei segreti.

  Esistono tuttavia svantaggi per questo approccio. Introduce la complessità del controllo degli accessi in base al ruolo negli strumenti DevOps per quanto riguarda il controllo dell'accesso all'entità servizio e nell'applicazione per la protezione dei segreti recuperati. Inoltre, i vantaggi di sicurezza della soluzione di gestione dei segreti non vengono applicati perché questo approccio si basa solo sul controllo di accesso nella piattaforma applicazione.

  Per implementare gli aggiornamenti o la rotazione dei segreti, è necessario eseguire una ridistribuzione completa.

• Recupero dell'avvio dell'applicazione. In questo approccio, i segreti vengono recuperati e inseriti all'avvio dell'applicazione. Il vantaggio è che è possibile aggiornare o ruotare facilmente i segreti. Non è necessario archiviare i segreti nella piattaforma applicazione. Per recuperare il valore più recente, è necessario riavviare l'applicazione.

  Le opzioni di archiviazione comuni includono Provider di Azure Key Vault per il driver CSI dell'archivio segreti e akv2k8s. È disponibile anche una soluzione di Azure nativa, Key Vault impostazioni di app a cui si fa riferimento.

  Uno svantaggio di questo approccio è che crea una dipendenza di runtime dalla soluzione di gestione dei segreti. Se la soluzione di gestione dei segreti riscontra un'interruzione, i componenti dell'applicazione già in esecuzione potrebbero essere in grado di continuare a gestire le richieste. Qualsiasi operazione di riavvio o scalabilità orizzontale potrebbe causare un errore.

• Recupero runtime. Il recupero dei segreti in fase di esecuzione dall'interno dell'applicazione è l'approccio più sicuro perché anche la piattaforma applicazione non ha mai accesso ai segreti. L'applicazione deve autenticarsi nel sistema di gestione dei segreti.

  Tuttavia, per questo approccio, i componenti dell'applicazione richiedono una dipendenza diretta e una connessione al sistema di gestione dei segreti. Ciò rende più difficile testare i componenti singolarmente e in genere richiede l'uso di un SDK.

Suggerimenti per la progettazione

• Quando possibile, usare Microsoft Entra autenticazione per connettersi ai servizi anziché usare stringhe di connessione o chiavi. Usare questo metodo di autenticazione insieme alle identità gestite di Azure in modo da non dover archiviare i segreti nella piattaforma applicazione.

• Sfruttare l'impostazione di scadenza in Key Vault e configurare l'avviso per le prossime scadenze. Eseguire tutti gli aggiornamenti chiave, segreto e certificato usando il processo di rilascio standard.

• Distribuire Key Vault istanze come parte di un timbro a livello di area per attenuare l'effetto potenziale di un errore in un singolo timbro di distribuzione. Usare un'istanza separata per le risorse globali. Per informazioni su queste risorse, vedere il modello di architettura tipico per carichi di lavoro cruciali.

• Per evitare la necessità di gestire le credenziali dell'entità servizio o le chiavi API, usare identità gestite anziché entità servizio per accedere a Key Vault ogni volta che possibile.

• Implementare modelli di codifica per assicurarsi che i segreti vengano recuperati nuovamente quando si verifica un errore di autorizzazione in fase di esecuzione.

• Applicare un processo di rotazione delle chiavi completamente automatizzato che viene eseguito periodicamente all'interno della soluzione.

• Usare la notifica della chiave quasi scaduta in Azure Key Vault per ottenere avvisi sulle scadenze imminenti.

Considerazioni specifiche di IaaS quando si usano macchine virtuali

Se è necessario usare macchine virtuali IaaS, alcune delle procedure e delle procedure descritte in precedenza in questo documento potrebbero essere diverse. L'uso delle macchine virtuali offre maggiore flessibilità nelle opzioni di configurazione, nei sistemi operativi, nell'accesso ai driver, nell'accesso al sistema operativo a basso livello e nei tipi di software che è possibile installare. Gli svantaggi sono maggiori costi operativi e la responsabilità per le attività che vengono in genere eseguite dal provider cloud quando si usano i servizi PaaS.

Considerazioni relative alla progettazione

• Le singole macchine virtuali non offrono disponibilità elevata, ridondanza della zona o ridondanza geografica.
• Le singole macchine virtuali non vengono aggiornate automaticamente dopo la distribuzione. Ad esempio, un SQL Server 2019 distribuito in Windows Server 2019 non verrà aggiornato automaticamente a una versione più recente.
• I servizi in esecuzione in una macchina virtuale richiedono un trattamento speciale e strumenti aggiuntivi se si desidera distribuire e configurarli tramite l'infrastruttura come codice.
• Azure aggiorna periodicamente la piattaforma. Questi aggiornamenti potrebbero richiedere il riavvio della macchina virtuale. Aggiornamenti che richiedono un riavvio vengono in genere annunciati in anticipo. Vedere Manutenzione per le macchine virtuali in Azure e Gestione delle notifiche di manutenzione pianificata.

Suggerimenti per la progettazione

• Evitare operazioni manuali sulle macchine virtuali e implementare processi appropriati per distribuire e implementare modifiche.

  • Automatizzare il provisioning delle risorse di Azure usando soluzioni di infrastruttura come azure Resource Manager (ARM), Bicep, Terraform o altre soluzioni.

• Assicurarsi che i processi operativi per la distribuzione di macchine virtuali, aggiornamenti e backup e ripristino siano presenti e testati correttamente. Per testare la resilienza, inserire errori nell'applicazione, prendere nota degli errori e attenuare tali errori.

• Assicurarsi che le strategie siano disponibili per eseguire il rollback all'ultimo stato integro noto se una versione più recente non funziona correttamente.

• Creare backup frequenti per carichi di lavoro con stato, assicurarsi che le attività di backup funzionino in modo efficace e implementino avvisi per i processi di backup non riusciti.

• Monitorare le macchine virtuali e rilevare gli errori. I dati non elaborati per il monitoraggio possono derivare da un'ampia gamma di origini. Analizzare le cause dei problemi.

• Assicurarsi che i backup pianificati vengano eseguiti come previsto e che i backup periodici vengano creati in base alle esigenze. È possibile usare il Centro backup per ottenere informazioni dettagliate.

• Assegnare priorità all'uso di set di scalabilità di macchine virtuali anziché alle macchine virtuali per abilitare funzionalità come scalabilità, scalabilità automatica e ridondanza della zona.

• Assegnare priorità all'uso di immagini standard da Azure Marketplace anziché immagini personalizzate che devono essere mantenute.

• Usare Image Builder di macchine virtuali di Azure o altri strumenti per automatizzare i processi di compilazione e manutenzione per le immagini personalizzate in base alle esigenze.

Oltre a queste raccomandazioni specifiche, applicare le procedure consigliate per le procedure operative per scenari di applicazioni cruciali in base alle esigenze.

Passaggio successivo

Esaminare il modello di architettura per scenari di applicazioni cruciali:

Modello di architettura