Aanbevelingen voor veilige implementatieprocedures

  • Artikel

Is van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

OE:11 Definieer duidelijk de veilige implementatieprocedures van uw workload. Benadruk de idealen van kleine, incrementele, hoogwaardige releasemethoden. Gebruik moderne implementatiepatronen en progressieve blootstellingstechnieken om risico's te beheersen. Account voor routine-implementaties en implementaties voor noodgevallen of hotfiximplementaties.

In deze handleiding worden de aanbevelingen beschreven voor het gebruik van veilige implementatieprocedures (SDP). Veilige implementatieprocessen en -procedures bepalen hoe u veilig wijzigingen in uw workload aanbrengt en implementeert. Voor het implementeren van SDP moet u nadenken over implementaties via de lens van het beheren van risico's. U kunt het risico op menselijke fouten in uw implementaties minimaliseren en de gevolgen van problematische implementaties voor uw gebruikers beperken door SDP te implementeren.

Belangrijke ontwerpstrategieën

Er zijn vier belangrijke richtlijnen waar u rekening mee moet houden bij het implementeren van veilige implementatieprocedures:

  • Veiligheid en consistentie: alle wijzigingen in de productieworkload zijn inherent riskant en moeten worden aangebracht met een focus op veiligheid en consistentie.

  • Progressieve blootstelling: u kunt de potentiële explosieradius van implementatieproblemen minimaliseren door een implementatiemodel voor progressieve blootstelling te gebruiken.

  • Statusmodellen: implementaties moeten de statuscontroles doorstaan voordat elke fase van progressieve blootstelling kan beginnen.

  • Detectie van problemen: wanneer er problemen worden gedetecteerd, moet de implementatie onmiddellijk worden gestopt en moet het herstel worden gestart.

De volgende secties bevatten gedetailleerde aanbevelingen voor elk van deze punten.

Veiligheid en consistentie

Of u nu een update implementeert in uw toepassingscode, infrastructuur als code (IaC), functievlag of een configuratie-update, u loopt risico's voor de workload. Er zijn geen implementaties met een laag risico voor productie. Elke implementatie moet een standaardpatroon volgen en moet worden geautomatiseerd om consistentie af te dwingen en het risico op menselijke fouten te minimaliseren. Het is essentieel dat de toeleveringsketen en implementatiepijplijnen van uw workload betrouwbaar en veilig zijn en duidelijk gedefinieerde implementatiestandaarden hebben. Behandel elke implementatie als een mogelijk risico en onderwerp elke implementatie aan hetzelfde niveau van risicobeheer. Ondanks de risico's moet u regelmatig wijzigingen in uw workload blijven implementeren. Het niet implementeren van regelmatige updates brengt andere risico's met zich mee, zoals beveiligingsproblemen die moeten worden aangepakt via implementaties. Zie Aanbevelingen voor het ontwerpen van een supply chain voor workloadontwikkeling voor meer informatie.

Frequente kleine implementaties hebben de voorkeur boven onregelmatige grote implementaties. Kleine wijzigingen zijn gemakkelijker op te lossen wanneer er problemen optreden en frequente implementaties helpen uw team vertrouwen te krijgen in het implementatieproces. Het is ook belangrijk dat u leert van productie door uw workloadprocessen te controleren wanneer er een anomalie optreedt tijdens de implementatie. Mogelijk vindt u zwakke plekken in het ontwerp van uw infrastructuur of implementatie. Wanneer er problemen optreden tijdens implementaties, moet u ervoor zorgen dat schuldloze postmortems deel uitmaken van uw SDP-proces om lessen over het incident vast te leggen.

Implementatie van progressieve blootstelling

Wanneer er implementatieproblemen optreden, is het doel deze zo vroeg mogelijk te ondervangen om het effect op eindgebruikers te minimaliseren. Implementeer een implementatiemodel voor geleidelijke implementatie, ook wel een progressief blootstellingsmodel genoemd, om dit doel te bereiken. Canary-implementaties zijn een veelvoorkomend voorbeeld van progressieve blootstelling. In dit implementatiemodel ontvangt een kleine groep interne of externe gebruikers eerst de nieuwe functie. Nadat de eerste groep de nieuwe versie zonder probleem uitvoert, wordt de functie geïmplementeerd in opeenvolgende grotere groepen totdat de hele gebruikerspopulatie de nieuwe versie uitvoert. Functievlagmen worden doorgaans gebruikt om de nieuwe versie in te schakelen voor de doelgebruikers in canary-implementaties.

Een ander algemeen implementatiemodel is een blauw-groene benadering. In dit model worden twee identieke sets of pools van de workloadinfrastructuur geïmplementeerd. Beide pools kunnen een volledige productiebelasting verwerken. De eerste (blauwe) pool voert de huidige versie van de implementatie uit waar alle gebruikers terechtkomen. De tweede (groene) pool wordt bijgewerkt met de nieuwe functie en intern getest. Na interne tests wordt een subset van het productieverkeer gerouteerd van de blauwe pool naar de groene pool. Net als bij canary-implementaties is de implementatie progressief naarmate u meer verkeer naar de groene pool verplaatst in opeenvolgend grotere implementatiegolven. Nadat u de implementatie hebt voltooid, wordt de updategroep de blauwe pool en is de groene pool gereed voor de volgende implementatie. De twee pools zijn logisch van elkaar gescheiden om te beschermen tegen storingen. U kunt een variant van het blauwgroene model implementeren in een workload die gebruikmaakt van het ontwerppatroon Implementatiestempels door op één stempel tegelijk te implementeren.

In beide modellen moet de tijd tussen elke fase van de implementatie lang genoeg zijn om u in staat te stellen de metrische statusgegevens van de workload te bewaken. U moet voldoende bake-tijd en tijd opgeven tussen implementatiegroepen om ervoor te zorgen dat gebruikers uit verschillende regio's of gebruikers die verschillende taken uitvoeren, tijd hebben om de workload in hun normale capaciteit te gebruiken. Baktijden moeten worden gemeten in uren en dagen in plaats van minuten. Baktijden moeten ook toenemen voor elke implementatiegroep, zodat u in de loop van de dag rekening kunt houden met verschillende tijdzones en gebruikspatronen.

Statusmodellen

Ontwikkel een robuust statusmodel als onderdeel van uw waarneembaarheidsplatform en betrouwbaarheidsstrategieën. Uw statusmodel moet uitgebreid inzicht bieden in de onderdelen en de algehele status van de workload. Als u tijdens een implementatie een waarschuwing ontvangt over een statuswijziging met betrekking tot een eindgebruiker, moet de implementatie onmiddellijk worden gestopt en moet er een onderzoek worden uitgevoerd naar de oorzaak van de waarschuwing om de volgende actie te bepalen. Als er geen problemen worden gerapporteerd door eindgebruikers en alle statusindicatoren gedurende de bake-tijd groen blijven, moet de implementatie worden voortgezet. Zorg ervoor dat u metrische gegevens over gebruik opneemt in uw statusmodel om ervoor te zorgen dat een gebrek aan door de gebruiker gerapporteerde problemen en negatieve statussignalen geen probleem verbergen. Zie Een statusmodel bouwen voor meer informatie.

Probleemdetectie

Wanneer uw implementatie een probleem veroorzaakt in een van de implementatiegroepen, moet de implementatie onmiddellijk worden gestopt. Er moet een onderzoek worden uitgevoerd naar de oorzaak van het probleem en de ernst van de effecten zodra de waarschuwing is ontvangen. Herstel van het probleem kan het volgende omvatten:

  • De implementatie terugdraaien door de wijzigingen in de implementatie ongedaan te maken en terug te keren naar de laatst bekende werkende configuratie.

  • De implementatie wordt vooruitgerold door het probleem midden in de implementatie op te lossen. U kunt problemen halverwege de implementatie oplossen door een hotfix toe te passen of het probleem op een andere manier te minimaliseren.

  • Nieuwe infrastructuur implementeren met behulp van de laatst bekende werkende configuratie.

Het terugdraaien van wijzigingen, met name wijzigingen in de database, het schema of andere stateful onderdelen, kan complex zijn. Uw SDP-richtlijnen moeten duidelijke instructies bieden voor het omgaan met gegevenswijzigingen op basis van het gegevensdomeinontwerp voor uw workload. Op dezelfde manier moet het doorrollen zorgvuldig worden behandeld om ervoor te zorgen dat SDP niet wordt genegeerd en dat de hotfix of andere minimaliserende inspanningen veilig worden uitgevoerd.

Algemene aanbevelingen voor SDP

  • Implementeer versiebeheer in uw buildartefacten om ervoor te zorgen dat u kunt terugdraaien en terugdraaien wanneer dat nodig is.

  • Gebruik een releasestroom of vertakkingsstructuur op basis van trunks, waarmee nauw gesynchroniseerde samenwerking binnen het ontwikkelteam wordt afgedwongen, in plaats van een Gitflow- of omgevingsgebaseerde vertakkingsstructuur.

  • Automatiseer zoveel mogelijk van uw SDP. Zie Recommendations for implementing automation (Aanbevelingen voor het implementeren van automatisering) voor gedetailleerde richtlijnen voor het automatiseren van IaC- en toepassingsprocessen voor continue integratie en continue levering (CI/CD).

  • Gebruik CI-procedures om regelmatig codewijzigingen te integreren in opslagplaatsen. CI-procedures kunnen u helpen bij het identificeren van integratieconflicten en de kans op grote, riskante samenvoegingen verminderen. Zie de handleiding voor continue integratie voor meer informatie.

  • Gebruik functievlagmen om nieuwe functies of wijzigingen in de productie selectief in of uit te schakelen. Met functievlagmen kunt u de blootstelling van nieuwe code beheren en de implementatie snel terugdraaien als er problemen optreden.

  • Implementeer wijzigingen in faseringsomgevingen die uw productieomgeving weerspiegelen. Met oefenomgevingen kunt u wijzigingen in een gecontroleerde instelling testen voordat u implementeert in de live-omgeving.

  • Stel controles vooraf in, waaronder codebeoordeling, beveiligingsscans en nalevingscontroles, om ervoor te zorgen dat wijzigingen veilig kunnen worden geïmplementeerd.

  • Implementeer circuitonderbrekers om automatisch verkeer naar een service te stoppen die problemen ondervindt. Dit kan helpen om verdere degradatie van het systeem te voorkomen.

SDP-protocollen voor noodgevallen

Stel prescriptieve protocollen in die definiëren hoe uw SDP kan worden aangepast voor een hotfix of voor noodgevallen, zoals een beveiligingsschending of blootstelling aan beveiligingsproblemen. Uw SDP-protocollen voor noodgevallen kunnen bijvoorbeeld het volgende bevatten:

  • Versnelling van promotie- en goedkeuringsfase.

  • Betrouwbaarheidstests en integratietestversnelling.

  • Tijdverkorting bakken.

In sommige gevallen kan de nood de kwaliteit en het testen van poorten beperken, maar poorten moeten nog steeds zo snel mogelijk worden uitgevoerd als een out-of-band oefening. Zorg ervoor dat u definieert wie SDP-versnelling in een noodgeval kan goedkeuren en de criteria waaraan moet worden voldaan om de versnelling te kunnen goedkeuren. Stem uw SDP-protocollen voor noodgevallen af met uw noodplan om ervoor te zorgen dat alle noodsituaties volgens dezelfde protocollen worden afgehandeld.

Overwegingen

Het bouwen en onderhouden van veilige implementatieprocedures is complex. Uw succes bij het volledig implementeren van robuuste standaarden hangt af van de volwassenheid van uw procedures op veel gebieden van softwareontwikkeling. Het gebruik van automatisering, alleen-IaC voor wijzigingen in de infrastructuur, consistentie in vertakkingsstrategieën, het gebruik van functievlagmen en vele andere procedures kunnen helpen om een veilige implementatie te garanderen. Gebruik deze handleiding om uw workload te optimaliseren en uw plannen voor verbetering te informeren naarmate uw procedures zich ontwikkelen.

Azure-facilitering

  • Azure Pipelines en GitHub Actions ondersteunen implementaties met meerdere fasen met behulp van goedkeuringspoorten, die u kunnen helpen bij het ontwerpen van uw progressieve blootstellingsimplementatie voor implementaties.

  • Gebruik Azure App Service staging-sites om eenvoudig tussen codeversies te wisselen. Faseringssites zijn handig voor het testen in faseringsomgevingen en kunnen worden gebruikt voor blauwgroene implementaties.

  • De functievlagmen van uw web-app opslaan en beheren in Azure App Configuration. Met deze service kunt u functies maken, wijzigen en implementeren in een geïntegreerd beheervlak.

  • Implementeer workloadtoepassingen in uw virtuele machine met behulp van VM-toepassingen.

  • Gebruik Azure Load Balancers om implementatiestrategieën te implementeren en de status van uw workloadtoepassingen beschikbaar te maken met behulp van systeemeigen resources.

  • Gebruik de extensie Toepassingsstatus om te rapporteren over de toepassingsstatus vanuit een exemplaar van een virtuele-machineschaalset. De extensie test op een lokaal toepassingseindpunt en werkt de status bij op basis van TCP/HTTP(S)-antwoorden die van de toepassing zijn ontvangen.

  • Gebruik Azure Logic Apps om een nieuwe versie van de toepassing te maken wanneer er een update wordt uitgevoerd. Azure onderhoudt een geschiedenis van toepassingsversies en kan terugkeren naar of promoveren naar een eerdere versie.

  • Veel Azure Database-services bieden functionaliteit voor herstel naar een bepaald tijdstip die u kan helpen terug te draaien. Services die ondersteuning bieden voor herstel naar een bepaald tijdstip zijn onder andere:

Voorbeeld

Zie de blauwgroene handleiding voor de implementatie van Azure Kubernetes Service (AKS)-clusters voor een voorbeeld van het gebruik van dit implementatiemodel.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid