Aanbevelingen voor het ontwerpen van een strategie voor het beperken van implementatiefouten
Is van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:
| OE:12 | Implementeer een strategie voor het beperken van implementatiefouten waarmee onverwachte problemen tijdens de implementatie tijdens de implementatie worden opgelost met snel herstel. Combineer meerdere benaderingen, zoals het terugdraaien, uitschakelen van functies of het gebruik van de systeemeigen mogelijkheden van uw implementatiepatroon. |
|---|
In deze handleiding 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 instelling kunt u proactief zijn door een goed ontworpen, opzettelijke strategie te hebben voor het oplossen van implementatiefouten. Een dergelijke strategie stelt uw workloadteam in staat om fouten efficiënt te beperken met zo min mogelijk gevolgen voor uw eindgebruikers.
Het ontbreken van een dergelijk plan kan leiden tot chaotische en mogelijk schadelijke reacties op problemen, die een aanzienlijke invloed kunnen hebben op team- en organisatiecohesie, klantvertrouwen en financiën.
Belangrijke ontwerpstrategieën
Ondanks de volwassenheid van uw ontwikkelprocedures kunnen er af en toe implementatieproblemen optreden. Door veilige implementatieprocedures te gebruiken en een robuuste supply chain voor workloads te gebruiken , kunt u de frequentie van mislukte implementaties minimaliseren. Maar u moet ook een gestandaardiseerde strategie ontwerpen om mislukte implementaties af te handelen wanneer deze zich voordoen.
Wanneer u een implementatiemodel voor progressieve blootstelling als standaardpraktijk gebruikt:
- U hebt de juiste basis om de gevolgen voor uw klanten of interne gebruikers te minimaliseren wanneer implementaties mislukken.
- U kunt problemen efficiënt oplossen.
Een strategie voor het beperken van implementatiefouten bestaat uit vijf algemene fasen:
Detectie: als u wilt reageren op een mislukte implementatie, moet u de fout eerst detecteren. Detectie kan verschillende vormen aannemen, zoals mislukte betrouwbaarheidstests, door de gebruiker gemelde problemen of waarschuwingen die uw bewakingsplatform genereert.
Beslissing: u moet bepalen wat de beste risicobeperkingsstrategie is voor het specifieke fouttype.
Beperking: u voert de geïdentificeerde beperkingsactie uit. De beperking kan de vorm hebben van een terugval, terugdraaiactie, roll-forward of het gebruik van een runtime-configuratie om de offending-functie te omzeilen.
Communicatie: Belanghebbenden en betrokken eindgebruikers moeten op de hoogte worden gesteld van de status wanneer u het probleem detecteert en er doorheen werkt, zoals vereist door uw noodplan.
Postmortem: Blameless postmortems bieden het workloadteam de mogelijkheid om verbeterpunten te identificeren en plannen te maken voor het toepassen van leertrajecten.
De volgende secties bevatten gedetailleerde aanbevelingen voor deze fasen. In deze secties wordt ervan uitgegaan dat u een probleem detecteert nadat u uw wijzigingen hebt geïmplementeerd in een of meer groepen gebruikers of systemen, maar voordat u alle groepen in uw implementatieplan bijwerkt.
Detectie
Als u problemen met implementaties snel wilt identificeren, hebt u robuuste test - en waarneembaarheidsmethoden nodig voor wat betreft implementaties. Als u afwijkingen snel wilt detecteren, kunt u de bewaking en waarschuwingen van uw workload aanvullen door de volgende stappen uit te voeren:
- Een hulpprogramma voor toepassingsprestatiebeheer gebruiken.
- Logboekregistratie via instrumentatie inschakelen.
Betrouwbaarheidstests en andere kwaliteitstests moeten plaatsvinden in elke fase van uw implementatie. 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 bepalen aan welke implementatiegroep een bepaalde gebruiker is gekoppeld. Deze benadering is met name belangrijk voor implementaties met progressieve blootstelling, omdat u op een bepaald moment in de implementatie meerdere configuraties kunt uitvoeren in uw gebruikersbestand.
U moet klaar zijn om onmiddellijk te reageren op door de gebruiker gemelde problemen. Wanneer dit praktisch is, implementeert u de implementatiefase tijdens werkuren, wanneer u een volledig ondersteuningsteam beschikbaar hebt. Zorg ervoor dat het ondersteuningspersoneel is getraind in het escaleren van implementatieproblemen voor de juiste routering. Escalaties moeten in overeenstemming zijn met uw plan voor noodrespons op uw werkbelasting.
Besluit
Bij het kiezen van een geschikte risicobeperkingsstrategie voor een bepaald implementatieprobleem moet rekening worden gehouden met een groot aantal factoren, waaronder:
Het type model voor progressieve blootstelling dat u gebruikt. U kunt bijvoorbeeld een blauw-groen model of een kanariemodel gebruiken.
Als u een blauw-groen model gebruikt, is terugvallen praktischer dan terugdraaien. U kunt eenvoudig verkeer terugbrengen naar de stack waarop de configuratie wordt uitgevoerd die niet is bijgewerkt. Vervolgens kunt u het probleem in de problematische omgeving oplossen en de implementatie op een geschikt moment opnieuw proberen.
De methoden die u tot uw beschikking hebt om het probleem te omzeilen. Voorbeelden zijn het gebruik van functievlagmen, omgevingsvariabelen of een ander type runtimeconfiguratie-eigenschap die u kunt in- en uitschakelen.
Soms kunt u een probleem eenvoudig omzeilen door een functievlag uit te schakelen of een instelling in te schakelen. In dit geval kunt u mogelijk het volgende doen:
- Ga verder met de implementatie.
- Vermijd terugvallen.
- Terugdraaien terwijl u de code voor de overtreding herstelt.
Het inspanningsniveau dat nodig is om een fix in de code te implementeren.
Als het niveau van inspanning om de code te herstellen laag is, is doorrollen door het implementeren van een hot fix de juiste keuze voor bepaalde scenario's.
Het niveau van kritiek voor de betrokken workload.
Bedrijfskritieke workloads moeten altijd naast elkaar worden geïmplementeerd, zoals in een blauw-groen model, om implementaties zonder downtime te realiseren. Als gevolg hiervan is terugvallen de voorkeursstrategie voor dit soort workloads.
Het type infrastructuur dat door de workload wordt gebruikt: veranderlijk of onveranderbaar.
Als uw workload is ontworpen voor het gebruik van veranderlijke infrastructuur, kan het zinvol zijn om vooruit te gaan, omdat hiervoor de infrastructuur moet worden bijgewerkt. Omgekeerd kan terugdraaien of terugvallen zinvol zijn wanneer u een onveranderbare infrastructuur gebruikt.
Ongeacht welke keuzes u maakt, moet u de juiste goedkeuringen opnemen in uw besluitvormingsproces en deze in uw beslissingsstructuur codificeren.
Oplossing
Terugdraaien: In een terugdraaiscenario keert u bijgewerkte systemen terug naar de laatst bekende goede configuratiestatus.
Het is belangrijk dat het hele workloadteam het eens is over de betekenis van het laatst bekende goede. Deze expressie verwijst naar de laatste status van de werkbelasting die in orde was voordat de implementatie begon, wat niet noodzakelijkerwijs de vorige toepassingsversie is.
Terugdraaien kan complex zijn, vooral als het gaat om gegevenswijzigingen. Schemawijzigingen kunnen het terugdraaien riskant maken. Een veilige implementatie kan veel planning vereisen. Als algemene aanbeveling moeten schema-updates additief zijn. Dit mogen geen vervangende wijzigingen zijn. Records mogen niet worden vervangen 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.
Terugval: In een terugvalscenario worden de bijgewerkte systemen verwijderd uit de routering van productieverkeer. Al het verkeer wordt omgeleid naar de stack die niet is bijgewerkt. Deze strategie met een laag risico biedt u een manier om de problemen in uw code op te lossen zonder verdere onderbrekingen te veroorzaken.
Bij canary-implementaties is terugvallen mogelijk niet eenvoudig of zelfs niet mogelijk, afhankelijk van uw infrastructuur en app-ontwerp. Als u moet schalen om de belasting te verwerken op systemen die niet worden bijgewerkt, moet u dat schalen uitvoeren voordat u terugvalt.
De offending-functie omzeilen: als u het probleem kunt omzeilen met behulp van functievlagmen of een ander type runtimeconfiguratie-eigenschap, kunt u besluiten dat doorgaan met de implementatie de juiste strategie is voor een bepaald probleem.
U moet de afweging van het omzeilen van de functie duidelijk begrijpen en u moet die afweging kunnen communiceren met belanghebbenden. Belanghebbenden moeten het plan voor de toekomst goedkeuren. Belanghebbenden moeten bepalen hoe lang het duurt voor gebruik in een verslechterde status. Ze moeten die bepaling ook afwegen tegen uw schatting van de tijd die nodig is om de foutcode op te lossen en deze te implementeren.
Implementatie in noodgevallen (hot fix): als u het probleem halverwege de implementatie kunt oplossen, is een hot fix mogelijk de meest praktische oplossing.
Net als andere code moeten hot fixes uw veilige implementatieprocedures doorlopen. Maar met een snelle oplossing wordt de tijdlijn aanzienlijk versneld. U moet een strategie voor codepromotie gebruiken in uw omgevingen. U moet ook de hot fix-code controleren bij alle kwaliteitspoorten. Maar mogelijk moet u de baktijden aanzienlijk verkorten en moet u mogelijk 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 automatiseren van kwaliteitsbewakingstests in hoge mate helpt het testen in deze scenario's efficiënt te maken.
Compromissen:
- Als u kunt terugvallen, betekent dit meestal dat u voldoende infrastructuurcapaciteit nodig hebt om twee versies van uw workloadconfiguratie tegelijkertijd te verwerken. Uw workloadteams moeten ook tegelijkertijd twee versies in productie kunnen ondersteunen.
- Als u effectief kunt terugdraaien, kan het nodig zijn om elementen van uw workload te herstructureren. U moet bijvoorbeeld mogelijk functies loskoppelen of uw gegevensmodel wijzigen.
Communicatie
Het is belangrijk om duidelijk gedefinieerde communicatieverantwoordelijkheden te hebben om chaos tijdens incidenten te minimaliseren. Deze verantwoordelijkheden moeten bepalen hoe het workloadteam contact heeft met ondersteuningsteams, belanghebbenden en medewerkers van het noodhulpteam, zoals de noodhulpmanager.
Standaardiseer de frequentie die 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 workloadteam rechtstreeks met eindgebruikers moet communiceren, verduidelijkt u het type informatie en het detailniveau dat geschikt is voor het delen met gebruikers. Communiceer ook aan het workloadteam eventuele andere vereisten die van toepassing zijn op deze gevallen.
Postmortem
Postmortems moeten alle mislukte implementaties volgen, zonder uitzondering. Elke mislukte implementatie is een kans om te leren. Postmortems kunnen u helpen zwakke plekken in uw implementatie- en ontwikkelingsprocessen te identificeren. U kunt ook onjuiste configuraties in uw infrastructuur identificeren, naast vele andere mogelijkheden.
Postmortems moeten altijd foutloos zijn, zodat personen die betrokken zijn bij het incident zich veilig voelen wanneer ze hun perspectieven delen over wat kan worden verbeterd. Postmortem-leiders moeten opvolgen met plannen voor het implementeren van de geïdentificeerde verbeteringen en het toevoegen van deze plannen aan de workloadachterstand.
Overwegingen en algemene aanbevelingen
Zorg ervoor dat uw implementatiepijplijn afzonderlijke versies als parameters kan accepteren, zodat u eenvoudig de laatst bekende goede configuraties kunt implementeren.
Behoud consistentie met de beheer- en gegevensvlakken tijdens het terugdraaien of terugdraaien. Sleutels, geheimen, databasestatusgegevens en configuraties die specifiek zijn voor resources en beleidsregels, moeten allemaal binnen het bereik vallen en worden verwerkt. Let bijvoorbeeld op het ontwerp van het schalen 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 de verschillen tussen uw nieuwe en laatst bekende goede implementaties klein zijn.
Voer een foutmodusanalyse (FMA) uit op uw CI/CD-pijplijnen (continue integratie en continue levering) om problemen te identificeren die risicobeperkingen kunnen bemoeilijken. Net als uw workload als geheel kunnen uw pijplijnen worden geanalyseerd om gebieden te identificeren die mogelijk problematisch zijn wanneer u een bepaald beperkingstype probeert uit te voeren.
Gebruik de functionaliteit voor geautomatiseerd terugdraaien verstandig:
- Sommige CI/CD-hulpprogramma's, zoals Azure DevOps, hebben ingebouwde functionaliteit voor automatisch terugdraaien. Overweeg deze functionaliteit te gebruiken als deze tastbare waarde voor u biedt.
- U moet de functionaliteit voor automatisch terugdraaien pas gebruiken nadat u uw pijplijn grondig en regelmatig hebt getest. Zorg ervoor dat uw pijplijn volwassen genoeg is om extra problemen te veroorzaken als een automatische terugdraaiactie wordt geactiveerd.
- U moet erop vertrouwen dat de automatisering alleen noodzakelijke wijzigingen implementeert en dat deze 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 opslag en het terugdraaien van gegevens. Of als u virtuele machines (VM's) gebruikt om uw toepassing te hosten, kan het handig zijn om uw omgeving te herstellen naar een controlepunt dat zich vlak voor een incident bevindt.
Test uw volledige strategie voor het beperken van implementatiefouten regelmatig. Net als noodresponsplannen en noodherstelplannen is uw plan voor implementatiefouten alleen succesvol als uw team erop is getraind en het regelmatig uitvoert. Chaos-engineering en foutinjectietests kunnen effectieve technieken zijn voor het testen van uw implementatiebeperkingsstrategie.
Azure-facilitering
Azure Pipelines biedt build- en releaseservices ter ondersteuning van CI/CD van uw toepassingen.
Azure Test Plans is een op een browser gebaseerde oplossing voor testbeheer die eenvoudig te gebruiken is. Deze oplossing biedt mogelijkheden die vereist zijn voor geplande handmatige tests, gebruikersacceptatietests en verkennende tests. Azure Test Plans biedt u ook een manier om feedback van belanghebbenden te verzamelen.
Azure Monitor is een uitgebreide bewakingsoplossing voor het verzamelen, analyseren en reageren op bewakingsgegevens uit uw cloud- en on-premises omgevingen. Monitor bevat een robuust waarschuwingsplatform. U kunt dat systeem configureren voor automatische meldingen en andere acties, zoals automatisch schalen en andere mechanismen voor zelfherstel.
Application Insights is een uitbreiding van Monitor die APM-functies (Application Performance Monitoring) biedt.
Azure Logic Apps is een cloudplatform voor het uitvoeren van geautomatiseerde werkstromen die apps, gegevens, services en systemen integreren. U kunt Logic Apps gebruiken om een nieuwe versie van uw toepassing te maken wanneer er een update wordt uitgevoerd. Azure houdt een geschiedenis bij van de versies en kan een eerdere versie herstellen of promoveren.
Veel Azure-databaseservices bieden functionaliteit voor herstel naar een bepaald tijdstip die u kan helpen wanneer u wilt terugdraaien:
Azure Chaos Studio Preview is een beheerde service die gebruikmaakt van chaos-engineering om u te helpen bij het meten, begrijpen en verbeteren van de tolerantie van uw cloudtoepassing en service.
Verwante koppelingen
- Progressief experimenteren met functievlagmen
- Aanbevelingen voor het ontwerpen en maken van een framework voor waarneembaarheid
- Aanbevelingen voor het ontwerpen van een strategie voor noodhulp
- Aanbevelingen voor het ontwerpen van een strategie voor betrouwbaarheidstests
- Aanbevelingen voor het ontwerpen van een supply chain voor workloadontwikkeling
- Aanbevelingen voor het uitvoeren van analyse van foutmodus
- Aanbevelingen voor veilige implementatieprocedures
Controlelijst voor operationele uitmuntendheid
Raadpleeg de volledige set aanbevelingen.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor