Dela via

Automatisering

  • Artikel

I programvarudefinierad molninfrastruktur använder teamen olika verktyg och tekniker för att etablera, konfigurera och hantera infrastrukturen. När dina team utvecklas och växer kan de övergå från att använda portaler och manuella ansträngningar till att använda kod och automatisering för att etablera, konfigurera och hantera infrastruktur och tjänster.

Överväganden för plattformsautomatisering

  • Genom att implementera metoden Allt som kod (EaC) kan dina team frigöra viktiga fördelar, skapa en stark utvecklingskultur och göra det möjligt för alla i varje team att inspektera hur och vilka resurser som distribueras. EaC hjälper även dina plattformsteam att införa viktiga utvecklingsmetoder som förbättrar deras flexibilitet och effektivitet. Dina team kan spåra ändringar och kontrollera vilka som flyttas till produktion genom att inhysa kod i lagringsplatser och använda versionskontrollsystem för att hantera den.
  • Teams kan följa 4-ögons princip och använda peer-programmering eller peer-granskning för att säkerställa att kodändringar aldrig görs ensamma. Peer-programmering och peer-granskning förbättrar kodkvaliteten, låter team dela ansvaret för ändringar och öka teamets kunskap om vad som är överenskommet och distribuerat. Kodgranskning är ett fantastiskt sätt för teammedlemmar att lära sig nya tekniker och metoder för kodning och automatisering.
  • Teams bör använda versionskontrollsystem som Git, tillsammans med Git-lagringsplatser, för att framtvinga peer-granskning. Med Git-lagringsplatser kan dina team definiera viktiga grenar och skydda dem med förgreningsprinciper. Du kan använda principen för att kräva kodändringar på dessa grenar för att uppfylla vissa kriterier, till exempel ett minsta antal godkännanden för teammedlemmar, innan de kan slås samman till en skyddad gren.
  • Teams bör koppla samman EaC-metoden och ändringsgranskningsprocessen med en kontinuerlig integration och kontinuerlig leverans (CI/CD)-process. Varje kodändring ska automatiskt utlösa en CI-process som kör statisk kodanalys, validering och testdistributioner. CI säkerställer att utvecklare kontrollerar sin kod tidigt (kallas ofta misslyckas snabbt eller shift-left-testning) efter fel som kan orsaka framtida problem. Beroende på vilken förgreningsstrategi ditt team använder bör ändringar i en viktig gren utlösa distribution till olika miljöer. När ändringarna har godkänts och sammanfogats i maindistribuerar CD-processen ändringarna till produktion. Det här kodhanteringssystem ger ditt team en enhetlig sanningskälla för vad som körs i varje miljö.
  • För att säkerställa att din plattform är helt självläkande och tillhandahåller självbetjäning för team som hanterar arbetsbelastningar måste ditt plattformsteam arbeta för att automatisera allt (kallas ofta Extreme Automation) från tilldelning, konfiguration och plattformshantering till tilldelning av prenumerationer i landningszoner för arbetsbelastningsteam. Med extrem automatisering kan ditt plattformsteam fokusera på att tillhandahålla värde i stället för att distribuera, konfigurera och hantera din plattform. Extrem automatisering skapar också en självförbättrande cykel som ger ditt team mer tid att skapa mer automatisering.
  • När dina plattformsteam automatiserar operativa aktiviteter och minskar mänsklig inblandning bör de flytta fokus till viktiga uppgifter som möjliggör och påskyndar arbetsbelastningsteamets innovation i Azure. För att uppnå detta måste ditt plattformsteam iterera genom flera cykler av skapande och utveckling när de inför plattformens verktyg, skript och kapacitetsförbättringar.
  • Det finns flera alternativ som hjälper ditt team att komma igång med distributionen av Azure Landing Zone. De här alternativen beror på teamets aktuella funktioner och kan växa allt eftersom ditt team utvecklas. Mer specifikt för Platform Deploymentkan du välja mellan portal-, Bicep- eller Terraform-baserade upplevelser, beroende på IaC-kunskaper (infrastruktur som kod) och verktygspreferenser för respektive team.
    • Nya och framväxande plattformsteam som håller på att bekanta sig med IaC- och är vana vid att använda en portal för att distribuera och hantera resurser kan använda Azure landing zone-acceleratorn. Den här acceleratorn stöder team som för närvarande använder en ClickOps- metod. ClickOps är processen för att etablera, konfigurera och hantera resurser genom att klicka på portaler, hanteringskonsoler och guider. Med den här acceleratorn kan ditt team använda portalen som ett första distributionsverktyg. I takt med att plattformsteknikens mognad växer kan ditt team gradvis införliva Azure CLI, PowerShell eller IaC.
    • Med AzOps-lösningen kan teamen utveckla sina metoder för plattformsautomatisering och hantering från att vara ClickOps-drivna till att bli DevOps-kompatibla. Ditt team kan övergå från att använda sin personliga kontoåtkomst till att använda DevOps-principer och -metoder som endast förlitar sig på CI/CD med AzOps och IaC. AzOps låter ditt team ta med sin egen arkitektur, använda arkitekturen som distribueras av Azure Landing Zone Portal-acceleratorn (efter den första portalbaserade distributionen, eftersom AzOps-integrering inte ingår i ALZ-portalen), integrera med en distribution med brunfält eller använda anpassade mallar (Bicep eller ARM) för att skapa och operationalisera din plattform.
    • Plattformsteam med etablerade färdigheter och funktioner kan anta en kodifierad metod som följer DevOps-principer och -metoder. Ditt team bör basera sig mycket på IaC och moderna utvecklingsmetoder, övergå från att använda Azure-åtkomst på sina personliga konton och köra alla åtgärder via din CI/CD-pipeline. Ditt team bör använda IaC-baserade acceleratorer som ALZ-Bicep eller Terraformmodulen Azure-landningszoner för att påskynda övergången.
  • IaC-baserade acceleratorer har begränsat hanteringsomfång. Nya versioner ger fler funktioner och ökad resurshantering. Om du använder en accelerator bör ditt team överväga en metod i flera lager som börjar med en accelerator och sedan lägga till ett lager av automatisering. Automatiseringslagret innehåller funktioner som ditt team behöver för att fullt ut stödja dina arbetsbelastningsteam med plattformsfunktioner som distribution av domänkontrollanter för äldre program.
  • När ditt plattformsteam övergår till en DevOps-metod måste de upprätta en process för hantering av nödkorrigeringar. De kan använda Privileged Identity Management (PIM) berättigade behörigheter för att begära åtkomst för att utföra korrigeringar och senare föra tillbaka den till kod för att minska risken för konfigurationsdrift, eller så kan de använda kod för att implementera en snabbkorrigering. Ditt team bör alltid registrera snabbkorrigeringar i sina kvarvarande uppgifter så att de kan omarbeta varje korrigering vid ett senare tillfälle och begränsa sin tekniska skuld. För mycket teknisk skuld leder till framtida inbromsning eftersom viss plattformskod inte är helt granskad och inte uppfyller riktlinjerna och principerna för teamkodning.
  • Du kan använda Azure-principer för att lägga till viss automatisering i din plattform. Överväg att använda IaC för att distribuera och hantera Azure-principer, som ofta kallas PaC (Policy-as-Code). Med de här principerna kan du automatisera aktiviteter som logginsamling. Många PaC-ramverk implementerar också en undantagsprocess, så planera för att dina team ska kunna begära undantag från policyer.
  • Använd "Principdriven styrning" för att signalera till arbetslag när de försöker distribuera resurser som inte uppfyller en säkerhetskontroll. Överväg att distribuera principer med deny effekt för dessa situationer, vilket gör att dina arbetsbelastningsteam även kan behandla Allt som kod och undvika konfigurationsavvikelser där koden deklarerar en sak och principen ändrade en inställning vid distributionstillfället. Undvik att använda modify konsekvenser, till exempel om ett arbetsbelastningsteam distribuerar ett lagringskonto med supportOnlyHttpsTraffic = false som definierats i koden där en modify policy ändrar det till true vid distributionstillfället för att hålla den kompatibel. Detta orsakar att koden avviker från det som är implementerat.

Designrekommendations för plattformsautomatisering

  • Följ en Allt som kod metod för fullständig transparens och konfigurationskontroll av Azure-plattformen, dokumentationen, distributionen och testningsprocessen.
  • Använd versionskontroll för att hantera alla dina kodlagringsplatser, inklusive:
    • Infrastruktur som kod
    • Princip som kod
    • Konfiguration som kod
    • Distribution som kod
    • Dokumentation som kod
  • Implementera 4-ögonsprincipen och en process för parprogrammering eller granskning av kollegor för att säkerställa att alla kodändringar granskas av ditt team innan de driftsätts.
  • Anta en förgreningsstrategi för ditt team och fastställ grenpolicys för grenar som du vill skydda. Med grenprinciper måste teamen använda pull-begäranden för att göra sammanslagningsändringar.
  • Använd kontinuerlig integrering och kontinuerlig leverans (CI/CD) för att automatisera kodtestning och distribution till olika miljöer.
  • Arbeta för att automatisera allt, till exempel etableringen, konfigurationen och hanteringen av din plattform samt etableringen av landningszonprenumerationer för dina arbetslag.
  • Använd en av de tillgängliga acceleratorerna som matchar teamets funktioner för att komma igång med att distribuera Azure-landningszoner.
  • Planera att använda en distributionsmetod i flera lager för att lägga till funktioner som inte omfattas av en accelerator, men som behövs för att fullt ut stödja dina arbetsbelastningsteam.
  • Upprätta en process för att använda kod för att implementera snabbkorrigeringar. Registrera alltid snabbkorrigeringar i teamets kvarvarande uppgifter så att varje korrigering kan omarbetas vid ett senare tillfälle och du kan begränsa tekniska skulder.
  • Använd Infrastruktur som kod för att distribuera och hantera Azure-principer (kallas ofta princip som kod)
  • Implementera en undantagsprocess för principer. Planera för att dina arbetsgrupper ska begära undantag från policyer och vara redo att fria teamen från hinder när det behövs.
  • Använd "Principdriven styrning" för att blockera arbetsbelastningsteam när de försöker distribuera resurser som inte uppfyller en säkerhetskontroll. Detta hjälper till att minska konfigurationsavvikelsen, där koden deklarerar ett annat tillstånd än vad som distribueras.

Läs mer