Delen via

Operationele procedures voor bedrijfskritieke workloads in Azure

  • Artikel

Betrouwbare en effectieve bewerkingen moeten waar mogelijk worden gebaseerd op de principes van automatisering en configuratie als code. Deze aanpak vereist een aanzienlijke technische investering in DevOps-processen. Geautomatiseerde pijplijnen worden gebruikt voor het implementeren van toepassings- en infrastructuurcodeartefacten. De voordelen van deze aanpak zijn consistente en nauwkeurige operationele resultaten met minimale handmatige operationele procedures.

In dit ontwerpgebied wordt verkend hoe u effectieve en consistente operationele procedures kunt implementeren.

Belangrijk

Dit artikel maakt deel uit van de serie bedrijfskritische workloads van Azure Well-Architected Framework . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met Wat is een essentiële workload? .

DevOps-processen

DevOps combineert ontwikkelings- en operationele processen en teams in één technische functie. Het omvat de volledige levenscyclus van toepassingen en maakt gebruik van automatisering en DevOps-hulpprogramma's om implementatiebewerkingen op een snelle, efficiënte en betrouwbare manier uit te voeren. DevOps-processen ondersteunen en ondersteunen continue integratie en continue levering (CI/CD), terwijl een cultuur van continue verbetering wordt bevorderd.

Het DevOps-team voor een bedrijfskritieke toepassing moet verantwoordelijk zijn voor deze taken:

  • Maken en beheren van toepassings- en infrastructuurresources via CI/CD-automatisering.
  • Toepassingsbewaking en waarneembaarheid.
  • Op rollen gebaseerd toegangsbeheer van Azure (RBAC) en identiteitsbeheer voor toepassingsonderdelen.
  • Netwerkbeheer voor toepassingsonderdelen.
  • Kostenbeheer voor toepassingsresources.

DevSecOps breidt het DevOps-model uit door beveiligingsbewaking, toepassingsaudits en kwaliteitsbewaking te integreren met ontwikkeling en bewerkingen gedurende de levenscyclus van de toepassing. DevOps-teams zijn nodig voor beveiligingsgevoelige en sterk gereglementeerde scenario's om ervoor te zorgen dat beveiliging tijdens de ontwikkelingslevenscyclus wordt opgenomen in plaats van in een specifieke releasefase of gate.

Overwegingen bij het ontwerpen

  • Release- en updateproces. Vermijd handmatige processen voor wijzigingen in toepassingsonderdelen of onderliggende infrastructuur. Handmatige processen kunnen leiden tot inconsistente resultaten.

  • Afhankelijk van centrale IT-teams. DevOps-processen kunnen moeilijk zijn toe te passen wanneer er harde afhankelijkheden zijn van gecentraliseerde functies, omdat deze afhankelijkheden end-to-end-bewerkingen voorkomen.

  • Identiteits- en toegangsbeheer. DevOps-teams kunnen gedetailleerde Azure RBAC-rollen overwegen voor verschillende technische functies, zoals AppDataOps voor databasebeheer. Een nulvertrouwensmodel toepassen op DevOps-rollen.

Ontwerpaanbeveling

  • Configuratie-instellingen en updates definiëren als code. Pas wijzigingsbeheer toe via code om consistente release- en updateprocessen mogelijk te maken, inclusief taken zoals sleutel- of geheimrotatie en machtigingenbeheer. Gebruik door pijplijnen beheerde updateprocessen, zoals geplande pijplijnuitvoeringen, in plaats van ingebouwde mechanismen voor automatisch bijwerken.

  • Gebruik geen centrale processen of inrichtingspijplijnen voor de instantiëring of het beheer van toepassingsresources. Hierdoor worden externe toepassingsafhankelijkheden en extra risicovectoren geïntroduceerd, zoals die zijn gekoppeld aan scenario's met ruis.

    Als u gecentraliseerde inrichtingsprocessen wilt gebruiken, moet u ervoor zorgen dat de beschikbaarheidsvereisten van de afhankelijkheden volledig zijn afgestemd op essentiële vereisten. Centrale teams moeten transparantie bieden, zodat een holistische operationalisering van de end-to-end-toepassing wordt bereikt.

  • Wijs tijdens elke sprint een deel van de technische capaciteit toe aan het aansturen van fundamentele platformverbeteringen en het verbeteren van de betrouwbaarheid. We raden u aan 20-40 procent van de capaciteit toe te wijzen aan deze verbeteringen.

  • Ontwikkel algemene technische criteria, referentiearchitecturen en bibliotheken die zijn afgestemd op de belangrijkste ontwerpprincipes. Dwing een consistente basislijnconfiguratie af voor betrouwbaarheid, beveiliging en bewerkingen via een beleidsgestuurde benadering die gebruikmaakt van Azure Policy.

    U kunt ook de algemene technische criteria en bijbehorende artefacten, zoals Azure-beleid en Terraform-resources, gebruiken voor algemene ontwerppatronen, voor andere workloads binnen het bredere toepassingsecosysteem van uw organisatie.

  • Een nulvertrouwensmodel toepassen in kritieke toepassingsomgevingen. Gebruik technologieën zoals Microsoft Entra Privileged Identity Management om ervoor te zorgen dat bewerkingen consistent zijn en alleen worden uitgevoerd via CI/CD-processen of geautomatiseerde operationele procedures.

    Teamleden mogen geen permanente schrijftoegang hebben tot een omgeving. U kunt uitzonderingen maken in ontwikkelomgevingen om eenvoudiger testen en foutopsporing mogelijk te maken.

  • Definieer noodprocessen voor Just-In-Time-toegang tot productieomgevingen. Zorg ervoor dat er break glass-accounts bestaan in het geval van ernstige problemen met de verificatieprovider.

  • Overweeg het gebruik van AIOps om operationele procedures en triggers voortdurend te verbeteren.

Toepassingsbewerkingen

Het toepassingsontwerp en de platformaanbeveling zijn van invloed op operationele procedures. Er zijn ook operationele mogelijkheden die worden geleverd door verschillende Azure-services, met name voor hoge beschikbaarheid en herstel.

Overwegingen bij het ontwerpen

  • Ingebouwde bewerkingen van Azure-services. Azure-services bieden ingebouwde (standaard ingeschakelde) en configureerbare platformmogelijkheden, zoals zonegebonden redundantie en geo-replicatie. De betrouwbaarheid van een toepassing is afhankelijk van deze bewerkingen. Voor bepaalde configureerbare mogelijkheden worden extra kosten in rekening gebracht, zoals de implementatieconfiguratie voor meerdere schrijfbewerkingen voor Azure Cosmos DB. Vermijd het bouwen van aangepaste oplossingen, tenzij dat absoluut nodig is.

  • Operationele toegang en uitvoeringstijd. De meeste vereiste bewerkingen zijn beschikbaar en toegankelijk via de Azure Resource Manager-API of de Azure Portal. Voor bepaalde bewerkingen is echter ondersteuning nodig van ondersteuningstechnici. Een herstel vanuit een periodieke back-up van een Azure Cosmos DB-database of het herstellen van een verwijderde resource kan bijvoorbeeld alleen worden uitgevoerd door ondersteuning voor Azure technici via een ondersteuningsaanvraag. Deze afhankelijkheid kan van invloed zijn op de downtime van de toepassing. Voor staatloze resources raden we u aan opnieuw te implementeren in plaats van te wachten tot ondersteuningstechnici proberen verwijderde resources te herstellen.

  • Beleidshandhaving. Azure Policy biedt een framework voor het afdwingen en controleren van basislijnen voor beveiliging en betrouwbaarheid om te zorgen voor naleving van algemene technische criteria voor bedrijfskritieke toepassingen. Meer specifiek vormt Azure Policy een belangrijk onderdeel van het Azure Resource Manager-besturingsvlak en vormt een aanvulling op RBAC door de acties te beperken die geautoriseerde gebruikers kunnen uitvoeren. U kunt Azure Policy gebruiken om essentiële beveiligings- en betrouwbaarheidsconventies af te dwingen in platformservices.

  • Wijzigen en verwijderen van resources. U kunt Azure-resources vergrendelen om te voorkomen dat ze worden gewijzigd of verwijderd. Vergrendelingen brengen echter beheeroverhead in implementatiepijplijnen met zich mee. Voor de meeste resources raden we een robuust RBAC-proces aan met strikte beperkingen in plaats van resourcevergrendelingen.

Ontwerpaanbeveling

  • Failoverprocedures automatiseren. Gebruik voor een actief/actief model een statusmodel en geautomatiseerde schaalbewerkingen om ervoor te zorgen dat er geen failover-interventie vereist is. Voor een actief/passief model moet u ervoor zorgen dat failoverprocedures zijn geautomatiseerd of ten minste gecodificeerd binnen pijplijnen.

  • Geef prioriteit aan het gebruik van automatisch schalen in Azure voor services die dit ondersteunen. Voor services die geen ondersteuning bieden voor systeemeigen automatische schaalaanpassing, gebruikt u geautomatiseerde operationele processen om services te schalen. Schaaleenheden met meerdere services gebruiken om schaalbaarheid te bereiken.

  • Gebruik platformeigen mogelijkheden voor back-up en herstel, zodat ze zijn afgestemd op uw RTO/RPO en vereisten voor gegevensretentie. Definieer indien nodig een strategie voor langetermijnretentie van back-ups.

  • Gebruik ingebouwde mogelijkheden voor SSL-certificaatbeheer en -verlenging, zoals die van Azure Front Door.

  • Stel voor externe teams een herstelproces in voor resources die hulp nodig hebben. Als het gegevensplatform bijvoorbeeld onjuist is gewijzigd of verwijderd, moeten de herstelmethoden goed worden begrepen en moet er een herstelproces worden uitgevoerd. Stel op dezelfde manier procedures in voor het beheren van uit bedrijf genomen containerinstallatiekopieën in het register.

  • Oefen van tevoren herstelbewerkingen op niet-productieresources en -gegevens als onderdeel van standaard voorbereidingen voor bedrijfscontinuïteit.

  • Kritieke waarschuwingen identificeren en doelgroepen en systemen definiëren. Definieer duidelijke kanalen om de juiste belanghebbenden te bereiken. Alleen bruikbare waarschuwingen verzenden om witte ruis te voorkomen en te voorkomen dat operationele belanghebbenden waarschuwingen negeren en belangrijke informatie missen. Implementeer continue verbetering om waarschuwingen te optimaliseren en waargenomen witte ruis te verwijderen.

  • Pas beleidsgestuurde governance en Azure Policy toe om te zorgen voor het juiste gebruik van operationele mogelijkheden en een betrouwbare configuratiebasislijn voor alle toepassingsservices.

  • Vermijd het gebruik van resourcevergrendelingen voor tijdelijke regionale resources. Vertrouw in plaats daarvan op het juiste gebruik van RBAC- en CI/CD-pijplijnen om operationele updates te beheren. U kunt resourcevergrendelingen toepassen om te voorkomen dat globale resources met een lange levensduur worden verwijderd.

Updatebeheer

Bedrijfskritiek ontwerp onderschrijft sterk het principe van tijdelijke staatloze toepassingsresources. Als u dit principe toepast, kunt u doorgaans een update uitvoeren met behulp van een nieuwe implementatie- en standaardleveringspijplijn.

Overwegingen bij het ontwerpen

  • Afstemming met Azure-roadmaps. Stem uw workload af met Azure-roadmaps, zodat platformresources en runtimeafhankelijkheden regelmatig worden bijgewerkt.

  • Automatische detectie van updates. Processen instellen om updates te controleren en automatisch te detecteren. Gebruik hulpprogramma's zoals GitHub Dependabot.

  • Testen en valideren. Test en valideer nieuwe versies van pakketten, onderdelen en afhankelijkheden in een productiecontext vóór een release. Nieuwe versies kunnen wijzigingen bevatten die fouten veroorzaken.

  • Runtime-afhankelijkheden. Behandel runtime-afhankelijkheden zoals u elke andere wijziging in de toepassing zou doen. Oudere versies kunnen leiden tot beveiligingsproblemen en kunnen een negatief effect hebben op de prestaties. De runtime-omgeving van de toepassing bewaken en up-to-date houden.

  • Onderdeel hygiëne en huishouding. Resources die niet worden gebruikt uit bedrijf nemen of verwijderen. Bewaak bijvoorbeeld containerregisters en verwijder oude installatiekopieën die u niet gebruikt.

Ontwerpaanbeveling

  • Bewaak deze resources en houd ze up-to-date:

    • Het platform voor het hosten van de toepassing. U moet bijvoorbeeld de Kubernetes-versie in Azure Kubernetes Service (AKS) regelmatig bijwerken, vooral omdat ondersteuning voor oudere versies niet wordt ondersteund. U moet ook onderdelen bijwerken die worden uitgevoerd op Kubernetes, zoals certificaatbeheer en de Azure Key Vault CSI, en deze afstemmen op de Kubernetes-versie in AKS.
    • Externe bibliotheken en SDK's (.NET, Java, Python).
    • Terraform-providers.

  • Vermijd handmatige operationele wijzigingen om onderdelen bij te werken. Overweeg het gebruik van handmatige wijzigingen alleen in noodsituaties. Zorg ervoor dat u een proces hebt voor het afstemmen van handmatige wijzigingen in de bronopslagplaats om afwijkingen en terugkerende problemen te voorkomen.

  • Stel een geautomatiseerde procedure in voor het verwijderen van oude versies van installatiekopieën uit Azure Container Registry.

Geheimenbeheer

Het verlopen van sleutels, geheimen en certificaten is een veelvoorkomende oorzaak van een toepassingsstoring. Geheimbeheer voor een bedrijfskritieke toepassing moet de benodigde beveiliging bieden en een geschikt beschikbaarheidsniveau bieden om te voldoen aan uw vereisten voor maximale betrouwbaarheid. U moet regelmatig sleutel-, geheim- en certificaatrotatie uitvoeren met behulp van een beheerde service of als onderdeel van updatebeheer, en processen toepassen voor code- en configuratiewijzigingen.

Veel Azure-services ondersteunen Microsoft Entra verificatie in plaats van te vertrouwen op verbindingsreeksen/sleutels. Het gebruik van Microsoft Entra-id vermindert de operationele overhead aanzienlijk. Als u een oplossing voor geheimbeheer gebruikt, moet deze worden geïntegreerd met andere services, zonegebonden en regionale redundantie ondersteunen en integratie bieden met Microsoft Entra-id voor verificatie en autorisatie. Key Vault biedt deze functies.

Overwegingen bij het ontwerpen

Er zijn drie algemene benaderingen voor geheimbeheer. Elke benadering leest geheimen uit het geheimarchief en injecteert deze op een ander moment in de toepassing.

  • Ophalen van implementatietijd. Het voordeel van deze benadering is dat de oplossing voor geheimbeheer alleen beschikbaar moet zijn tijdens de implementatie, omdat er na die tijd geen directe afhankelijkheden meer zijn. Voorbeelden hiervan zijn het injecteren van geheimen als omgevingsvariabelen in een Kubernetes-implementatie of in een Kubernetes-geheim.

    Alleen de implementatieservice-principal moet toegang hebben tot geheimen, wat de RBAC-machtigingen in het geheimbeheersysteem vereenvoudigt.

    Er zijn echter nadelen aan deze benadering. Het introduceert RBAC-complexiteit in DevOps-hulpprogramma's met betrekking tot het beheren van toegang tot service-principals en in de toepassing met betrekking tot het beveiligen van opgehaalde geheimen. Bovendien worden de beveiligingsvoordelen van de oplossing voor geheimbeheer niet toegepast, omdat deze benadering alleen afhankelijk is van toegangsbeheer in het toepassingsplatform.

    Als u geheime updates of rotatie wilt implementeren, moet u een volledige herimplementatie uitvoeren.

  • Ophalen van toepassingsstart. Bij deze benadering worden geheimen opgehaald en geïnjecteerd bij het opstarten van de toepassing. Het voordeel is dat u geheimen eenvoudig kunt bijwerken of roteren. U hoeft geen geheimen op te slaan op het toepassingsplatform. De toepassing moet opnieuw worden opgestart om de meest recente waarde op te halen.

    Veelvoorkomende opslagopties zijn Azure Key Vault Provider for Secrets Store CSI-stuurprogramma en akv2k8s. Er is ook een systeemeigen Azure-oplossing beschikbaar, Key Vault app-instellingen waarnaar wordt verwezen.

    Een nadeel van deze benadering is dat er een runtimeafhankelijkheid ontstaat van de oplossing voor geheimbeheer. Als de oplossing voor geheimbeheer een storing ondervindt, kunnen toepassingsonderdelen die al worden uitgevoerd mogelijk aanvragen blijven verwerken. Elke bewerking voor opnieuw opstarten of uitschalen zou waarschijnlijk leiden tot een fout.

  • Runtime ophalen. Het ophalen van geheimen tijdens runtime vanuit de toepassing zelf is de veiligste benadering, omdat zelfs het toepassingsplatform nooit toegang heeft tot geheimen. De toepassing moet zichzelf verifiëren bij het geheime beheersysteem.

    Voor deze aanpak vereisen toepassingsonderdelen echter een directe afhankelijkheid en een verbinding met het geheime beheersysteem. Dit maakt het moeilijker om onderdelen afzonderlijk te testen en vereist meestal het gebruik van een SDK.

Ontwerpaanbeveling

  • Gebruik indien mogelijk Microsoft Entra-verificatie om verbinding te maken met services in plaats van verbindingsreeksen of sleutels te gebruiken. Gebruik deze verificatiemethode in combinatie met door Azure beheerde identiteiten, zodat u geen geheimen hoeft op te slaan op het toepassingsplatform.

  • Profiteer van de verloopinstelling in Key Vault en configureer waarschuwingen voor toekomstige vervaldatums. Voer alle sleutel-, geheim- en certificaatupdates uit met behulp van het standaardreleaseproces.

  • Implementeer Key Vault-exemplaren als onderdeel van een regionale zegel om het potentiële effect van een fout in één implementatiestempel te beperken. Gebruik een afzonderlijk exemplaar voor globale resources. Zie het typische architectuurpatroon voor bedrijfskritieke workloads voor informatie over deze resources.

  • Om te voorkomen dat referenties voor service-principals of API-sleutels moeten worden beheerd, gebruikt u waar mogelijk beheerde identiteiten in plaats van service-principals om toegang te krijgen tot Key Vault.

  • Implementeer coderingspatronen om ervoor te zorgen dat geheimen opnieuw worden opgehaald wanneer er een autorisatiefout optreedt tijdens runtime.

  • Pas een volledig geautomatiseerd sleutelrotatieproces toe dat periodiek binnen de oplossing wordt uitgevoerd.

  • Gebruik de melding dat de sleutel bijna verloopt in Azure Key Vault om waarschuwingen te ontvangen over aanstaande vervaldatums.

IaaS-specifieke overwegingen bij het gebruik van VM's

Als u IaaS-VM's moet gebruiken, kunnen sommige procedures en procedures die eerder in dit document zijn beschreven, verschillen. Het gebruik van VM's biedt meer flexibiliteit in configuratieopties, besturingssystemen, toegang tot stuurprogramma's, toegang tot besturingssystemen op laag niveau en de soorten software die u kunt installeren. De nadelen zijn hogere operationele kosten en de verantwoordelijkheid voor taken die meestal door de cloudprovider worden uitgevoerd wanneer u PaaS-services gebruikt.

Overwegingen bij het ontwerpen

  • Afzonderlijke VM's bieden geen hoge beschikbaarheid, zoneredundantie of geo-redundantie.
  • Afzonderlijke VM's worden niet automatisch bijgewerkt nadat u ze hebt geïmplementeerd. Een geïmplementeerde SQL Server 2019 op Windows Server 2019 wordt bijvoorbeeld niet automatisch bijgewerkt naar een nieuwere release.
  • Services die worden uitgevoerd op een VIRTUELE machine hebben een speciale behandeling en extra hulpprogramma's nodig als u ze via infrastructuur als code wilt implementeren en configureren.
  • Azure werkt het platform regelmatig bij. Voor deze updates moet de VM mogelijk opnieuw worden opgestart. Updates waarvoor opnieuw moet worden opgestart, worden meestal van tevoren aangekondigd. Zie Onderhoud voor virtuele machines in Azure en Meldingen over gepland onderhoud verwerken.

Ontwerpaanbeveling

  • Vermijd handmatige bewerkingen op VM's en implementeer de juiste processen om wijzigingen te implementeren en uit te rollen.

    • Automatiseer het inrichten van Azure-resources met behulp van infrastructure-as-code-oplossingen zoals ARM-sjablonen (Azure Resource Manager), Bicep, Terraform of andere oplossingen.

  • Zorg ervoor dat operationele processen voor de implementatie van VM's, updates en back-up en herstel aanwezig zijn en correct zijn getest. Als u wilt testen op tolerantie, injecteert u fouten in de toepassing, noteert u fouten en beperkt u deze fouten.

  • Zorg ervoor dat er strategieën zijn om terug te keren naar de laatst bekende status als een nieuwere versie niet goed werkt.

  • Maak frequente back-ups voor stateful workloads, zorg ervoor dat back-uptaken effectief werken en implementeer waarschuwingen voor mislukte back-upprocessen.

  • Vm's bewaken en detecteren op fouten. De onbewerkte gegevens voor bewaking kunnen afkomstig zijn uit verschillende bronnen. De oorzaken van problemen analyseren.

  • Zorg ervoor dat geplande back-ups worden uitgevoerd zoals verwacht en dat periodieke back-ups zo nodig worden gemaakt. U kunt back-upcentrum gebruiken om inzichten te verkrijgen.

  • Geef prioriteit aan het gebruik van Virtual Machine Scale Sets in plaats van VM's om mogelijkheden zoals schalen, automatisch schalen en zoneredundantie in te schakelen.

  • Geef prioriteit aan het gebruik van standaardinstallatiekopieën van Azure Marketplace in plaats van aangepaste installatiekopieën die moeten worden onderhouden.

  • Gebruik Azure VM Image Builder of andere hulpprogramma's om bouw- en onderhoudsprocessen voor aangepaste installatiekopieën indien nodig te automatiseren.

Afgezien van deze specifieke aanbevelingen past u best practices toe voor operationele procedures voor bedrijfskritieke toepassingsscenario's.

Volgende stap

Bekijk het architectuurpatroon voor essentiële toepassingsscenario's:

Architectuurpatroon