Condividi tramite

Automazione

  • Articolo

Nell'infrastruttura cloud definita dal software, i team usano vari strumenti e tecniche per effettuare il provisioning, configurare e gestire l'infrastruttura. Man mano che i team si evolvono e crescono, possono passare dall'uso di portali e sforzi manuali all'uso del codice e dell'automazione per effettuare il provisioning, configurare e gestire l'infrastruttura e i servizi.

Considerazioni sull'automazione della piattaforma

  • L'implementazione della metodologia Everything as Code (EaC) consente ai team di sbloccare i vantaggi principali, creare una cultura di sviluppo avanzata e consentire a tutti i membri di ogni team di controllare come e quali risorse vengono distribuite. EaC aiuta anche i team della piattaforma ad adottare procedure di sviluppo chiave che ne migliorano l'agilità e l'efficienza. I team possono tenere traccia delle modifiche e controllare quali passare alla produzione ospitando il codice nei repository e usando i sistemi di controllo della versione per gestirli.
  • I team possono seguire il principio 4 occhi e utilizzare la programmazione tra pari o la revisione tra pari per assicurarsi che le modifiche al codice non vengano mai apportate da sole. La programmazione peer e la revisione peer migliorano la qualità del codice, consentono ai team di condividere la responsabilità delle modifiche e aumentare le conoscenze del team su ciò che viene concordato e distribuito. La revisione del codice è un ottimo modo per consentire ai membri del team di apprendere nuove tecniche e metodi per la codifica e l'automazione.
  • I team devono usare sistemi di controllo della versione come Git, insieme ai repository Git , per applicare la revisione peer. I repository Git permettono ai team di definire rami essenziali e di proteggerli con criteri di protezione per i rami . È possibile utilizzare i criteri per richiedere che le modifiche al codice in questi rami soddisfino determinati criteri, come un numero minimo di approvazioni da parte dei membri del team, prima che possano fondere in un ramo protetto.
  • I team devono connettere la metodologia EaC e il processo di revisione delle modifiche insieme a un processo di integrazione continua e consegna continua (CI/CD) . Ogni modifica del codice deve attivare automaticamente un processo di integrazione continua che esegue l'analisi statica del codice, la convalida e le distribuzioni di test. L'integrazione continua garantisce che gli sviluppatori controllino il loro codice in anticipo (spesso indicato come fallimento rapido o test anticipati) per individuare errori che possono causare problemi futuri. A seconda della strategia di diramazione usata dal team, le modifiche apportate a qualsiasi ramo importante devono attivare la distribuzione in diversi ambienti . Dopo che le modifiche vengono approvate e unite in main, il processo cd distribuisce tali modifiche nell'ambiente di produzione. Questo sistema di gestione del codice fornisce al team una fonte unica di verità per ciò che viene eseguito in ogni ambiente.
  • Per garantire che la piattaforma sia completamente auto-riparante e fornisca self-service ai team dei carichi di lavoro, il team della piattaforma deve lavorare per automatizzare tutto (spesso definito Extreme Automation) dalla fornitura, configurazione e gestione della piattaforma al provisioning delle sottoscrizioni delle aree di destinazione per i team dei carichi di lavoro. L'automazione estrema consente al team della piattaforma di concentrarsi sul fornire valore anziché sulla distribuzione, la configurazione e la gestione della piattaforma. L'automazione estrema crea anche un ciclo di auto-miglioramento che offre al team più tempo per creare più automazione.
  • Man mano che i team della piattaforma automatizzano le attività operative e riducono l'intervento umano, devono concentrarsi su attività importanti che consentono e accelerano l'innovazione del team del carico di lavoro in Azure. A tale scopo, il team della piattaforma deve scorrere più cicli di compilazione e sviluppo man mano che vengono inseriti gli strumenti, gli script e i miglioramenti delle funzionalità della piattaforma.
  • Sono disponibili diverse opzioni per aiutare il team a iniziare con la distribuzione di Azure Landing Zone. Queste opzioni dipendono dalle funzionalità correnti del team e possono crescere man mano che il team si evolve. In particolare, per Platform Deployment, è possibile scegliere tra le esperienze basate su Portale, Bicep o Terraform, a seconda della competenza dell'infrastruttura come codice (IaC) e delle preferenze degli strumenti dei rispettivi team.
    • I team della piattaforma nuovi ed emergenti che stanno ancora imparando a conoscere IaC e hanno familiarità con l'uso di un portale per distribuire e gestire le risorse possono usare l'acceleratore di zone di atterraggio di Azure . Questo acceleratore supporta i team che attualmente usano un approccio ClickOps. ClickOps è il processo di provisioning, configurazione e gestione delle risorse facendo clic su portali web, console di gestione e procedure guidate. Questo acceleratore consente al team di usare il portale come strumento di distribuzione iniziale. Man mano che cresce la maturità della progettazione della piattaforma, il team può incorporare gradualmente l'interfaccia della riga di comando di Azure, PowerShell o IaC.
    • La soluzione AzOps consente ai team di evolvere le pratiche di automazione e gestione della piattaforma passando da un modello basato su ClickOps a uno capace di DevOps. Il tuo team può passare dall'utilizzo dei propri account personali all'adozione dei principi e delle pratiche di DevOps, basandosi esclusivamente su CI/CD con AzOps e IaC. AzOps consente al team di usare la propria architettura, usare l'architettura distribuita dall'acceleratore del portale di destinazione di Azure (dopo la distribuzione iniziale basata sul portale, perché l'integrazione di AzOps non fa parte dell'esperienza del portale ALZ), integrarla con una distribuzione brownfield o usare modelli personalizzati (Bicep o ARM) per compilare e rendere operativa la piattaforma.
    • I team della piattaforma con competenze e funzionalità consolidate possono adottare un approccio codificato che segue principi e procedure DevOps. Il team dovrebbe basarsi fortemente su IaC e pratiche di sviluppo moderne, abbandonando l'accesso ad Azure tramite account personali e gestire tutte le operazioni attraverso la pipeline CI/CD. Il team dovrebbe utilizzare acceleratori basati su IaC, come ALZ-Bicep o il modulo Terraform delle zone di destinazione di Azure per accelerare questa transizione.
  • Gli acceleratori basati su IaC hanno un ambito di gestione limitato. Le nuove versioni offrono maggiori funzionalità e una maggiore capacità di gestione delle risorse. Se si usa un acceleratore, il team deve considerare un approccio a più livelli che inizia con un acceleratore, quindi aggiunge un livello di automazione. Il livello di automazione offre le funzionalità necessarie alla tua squadra per fornire pieno supporto ai team di gestione dei carichi di lavoro con caratteristiche della piattaforma quali la distribuzione del controller di dominio per le applicazioni legacy.
  • Quando il team della piattaforma passa a un approccio DevOps, è necessario stabilire un processo per la gestione delle correzioni di emergenza. Possono usare Privileged Identity Management (PIM) autorizzazioni eleggibili per richiedere l'accesso per eseguire correzioni e successivamente riportare le modifiche al codice per limitare il drift di configurazione oppure possono usare il codice per implementare una correzione rapida. Il team deve sempre registrare correzioni rapide nel backlog, in modo da poter rielaborare ogni correzione in un secondo momento e limitare il debito tecnico. Un debito tecnico troppo elevato comporta una decelerazione futura, perché alcuni codici della piattaforma non vengono esaminati completamente e non soddisfano le linee guida e i principi di codifica del team.
  • È possibile usare Criteri di Azure per aggiungere un'automazione alla piattaforma. Prendere in considerazione l'uso di IaC per distribuire e gestire criteri di Azure, spesso definiti policy-as-code (PaC). Questi criteri consentono di automatizzare attività come la raccolta di log. Molti framework PaC implementano anche un processo di esenzione, quindi pianifica affinché i team del carico di lavoro possano richiedere esenzioni dai criteri.
  • Usare "Governance guidata dai criteri" per segnalare quando i team di lavoro tentano di distribuire risorse che non soddisfano un controllo di sicurezza. Prendere in considerazione la distribuzione dei criteri con l'effetto deny per queste situazioni, che consente ai team di lavoro di considerare anche Tutto come Codice ed evitare la deriva della configurazione in cui il codice dichiara un elemento e i criteri hanno modificato un'impostazione al momento della distribuzione. Evitare l'uso di effetti modify, come quando un team di lavoro implementa un account di archiviazione con supportOnlyHttpsTraffic = false definito nel loro codice, dove una policy modify lo modifica a true al momento del deployment per mantenerlo conforme. Questo comporta che il codice si discosta da quello che viene distribuito.

Raccomandazione per la progettazione dell'automazione della piattaforma

  • Seguire un approccio Tutto come Codice per garantire la trasparenza completa e il controllo della configurazione della piattaforma Azure, della documentazione, della distribuzione e del processo di test.
  • Utilizzare il controllo della versione per gestire tutti i repository di codice, tra cui:
    • Infrastruttura come codice
    • Politica come Codice
    • Configurazione come codice
    • Distribuzione come codice
    • Documentazione come codice
  • Implementare il principio a 4 occhi e un processo per di programmazione peer o di peer-review per assicurarsi che tutte le modifiche al codice vengano esaminate dal team prima di essere distribuite nell'ambiente di produzione.
  • Adotta una strategia di diramazione per il team e imposta i criteri per i rami per i rami da proteggere. Con i criteri dei rami, i team devono usare richieste pull per apportare modifiche di tipo merge.
  • Usare l'integrazione continua e la distribuzione continua (CI/CD) per l'automazione dei test del codice e la distribuzione in ambienti diversi.
  • È possibile automatizzare tutto, ad esempio il provisioning, la configurazione e la gestione della piattaforma e il provisioning delle sottoscrizioni di zona di destinazione per i team del carico di lavoro.
  • Usare uno degli acceleratori disponibili che corrisponde alle capacità del team per iniziare a distribuire le Azure Landing Zones.
  • Pianificare l'uso di un approccio di distribuzione a più livelli per aggiungere funzionalità non coperte da un acceleratore, ma necessarie per supportare completamente i team del carico di lavoro.
  • Stabilire un processo per l'uso del codice per implementare correzioni rapide. Registra sempre le correzioni rapide nel backlog del team, in modo che ogni correzione possa essere rielaborata in un secondo momento e si possa limitare il debito tecnico.
  • Usare Infrastruttura come Codice per distribuire e gestire Criteri di Azure (spesso definiti Criteri come Codice)
  • Implementare un processo di esenzione per le politiche. Preparati affinché i team di lavoro richiedano esenzioni dalle politiche ed essere pronti a sbloccarli quando necessario.
  • Usare "Governance basata su criteri" per bloccare i team di lavoro quando tentano di distribuire risorse che non soddisfano un controllo di sicurezza. Ciò consente di ridurre la deriva della configurazione, in cui il codice dichiara uno stato diverso da quello che finisce per essere distribuito.

Leggi di più