Delen via

Aanbevelingen voor het ontwerpen van een supply chain voor workloadontwikkeling

  • Artikel

Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:

OE:06 Bouw een supply chain voor workloads die voorgestelde wijzigingen aanstuurt via voorspelbare, geautomatiseerde pijplijnen. De pijplijnen testen en promoten deze wijzigingen in omgevingen. Optimaliseer een supply chain om uw workload betrouwbaar, veilig, rendabel en performant te maken.

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een supply chain voor workloadontwikkeling die is gebaseerd op CI/CD-pijplijnen (continue integratie en continue levering). Ontwikkel een toeleveringsketen om ervoor te zorgen dat u een voorspelbare, gestandaardiseerde methode hebt om uw workload te onderhouden. CI/CD-pijplijnen zijn de manifestatie van de toeleveringsketen, maar u moet één toeleveringsketen hebben. En mogelijk hebt u verschillende pijplijnen die dezelfde processen volgen en dezelfde hulpprogramma's gebruiken.

Neem een toeleveringsketen op om uw werkbelasting te beschermen tegen schade die kan optreden wanneer u de wijzigingen van de werkbelasting niet goed beheert. Houd altijd rekening met de status van uw workload, zodat u geen onvoorspelbaar gedrag ondervindt. Dit risico zorgt ervoor dat u kritieke tijd moet besteden aan het opnieuw aftrekken van wijzigingen wanneer er problemen optreden. Als u deze risico's wilt minimaliseren, standaardiseert u de processen en hulpprogramma's die uw toeleveringsketen definiëren en zorgt u ervoor dat uw workloadteam zich volledig verbindt aan het gebruik ervan.

Definitie

Term Definitie
Toeleveringsketen In cloudworkloads is een toeleveringsketen een gestandaardiseerde suite met hulpprogramma's en processen die u gebruikt om de infrastructuur en toepassingswijziging in omgevingen te beïnvloeden.

Belangrijke ontwerpstrategieën

Notitie

De aanbevelingen in deze handleiding verwijzen naar workloadomgevingen in een codepromotieketen. Sandbox- of andere experimentele en proof-of-concept-omgevingen vereisen minder striktheid en structuur.

Kerntenets

De volgende aanbevelingen kunnen u helpen bij het definiëren van de kernten van uw toeleveringsketen.

Breng voorgestelde workloadwijzigingen aan via processen en hulpprogramma's van de toeleveringsketen. Dwing een strikt beleid af voor geautomatiseerde implementaties op basis van sjablonen. Deze methode helpt ervoor te zorgen dat de configuratie van uw workload in alle omgevingen is gestandaardiseerd, goed gedefinieerd en nauwkeurig wordt beheerd. Voor omgevingen in een codepromotieketen moet u geen updates uitvoeren met behulp van handmatige processen of menselijke interactie met het besturingsvlak van het cloudplatform, bijvoorbeeld de portal of een API. Neem alle wijzigingen in de omgeving op via een pijplijn door de implementatieprocedures te volgen die u definieert. Om dit beleid af te dwingen, kunt u overwegen om de toegang tot alleen-lezen als standaard te beperken en een toegangsautorisatiepoort te gebruiken om schrijftoegang toe te staan.

Een belangrijk aspect van dit tenet is dat alle wijzigingen worden voorgesteld totdat ze in productie worden geïmplementeerd. Door middel van geautomatiseerde tests, zoals integratie en betrouwbaarheidstests, kunt u uw toeleveringsketen in staat stellen om wijzigingen automatisch te negeren.

Implementeer herhaalbare en onveranderbare infrastructuur als code (IaC). IaC is het beheer van infrastructuur in een beschrijvend model dat gebruikmaakt van een versiebeheersysteem dat de broncode spiegelt. Wanneer u een toepassing maakt, moet dezelfde broncode steeds hetzelfde binaire bestand genereren wanneer deze wordt gecompileerd. Op een vergelijkbare manier genereert een IaC-model steeds dezelfde omgeving wanneer het wordt toegepast.

Neem IaC op om ervoor te zorgen dat uw team een standaard, goed opgezet proces volgt. Sommige organisaties wijzen één individuele of kleine groep personen aan voor het implementeren en configureren van infrastructuur. Wanneer u een volledig geautomatiseerd proces implementeert, vereisen infrastructuurimplementaties minder beheer van personen. De verantwoordelijkheid wordt overgedragen aan het automatiseringsproces en de hulpprogramma's. Teamleden kunnen infrastructuurimplementaties initiëren om consistentie en kwaliteit te behouden.

Ontwerp uw workload als een logische groep onderdelen die u in één sjabloon kunt bundelen om implementaties eenvoudig en herhaalbaar te maken. U kunt deze bundels beschouwen als stempels of schaaleenheden. Zie het patroon Implementatiestempels voor meer informatie. Wanneer u uw workload wilt implementeren om uit te schalen naar een andere regio of zone binnen dezelfde regio, implementeert u een stempel met behulp van een pijplijn. Afhankelijk van hoe u uw stempels ontwerpt, kunt u een subset van uw workload implementeren in plaats van de hele workload. Neem netwerkonderdelen op in uw IaC-pijplijnen om ervoor te zorgen dat uw implementatiestempels automatisch verbinding maken met bestaande resources.

Als u uw IaC-pijplijn wilt optimaliseren voor consistentie en efficiëntie, ontwerpt u een onveranderbare infrastructuur in plaats van een onveranderbare infrastructuur. Implementeer een onveranderbare infrastructuur om ervoor te zorgen dat alle systemen binnen het bereik worden vervangen door de bijgewerkte configuratie tegelijk en identiek aan elke implementatie.

Gebruik één set codeassets en artefacten in alle omgevingen en pijplijnen. Een veelvoorkomend pijnpunt voor organisaties is wanneer niet-productieomgevingen verschillen van productieomgevingen. Het handmatig bouwen van productie- en niet-productieomgevingen kan leiden tot niet-overeenkomende configuraties tussen de omgevingen. Dit komt niet overeen met het testen en maakt het waarschijnlijker dat wijzigingen een productiesysteem kunnen schaden. Een IaC-benadering minimaliseert deze problemen. Wanneer u IaC-automatisering gebruikt, kunt u dezelfde infrastructuurconfiguratiebestanden voor alle omgevingen gebruiken om bijna identieke omgevingen te produceren. U kunt parameters toevoegen aan de infrastructuurconfiguratiebestanden en deze aanpassen om te voldoen aan de vereisten voor elke omgeving.

Om de kosten te beheren, is er meestal een variantie tussen productie- en niet-productieomgevingen. Vaak hebt u niet dezelfde mate van redundantie en prestaties nodig in niet-productieomgevingen als in productieomgevingen. Het aantal en de SKU van uw resources kunnen verschillen tussen omgevingen. Zorg ervoor dat u de variantie beheert en begrijpt met behulp van gestandaardiseerde parameters om u te helpen voorspelbaarheid te behouden wanneer u wijzigingen aanbrengt.

Geef uw organisatiestructuur weer in uw toeleveringsketen- en pijplijnontwerpen. Uw organisatie kan tussen teams worden gesiloteerd. Elk team kan een deel van de toeleveringsketen beheren. Veel organisaties hebben bijvoorbeeld teams die infrastructuurdomeinen beheren, zoals netwerken, gegevens en rekenresources. Deze teams staan los van ontwikkelteams die toepassingsontwikkeling, testen en implementaties beheren. In sommige organisaties worden ontwikkel- en infrastructuurteams opgenomen in DevOps-teams die gezamenlijk alle infrastructuur- en toepassingsimplementaties beheren. Er zijn veel manieren om de teams te organiseren die betrokken zijn bij een toeleveringsketen. Uw toeleveringsketen is afhankelijk van alle teams die naadloos samenwerken. Zorg ervoor dat alle teams standaardprocessen volgen en gebruik standaardhulpprogramma's om de toeleveringsketen zo efficiënt mogelijk te maken.

Uw toeleveringsketen kan afhankelijk zijn van externe leveranciers als u onderdelen van de levenscyclus van de workload uitbesteedt. Deze leveranciers zijn net zo essentieel voor het succes van uw toeleveringsketen als interne resources. Zorg ervoor dat er een wederzijdse overeenkomst is tussen alle teams over de processen en hulpprogramma's die u gebruikt.

Uw implementatiemethode standaardiseren. Neem contact op met de producteigenaar over de acceptabele hoeveelheid productie-downtime voor uw workload. Afhankelijk van hoeveel, indien van toepassing, downtime acceptabel is, kunt u de implementatiemethode kiezen die geschikt is voor uw vereisten. In het ideale geval moet u implementaties uitvoeren tijdens een onderhoudsvenster om de complexiteit en het risico te verminderen. Als er geen downtime acceptabel is, gebruikt u een blauwgroene implementatiemethode.

Gebruik een progressieve blootstellingsbenadering om het risico op het introduceren van onopgemerkte bugs voor uw klanten te verminderen. Deze methode wordt ook wel canary-implementaties genoemd. Deze methode wordt in een geleidelijke volgorde geïmplementeerd in gecontroleerde groepen gebruikers. Het onderschept problemen voordat ze meer gebruikers beïnvloeden. De eerste implementatiegroep kan een subsectie zijn van uw klanten die op de hoogte zijn van de implementatiestrategie. Deze subsectie van klanten kan enige hoeveelheid onverwacht gedrag tolereren en feedback geven. Of het kan een groep interne gebruikers zijn, die de straal van bugs tijdens de implementatie kan bevatten.

Wanneer u uw implementatiemethode definieert, moet u een standaardbeleid gebruiken om alleen de kleinste haalbare wijziging in elke implementatie te implementeren. Afhankelijk van factoren zoals de kritiek van de workload en complexiteit van de onderdelen, bepaalt u de kleinste levensvatbare wijziging. Als u een onveranderbare infrastructuur gebruikt, is de kleinste haalbare wijziging doorgaans de implementatie van resources met de nieuwste configuratie om resources te vervangen die de vorige versie uitvoeren. Als u een onveranderbare infrastructuur gebruikt, kunt u besluiten dat de kleinste haalbare wijziging slechts één update is voor de groep resources binnen het bereik.

Volg een gelaagde benadering om verschillende levenscycluss weer te geven. Basislagen moeten statisch blijven gedurende de meeste levenscyclus van de workload en toepassingslagen veranderen regelmatig. Als u rekening wilt houden met deze verschillen, moet u verschillende pijplijnen hebben om wijzigingen op elke laag door te voeren.

Een landingszone bevindt zich op de laagste laag. Een landingszone is een logische groepering van basiselementen, zoals abonnementen, beheergroepen, resourcegroepen, governancefuncties en netwerktopologie. Met een landingszone kunt u eenvoudig uw workload implementeren en beheren en centrale operationele teams of platformteams bieden, met een herhaalbare benadering van een omgevingsconfiguratie. Om consistente omgevingen te leveren, bieden alle Azure-landingszones een set gemeenschappelijke ontwerpgebieden, een referentiearchitectuur, een referentie-implementatie en een proces om een implementatie aan te passen aan uw ontwerpvereisten. De ontwerpprincipes van de Azure-landingszone bieden aanbevolen procedures op basis van beleidsgestuurde governance naast democratisering van abonnementen. Een landingszone moet minimale wijzigingen vereisen gedurende de loop van de levenscyclus van uw workload. Zie Wat is een Azure-landingszone voor een voorbeeld van een landingszone. Deze conceptuele architectuur biedt een reeks adviezen die worden aanbevolen voor Azure.

Uw kerninfrastructuur en -functies, zoals inkomend en uitgaand netwerkcontrollers, taakverdeling, netwerkrouteringsoplossingen, DNS-beheer en kernservers, moeten ook onregelmatige belangrijke wijzigingen vereisen. Maar er zijn mogelijk frequente configuratie-updates vereist.

Voor uw toepassing en gegevenslaag zijn frequente configuratie-updates en frequente infrastructuurwijzigingen vereist. Deze onderdelen moeten de meest dynamische pijplijnen hebben.

Plan een holistische teststrategie. Een kern-tenet van systeembetrouwbaarheid is het verschuivingsprincipe links . Het ontwikkelen en implementeren van een toepassing is een proces dat wordt weergegeven als een reeks stappen die van links naar rechts gaan. U mag het testen niet beperken tot het einde van het proces. Verschuif zoveel mogelijk het testen naar het begin of naar links. Fouten zijn goedkoper om te herstellen wanneer u ze vroeg ondervangt. Ze kunnen duur of onmogelijk zijn om later in de levenscyclus van de toepassing op te lossen.

Test alle code, inclusief toepassingscode, infrastructuursjablonen en configuratiescripts. De omgeving waarop toepassingen worden uitgevoerd, moeten versiebeheerd en geïmplementeerd worden via dezelfde mechanismen als toepassingscode. U kunt de omgeving testen en valideren met behulp van dezelfde testparadigma's die uw teams al gebruiken voor toepassingscode.

Gebruik, indien mogelijk, geautomatiseerde tests om consistentie te garanderen. Neem de volgende soorten tests op in uw supply chain-ontwerp.

  • Eenheidstests: Eenheidstests worden doorgaans uitgevoerd als onderdeel van een continue integratieroutine. Eenheidstests moeten uitgebreid en snel zijn. Ze moeten in het ideale geval 100 procent van de code dekken en binnen 30 seconden worden uitgevoerd.

    Implementeer eenheidstests om te controleren of de syntaxis en functionaliteit van afzonderlijke codemodules werken zoals ze moeten, bijvoorbeeld het produceren van een gedefinieerde uitvoer voor een bekende invoer. U kunt ook eenheidstests gebruiken om te controleren of IaC-assets geldig zijn.

    Eenheidstests toepassen op alle codeassets, inclusief sjablonen en scripts.

  • Betrouwbaarheidstests: Betrouwbaarheidstests controleren of een workload in een testomgeving kan worden opgesteld en naar verwachting wordt uitgevoerd. Betrouwbaarheidstests verifiëren de interoperabiliteit van onderdelen niet.

    Betrouwbaarheidstests controleren of de implementatiemethodologie voor de infrastructuur en de toepassing werkt en of het systeem reageert zoals bedoeld nadat het proces is voltooid.

  • Integratietests: Integratietests zorgen ervoor dat de toepassingsonderdelen afzonderlijk werken en vervolgens bepalen of onderdelen naar behoren met elkaar kunnen communiceren.

    Het kan veel tijd duren om een grote integratietestsuite uit te voeren. Daarom is het raadzaam om het shift left-principe op te nemen en vroeg in de levenscyclus van softwareontwikkeling tests uit te voeren. Reserveer integratietests voor scenario's die u niet kunt testen met een betrouwbaarheidstest of eenheidstest.

    U kunt indien nodig langlopende testprocessen uitvoeren op een regelmatig interval. Een regelmatig interval biedt een goed compromis en detecteert interoperabiliteitsproblemen tussen toepassingsonderdelen uiterlijk één dag nadat ze zijn geïntroduceerd.

    Sommige testscenario's profiteren van handmatige uitvoeringen. Gebruik handmatige tests wanneer u menselijke interactiviteitselementen in tests moet introduceren.

  • Acceptatietests: afhankelijk van de context kunt u acceptatietests handmatig uitvoeren. Het kan gedeeltelijk of volledig geautomatiseerd zijn. Acceptatietests bepalen of het softwaresysteem voldoet aan de vereistenspecificaties.

    Het belangrijkste doel van deze test is om de naleving van de bedrijfsvereisten van het systeem te evalueren en te bepalen of het systeem voldoet aan de vereiste criteria voor levering aan eindgebruikers.

Implementeer kwaliteitspoorten tijdens uw codepromotieproces via testen. Implementeer uw code in lagere omgevingen, zoals ontwikkeling en testen, en door middel van hogere omgevingen, zoals fasering en productie. Wanneer uw implementatie kwaliteitspoorten doorloopt, moet u ervoor zorgen dat deze voldoet aan uw kwaliteitsdoelen voordat wijzigingen naar productie gaan. Uw bedrijfsvereisten bepalen wat de focus van uw kwaliteitspoorten is. Houd ook rekening met de basisprincipes van goed ontworpen framework: Beveiliging, betrouwbaarheid en prestatie-efficiëntie.

Integreer ook goedkeuringswerkstromen in uw kwaliteitspoorten. Definieer en automatiseer goedkeuringswerkstromen duidelijk indien van toepassing. Definieer kwaliteitsacceptatiecriteria in uw automatisering, zodat u efficiënt en veilig door uw poorten kunt navigeren.

Azure-facilitering

Azure DevOps is een verzameling services waarmee u een gezamenlijke, efficiënte en consistente ontwikkelpraktijk kunt bouwen.

Azure Pipelines biedt build- en releaseservices ter ondersteuning van CI/CD in uw toepassingen.

GitHub Actions voor Azure kan worden geïntegreerd met Azure om implementaties te vereenvoudigen. Gebruik GitHub Actions om CI/CD-processen te automatiseren. U kunt werkstromen maken die elke pull-aanvraag in uw opslagplaats bouwen en testen, of samengevoegde pull-aanvragen implementeren in productie.

U kunt Terraform, Bicep en Azure Resource Manager gebruiken voor IaC-implementaties. Afhankelijk van uw vereisten en de bekendheid van uw team met de hulpprogramma's, kunt u een of meer van deze hulpprogramma's gebruiken voor uw implementaties en beheer van de resources.

Opmerking

Zie de basislijnarchitectuur van Azure Pipelines voor een voorbeeld waarin wordt getoond hoe u Azure Pipelines gebruikt om een CI/CD-pijplijn te bouwen.

Controlelijst voor Operation Excellence

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid