Operativa procedurer för verksamhetskritiska arbetsbelastningar i Azure

Tillförlitliga och effektiva åtgärder måste baseras på principerna för automatisering där det är möjligt och konfiguration som kod. Den här metoden kräver en betydande teknisk investering i DevOps-processer. Automatiserade pipelines används för att distribuera kodartefakter för program och infrastruktur. Fördelarna med den här metoden är konsekventa och korrekta operativa resultat med minimala manuella operativa procedurer.

Det här designområdet utforskar hur du implementerar effektiva och konsekventa operativa procedurer.

Viktigt

Den här artikeln är en del av den verksamhetskritiska arbetsbelastningsserien för Azure Well-Architected Framework . Om du inte är bekant med den här serien rekommenderar vi att du börjar med Vad är en verksamhetskritisk arbetsbelastning?.

DevOps-processer

DevOps kombinerar utveckling och driftsprocesser och team till en enda teknisk funktion. Den omfattar hela programlivscykeln och använder automatiserings- och DevOps-verktyg för att utföra distributionsåtgärder på ett snabbt, effektivt och tillförlitligt sätt. DevOps-processer stöder och upprätthåller kontinuerlig integrering och kontinuerlig leverans (CI/CD) samtidigt som en kultur av kontinuerlig förbättring främjas.

DevOps-teamet för ett verksamhetskritiskt program måste ansvara för dessa uppgifter:

• Skapa och hantera program- och infrastrukturresurser via CI/CD-automatisering.
• Programövervakning och observerbarhet.
• Rollbaserad åtkomstkontroll i Azure (RBAC) och identitetshantering för programkomponenter.
• Nätverkshantering för programkomponenter.
• Kostnadshantering för programresurser.

DevSecOps utökar DevOps-modellen genom att integrera säkerhetsövervakning, programgranskningar och kvalitetssäkring med utveckling och åtgärder under hela programlivscykeln. DevOps-team behövs för säkerhetskänsliga och strikt reglerade scenarier för att säkerställa att säkerheten införlivas under utvecklingslivscykeln i stället för i ett specifikt lanseringsstadium eller en specifik port.

Designöverväganden

• Lanserings- och uppdateringsprocess. Undvik manuella processer för ändringar av programkomponenter eller underliggande infrastruktur. Manuella processer kan leda till inkonsekventa resultat.

• Beroenden för centrala IT-team. DevOps-processer kan vara svåra att tillämpa när det finns hårda beroenden för centraliserade funktioner eftersom dessa beroenden förhindrar åtgärder från slutpunkt till slutpunkt.

• Identitets- och åtkomsthantering. DevOps-team kan överväga detaljerade Azure RBAC-roller för olika tekniska funktioner, till exempel AppDataOps för databashantering. Tillämpa en nollförtroendemodell för DevOps-roller.

Designrekommendationer

• Definiera konfigurationsinställningar och uppdateringar som kod. Använd ändringshantering via kod för att aktivera konsekventa processer för lansering och uppdatering, inklusive uppgifter som nyckelrotation eller hemlig rotation och behörighetshantering. Använd pipelinehanterade uppdateringsprocesser, till exempel schemalagda pipelinekörningar, i stället för inbyggda mekanismer för automatisk uppdatering.

• Använd inte centrala processer eller etableringspipelines för instansiering eller hantering av programresurser. På så sätt introduceras externa programberoenden och ytterligare riskvektorer, till exempel de som är associerade med scenarier med bullriga grannar.

  Om du behöver använda centraliserade etableringsprocesser kontrollerar du att tillgänglighetskraven för beroendena är helt i linje med verksamhetskritiska krav. Centrala team måste tillhandahålla transparens så att en holistisk operationalisering av programmet från slutpunkt till slutpunkt uppnås.

• Ägna en del av ingenjörskapaciteten under varje sprint till att driva grundläggande plattformsförbättringar och stärka tillförlitligheten. Vi rekommenderar att du allokerar 20–40 procent av kapaciteten till dessa förbättringar.

• Utveckla vanliga tekniska kriterier, referensarkitekturer och bibliotek som är anpassade till grundläggande designprinciper. Framtvinga en konsekvent baslinjekonfiguration för tillförlitlighet, säkerhet och åtgärder via en principdriven metod som använder Azure Policy.

  Du kan också använda vanliga tekniska kriterier och associerade artefakter, till exempel Azure-principer och Terraform-resurser för vanliga designmönster, för andra arbetsbelastningar i organisationens bredare programekosystem.

• Tillämpa en nollförtroendemodell i kritiska programmiljöer. Använd tekniker som Microsoft Entra Privileged Identity Management för att säkerställa att åtgärderna är konsekventa och endast sker via CI/CD-processer eller automatiserade operativa procedurer.

  Gruppmedlemmar ska inte ha stående skrivåtkomst till någon miljö. Du kanske vill göra undantag i utvecklingsmiljöer för enklare testning och felsökning.

• Definiera nödsituationsprocesser för just-in-time-åtkomst till produktionsmiljöer. Kontrollera att break glass-konton finns i händelse av allvarliga problem med autentiseringsprovidern.

• Överväg att använda AIOps för att kontinuerligt förbättra operativa procedurer och utlösare.

Programåtgärder

Programdesignen och plattformsrekommendationerna påverkar operativa procedurer. Det finns även driftfunktioner som tillhandahålls av olika Azure-tjänster, särskilt för hög tillgänglighet och återställning.

Designöverväganden

• Inbyggda åtgärder för Azure-tjänster. Azure-tjänster tillhandahåller inbyggda (aktiverade som standard) och konfigurerbara plattformsfunktioner, till exempel zonredundans och geo-replikering. Ett programs tillförlitlighet beror på dessa åtgärder. Vissa konfigurerbara funktioner medför en extra kostnad, till exempel distributionskonfigurationen för flera skrivning för Azure Cosmos DB. Undvik att skapa anpassade lösningar om du inte absolut behöver det.

• Driftåtkomst och körningstid. De flesta nödvändiga åtgärder exponeras och är tillgängliga via Azure Resource Manager-API:et eller Azure Portal. Vissa åtgärder kräver dock hjälp från supporttekniker. En återställning från en periodisk säkerhetskopia av en Azure Cosmos DB-databas eller återställning av en borttagen resurs kan till exempel endast utföras av Azure Support tekniker via ett supportärende. Det här beroendet kan påverka programmets stilleståndstid. För tillståndslösa resurser rekommenderar vi att du distribuerar om i stället för att vänta på att supporttekniker försöker återställa borttagna resurser.

• Principframtvingande. Azure Policy tillhandahåller ett ramverk för att framtvinga och granska säkerhets- och tillförlitlighetsbaslinjer för att säkerställa efterlevnad av vanliga tekniska kriterier för verksamhetskritiska program. Mer specifikt utgör Azure Policy en viktig del av Azure Resource Manager kontrollplan, vilket kompletterar RBAC genom att begränsa de åtgärder som behöriga användare kan utföra. Du kan använda Azure Policy för att framtvinga viktiga säkerhets- och tillförlitlighetskonventioner för plattformstjänster.

• Ändring och borttagning av resurser. Du kan låsa Azure-resurser för att förhindra att de ändras eller tas bort. Lås medför dock hanteringskostnader i distributionspipelines. För de flesta resurser rekommenderar vi en robust RBAC-process med snäva begränsningar snarare än resurslås.

Designrekommendationer

• Automatisera redundansprocedurer. För en aktiv/aktiv modell använder du en hälsomodell och automatiserade skalningsåtgärder för att säkerställa att ingen redundansåtgärd krävs. För en aktiv/passiv modell kontrollerar du att redundansprocedurerna automatiseras eller åtminstone kodas i pipelines.

• Prioritera användningen av Azure-inbyggd autoskalning för tjänster som stöder den. För tjänster som inte stöder inbyggd autoskalning använder du automatiserade driftsprocesser för att skala tjänster. Använd skalningsenheter med flera tjänster för att uppnå skalbarhet.

• Använd plattformsbaserade funktioner för säkerhetskopiering och återställning, vilket säkerställer att de är i linje med dina RTO/RPO- och datakvarhållningskrav. Definiera en strategi för långsiktig kvarhållning av säkerhetskopior efter behov.

• Använd inbyggda funktioner för SSL-certifikathantering och -förnyelse, som de som tillhandahålls av Azure Front Door.

• För externa team upprättar du en återställningsprocess för resurser som behöver hjälp. Om dataplattformen till exempel har ändrats eller tagits bort felaktigt bör återställningsmetoderna förstås väl och en återställningsprocess bör vara på plats. På samma sätt upprättar du procedurer för att hantera inaktiverade containeravbildningar i registret.

• Öva på återställningsåtgärder i förväg, på icke-produktionsresurser och data, som en del av standardförberedelserna för affärskontinuitet.

• Identifiera kritiska aviseringar och definiera målgrupper och system. Definiera tydliga kanaler för att nå lämpliga intressenter. Skicka endast åtgärdsbara aviseringar för att undvika vitt brus och förhindra att driftsintressenter ignorerar aviseringar och saknar viktig information. Implementera kontinuerlig förbättring för att optimera aviseringar och ta bort observerat vitt brus.

• Tillämpa principdriven styrning och Azure Policy för att säkerställa lämplig användning av driftsfunktioner och en tillförlitlig konfigurationsbaslinje för alla programtjänster.

• Undvik att använda resurslås på tillfälliga regionala resurser. Förlita dig i stället på lämplig användning av RBAC- och CI/CD-pipelines för att kontrollera driftuppdateringar. Du kan använda resurslås för att förhindra borttagning av långvariga globala resurser.

Hantering av uppdateringar

Verksamhetskritisk design stöder starkt principen om tillfälliga tillståndslösa programresurser. Om du tillämpar den här principen kan du vanligtvis utföra en uppdatering med hjälp av en ny distribution och standardleveranspipelines.

Designöverväganden

• Anpassning med Azure-översikter. Anpassa din arbetsbelastning med Azure-översikter så att plattformsresurser och körningsberoenden uppdateras regelbundet.

• Automatisk identifiering av uppdateringar. Konfigurera processer för att övervaka och automatiskt identifiera uppdateringar. Använd verktyg som GitHub Dependabot.

• Testning och validering. Testa och validera nya versioner av paket, komponenter och beroenden i en produktionskontext innan någon version släpps. Nya versioner kan innehålla icke-bakåtkompatibla ändringar.

• Körningsberoenden. Hantera körningsberoenden på samma sätt som om du skulle göra andra ändringar i programmet. Äldre versioner kan medföra säkerhetsproblem och kan ha en negativ inverkan på prestandan. Övervaka programmets körningsmiljö och håll den uppdaterad.

• Komponenthygien och hushållning. Inaktivera eller ta bort resurser som inte används. Du kan till exempel övervaka containerregister och ta bort gamla avbildningsversioner som du inte använder.

Designrekommendationer

• Övervaka dessa resurser och håll dem uppdaterade:

  • Programvärdplattformen. Du måste till exempel uppdatera Kubernetes-versionen i Azure Kubernetes Service (AKS) regelbundet, särskilt med tanke på att stöd för äldre versioner inte upprätthålls. Du måste också uppdatera komponenter som körs på Kubernetes, till exempel cert-manager och Azure Key Vault CSI, och justera dem med Kubernetes-versionen i AKS.
  • Externa bibliotek och SDK:er (.NET, Java, Python).
  • Terraform-providrar.

• Undvik manuella driftsändringar för att uppdatera komponenter. Överväg att endast använda manuella ändringar i nödsituationer. Se till att du har en process för att stämma av eventuella manuella ändringar tillbaka till källlagringsplatsen för att undvika drift och problem med upprepning.

• Upprätta en automatiserad procedur för att ta bort gamla versioner av avbildningar från Azure Container Registry.

Hemlighetshantering

Förfallodatum för nycklar, hemligheter och certifikat är en vanlig orsak till programavbrott. Hemlighetshantering för ett verksamhetskritiskt program måste ge nödvändig säkerhet och erbjuda en lämplig tillgänglighetsnivå för att uppfylla dina krav på maximal tillförlitlighet. Du måste regelbundet utföra nyckel-, hemlighets- och certifikatrotation med hjälp av en hanterad tjänst eller som en del av uppdateringshanteringen och tillämpa processer för kod- och konfigurationsändringar.

Många Azure-tjänster stöder Microsoft Entra autentisering i stället för att förlita sig på anslutningssträngar/nycklar. Användning av Microsoft Entra-ID minskar avsevärt driftskostnaderna. Om du använder en lösning för hemlig hantering bör den integreras med andra tjänster, stödja zonindelad och regional redundans och tillhandahålla integrering med Microsoft Entra-ID för autentisering och auktorisering. Key Vault innehåller dessa funktioner.

Designöverväganden

Det finns tre vanliga metoder för hantering av hemligheter. Varje metod läser hemligheter från det hemliga arkivet och matar in dem i programmet vid olika tidpunkter.

• Distributionstidshämtning. Fördelen med den här metoden är att den hemliga hanteringslösningen bara måste vara tillgänglig vid distributionen eftersom det inte finns direkta beroenden efter den tiden. Exempel är att mata in hemligheter som miljövariabler i en Kubernetes-distribution eller i en Kubernetes-hemlighet.

  Endast distributionstjänstens huvudnamn behöver kunna komma åt hemligheter, vilket förenklar RBAC-behörigheter i det hemliga hanteringssystemet.

  Det finns dock nackdelar med den här metoden. Den introducerar RBAC-komplexitet i DevOps-verktyg när det gäller att kontrollera åtkomsten till tjänstens huvudnamn och i programmet när det gäller att skydda hämtade hemligheter. Dessutom tillämpas inte säkerhetsfördelarna med den hemliga hanteringslösningen eftersom den här metoden endast förlitar sig på åtkomstkontroll på programplattformen.

  Om du vill implementera uppdateringar eller rotation av hemligheter måste du utföra en fullständig omdistribution.

• Hämtning av programstart. I den här metoden hämtas och matas hemligheter in vid programstart. Fördelen är att du enkelt kan uppdatera eller rotera hemligheter. Du behöver inte lagra hemligheter på programplattformen. En omstart av programmet krävs för att hämta det senaste värdet.

  Vanliga lagringsalternativ är Azure Key Vault Provider för Secrets Store CSI-drivrutin och akv2k8s. En intern Azure-lösning, Key Vault refererade appinställningar, är också tillgänglig.

  En nackdel med den här metoden är att den skapar ett körningsberoende för den hemliga hanteringslösningen. Om det uppstår ett avbrott i den hemliga hanteringslösningen kan programkomponenter som redan körs fortsätta att hantera begäranden. En omstarts- eller utskalningsåtgärd skulle sannolikt leda till fel.

• Körningshämtning. Att hämta hemligheter vid körning inifrån själva programmet är den säkraste metoden eftersom inte ens programplattformen har åtkomst till hemligheter. Programmet måste autentisera sig mot det hemliga hanteringssystemet.

  För den här metoden kräver dock programkomponenter ett direkt beroende och en anslutning till det hemliga hanteringssystemet. Detta gör det svårare att testa komponenter individuellt och kräver vanligtvis användning av ett SDK.

Designrekommendationer

• Använd om möjligt Microsoft Entra-autentisering för att ansluta till tjänster i stället för att använda anslutningssträngar eller nycklar. Använd den här autentiseringsmetoden tillsammans med hanterade Azure-identiteter så att du inte behöver lagra hemligheter på programplattformen.

• Dra nytta av inställningen för förfallodatum i Key Vault och konfigurera aviseringar för kommande förfallodatum. Utför alla nyckel-, hemlighets- och certifikatuppdateringar med hjälp av standardversionen.

• Distribuera Key Vault instanser som en del av en regional stämpel för att minimera den potentiella effekten av ett fel på en enda distributionsstämpel. Använd en separat instans för globala resurser. Information om dessa resurser finns i det typiska arkitekturmönstret för verksamhetskritiska arbetsbelastningar.

• Om du vill undvika behovet av att hantera autentiseringsuppgifter för tjänstens huvudnamn eller API-nycklar använder du hanterade identiteter i stället för tjänstens huvudnamn för att få åtkomst till Key Vault när det är möjligt.

• Implementera kodningsmönster för att säkerställa att hemligheter hämtas igen när ett auktoriseringsfel inträffar vid körning.

• Tillämpa en helt automatiserad nyckelrotationsprocess som körs regelbundet i lösningen.

• Använd meddelandet om nära förfallodatum i Azure Key Vault för att få aviseringar om kommande förfallodatum.

IaaS-specifika överväganden när du använder virtuella datorer

Om du behöver använda virtuella IaaS-datorer kan vissa procedurer och metoder som beskrivs tidigare i det här dokumentet skilja sig åt. Användningen av virtuella datorer ger större flexibilitet i konfigurationsalternativ, operativsystem, drivrutinsåtkomst, åtkomst till operativsystem på låg nivå och de typer av programvara som du kan installera. Nackdelarna är ökade driftskostnader och ansvaret för uppgifter som vanligtvis utförs av molnleverantören när du använder PaaS-tjänster.

Designöverväganden

• Enskilda virtuella datorer ger inte hög tillgänglighet, zonredundans eller geo-redundans.
• Enskilda virtuella datorer uppdateras inte automatiskt när du har distribuerat dem. En distribuerad SQL Server 2019 på Windows Server 2019 uppdateras till exempel inte automatiskt till en nyare version.
• Tjänster som körs på en virtuell dator behöver särskild behandling och ytterligare verktyg om du vill distribuera och konfigurera dem via infrastruktur som kod.
• Azure uppdaterar regelbundet sin plattform. Dessa uppdateringar kan kräva omstart av virtuella datorer. Uppdateringar som kräver en omstart meddelas vanligtvis i förväg. Se Underhåll för virtuella datorer i Azure och Hantera aviseringar om planerat underhåll.

Designrekommendationer

• Undvik manuella åtgärder på virtuella datorer och implementera rätt processer för att distribuera och distribuera ändringar.

  • Automatisera etableringen av Azure-resurser med hjälp av infrastruktur som kod-lösningar som Arm-mallar (Azure Resource Manager), Bicep, Terraform eller andra lösningar.

• Se till att driftsprocesserna för distribution av virtuella datorer, uppdateringar och säkerhetskopiering och återställning är på plats och testas korrekt. Testa återhämtning genom att mata in fel i programmet, anteckna fel och åtgärda dessa fel.

• Se till att strategier finns på plats för att återställa till det senast kända felfria tillståndet om en nyare version inte fungerar korrekt.

• Skapa frekventa säkerhetskopieringar för tillståndskänsliga arbetsbelastningar, se till att säkerhetskopieringsuppgifter fungerar effektivt och implementera aviseringar för misslyckade säkerhetskopieringsprocesser.

• Övervaka virtuella datorer och identifiera fel. Rådata för övervakning kan komma från en mängd olika källor. Analysera orsakerna till problem.

• Se till att schemalagda säkerhetskopieringar körs som förväntat och att regelbundna säkerhetskopieringar skapas efter behov. Du kan använda Backup Center för att få insikter.

• Prioritera användningen av Virtual Machine Scale Sets i stället för virtuella datorer för att aktivera funktioner som skalning, autoskalning och zonredundans.

• Prioritera användningen av standardbilder från Azure Marketplace i stället för anpassade avbildningar som måste underhållas.

• Använd Azure VM Image Builder eller andra verktyg för att automatisera bygg- och underhållsprocesser för anpassade avbildningar efter behov.

Utöver dessa specifika rekommendationer tillämpar du bästa praxis för operativa procedurer för verksamhetskritiska programscenarier efter behov.

Nästa steg

Granska arkitekturmönstret för verksamhetskritiska programscenarier:

Arkitekturmönster