Aanbevelingen voor het ontwerpen van een strategie voor het beperken van implementatiefouten

Van toepassing op deze aanbeveling voor de Well-Architected Operational Excellence-checklist: Power Platform

OE:11	Een strategie implementeren voor het beperken van implementatiefouten die onverwachte problemen tijdens de implementatie aanpakt met snel herstel. Combineer meerdere benaderingen, zoals terugdraaien, functie-uitschakeling of het gebruik van de eigen mogelijkheden van uw implementatiepatroon.

In deze guide worden de aanbevelingen beschreven voor het ontwerpen van een gestandaardiseerde strategie om implementatiefouten effectief af te handelen. Net als andere workloadproblemen zijn implementatiefouten een onvermijdelijk onderdeel van de levenscyclus van een workload. Met deze mindset kunt u proactief handelen door een goed ontworpen, doelbewuste strategie te hebben om met implementatiefouten om te gaan. Met een dergelijke strategie kan uw werklastteam storingen efficiënt beperken en zo min mogelijk impact hebben op uw gebruikers.

Het ontbreken van een dergelijk plan kan leiden tot chaotische en potentieel schadelijke reacties op problemen, die een aanzienlijke invloed kunnen hebben op de cohesie binnen team en organisatie, het vertrouwen van klanten en de financiën.

Belangrijke ontwerpstrategieën

Af en toe doen zich, ondanks de gevorderdheid van uw ontwikkelprocedures, implementatieproblemen voor. Door gebruik te maken van veilige implementatieprocedures en een robuuste toeleveringsketen voor workloads kunt u het aantal mislukte implementaties tot een minimum beperken. U moet ook een gestandaardiseerde strategie ontwerpen om met mislukte implementaties om te gaan wanneer deze zich voordoen.

Een strategie voor het beperken van implementatiefouten bestaat uit vijf fasen:

1. Detectie: Om te kunnen reageren op een mislukte implementatie, moet u eerst de fout detecteren. Detectie kan verschillende vormen aannemen, zoals mislukte rooktests, gebruikersrapporten of waarschuwingen die uw monitoringplatform genereert.
2. Beslissing: U moet beslissen wat de beste beperkingsstrategie is voor het specifieke type storing.
3. Beperking: U moet de geïdentificeerde beperkingsactie uitvoeren. De beperking kan de vorm aannemen van een terugval-, terugdraai- of vooruitdraaiactie.
4. Communicatie: Belanghebbenden en getroffen gebruikers moeten op de hoogte worden gebracht van de status zodra u het probleem detecteert en oplost, zoals vereist door uw noodplan respons.
5. Postmortem: Blameless postmortems bieden het werklastteam de kans om verbeterpunten te identificeren en plannen te maken om de geleerde lessen toe te passen.

De volgende secties bevatten gedetailleerde aanbevelingen voor deze fasen.

Detectie

Om problemen met implementaties snel te kunnen identificeren, hebt u robuuste test- en monitoringpraktijken nodig die betrekking hebben op implementaties. Om afwijkingen snel te kunnen detecteren, kunt u uw werklastbewaking en waarschuwingen aanvullen met een tool voor applicatieprestatiebeheer en logging via instrumentatie.

Rooktests en andere kwaliteitstests moeten in elke fase van uw uitrol plaatsvinden. Geslaagde tests in één implementatiegroep mogen geen invloed hebben op beslissingen om in volgende groepen te testen.

U kunt telemetrie implementeren die gebruikersproblemen correleert met een implementatiefase. Vervolgens kunt u snel vaststellen aan welke implementatiegroep een bepaalde gebruiker is gekoppeld. Deze aanpak is vooral belangrijk voor implementaties met progressieve blootstelling, omdat er op een bepaald moment in de implementatie mogelijk meerdere configuraties in uw gebruikersbestand actief zijn.

U moet onmiddellijk kunnen reageren op door gebruikers gemelde problemen. Wanneer dit praktisch haalbaar is, kunt u uw uitrolfase tijdens werkuren inzetten, wanneer u compleet ondersteuningsteam beschikbaar is. Zorg ervoor dat ondersteunend personeel is getraind in het escaleren van implementatieproblemen voor een correcte routering. Escalaties moeten zijn afgestemd op het noodplan voor uw workload.

Beslissing

Bij het bepalen van een geschikte mitigatiestrategie voor een implementatieprobleem moet u rekening houden met factoren zoals:

• Het type progressieve blootstellingsmodel dat u gebruikt. U kunt bijvoorbeeld een blauwgroen model of een canary-model gebruiken. Als u een blauwgroen model gebruikt, is terugvallen praktischer dan terugdraaien. U kunt verkeer eenvoudig terugleiden naar de stack waarop de configuratie wordt uitgevoerd die niet is bijgewerkt. U kunt het probleem vervolgens in de problematische omgeving oplossen en uw implementatie op een geschikt moment opnieuw proberen.

• De methoden die u tot uw beschikking hebt om het probleem te omzeilen. Voorbeelden hiervan zijn het gebruik van functievlaggen, omgevingsvariabelen of elk ander type runtime-configuratie-eigenschap die u kunt in- en uitschakelen. Soms kunt u een probleem eenvoudig omzeilen door een functievlag uit te schakelen of een instelling te wijzigen. In dit geval kunt u mogelijk het volgende doen:

  • Doorgaan met de uitrol.
  • Terugvallen vermijden.
  • Terugdraaien terwijl u de defecte code repareert.

• Het inspanningsniveau dat nodig is om een oplossing in de code te implementeren. Als het niet veel moeite kost om de code te repareren, is het in bepaalde scenario's de juiste keuze om een hotfix te implementeren.

• Het kritikaliteitsniveau voor de getroffen workload. Bedrijfskritische workloads moeten altijd naast elkaar worden geïmplementeerd, zoals in een blauwgroen model, om implementaties zonder downtime te realiseren. Als gevolg daarvan is terugvallen de beste beperkingsstrategie voor dit soort workloads.

Beperking

Hieronder volgen enkele veelvoorkomende beperkingsstrategieën:

• Terugdraaien: In een terugdraaiscenario hebt u terugkeren systemen bijgewerkt naar de laatste bekende juiste configuratiestatus.

  Het is belangrijk dat het hele workloadteam het eens is over de betekenis van 'laatste bekende goede'. Deze uitdrukking verwijst naar de laatste staat van de workload die gezond was voordat de implementatie begon. Dit is niet noodzakelijkerwijs de vorige versie van de applicatie.

  Terugdraaien kan complex zijn, vooral omdat het betrekking heeft op gegevenswijzigingen. Schemawijzigingen kunnen het terugdraaien riskant maken. Veilige implementatie vereist mogelijk aanzienlijke planning. Als algemene aanbeveling moeten schema-updates additief van aard zijn. Records mogen niet vervangen worden door nieuwe records. In plaats daarvan moeten oudere records worden afgeschaft en moeten ze naast nieuwe records bestaan totdat het veilig is om de afgeschafte records te verwijderen.

• Fallback: In een fallbackscenario worden de bijgewerkte systemen uit de productieverkeersroutering verwijderd. Al het verkeer wordt doorgestuurd naar de stack die niet is bijgewerkt. Deze strategie met laag risico biedt u een manier om de problemen in uw code aan te pakken zonder verdere verstoringen te veroorzaken.

  Bij canary-implementaties is terugvallen wellicht niet eenvoudig of zelfs mogelijk, afhankelijk van uw infrastructuur en app-ontwerp. Als u moet schalen om de belasting van de systemen die niet worden bijgewerkt aan te kunnen, moet u dit voorafgaand aan de terugvalactie doen.

• De functie die het probleem veroorzaakt omzeilen: Als u het probleem kunt omzeilen door gebruik te maken van feature flags of een ander type runtime-configuratie-eigenschap, kunt u besluiten dat doorgaan met de uitrol de juiste strategie is om een probleem aan te pakken.

  U moet de afweging om de functie te omzeilen goed begrijpen en u moet die afweging aan belanghebbenden kunnen communiceren. Belanghebbenden moeten het vervolgplan goedkeuren. Belanghebbenden moeten bepalen hoeveel tijd aanvaardbaar is voor het werken in een verslechterde status. Ze moeten die vastberadenheid ook afwegen tegen uw inschatting van de tijd die nodig is om de defecte code te repareren en te implementeren.

• Noodimplementatie (hotfix): Als u het probleem halverwege de uitrol kunt oplossen, is een hotfix mogelijk de meest praktische oplossingsstrategie.

  Net als alle andere code moeten hotfixes voldoen aan uw veilige implementatieprocedures. Maar met een hotfix wordt de tijdlijn aanzienlijk versneld. U moet in al uw omgevingen een strategie voor codepromotie gebruiken. Controleer ook de hotfixcode bij alle kwaliteitspoorten. Maar mogelijk moet u de simulatietijden drastisch verkorten en de tests aanpassen om ze te versnellen. Zorg ervoor dat u zo snel mogelijk na de implementatie volledige tests kunt uitvoeren op de bijgewerkte code. Het in hoge mate automatiseren van kwaliteitsborgingstests helpt het testen in deze scenario's efficiënt te maken.

Communicatie

Het is belangrijk om de communicatieverantwoordelijkheden duidelijk te definiëren om chaos tijdens incidenten tot een minimum te beperken. Deze verantwoordelijkheden moeten bepalen hoe het workloadteam omgaat met ondersteuningsteams, belanghebbenden en personeel van het noodresponsteam, zoals de noodresponsmanager.

Standaardiseer het interval dat het workloadteam volgt voor het verstrekken van statusupdates. Zorg ervoor dat belanghebbenden op de hoogte zijn van deze standaard, zodat ze weten wanneer ze updates kunnen verwachten.

Als het werklastteam rechtstreeks met gebruikers moet communiceren, moet u duidelijk maken welk type informatie en welk detailniveau geschikt zijn om te delen. Communiceer ook eventuele andere vereisten die op deze gevallen van toepassing zijn aan het workloadteam.

Nabeschouwingen

Postmortems moeten volgen alle mislukte implementaties zonder uitzondering behandelen. Elke mislukte implementatie is een kans om van te leren. Met postmortems kunt u zwakke plekken in uw implementatie- en ontwikkelingsprocessen en verkeerde configuraties in uw infrastructuur identificeren.

Nabeschouwingen moeten altijd zonder schuldvraag zijn, zodat personen die bij het incident betrokken zijn zich veilig voelen als ze hun visie delen op wat er verbeterd kan worden. Postmortem-leiders moeten opvolgende aanleveren met plannen voor het implementeren van de geïdentificeerde verbeteringen en voor het toevoegen van deze plannen aan de werklastbacklog.

Overwegingen en algemene aanbevelingen

Zorg ervoor dat uw implementatiepijplijn verschillende afzonderlijke versies als parameters kan accepteren, zodat u eenvoudig de laatst bekende goede configuraties kunt implementeren.

Zorg voor consistentie met de beheer- en datavlakken terwijl u terug- of vooruitrolt. Sleutels, geheimen, databasestatusgegevens en configuraties die specifiek zijn voor resources en beleid moeten allemaal binnen het bereik vallen en worden meegewogen. Besteed bijvoorbeeld aandacht aan het ontwerp van de schaalbaarheid van uw infrastructuur in uw laatst bekende goede implementatie. Bepaal of u die configuratie moet aanpassen wanneer u uw code opnieuw implementeert.

Geef de voorkeur aan kleine, frequente wijzigingen boven onregelmatige, grote wijzigingen, zodat het verschil tussen uw nieuwe en de laatst bekende goede implementaties zo klein mogelijk is.

Voer een faalmodusanalyse uit op uw CI/CD-pijplijnen (Continuous Integration and Continuous Delivery) om problemen te identificeren die de mitigatie-inspanningen kunnen compliceren. Net als bij uw totale werklast kunnen uw pijplijnen worden geanalyseerd om gebieden te identificeren die mogelijk problematisch kunnen zijn wanneer u een bepaald type beperking probeert uit te voeren.

Spring verstandig om met het gebruik van de functionaliteit voor geautomatiseerde terugdraaiacties:

• Sommige CI/CD-tools, zoals Azure DevOps, hebben automatische terugdraaifunctionaliteit ingebouwd. Overweeg deze functionaliteit te gebruiken als deze tastbare waarde voor u oplevert.
• U moet de automatische terugdraaifunctionaliteit alleen gebruiken nadat u uw pijplijn grondig en regelmatig hebt getest. Zorg ervoor dat uw pijplijn volgroeid genoeg is om extra problemen te introduceren als een automatische terugdraaiactie wordt geactiveerd.
• U moet erop kunnen vertrouwen dat de automatisering alleen noodzakelijke wijzigingen doorvoert en alleen wordt geactiveerd wanneer dat nodig is. Ontwerp uw triggers zorgvuldig om aan deze vereisten te voldoen.

Gebruik door het platform geleverde mogelijkheden tijdens terugdraaiacties. Back-ups en herstel naar een bepaald tijdstip kunnen bijvoorbeeld helpen bij het terugdraaien van opslag en gegevens. Of als u virtuele machines gebruikt om uw applicatie te hosten, kan het handig zijn om uw omgeving te herstellen naar een controlepunt van vlak vóór het incident.

Test uw volledige strategie voor het beperken van implementatiefouten regelmatig. Net als noodplannen en noodherstelplannen is uw plan voor implementatiefout alleen succesvol als uw team hierin is getraind en er regelmatig mee oefent. Chaos engineering en fault injection testing kunnen effectieve technieken zijn voor het testen van uw strategie voor het beperken van implementatieproblemen.

Power Platform-facilitering

Pipelines zijn bedoeld om Application Lifecycle Management (ALM) te democratiseren voor Power Platform - en Dynamics 365-klanten door ALM-automatisering en CI/CD-mogelijkheden (Continuous Integration and Continuous Delivery) in de service te integreren. Power Platform

Microsoft Power Platform Build Tools voor Azure DevOps kunnen worden gebruikt om algemene build- en implementatietaken te automatiseren die betrekking hebben op apps die zijn gebouwd op Power Platform.

Met GitHub Actions kunnen ontwikkelaars geautomatiseerde workflows voor de levenscyclus van softwareontwikkeling bouwen. Power Platform Met GitHub-acties voor Microsoft Power Platform kunt u werkstromen in uw opslagplaats maken om apps te bouwen, te testen, te verpakken, vrij te geven, te implementeren, automatisering uit te voeren en bots en andere onderdelen gebouwd op Microsoft Power Platform te beheren.

ALM Accelerator is een open-sourcetool die bestaat uit een set applicaties, scripts en pijplijnen die zijn ontworpen om het continue integratie-/continue leveringsproces te automatiseren.

Automatiseer tests met Azure Pipelines.

Gebruik de Power CAT Copilot Studio Kit om copiloten en tests te configureren. Door afzonderlijke tests uit te voeren op de Copilot Studio API's (Direct Line) worden de reacties van de copiloot geëvalueerd aan de hand van de verwachte resultaten.

omgeving variabelen in oplossingen slaan de parametersleutels en -waarden op, die vervolgens als invoer voor andere toepassingsobjecten dienen. Door de parameters te scheiden van de verbruikende objecten, kunt u de waarden binnen dezelfde omgeving wijzigen of wanneer u oplossingen naar andere omgevingen migreert.

Power Platform omgevingen bieden functionaliteit voor herstel op een bepaald tijdstip, waarmee u kunt terugdraaien.

Power Platform integreert met Application Insights, dat onderdeel is van het Azure Monitor-ecosysteem. Gebruik deze integratie voor:

• Ontvang telemetrie over diagnostiek en prestaties die zijn vastgelegd door het Dataverse-platform in Application Insights. U kunt zich abonneren op het ontvangen van telemetrie over bewerkingen die toepassingen uitvoeren op uw Dataverse-database en binnen modelgestuurde apps. Deze telemetrie biedt informatie die u kunt gebruiken om problemen met betrekking tot fouten en prestaties te diagnosticeren en op te lossen.

• Koppel uw canvas-apps met Application Insights. U kunt deze analyses gebruiken om problemen te diagnosticeren en inzicht te krijgen in wat gebruikers met uw apps doen. U kunt informatie verzamelen om u te helpen betere zakelijke beslissingen te nemen en de kwaliteit van uw apps te verbeteren.

• Configure Power Automate telemetrie instromen Application Insights ; bijvoorbeeld om uitvoeringen van cloudstroom te bewaken en waarschuwingen te maken voor mislukte uitvoeringen van cloudstroom.

• Leg telemetriegegevens van uw Microsoft Copilot Studio copiloot vast voor gebruik in Azure Application Insights. Met deze telemetrie kunt u geregistreerde berichten en gebeurtenissen bewaken die naar en van uw copiloot worden verzonden, onderwerpen die tijdens gebruikersgesprekken moeten worden geactiveerd en aangepaste telemetriegebeurtenissen die vanuit uw onderwerpen kunnen worden verzonden.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige reeks aanbevelingen.

Checklist voor operationele excellentie