Ontwerpprincipes van een bedrijfskritieke workload

De bedrijfskritieke ontwerpmethodologie wordt ondersteund door vijf belangrijke ontwerpprincipes die als kompas dienen voor latere ontwerpbeslissingen in de kritieke ontwerpgebieden. We raden u ten zeerste aan vertrouwd te raken met deze principes om meer inzicht te krijgen in de impact ervan en de compromissen die gepaard gaan met niet-naleving.

Belangrijk

Dit artikel maakt deel uit van de reeks bedrijfskritieke azure Well-Architected workloads . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat een bedrijfskritieke workload is?

Deze essentiële ontwerpprincipes resoneren en breiden de kwaliteitspijlers van het Azure Well-Architected Framework uit: betrouwbaarheid, beveiliging, kostenoptimalisatie, operationele uitmuntendheid en prestatie-efficiëntie.

Betrouwbaarheid

Maximale betrouwbaarheid : fundamenteel streven naar de meest betrouwbare oplossing om ervoor te zorgen dat de afwegingen goed worden begrepen.

Ontwerpprincipe	Overwegingen
Actief/actief-ontwerp	Om de beschikbaarheid te maximaliseren en regionale fouttolerantie te bereiken, moeten oplossingsonderdelen waar mogelijk worden gedistribueerd over meerdere Beschikbaarheidszones en Azure-regio's met behulp van een actief/actief implementatiemodel.
Straalreductie en foutisolatie	Fouten kunnen niet worden vermeden in een zeer gedistribueerde multitenant-cloudomgeving, zoals Azure. Door te anticiperen op fouten en gecorreleerde impact, van afzonderlijke onderdelen tot volledige Azure-regio's, kan een oplossing op een tolerante manier worden ontworpen en ontwikkeld.
Toepassingsstatus observeren	Voordat problemen die van invloed zijn op de betrouwbaarheid van toepassingen kunnen worden beperkt, moeten ze eerst worden gedetecteerd en begrepen. Door de werking van een toepassing ten opzichte van een bekende gezonde status te bewaken, wordt het mogelijk om betrouwbaarheidsproblemen te detecteren of zelfs te voorspellen, zodat snel herstelacties kunnen worden ondernomen.
Automatisering aandrijven	Een van de belangrijkste oorzaken van downtime van toepassingen is een menselijke fout, ongeacht of dit wordt veroorzaakt door de implementatie van onvoldoende geteste software of onjuiste configuratie. Om de kans op en de impact van menselijke fouten te minimaliseren, is het essentieel om te streven naar automatisering in alle aspecten van een cloudoplossing om de betrouwbaarheid te verbeteren; geautomatiseerd testen, implementeren en beheren.
Integreer zelfherstel in het ontwerp	Zelfherstel beschrijft het vermogen van een systeem om fouten automatisch af te handelen via vooraf gedefinieerde herstelprotocollen die zijn verbonden met foutmodi in de oplossing. Het is een geavanceerd concept dat een hoog niveau van systeemrijpheid vereist met bewaking en automatisering, maar vanaf het begin een streven moet zijn om de betrouwbaarheid te maximaliseren.
Vermijden van complexiteit	Vermijd onnodige complexiteit bij het ontwerpen van de oplossing en alle operationele processen om betrouwbaarheid en beheerefficiëntie te stimuleren, waardoor de kans op fouten wordt geminimaliseerd.

Prestatie-efficiëntie

Duurzame prestaties en schaalbaarheid : ontwerp voor schaalbaarheid in de end-to-end-oplossing zonder prestatieknelpunten.

Ontwerpprincipe	Overwegingen
Ontwerpen voor uitschalen	Scale-out is een concept dat zich richt op het vermogen van een systeem om te reageren op de vraag door middel van horizontale groei. Dit betekent dat naarmate het verkeer groeit, er parallel meer resource-eenheden worden toegevoegd in plaats van de bestaande resources groter te maken. De mogelijkheid van systemen om verwachte en onverwachte verkeerstoenames via schaaleenheden af te handelen, is essentieel voor de algehele prestaties en betrouwbaarheid door de impact van één resourcefout verder te verminderen.
Automatisering voor hyperscale	Schaalbewerkingen in de hele oplossing moeten volledig geautomatiseerd zijn om de impact op prestaties en beschikbaarheid van onverwachte of verwachte toename van verkeer te minimaliseren, zodat de tijd die nodig is om schaalbewerkingen uit te voeren, wordt begrepen en afgestemd op een model voor toepassingsstatus.
Continue validatie en testen	Geautomatiseerde tests moeten worden uitgevoerd binnen CI/CD-processen om continue validatie voor elke toepassingswijziging te stimuleren. Belastingstests op basis van een prestatiebasislijn met gesynchroniseerde chaos-experimenten moeten worden opgenomen om bestaande drempelwaarden, doelen en veronderstellingen te valideren, en om snel risico's voor tolerantie en beschikbaarheid te identificeren. Dergelijke tests moeten worden uitgevoerd in faserings- en testomgevingen, maar ook optioneel binnen ontwikkelomgevingen. Het kan ook nuttig zijn om een subset van tests uit te voeren op basis van de productieomgeving, met name in combinatie met een blauw/groen-implementatiemodel om nieuwe implementatiestempels te valideren voordat u productieverkeer ontvangt.
Overhead verminderen met beheerde rekenservices	Het gebruik van beheerde rekenservices en in containers geplaatste architecturen vermindert de doorlopende administratieve en operationele overhead van het ontwerpen, uitvoeren en schalen van toepassingen aanzienlijk door de implementatie en het onderhoud van de infrastructuur te verplaatsen naar de beheerde serviceprovider.
Basislijnprestaties en knelpunten identificeren	Met prestatietests met gedetailleerde telemetrie van elk systeemonderdeel kunnen knelpunten in het systeem worden geïdentificeerd, inclusief onderdelen die moeten worden geschaald ten opzichte van andere onderdelen. Deze informatie moet worden opgenomen in een capaciteitsmodel.
Modelcapaciteit	Met een capaciteitsmodel kunt u schaalniveaus voor resources voor een bepaald belastingsprofiel plannen en wordt bovendien weergegeven hoe systeemonderdelen ten opzichte van elkaar presteren, waardoor capaciteitstoewijzingsplanning voor het hele systeem mogelijk is.

Operationele topprestaties

Bewerkingen per ontwerp : ontworpen om duurzaam te blijven met robuust en assertief operationeel beheer.

Ontwerpprincipe	Overwegingen
Losjes gekoppelde onderdelen	Losse koppeling maakt onafhankelijke en on-demand testen, implementaties en updates van onderdelen van de toepassing mogelijk, terwijl afhankelijkheden tussen teams voor ondersteuning, services, resources of goedkeuringen worden geminimaliseerd.
Build- en releaseprocessen automatiseren	Volledig geautomatiseerde build- en releaseprocessen verminderen de wrijving en verhogen de snelheid van het implementeren van updates, waardoor herhaalbaarheid en consistentie in omgevingen mogelijk worden. Automatisering verkort de feedbacklus van ontwikkelaars die wijzigingen pushen om inzicht te krijgen in codekwaliteit, testdekking, tolerantie, beveiliging en prestaties, waardoor de productiviteit van ontwikkelaars toeneemt.
Flexibiliteit van ontwikkelaars	Automatisering van continue integratie en continue implementatie (CI/CD) maakt het gebruik van kortdurende ontwikkelomgevingen mogelijk met levenscyclussen die zijn gekoppeld aan die van een bijbehorende functievertakking, waardoor de flexibiliteit van ontwikkelaars wordt bevorderd en validatie zo vroeg mogelijk binnen de engineeringcyclus wordt aangestuurd om de technische kosten van bugs te minimaliseren.
Operationele status kwantificeren	Volledige diagnostische instrumentatie van alle onderdelen en resources maakt doorlopende waarneembaarheid van logboeken, metrische gegevens en traceringen mogelijk, maar maakt ook het maken van statusmodellen mogelijk om de toepassingsstatus te kwantificeren in de context van beschikbaarheids- en prestatievereisten.
Oefenherstel en oefenfout	Plannings- en oefenoefeningen voor bedrijfscontinuïteit (BC) en Noodherstel (DR) zijn essentieel en moeten regelmatig worden uitgevoerd, omdat leerstof plannen en procedures iteratief kan verbeteren om de tolerantie te maximaliseren in het geval van niet-geplande downtime.
Continue operationele verbetering omarmen	Geef prioriteit aan routinematige verbetering van het systeem en de gebruikerservaring, waarbij een statusmodel wordt gebruikt om de operationele efficiëntie te begrijpen en te meten met feedbackmechanismen, zodat toepassingsteams hiaten op een iteratieve manier kunnen begrijpen en aanpakken.

Beveiliging

Altijd veilig : ontwerp voor end-to-end-beveiliging om de stabiliteit van toepassingen te behouden en beschikbaarheid te garanderen.

Ontwerpprincipe	Overwegingen
De beveiliging van de hele oplossing bewaken en reacties op incidenten plannen	Correleer beveiligings- en controlegebeurtenissen om de toepassingsstatus te modelleren en actieve bedreigingen te identificeren. Stel geautomatiseerde en handmatige procedures in om te reageren op incidenten met behulp van SIEM-hulpprogramma's (Security Information and Event Management) voor tracering.
Modelleren en testen op potentiële bedreigingen	Zorg voor de juiste resourcebeveiliging en stel procedures in om bekende bedreigingen te identificeren en te beperken, met behulp van penetratietests om bedreigingsbeperking te controleren, evenals statische codeanalyse en codescans.
Eindpunten identificeren en beveiligen	Bewaak en beveilig de netwerkintegriteit van interne en externe eindpunten via beveiligingsmogelijkheden en -apparaten, zoals firewalls of webtoepassingsfirewalls. Gebruik industriestandaardmethoden om te beschermen tegen veelvoorkomende aanvalsvectoren, zoals DDoS-aanvallen (Distributed Denial-Of-Service), zoals SlowLoris.
Bescherming tegen beveiligingsproblemen op codeniveau	Identificeer en verminder beveiligingsproblemen op codeniveau, zoals cross-site scripting of SQL-injectie, en neem beveiligingspatches op in operationele levenscyclussen voor alle onderdelen van de codebasis, inclusief afhankelijkheden.
Minimale bevoegdheden automatiseren en gebruiken	Stuur automatisering aan om de noodzaak van menselijke interactie te minimaliseren en implementeer minimale bevoegdheden in zowel het toepassings- als besturingsvlak om te beschermen tegen gegevensexfiltratie en scenario's met schadelijke actors.
Gegevens classificeren en versleutelen	Classificeer gegevens op basis van risico's en pas industriestandaard versleuteling at rest en in transit toe, zodat sleutels en certificaten veilig worden opgeslagen en goed worden beheerd.

Kostenoptimalisatie

Er zijn duidelijke kostennadelen verbonden aan het introduceren van een grotere betrouwbaarheid, die zorgvuldig moeten worden overwogen in de context van workloadvereisten.

Het maximaliseren van de betrouwbaarheid kan van invloed zijn op de totale financiële kosten van de oplossing. Het dupliceren van resources en de verdeling van resources over regio's om hoge beschikbaarheid te bereiken, hebben bijvoorbeeld duidelijke gevolgen voor de kosten. Om overtollige kosten te voorkomen, moet u niet te veel engineeren of te veel inrichten buiten de relevante bedrijfsvereisten.

Er zijn ook extra kosten verbonden aan technische investeringen in fundamentele betrouwbaarheidsconcepten, zoals het omarmen van infrastructuur als code, implementatieautomatisering en chaos-engineering. Dit brengt kosten met zich mee in termen van tijd en inspanning, die elders kunnen worden geïnvesteerd om nieuwe toepassingsfunctionaliteit en -functies te leveren.

Cloudeigen ontwerp

• Systeemeigen beheerde services van Azure : systeemeigen beheerde services van Azure krijgen prioriteit vanwege de lagere administratieve en operationele overhead en de nauwe integratie met consistente configuratie en instrumentatie in de toepassingsstack.

• Routekaartuitlijning : neem toekomstige nieuwe en verbeterde Azure-servicemogelijkheden op zodra deze algemeen beschikbaar worden (GA) om dicht bij de voorsprong van Azure te blijven.

• Preview-mogelijkheden omarmen en bekende hiaten verhelpen : hoewel algemeen beschikbare (GA)-services prioriteit krijgen voor ondersteuning, worden Azure-servicevoorbeelden actief verkend voor snelle integratie, waardoor technische en bruikbare feedback wordt gegeven aan Azure-productgroepen om hiaten op te lossen.

• Uitlijning azure-landingszone : implementeerbaar binnen een Azure-landingszone en afgestemd op de ontwerpmethodologie voor Azure-landingszones, maar ook volledig functioneel en implementeerbaar in een lege omgeving buiten een landingszone.

Volgende stap

Bekijk horizontale problemen met betrekking tot bedrijfskritieke workloads.

Algemene problemen