Delen via

Aanbevelingen voor veilige implementatieprocedures

  • Artikel

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

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

In deze handleiding worden de aanbevelingen beschreven voor het gebruik van veilige implementatieprocedures (SDP). Veilige implementatieprocessen en -procedures definiëren hoe u veilig wijzigingen in uw workload kunt aanbrengen en implementeren. Voor het implementeren van SDP moet u nadenken over implementaties via het oog op 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 waarmee u rekening 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 straal van implementatieproblemen minimaliseren door gebruik te maken van een progressief implementatiemodel voor blootstelling.

  • Statusmodellen: implementaties moeten statuscontroles doorgeven 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 van implementaties garanderen

Of u nu een update naar uw toepassingscode, infrastructuur als code (IaC), functievlag of een configuratie-update implementeert, u introduceert 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 uw supply chain en implementatiepijplijnen voor uw workload betrouwbaar, 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. Als u reguliere updates niet implementeert, worden andere risico's geïntroduceerd, 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 aan onregelmatige grote implementaties. Kleine wijzigingen zijn gemakkelijker op te lossen wanneer er problemen optreden en frequente implementaties helpen uw team om vertrouwen in het implementatieproces op te bouwen. Het is ook belangrijk dat u van productie leert door uw workloadprocessen te controleren wanneer u tijdens de implementatie een anomalie tegenkomt. Mogelijk zijn er zwakke punten 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.

Een progressief blootstellingsmodel aannemen

Wanneer er implementatieproblemen optreden, is het doel om ze zo vroeg mogelijk te ondervangen om het effect op eindgebruikers te minimaliseren. Implementeer een geleidelijk implementatiemodel, ook wel bekend als een progressief blootstellingsmodel, 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 heeft uitgevoerd, wordt de functie geïmplementeerd in opeenvolgend grotere groepen totdat de volledige 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 blauwgroene 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 klaar 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 baktijd, tijd tussen implementatiegroepen opgeven om ervoor te zorgen dat gebruikers uit verschillende regio's of gebruikers die verschillende taken uitvoeren tijd hebben om de werkbelasting 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 gedurende de loop van de dag rekening kunt houden met verschillende tijdzones en gebruikspatronen.

Robuuste workloadstatusmodellen ontwikkelen

Ontwikkel een robuust statusmodel als onderdeel van uw waarneembaarheidsplatform en betrouwbaarheidsstrategieën. Uw statusmodel moet uitgebreide zichtbaarheid 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 helpen bepalen. Als er geen problemen zijn gerapporteerd door eindgebruikers en alle statusindicatoren gedurende de baktijd groen blijven, moet de implementatie worden voortgezet. Zorg ervoor dat u metrische gegevens over gebruik in uw statusmodel opneemt om ervoor te zorgen dat een gebrek aan door de gebruiker gerapporteerde problemen en negatieve gezondheidssignalen een probleem niet verbergt. Zie Een statusmodel bouwen voor meer informatie.

Mechanismen voor foutdetectie implementeren

Wanneer uw implementatie een probleem veroorzaakt in een van de implementatiegroepen, moet de implementatie onmiddellijk stoppen. Een onderzoek naar de oorzaak van het probleem en de ernst van de effecten moet worden uitgevoerd 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 geïmplementeerd door het probleem in het midden van de implementatie aan te pakken. U kunt problemen tijdens 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 de database, het schema of andere stateful onderdelen, kan complex zijn. Uw SDP-richtlijnen moeten duidelijke instructies bieden voor het omgaan met gegevenswijzigingen volgens het ontwerp van gegevensomgevingen voor uw workload. Op dezelfde manier moet rolling forward zorgvuldig worden afgehandeld om ervoor te zorgen dat SDP niet wordt genegeerd en dat de hotfix of andere minimale inspanningen veilig worden uitgevoerd.

Protocollen voor noodimplementaties instellen

  • Implementeer versiebeheer in uw buildartefacten om ervoor te zorgen dat u zo nodig kunt terugdraaien en vooruit kunt draaien.

  • Gebruik een releasestroom- of trunk-gebaseerde vertakkingsstructuur, die nauw gesynchroniseerde samenwerking afdwingt binnen het ontwikkelteam, in plaats van een Gitflow- of omgevingsstructuur voor vertakkingen.

  • Automatiseer zoveel mogelijk van uw SDP. Zie Aanbevelingen voor het implementeren van automatisering van automatisering van IaC en continue integratie en continue levering (CI/CD) voor gedetailleerde richtlijnen voor het automatiseren van IaC- en application continuous integration and continuous delivery (CI/CD).

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

  • Gebruik functievlagmen om nieuwe functies of wijzigingen in 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 liveomgeving.

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

  • Implementeer circuitonderbrekers om het verkeer automatisch te stoppen naar een service die problemen ondervindt. Dit kan helpen om verdere verslechtering 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 problemen met noodgevallen, zoals een beveiligingsschending of blootstelling aan beveiligingsproblemen. Uw SDP-protocollen voor noodgevallen kunnen bijvoorbeeld het volgende omvatten:

  • Versnelling van niveauverhoging en goedkeuringsfase.

  • Betrouwbaarheidstests en integratietestversnelling.

  • Tijdsvermindering bakken.

In sommige gevallen kan het noodgeval de kwaliteit en testpoorten 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 noodgevallen kan goedkeuren en aan de criteria waaraan moet worden voldaan om versnelling te kunnen goedkeuren. Stem uw SDP-protocollen voor noodgevallen af met uw noodresponsplan 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 is afhankelijk van de volwassenheid van uw werkwijzen op veel gebieden van softwareontwikkeling. Het gebruik van automatisering, alleen IaC voor infrastructuurwijzigingen, 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 praktijken zich ontwikkelen.

Azure-facilitering

  • Azure Pipelines en GitHub Actions ondersteunen implementaties met meerdere fasen met behulp van goedkeuringspoorten, waarmee u uw progressieve blootstellingsimplementatie voor implementaties kunt ontwerpen.

  • Gebruik Azure-app Service-faseringssites om eenvoudig te wisselen tussen versies van code. Faseringssites zijn handig voor het testen in faseringsomgevingen en kunnen worden gebruikt voor blauwgroene implementaties.

  • Sla uw web-app-functievlagmen op en beheer deze in Azure-app Configuratie. 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 Application Health 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 zijn ontvangen van de toepassing.

  • 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 een eerdere versie herstellen of promoveren.

  • 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:

Opmerking

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

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid