Implementatie en testen voor bedrijfskritieke workloads in Azure

Mislukte implementaties en onjuiste releases zijn veelvoorkomende oorzaken voor storingen in toepassingen. Uw implementatie- en testbenadering speelt een cruciale rol in de algehele betrouwbaarheid van een bedrijfskritieke toepassing.

Implementatie en testen moeten de basis vormen voor alle toepassings- en infrastructuurbewerkingen om consistente resultaten te garanderen voor bedrijfskritieke workloads. Wees voorbereid om wekelijks, dagelijks of vaker te implementeren. Ontwerp uw CI/CD-pijplijnen (continue integratie en continue implementatie) om deze doelstellingen te ondersteunen.

De strategie moet het volgende implementeren:

• Strenge pre-release testen. Updates mogen geen defecten, beveiligingsproblemen of andere factoren introduceren die de toepassingsstatus in gevaar kunnen brengen.

• Transparante implementaties. Het moet mogelijk zijn om updates op elk gewenst moment uit te rollen zonder dat dit van invloed is op gebruikers. Gebruikers moeten zonder onderbreking hun interactie met de toepassing kunnen voortzetten.

• Maximaal beschikbare bewerkingen. Implementatie- en testprocessen en -hulpprogramma's moeten maximaal beschikbaar zijn om de algehele betrouwbaarheid van toepassingen te ondersteunen.

• Consistente implementatieprocessen. Dezelfde toepassingsartefacten en -processen moeten worden gebruikt om de infrastructuur- en toepassingscode in verschillende omgevingen te implementeren. End-to-end automatisering is verplicht. Handmatige interventies moeten worden vermeden omdat ze betrouwbaarheidsrisico's kunnen veroorzaken.

Dit ontwerpgebied bevat aanbevelingen voor het optimaliseren van implementatie- en testprocessen met het doel downtime te minimaliseren en de status en beschikbaarheid van toepassingen te behouden.

Belangrijk

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

Implementatie zonder downtime

Bekijk de volgende video voor een overzicht van implementatie zonder downtime.

Het bereiken van implementaties zonder downtime is een fundamenteel doel voor bedrijfskritieke toepassingen. Uw toepassing moet de hele dag, elke dag beschikbaar zijn, zelfs wanneer er nieuwe releases worden geïmplementeerd tijdens kantooruren. Investeer uw inspanningen vooraf om implementatieprocessen te definiëren en te plannen om belangrijke ontwerpbeslissingen te nemen, zoals of resources kortstondig moeten worden behandeld.

Als u een implementatie zonder downtime wilt realiseren, implementeert u een nieuwe infrastructuur naast de bestaande infrastructuur, test u deze grondig, zet u het verkeer van eindgebruikers over en implementeert u alleen de vorige infrastructuur. Andere procedures, zoals de architectuur voor schaaleenheden, zijn ook belangrijk.

De mission-critical online - en Azure Mission-Critical Connected-referentieimplementaties illustreren deze implementatiebenadering, zoals wordt weergegeven in dit diagram:

Toepassingsomgevingen

Bekijk de volgende video voor een overzicht van aanbevelingen voor toepassingsomgevingen.

U hebt verschillende soorten omgevingen nodig om implementatiebewerkingen te valideren en te fasen. De typen hebben verschillende mogelijkheden en levenscycluss. Sommige omgevingen kunnen de productieomgeving weerspiegelen en lange levensduur hebben, en andere omgevingen hebben mogelijk korte levensduur en hebben minder mogelijkheden dan productie. Het instellen van deze omgevingen vroeg in de ontwikkelingscyclus helpt bij het garanderen van flexibiliteit, scheiding van productie- en preproductieassets en grondige tests van bewerkingen vóór de release van de productieomgeving. Alle omgevingen moeten de productieomgeving zoveel mogelijk weerspiegelen, hoewel u zo nodig vereenvoudigingen kunt toepassen op lagere omgevingen. In dit diagram ziet u een bedrijfskritieke architectuur:

Er zijn enkele veelvoorkomende overwegingen:

• Onderdelen mogen niet worden gedeeld tussen omgevingen. Mogelijke uitzonderingen zijn downstreambeveiligingsapparaten, zoals firewalls en bronlocaties voor synthetische testgegevens.

• Alle omgevingen moeten infrastructuur gebruiken als codeartefacten (IaC), zoals Terraform- of Arm-sjablonen (Azure Resource Manager).

Ontwikkelomgevingen

Bekijk de volgende video voor informatie over tijdelijke ontwikkelomgevingen en geautomatiseerde functievalidatie.

Ontwerpoverwegingen

• Mogelijkheden. Lagere vereisten voor betrouwbaarheid, capaciteit en beveiliging zijn acceptabel voor ontwikkelomgevingen.

• Levenscyclus. Ontwikkelomgevingen moeten zo nodig worden gemaakt en gedurende korte tijd bestaan. Kortere levenscyclusn helpen configuratiedrift van de codebasis te voorkomen en kosten te verlagen. Ontwikkelomgevingen delen ook vaak de levenscyclus van een functiebranch.

• Dichtheid. Teams heeft meerdere omgevingen nodig om parallelle functieontwikkeling te ondersteunen. Ze kunnen naast elkaar bestaan binnen één abonnement.

Ontwerpaanaanvelingen

• Bewaar de omgeving in een toegewezen abonnement met context die is ingesteld voor ontwikkelingsdoeleinden.

• Gebruik een geautomatiseerd proces om code te implementeren vanuit een functiebranch naar een ontwikkelomgeving.

Test- of faseringsomgevingen

Deze omgevingen worden gebruikt voor testen en validatie. Er worden veel testcycli uitgevoerd om een foutloze implementatie naar productie te garanderen. De juiste tests voor een bedrijfskritieke workload worden beschreven in de sectie Continue validatie en testen .

Ontwerpoverwegingen

• Mogelijkheden. Deze omgevingen moeten de productieomgeving weerspiegelen voor betrouwbaarheid, capaciteit en beveiliging. Als er geen productiebelasting is, gebruikt u een synthetische gebruikersbelasting om realistische metrische gegevens en waardevolle invoer voor statusmodellering te bieden.

• Levenscyclus. Deze omgevingen hebben een korte levensduur. Ze moeten worden vernietigd nadat de testvalidaties zijn voltooid.

• Dichtheid. U kunt veel onafhankelijke omgevingen uitvoeren in één abonnement. U moet ook overwegen om meerdere omgevingen te gebruiken, elk in een toegewezen abonnement.

Notitie

Bedrijfskritieke toepassingen moeten worden onderworpen aan strenge tests.

U kunt verschillende testfuncties uitvoeren in één omgeving en in sommige gevallen moet u dat doen. Voor chaostests om zinvolle resultaten te bieden, moet u de toepassing bijvoorbeeld eerst laden, zodat u kunt begrijpen hoe de toepassing reageert op geïnjecteerde fouten. Daarom worden chaostests en belastingstests doorgaans parallel uitgevoerd.

Ontwerpaanaanvelingen

• Zorg ervoor dat ten minste één faseringsomgeving volledig overeenkomt met productie om productie-achtige tests en validatie mogelijk te maken. Capaciteit binnen deze omgeving kan flexen op basis van de uitvoering van testactiviteiten.

• Genereer synthetische gebruikersbelasting om een realistische testcase te bieden voor wijzigingen in een van de omgevingen.

  Notitie

  De mission Critical Online-referentie-implementatie biedt een voorbeeld van een generator voor gebruikersbelastingen.

• Definieer het aantal faseringsomgevingen en hun doeleinden binnen de ontwikkelings- en releasecyclus.

Productieomgevingen

Ontwerpoverwegingen

• Mogelijkheden. De hoogste niveaus van betrouwbaarheid, capaciteit en beveiligingsfunctionaliteit voor de toepassing zijn vereist.

• Levenscyclus. Hoewel de levenscyclus van de workload en de infrastructuur hetzelfde blijft, hebben alle gegevens, inclusief bewaking en logboekregistratie, speciaal beheer nodig. Het beheer is bijvoorbeeld vereist voor back-up en herstel.

• Dichtheid. Voor sommige toepassingen kunt u overwegen om verschillende productieomgevingen te gebruiken om te voldoen aan verschillende clients, gebruikers of zakelijke functies.

Ontwerpaanaanvelingen

Een duidelijke governancegrens hebben voor productie- en lagere omgevingen. Plaats elk omgevingstype in een toegewezen abonnement om dat doel te bereiken. Deze segmentatie zorgt ervoor dat het resourcegebruik in lagere omgevingen geen invloed heeft op productiequota. Toegewezen abonnementen stellen ook toegangsgrenzen in.

Kortstondige blauw/groene implementaties

Voor een blauw/groen implementatiemodel zijn ten minste twee identieke implementaties vereist. De blauwe implementatie is de actieve implementatie die gebruikersverkeer in productie verwerkt. De groene implementatie is de nieuwe implementatie die is voorbereid en getest om verkeer te ontvangen. Nadat de groene implementatie is voltooid en getest, wordt het verkeer geleidelijk van blauw naar groen geleid. Als de overdracht van de belasting is geslaagd, wordt de groene implementatie de nieuwe actieve implementatie. De oude blauwe implementatie kan vervolgens worden uit bedrijf genomen via een gefaseerd proces. Als er echter problemen zijn in de nieuwe implementatie, kan deze worden afgebroken en kan het verkeer in de oude blauwe implementatie blijven of naar de implementatie worden omgeleid.

Azure Mission-Critical raadt een blauw/groene implementatiebenadering aan waarbij infrastructuur en toepassingen samen worden geïmplementeerd als onderdeel van een implementatiestempel. Het implementeren van een wijziging in de infrastructuur of toepassing resulteert dus altijd in een groene implementatie die beide lagen bevat. Met deze aanpak kunt u het effect van de wijziging volledig testen en valideren op basis van de infrastructuur en de end-to-end van de toepassing voordat u gebruikersverkeer ernaar omleidt. De aanpak verhoogt het vertrouwen in het vrijgeven van wijzigingen en maakt upgrades zonder downtime mogelijk, omdat compatibiliteit met downstreamafhankelijkheden zoals het Azure-platform, resourceproviders en IaC-modules kan worden gevalideerd.

Ontwerpoverwegingen

• Technologiemogelijkheden. Profiteer van de ingebouwde implementatiefuncties in Azure-services. Azure-app Service biedt bijvoorbeeld secundaire implementatiesites die na een implementatie kunnen worden gewisseld. Met Azure Kubernetes Service (AKS) kunt u een afzonderlijke pod-implementatie op elk knooppunt gebruiken en de servicedefinitie bijwerken.

• Duur van de implementatie. Het kan langer duren voordat de implementatie is voltooid omdat het stempel de infrastructuur en toepassing bevat in plaats van alleen het gewijzigde onderdeel. Dit is echter acceptabel omdat het risico van alle onderdelen die niet werken zoals verwacht, de tijdproblemen overschrijft.

• Gevolgen voor kosten. Er zijn extra kosten vanwege de twee naast elkaar bestaande implementaties, die naast elkaar moeten bestaan totdat de implementatie is voltooid.

• Verkeersovergang. Nadat de nieuwe implementatie is gevalideerd, moet verkeer worden overgezet van de blauwe omgeving naar de groene omgeving. Voor deze overgang is indeling van gebruikersverkeer tussen de omgevingen vereist. De overgang moet volledig worden geautomatiseerd.

• Levenscyclus. Bedrijfskritieke implementatiestempels moeten worden beschouwd als kortstondig. Als u kortstondige stempels gebruikt, wordt elke keer een nieuwe start gemaakt voordat resources worden ingericht.

Ontwerpaanaanvelingen

• Gebruik een blauw/groene implementatiebenadering om alle productiewijzigingen vrij te geven. Implementeer elke keer alle infrastructuur en de toepassing, voor elk type wijziging, om een consistente status te bereiken en geen downtime. Hoewel u omgevingen opnieuw kunt gebruiken, raden we dit niet aan voor bedrijfskritieke workloads. Behandel elke regionale implementatiestempel als kortstondig met een levenscyclus die is gekoppeld aan die van één release.

• Gebruik een globale load balancer, zoals Azure Front Door, om de geautomatiseerde overgang van gebruikersverkeer tussen de blauwe en groene omgevingen te organiseren.

• Als u verkeer wilt overschakelen, voegt u een groen back-endeindpunt toe dat een laag verkeer naar volumegewicht gebruikt, zoals 10 procent. Nadat u hebt gecontroleerd of het volume met weinig verkeer op de groene implementatie werkt en de verwachte toepassingsstatus biedt, neemt het verkeer geleidelijk toe. Pas daarbij een korte oploopperiode toe om fouten te ondervangen die mogelijk niet onmiddellijk zichtbaar zijn.

  Nadat al het verkeer is overgezet, verwijdert u de blauwe back-end uit bestaande verbindingen. Verwijder bijvoorbeeld de back-end uit de globale load balancer-service, verwijder wachtrijen en ontkoppel andere koppelingen. Dit helpt om de kosten voor het onderhouden van secundaire productie-infrastructuur te optimaliseren en ervoor te zorgen dat nieuwe omgevingen vrij zijn van configuratiedrift.

  Op dit moment moet u de oude en nu inactieve blauwe omgeving buiten gebruik stellen. Herhaal voor de volgende implementatie het proces met blauw en groen omgekeerd.

Implementatie met abonnementsbereik

Afhankelijk van de schaalvereisten van uw toepassing hebt u mogelijk meerdere productieabonnementen nodig om te fungeren als schaaleenheden.

Bekijk de volgende video om een overzicht te krijgen van aanbevelingen voor bereikabonnementen voor een bedrijfskritieke toepassing.

Ontwerpoverwegingen

• Schaalbaarheid. Voor grootschalige toepassingsscenario's met aanzienlijke hoeveelheden verkeer ontwerpt u de oplossing voor het schalen van meerdere Azure-abonnementen, zodat de schaallimieten van één abonnement de schaalbaarheid niet beperken.

  Belangrijk

  Het gebruik van meerdere abonnementen vereist extra CI/CD-complexiteit, die op de juiste wijze moet worden beheerd. Daarom raden we meerdere abonnementen alleen aan in scenario's met extreme schaal, waarbij de limieten van één abonnement waarschijnlijk een beperking worden.

• Omgevingsgrenzen. Implementeer productie-, ontwikkel- en testomgevingen in afzonderlijke abonnementen. Deze procedure zorgt ervoor dat lagere omgevingen niet bijdragen aan schaallimieten. Het vermindert ook het risico dat milieuvervuilende productie wordt bijgewerkt door een duidelijk beheer en identiteitsgrens te bieden.

• Governance. Wanneer u meerdere productieabonnementen nodig hebt, kunt u overwegen om een toegewezen toepassingsbeheergroep te gebruiken om beleidstoewijzing te vereenvoudigen via een grens voor beleidsaggregatie.

Ontwerpaanaanvelingen

• Implementeer elke regionale implementatiestempel in een toegewezen abonnement om ervoor te zorgen dat de abonnementslimieten alleen van toepassing zijn binnen de context van één implementatiestempel en niet in de hele toepassing. In voorkomend geval kunt u overwegen om meerdere implementatiestempels binnen één regio te gebruiken, maar u moet deze implementeren in onafhankelijke abonnementen.

• Plaats globale gedeelde resources in een toegewezen abonnement om consistente regionale abonnementsimplementatie mogelijk te maken. Vermijd het gebruik van een gespecialiseerde implementatie voor de primaire regio.

Continue validatie en testen

Testen is een kritieke activiteit waarmee u de status van uw toepassingscode en infrastructuur volledig kunt valideren. Met testen kunt u voldoen aan uw standaarden voor betrouwbaarheid, prestaties, beschikbaarheid, beveiliging, kwaliteit en schaal. Testen moet goed zijn gedefinieerd en toegepast als onderdeel van uw toepassingsontwerp en DevOps-strategie. Testen is een belangrijke zorg tijdens het lokale ontwikkelaarsproces (de binnenste lus) en als onderdeel van de volledige DevOps-levenscyclus (de buitenste lus), wat is wanneer code op het pad begint van releasepijplijnprocessen naar de productieomgeving.

Bekijk de volgende video om een overzicht te krijgen van continue validatie en testen.

Deze sectie is gericht op het testen van de buitenste lus. Hierin worden verschillende soorten tests beschreven.

Testen	Beschrijving
Eenheidstests	Bevestigt dat de bedrijfslogica van de toepassing werkt zoals verwacht. Valideert het algehele effect van codewijzigingen.
Betrouwbaarheidstests	Hiermee wordt aangegeven of infrastructuur- en toepassingsonderdelen beschikbaar zijn en werken zoals verwacht. Normaal gesproken wordt slechts één virtuele gebruikerssessie getest. Het resultaat moet zijn dat het systeem reageert met verwachte waarden en gedrag. Veelvoorkomende scenario's voor betrouwbaarheidstests omvatten het bereiken van het HTTPS-eindpunt van een webtoepassing, het uitvoeren van query's op een database en het simuleren van een gebruikersstroom in de toepassing.
UI-tests	Valideert of gebruikersinterfaces van toepassingen zijn geïmplementeerd en of interacties tussen gebruikersinterfaces werken zoals verwacht. U moet hulpprogramma's voor ui-automatisering gebruiken om automatisering te stimuleren. Tijdens een UI-test moet een script een realistisch gebruikersscenario nabootsen en een reeks stappen uitvoeren om acties uit te voeren en een beoogde uitkomst te bereiken.
Belastingstests	Valideert schaalbaarheid en toepassingsbewerking door de belasting snel en/of geleidelijk te verhogen totdat een vooraf vastgestelde drempelwaarde is bereikt. Belastingstests zijn doorgaans ontworpen rond een bepaalde gebruikersstroom om te controleren of aan de toepassingsvereisten wordt voldaan onder een gedefinieerde belasting.
Stresstests	Past activiteiten toe die bestaande resources overbelasten om oplossingslimieten te bepalen en te controleren of het systeem probleemloos kan worden hersteld. Het belangrijkste doel is om potentiële knelpunten en schaallimieten voor prestaties te identificeren. Schaal daarentegen de rekenresources van het systeem omlaag en controleer hoe het zich gedraagt onder belasting en bepaal of het kan worden hersteld.
Prestaties testen	Combineert aspecten van belasting- en stresstests om prestaties onder belasting te valideren en benchmarkgedrag voor toepassingsbewerkingen tot stand te brengen.
Chaos testen	Injecteert kunstmatige fouten in het systeem om te evalueren hoe het reageert en om de effectiviteit van tolerantiemaatregelen, operationele procedures en oplossingen te valideren. Het afsluiten van infrastructuuronderdelen, het opzettelijk verminderen van de prestaties en het introduceren van toepassingsfouten zijn voorbeelden van tests die kunnen worden gebruikt om te controleren of de toepassing op de verwachte manier reageert wanneer de scenario's daadwerkelijk optreden.
Indringingstests	Zorgt ervoor dat een toepassing en de omgeving voldoen aan de vereisten van een verwachte beveiligingspostuur. Het doel is beveiligingsproblemen te identificeren. Beveiligingstests kunnen end-to-end software supply chain en pakketafhankelijkheden omvatten, met scannen en controleren op bekende Common Vulnerabilities and Exposures (CVE).

Ontwerpoverwegingen

• Automatisering. Geautomatiseerd testen is essentieel voor het valideren van wijzigingen in toepassingen of infrastructuur op een tijdige en herhaalbare manier.

• Testvolgorde. De volgorde waarin tests worden uitgevoerd, is een belangrijke overweging vanwege verschillende afhankelijkheden, zoals de noodzaak om een actieve toepassingsomgeving te hebben. De testduur heeft ook invloed op de volgorde. Tests met kortere uitvoeringstijden moeten zo mogelijk eerder in de cyclus worden uitgevoerd om de testefficiëntie te verhogen.

• Schaalbaarheidslimieten. Azure-services hebben verschillende zachte en harde limieten. Overweeg het gebruik van belastingstests om te bepalen of een systeem risico's overschrijdt tijdens de verwachte productiebelasting. Belastingstests kunnen ook handig zijn voor het instellen van de juiste drempelwaarden voor automatisch schalen. Voor services die automatische schaalaanpassing niet ondersteunen, kunt u met belastingstests geautomatiseerde operationele procedures verfijnen.

  De onmogelijkheid van systeemonderdelen, zoals actieve/passieve netwerkonderdelen of databases, kan beperkend zijn. Stresstests kunnen helpen bij het identificeren van beperkingen.

• Analyse van foutmodus. Het introduceren van fouten in de toepassing en onderliggende infrastructuur en het evalueren van het effect is essentieel voor het beoordelen van de redundantiemechanismen van de oplossing. Tijdens deze analyse identificeert u het risico, de impact en de breedte van de impact (gedeeltelijke of volledige storing). Zie Onderbrekingsrisico's van afzonderlijke onderdelen voor een voorbeeldanalyse die is gemaakt voor de mission critical online-referentie-implementatie.

• Bewaking. U moet testresultaten afzonderlijk vastleggen en analyseren en deze ook aggregeren om trends in de loop van de tijd te beoordelen. U moet voortdurend testresultaten evalueren op nauwkeurigheid en dekking.

Ontwerpaanaanvelingen

Bekijk de volgende video om te zien hoe tolerantietests kunnen worden geïntegreerd met Azure DevOps CI/CD-pijplijnen.

• Zorg voor consistentie door alle tests op infrastructuur- en toepassingsonderdelen te automatiseren. Integreer de tests in CI/CD-pijplijnen om ze waar van toepassing te organiseren en uit te voeren. Zie DevOps-hulpprogramma's voor informatie over technologieopties.

• Behandel alle testartefacten als code. Ze moeten worden onderhouden en versiebeheer, samen met andere toepassingscodeartefacten.

• De SLA van de testinfrastructuur afstemmen op de SLA voor implementatie- en testcycli.

• Voer betrouwbaarheidstests uit als onderdeel van elke implementatie. Voer ook uitgebreide belastingstests uit, samen met stress- en chaostests om te controleren of de prestaties en operabiliteit van toepassingen behouden blijven.

  • Gebruik belastingprofielen die echte piekgebruikspatronen weerspiegelen.
  • Voer chaosexperimenten en foutinjectietests uit op hetzelfde moment als belastingstests.

  Tip

  Azure Chaos Studio is een systeemeigen suite met hulpprogramma's voor chaos-experimenten. Met de hulpprogramma's kunt u eenvoudig chaosexperimenten uitvoeren en fouten binnen Azure-services en toepassingsonderdelen injecteren.

  Chaos Studio biedt ingebouwde chaos-experimenten voor veelvoorkomende foutscenario's en ondersteunt aangepaste experimenten die gericht zijn op infrastructuur en toepassingsonderdelen.

• Als database-interacties, zoals het maken van records, vereist zijn voor belasting- of betrouwbaarheidstests, gebruikt u testaccounts met beperkte bevoegdheden en maakt u testgegevens gescheiden van echte gebruikersinhoud.

• Scan en bewaak de end-to-end software supply chain en pakketafhankelijkheden voor bekende CVE's.

  • Gebruik Dependabot voor GitHub-opslagplaatsen om ervoor te zorgen dat de opslagplaats automatisch up-to-date is met de nieuwste versies van pakketten en toepassingen waarvan deze afhankelijk is.

Infrastructuur als code-implementaties

Infrastructuur als code (IaC) behandelt infrastructuurdefinities als broncode die wordt beheerd met andere toepassingsartefacten. Het gebruik van IaC bevordert codeconsistentie in omgevingen, elimineert het risico op menselijke fouten tijdens geautomatiseerde implementaties en biedt traceerbaarheid en terugdraaien. Voor blauw/groene implementaties is het gebruik van IaC met volledig geautomatiseerde implementaties noodzakelijk.

Een bedrijfskritieke IaC-opslagplaats heeft twee afzonderlijke definities die zijn toegewezen aan wereldwijde en regionale resources. Zie het basisarchitectuurpatroon voor informatie over deze typen resources.

Ontwerpoverwegingen

• Herhaalbare infrastructuur. Implementeer bedrijfskritieke workloads op een manier die elke keer dezelfde omgeving genereert. IaC moet het primaire model zijn.

• Automatisering. Alle implementaties moeten volledig worden geautomatiseerd. Menselijke processen zijn foutgevoelig.

Ontwerpaanaanvelingen

• Pas IaC toe, zodat alle Azure-resources worden gedefinieerd in declaratieve sjablonen en worden onderhouden in een opslagplaats voor broncodebeheer. Sjablonen worden geïmplementeerd en resources worden automatisch ingericht vanuit broncodebeheer via CI/CD-pijplijnen. We raden het gebruik van imperatieve scripts niet aan.

• Verbied handmatige bewerkingen voor alle omgevingen. De enige uitzondering is volledig onafhankelijke ontwikkelomgevingen.

DevOps-hulpprogramma’s

Het effectieve gebruik van implementatiehulpprogramma's is essentieel voor de algehele betrouwbaarheid, omdat DevOps-processen van invloed zijn op het algehele functie- en toepassingsontwerp. Failover- en schaalbewerkingen kunnen bijvoorbeeld afhankelijk zijn van automatisering die wordt geleverd door DevOps-hulpprogramma's. Technische teams moeten inzicht hebben in het effect van de onbeschikbaarheid van een implementatieservice met betrekking tot de algehele workload. Implementatiehulpprogramma's moeten betrouwbaar en maximaal beschikbaar zijn.

Microsoft biedt twee systeemeigen Azure-hulpprogramma's, GitHub Actions en Azure Pipelines, waarmee een bedrijfskritieke toepassing effectief kan worden geïmplementeerd en beheerd.

Ontwerpoverwegingen

• Technologiemogelijkheden. De mogelijkheden van GitHub en Azure DevOps overlappen. U kunt ze samen gebruiken om het beste van beide te krijgen. Een veelvoorkomende benadering is het opslaan van codeopslagplaatsen in GitHub.com of GitHub AE tijdens het gebruik van Azure Pipelines voor implementatie.

  Houd rekening met de complexiteit die wordt toegevoegd wanneer u meerdere technologieën gebruikt. Evalueer een uitgebreide functieset op basis van de algehele betrouwbaarheid.

• Regionale beschikbaarheid. Wat de maximale betrouwbaarheid betreft, vertegenwoordigt de afhankelijkheid van één Azure-regio een operationeel risico.

  Stel dat verkeer is verdeeld over twee regio's: Regio 1 en Regio 2. Regio 2 fungeert als host voor het Azure DevOps-hulpprogramma-exemplaar. Stel dat er een storing is in Regio 2 en dat het exemplaar niet beschikbaar is. Regio 1 verwerkt automatisch al het verkeer en moet extra schaaleenheden implementeren om een goede failover-ervaring te bieden. Maar dit kan niet vanwege de Azure DevOps-afhankelijkheid in Regio 2.

• Gegevensreplicatie. Gegevens, waaronder metagegevens, pijplijnen en broncode, moeten worden gerepliceerd in verschillende regio's.

Ontwerpaanaanvelingen

• Beide technologieën worden gehost in één Azure-regio, waardoor uw strategie voor herstel na noodgevallen kan worden beperkt.

  GitHub Actions is geschikt voor buildtaken (doorlopende integratie), maar heeft mogelijk geen functies voor complexe implementatietaken (continue implementatie). Gezien de uitgebreide functieset van Azure DevOps raden we dit aan voor bedrijfskritieke implementaties. U moet echter een keuze maken nadat u afwegingen hebt beoordeeld.

• Definieer een SLA voor beschikbaarheid voor implementatiehulpprogramma's en zorg voor afstemming met bredere vereisten voor toepassingsbetrouwbaarheid.

• Voor scenario's met meerdere regio's die gebruikmaken van een actieve/passieve of actieve/actieve implementatieconfiguratie, moet u ervoor zorgen dat failover-indelings- en schaalbewerkingen kunnen blijven functioneren, zelfs als de primaire regio die als host fungeert voor implementatiehulpprogramma's niet meer beschikbaar is.

Vertakkingsstrategie

Er zijn veel geldige benaderingen voor vertakkingen. U moet een strategie kiezen die een maximale betrouwbaarheid garandeert. Een goede strategie maakt parallelle ontwikkeling mogelijk, biedt een duidelijk pad van ontwikkeling naar productie en ondersteunt snelle releases.

Ontwerpoverwegingen

• Minimaliseer de toegang. Ontwikkelaars moeten hun werk doen in feature/* en fix/* vertakkingen. Deze vertakkingen worden toegangspunten voor wijzigingen. Beperkingen op basis van rollen moeten worden toegepast op vertakkingen als onderdeel van de vertakkingsstrategie. Beheerders kunnen bijvoorbeeld alleen releasevertakkingen maken of naamconventies afdwingen voor vertakkingen.

• Versneld proces voor noodgevallen. De vertakkingsstrategie moet toestaan dat hotfixes zo snel mogelijk worden samengevoegd main . Op die manier bevatten toekomstige releases de oplossing en wordt het probleem vermeden. Gebruik dit proces alleen voor kleine wijzigingen die urgente problemen oplossen en gebruiken met beperking.

Ontwerpaanaanvelingen

• Geef prioriteit aan het gebruik van GitHub voor broncodebeheer.

  Belangrijk

  Maak een vertakkingsstrategie waarmee functie-werk en releases minimaal worden beschreven, en gebruik vertakkingsbeleid en -machtigingen om ervoor te zorgen dat de strategie op de juiste wijze wordt afgedwongen.

• Activeer een geautomatiseerd testproces om bijdragen voor codewijziging te valideren voordat deze worden geaccepteerd. Teamleden moeten ook wijzigingen controleren.

• Behandel de main vertakking als een continu bewegende en stabiele vertakking die voornamelijk wordt gebruikt voor integratietests.

  • Zorg ervoor dat wijzigingen alleen via PULL's worden aangebracht main . Gebruik een vertakkingsbeleid om directe doorvoeringen te verbieden.
  • Telkens wanneer een pull-aanvraag wordt samengevoegd main, wordt er automatisch een implementatie gestart op basis van een integratieomgeving.
  • De main tak moet als stabiel worden beschouwd. Het moet veilig zijn om op elk gewenst moment een release te maken.main

• Gebruik toegewezen release/* vertakkingen die zijn gemaakt op basis van de main vertakking en die worden gebruikt om te implementeren in productieomgevingen. release/* vertakkingen moeten in de opslagplaats blijven staan en kunnen worden gebruikt voor het patchen van een release.

• Documenteer een hotfixproces en gebruik dit alleen wanneer dat nodig is. Maak hotfixes in een fix/* vertakking voor volgende samenvoeging in de releasebranch en implementatie naar productie.

AI voor DevOps

U kunt AIOps-methodologieën in CI/CD-pijplijnen toepassen om traditionele testmethoden aan te vullen. Als u dit doet, kunnen potentiële regressies of afnames worden gedetecteerd en kunnen implementaties preventief worden gestopt om potentiële negatieve effecten te voorkomen.

Ontwerpoverwegingen

• Volume van telemetriegegevens. CI/CD-pijplijnen en DevOps-processen verzenden een groot aantal telemetriegegevens voor machine learning-modellen. De telemetrie varieert van testresultaten en implementatieresultaten tot operationele gegevens over testonderdelen uit samengestelde implementatiefasen.

• Schaalbaarheid. Traditionele gegevensverwerkingsmethoden zoals Extract, Transform, Load (ETL) kunnen de doorvoer mogelijk niet schalen om de groei van implementatietelemetriegegevens en waarneembaarheidsgegevens van toepassingen bij te houden. U kunt moderne analysemethoden gebruiken waarvoor ETL en gegevensverplaatsing, zoals gegevensvirtualisatie, niet nodig zijn om doorlopende analyses door AIOps-modellen mogelijk te maken.

• Implementatiewijzigingen. Wijzigingen in de implementatie moeten worden opgeslagen voor geautomatiseerde analyse en correlatie met implementatieresultaten.

Ontwerpaanaanvelingen

• Definieer de DevOps-procesgegevens die moeten worden verzameld en hoe ze moeten worden geanalyseerd. Telemetrie, zoals metrische gegevens voor testuitvoering en tijdreeksgegevens van wijzigingen binnen elke implementatie, is belangrijk.

  • Maak waarneembaarheidsgegevens van toepassingen beschikbaar vanuit faserings-, test- en productieomgevingen voor analyse en correlatie binnen AIOps-modellen.

• De MLOps-werkstroom gebruiken.

• Ontwikkel analytische modellen die contextbewust en afhankelijk zijn om voorspellingen te bieden met geautomatiseerde functie-engineering om wijzigingen in het schema en gedrag aan te pakken.

• Implementeer modellen door de best getrainde modellen in implementatiepijplijnen te registreren en te implementeren.

Volgende stap

Bekijk de beveiligingsoverwegingen.

Beveiliging