Aanbevelingen voor het ontwerpen van een strategie voor het beperken van implementatiefouten
Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:
| OE:12 | Implementeer een strategie voor het beperken van implementatiefouten die onverwachte problemen met de implementatie tijdens de implementatie oplossen met snel herstel. Combineer meerdere benaderingen, zoals 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 bij andere workloadproblemen zijn implementatiefouten een onvermijdelijk onderdeel van de levenscyclus van een workload. Met deze mindset kunt u proactief zijn door een goed ontworpen, opzettelijke strategie te hebben voor het omgaan met implementatiefouten. Met een dergelijke strategie kan uw workloadteam fouten efficiënt beperken met zo weinig mogelijk impact op uw eindgebruikers.
Het ontbreken van een dergelijk plan kan leiden tot chaos en potentieel schadelijke reacties op problemen, die een aanzienlijke invloed kunnen hebben op de samenhang van het team en de organisatie, het vertrouwen van de klant en de financiën.
Belangrijke ontwerpstrategieën
Af en toe, ondanks de volwassenheid van uw ontwikkelprocedures, treden implementatieproblemen op. 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 plaatsvinden.
Wanneer u een progressief implementatiemodel voor blootstelling gebruikt als uw standaardpraktijk:
- U hebt de juiste basis voor het minimaliseren van de gevolgen voor uw klanten of interne gebruikers wanneer implementaties mislukken.
- U kunt problemen efficiënt beperken.
Een strategie voor het beperken van implementatiefouten bestaat uit vijf algemene fasen:
Detectie: Als u wilt reageren op een mislukte implementatie, moet u eerst de fout detecteren. Detectie kan verschillende vormen aannemen, zoals mislukte betrouwbaarheidstests, door de gebruiker gerapporteerde problemen of waarschuwingen die door uw bewakingsplatform worden gegenereerd.
Beslissing: U moet bepalen wat de beste risicobeperkingsstrategie is voor het specifieke fouttype.
Risicobeperking: u voert de geïdentificeerde risicobeperkingsactie uit. De beperking kan de vorm aannemen van een terugval, terugdraaien, terugdraaien, doorsturen of het gebruik van een runtimeconfiguratie 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 doorwerkt zoals vereist voor uw noodresponsplan.
Postmortem: Schuldloze postmortems bieden mogelijkheden voor het workloadteam om gebieden voor verbetering te identificeren en plannen te maken om leertrajecten toe te passen.
De volgende secties bevatten gedetailleerde aanbevelingen voor deze fasen. In deze secties wordt ervan uitgegaan dat u een probleem detecteert nadat u uw wijzigingen in een of meer groepen gebruikers of systemen hebt geïmplementeerd, maar voordat u alle groepen in uw implementatieplan bijwerkt.
Mechanismen voor foutdetectie ontwerpen
Als u snel problemen met implementaties wilt identificeren, hebt u robuuste test- en waarneembaarheidsprocedures nodig, omdat deze betrekking hebben op implementaties. Als u afwijkingen snel wilt detecteren, kunt u uw workloadbewaking en -waarschuwingen aanvullen door de volgende stappen uit te voeren:
- Gebruik een hulpprogramma voor het beheer van toepassingsprestaties.
- 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 te testen in volgende groepen.
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 er mogelijk meerdere configuraties worden uitgevoerd in uw gebruikersbasis op elk bepaald punt in de implementatie.
U moet direct kunnen reageren op door de gebruiker gerapporteerde problemen. Implementeer uw implementatiefase tijdens kantooruren wanneer u een volledig ondersteuningsteam beschikbaar hebt wanneer u praktisch de implementatiefase implementeert. Zorg ervoor dat ondersteuningsmedewerkers zijn getraind voor het escaleren van implementatieproblemen voor de juiste routering. Escalaties moeten overeenkomen met uw plan voor reactie op noodgevallen van workloads.
Beslissen over de risicobeperkingsstrategie
Het bepalen van een geschikte oplossingsstrategie voor een bepaald implementatieprobleem omvat het overwegen van veel factoren, waaronder:
Het type progressief blootstellingsmodel dat u gebruikt. U kunt bijvoorbeeld een blauw-groen model of een canary-model gebruiken.
Als u een blauwgroen model gebruikt, is terugvallen praktischer dan terugdraaien. U kunt eenvoudig verkeer terugzetten naar de stack waarop de configuratie wordt uitgevoerd die niet wordt bijgewerkt. Vervolgens kunt u het probleem 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 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 door met de implementatie.
- Vermijd terugvallen.
- Terugdraaien terwijl u de offending-code herstelt.
Het inspanningsniveau dat nodig is om een oplossing in de code te implementeren.
Als het inspanningsniveau voor het oplossen van de code laag is, is het implementeren van een hot fix de juiste keuze voor bepaalde scenario's.
Het kritieke niveau voor de betrokken workload.
Bedrijfskritieke workloads moeten altijd naast elkaar worden geïmplementeerd, zoals in een blauwgroen model, om implementaties zonder downtime te realiseren. Als gevolg hiervan is het terugvallen de voorkeursstrategie voor het beperken van deze typen workloads.
Het type infrastructuur dat door de workload wordt gebruikt, onveranderbaar of onveranderbaar.
Als uw workload is ontworpen voor het gebruik van onveranderbare infrastructuur, kan het voortschrijden zinvol zijn, omdat het gaat om het bijwerken van de infrastructuur. Omgekeerd kan het terugdraaien of terugvallen zinvol zijn wanneer u onveranderbare infrastructuur gebruikt.
Ongeacht welke keuzes u maakt, moet u de juiste goedkeuringen opnemen in uw besluitvormingsproces en deze in uw beslissingsstructuur codificeren.
De risicobeperkingsstrategie implementeren
Terugdraaien: In een terugdraaiscenario kunt u bijgewerkte systemen terugzetten naar de laatst bekende goede configuratiestatus.
Het is belangrijk dat het hele workloadteam het eens is over de betekenis van laatst bekende goede. Deze expressie verwijst naar de laatste status van de workload die in orde was voordat de implementatie werd gestart, wat niet noodzakelijkerwijs de vorige toepassingsversie is.
Terugdraaien kan complex zijn, met name omdat het betrekking heeft op gegevenswijzigingen. Schemawijzigingen kunnen riskant zijn. Het veilig implementeren ervan kan aanzienlijke planning vereisen. Als algemene aanbeveling moeten schema-updates additief zijn. Ze mogen geen vervangingswijzigingen 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 wordt bijgewerkt. Deze strategie met een laag risico biedt u een manier om de problemen in uw code op te lossen zonder verdere onderbrekingen te introduceren.
Bij canary-implementaties is het terugvallen mogelijk niet eenvoudig of zelfs niet mogelijk, afhankelijk van uw infrastructuur en app-ontwerp. Als u schaalaanpassing moet uitvoeren om de belasting van systemen te verwerken die niet worden bijgewerkt, moet u die schaalbewerking uitvoeren voordat u terugvalt.
Overslaan van de offending-functie: als u het probleem kunt omzeilen met behulp van functievlagmen of een ander type runtimeconfiguratie-eigenschap, kunt u besluiten dat het doorgaan met de implementatie de juiste strategie is voor een bepaald probleem.
U moet duidelijk begrijpen wat de afweging is van het omzeilen van de functie en u moet die afweging kunnen communiceren met belanghebbenden. Belanghebbenden moeten het plan goedkeuren. Belanghebbenden moeten de tijdsduur bepalen die acceptabel is voor het werken in een gedegradeerde status. Ze moeten die bepaling ook afwegen tegen uw schatting van de tijd die nodig is om de code te herstellen en deze te implementeren.
Implementatie van noodgevallen (hot fix): als u het probleem tijdens de implementatie kunt oplossen, is een hot fix mogelijk de meest praktische oplossingsstrategie.
Net als bij andere code moeten hot fixes uw veilige implementatieprocedures doorlopen. Maar met een hot fix is de tijdlijn aanzienlijk versneld. U moet een strategie voor codepromotie gebruiken in uw omgevingen. U moet ook hot fix-code controleren bij alle kwaliteitspoorten. Maar misschien moet u de baktijden aanzienlijk verkorten en moet u mogelijk tests wijzigen om ze te versnellen. Zorg ervoor dat u na de implementatie volledige tests op de bijgewerkte code kunt uitvoeren. Het automatiseren van kwaliteitscontroletests in hoge mate helpt het testen efficiënt te maken in deze scenario's.
Compromissen:
- Het terugvallen betekent meestal dat u voldoende infrastructuurcapaciteit nodig hebt om tegelijkertijd twee versies van uw workloadconfiguratie af te handelen. Uw workloadteams moeten ook tegelijkertijd twee versies in productie kunnen ondersteunen.
- Het effectief terugdraaien kan betrekking hebben op het herstructureren van elementen van uw workload. U moet bijvoorbeeld functies loskoppelen of uw gegevensmodel wijzigen.
Statusupdates standaardiseren tijdens een incident
Het is belangrijk om duidelijk gedefinieerde communicatieverantwoordelijkheden te hebben om chaos tijdens incidenten tot een minimum te beperken. Deze verantwoordelijkheden moeten bepalen hoe het workloadteam contact houdt met ondersteuningsteams, belanghebbenden en medewerkers van het noodhulpteam, zoals de noodhulpmanager.
Standaardiseer de frequentie die het workloadteam volgt voor het leveren van statusupdates. Zorg ervoor dat belanghebbenden op de hoogte zijn van deze standaard, zodat ze weten wanneer ze updates moeten verwachten.
Als het workloadteam rechtstreeks met eindgebruikers moet communiceren, moet u het type informatie en detailniveau verduidelijken dat geschikt is voor het delen met gebruikers. Communiceer ook met het workloadteam alle andere vereisten die van toepassing zijn op deze gevallen.
Incidentpostmortems uitvoeren
Postmortems moeten alle mislukte implementaties volgen, zonder uitzondering. Elke mislukte implementatie is een kans om te leren. Postmortems kunnen u helpen zwakke punten in uw implementatie- en ontwikkelingsprocessen te identificeren. U kunt ook onjuiste configuraties in uw infrastructuur identificeren, naast vele andere mogelijkheden.
Postmortems moeten altijd schuldloos zijn, zodat personen die betrokken zijn bij het incident zich veilig voelen wanneer ze hun perspectief delen over wat er kan worden verbeterd. Postmortem-leiders moeten opvolgen met plannen voor het implementeren van de verbeteringen die zijn geïdentificeerd en die deze plannen toevoegen aan de achterstand van de werkbelasting.
Risicobeperkingsprocessen operationeel maken
Zorg ervoor dat uw implementatiepijplijn afzonderlijke versies als parameters kan accepteren, zodat u eenvoudig last-known-good-configuraties kunt implementeren.
Behoud de consistentie met de beheer- en gegevensvlakken terwijl u terugdraait of vooruitdraait. Sleutels, geheimen, databasestatusgegevens en configuraties die specifiek zijn voor resources en beleidsregels, moeten allemaal binnen het bereik vallen en waarvoor rekening moet worden gehouden. 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 de code opnieuw implementeert.
Geef de voorkeur aan kleine, frequente wijzigingen ten opzichte van onregelmatige, grote wijzigingen, zodat de verschillen tussen uw nieuwe en laatst bekende goede implementaties klein zijn.
Voer een analyse van de foutmodus (FMA) uit op uw CI/CD-pijplijnen (continue integratie en continue levering) om problemen te identificeren die risicobeperking 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 zorgvuldig:
- Sommige CI/CD-hulpprogramma's zoals Azure DevOps hebben automatische terugdraaifunctionaliteit die is ingebouwd. Overweeg deze functionaliteit te gebruiken als deze tastbare waarde aan 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 voldoende volwassen is om extra problemen te introduceren als een automatische terugdraaiactie wordt geactiveerd.
- U moet 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 het terugdraaien. Back-ups en herstel naar een bepaald tijdstip kunnen bijvoorbeeld helpen bij het terugdraaien van opslag en 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 direct vóór een incident valt.
Test regelmatig de volledige strategie voor het beperken van implementatiefouten. Net als noodresponsplannen en noodherstelplannen is uw implementatiefoutplan alleen succesvol als uw team hierop is getraind en regelmatig in de praktijk wordt gebruikt. 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 browsers gebaseerde testbeheeroplossing die eenvoudig te gebruiken is. Deze oplossing biedt mogelijkheden die vereist zijn voor geplande handmatige tests, gebruikersacceptatietests en verkennende tests. Azure Test Plans biedt 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 zelfherstelmechanismen.
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 waarmee apps, gegevens, services en systemen kunnen worden geïntegreerd. U kunt Logic Apps gebruiken om een nieuwe versie van uw toepassing te maken wanneer er een update wordt uitgevoerd. Azure onderhoudt een geschiedenis van de versies en kan een eerdere versie terugdraaien of promoveren.
Veel Azure-databaseservices bieden functionaliteit voor herstel naar een bepaald tijdstip die u kan helpen bij het terugdraaien:
Azure Chaos Studio Preview is een beheerde service die gebruikmaakt van chaos-engineering om u te helpen uw cloudtoepassing en servicetolerantie te meten, te begrijpen en te verbeteren.
Verwante koppelingen
- Progressieve experimenten met functievlagmen
- Aanbevelingen voor het ontwerpen en maken van een waarneembaarheidsframework
- Aanbevelingen voor het ontwerpen van een strategie voor noodgevallen
- 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.