Betrouwbaarheidsafwegingen voor Power Platform werklasten
Een betrouwbare workload voldoet consequent aan de bijbehorende gedefinieerde betrouwbaarheidsdoelstellingen. Er moeten vastgestelde tolerantiedoelen worden bereikt, idealiter door gebeurtenissen te omzeilen die de betrouwbaarheid beïnvloeden. Realistisch gezien moet een workload echter de impact van dergelijke gebeurtenissen tolereren en beheersen en de activiteiten op een vooraf bepaald niveau houden tijdens actieve storingen. Zelfs tijdens een ramp moet een betrouwbare workload zich binnen een bepaalde tijd in een bepaalde toestand herstellen, over welke zaken de belanghebbenden het eens zijn. Een incidentresponsplan waarmee u een snelle detectie en herstel kunt realiseren, is van cruciaal belang.
Tijdens de ontwerpfase van een workload moet u rekening houden met de manier waarop beslissingen op basis van de Ontwerpprincipes van betrouwbaarheid en de aanbevelingen in Beoordelingscontrolelijst voor betrouwbaarheid ontwerpen van invloed kan zijn op de doelen en optimalisaties van andere pijlers. Bepaalde beslissingen kunnen sommige pijlers ten goede komen, maar vormen voor andere een afweging. In dit artikel worden voorbeelden van afwegingen beschreven die een workloadteam kan tegenkomen bij het ontwerpen van workloadarchitectuur en -bewerkingen met het oog op betrouwbaarheid.
Betrouwbaarheidsafwegingen met betrekking tot beveiliging
Nadeel: groter werkoppervlak. De beveiligingspijler geeft prioriteit aan een verkleind en beperkt oppervlak om aanvalsvectoren te minimaliseren en het beheer van beveiligingscontroles te verminderen.
Betrouwbaarheid wordt vaak verkregen via replicatie. Replicatie kan plaatsvinden op onderdeelniveau, op gegevensniveau of zelfs op geografisch niveau. Replica's vergroten door hun ontwerp het oppervlak van een workload. Vanuit beveiligingsperspectief wordt de voorkeur gegeven aan een verkleind en beperkt oppervlak om potentiële aanvalsvectoren te minimaliseren en het beheer van beveiligingscontroles te stroomlijnen.
Op dezelfde manier vergroten oplossingen voor herstel, na noodgevallen zoals back-ups, het oppervlak van een workload. Ze zijn echter vaak geïsoleerd van de runtime van de workload. Dit vereist de implementatie van aanvullende beveiligingscontroles, die specifiek kunnen zijn voor de oplossing voor herstel na noodgevallen.
Omwille van de betrouwbaarheidsdoelstellingen zijn mogelijk extra onderdelen nodig voor de architectuur, waardoor het oppervlak groter wordt. Deze toegenomen complexiteit vergroot het oppervlak van de workload doordat nieuwe onderdelen worden toegevoegd die moeten worden beveiligd, mogelijk op manieren die nog niet in het systeem worden gebruikt. Deze onderdelen gaan doorgaans vergezeld van aanvullende code ter ondersteuning van het gebruik ervan of van algemene betrouwbaarheidspatronen, waardoor ook het oppervlak van de toepassing wordt vergroot.
Wanneer een workload een betrouwbaarheidsgebeurtenis ervaart die wordt aangepakt op basis van actieve incidentrespons, kan urgentie druk uitoefenen op workloadteams om beveiligingscontroles te omzeilen die zijn geoptimaliseerd voor routinematige toegang.
Probleemoplossingsactiviteiten kunnen ertoe leiden dat het team beveiligingsprotocollen tijdelijk uitschakelt, waardoor een reeds onder druk staand systeem mogelijk wordt blootgesteld aan extra beveiligingsrisico's. Er bestaat ook een risico dat de beveiligingsprotocollen niet onmiddellijk worden hersteld.
Gedetailleerde implementaties van beveiligingscontroles, zoals op rollen gebaseerde toegangscontroletoewijzingen of firewallregels, brengen configuratiecomplexiteit en gevoeligheid met zich mee, waardoor de kans op een verkeerde configuratie toeneemt. Door deze potentiële betrouwbaarheidsimpact te verzachten door het gebruik van brede regels, worden alle drie de Zero Trust-architectuurprincipes aangetast.
Het toepassen van releasewave-updates of updates van leveranciersbibliotheken, zoals onderdelen of oplossingen van derden, kan mogelijk het doelonderdeel verstoren, waardoor deze tijdens de wijziging niet beschikbaar is. Door patches uit te stellen of te vermijden kunnen de potentiële betrouwbaarheidsrisico's worden vermeden, maar wordt het systeem onbeschermd gelaten betreffende zich ontwikkelende bedreigingen.
De voorgaande overweging is ook van toepassing op de code van de workload. Het is bijvoorbeeld van toepassing op toepassingscode die gebruikmaakt van oude bibliotheken en onderdelen. Als het bijwerken en implementeren van toepassingscode wordt gezien als een absoluut betrouwbaarheidsrisico, wordt de toepassing in de loop van de tijd blootgesteld aan extra beveiligingsrisico's.
Betrouwbaarheidsafwegingen met betrekking tot operationele uitmuntendheid
Een belangrijk onderdeel van operationele uitmuntendheid is dat er wordt beschikt over een uitgebreide bewakingsstrategie. Als extra onderdelen in een architectuur worden geïntroduceerd om betrouwbaarheidsontwerppatronen te implementeren, resulteert dit in meer gegevensbronnen die moeten worden beheerd, waardoor de complexiteit van het implementeren van gedistribueerde tracering en waarneembaarheid toeneemt.
Het gebruik van meerdere regio's om de beperkingen van resourcecapaciteiten van één regio te overwinnen en/of een actieve architectuur te implementeren, vergroot de complexiteit van het operationele beheer van de workload. Deze complexiteit wordt veroorzaakt door de noodzaak om meerdere regio's te beheren en de noodzaak om de gegevensreplicatie daartussen te beheren.
Naarmate een workload robuuster wordt door de toevoeging van betrouwbaarheidsonderdelen en -patronen, kost het meer tijd om operationele procedures en artefactdocumentatie te onderhouden.
Trainen wordt complexer naarmate het aantal onderdelen in de workload toeneemt. Deze complexiteit heeft invloed op de tijd die nodig is voor onboarding en vergroot de kennis die nodig is om productroadmaps en begeleiding op serviceniveau bij te houden.
Betrouwbaarheidsafwegingen met betrekking tot ervaringsoptimalisatie
Het benadrukken van strenge tests kan de release van ervaringsfuncties vertragen die essentieel zijn voor acceptatie.
Het optimaliseren voor betrouwbaarheid kan een overbelasting veroorzaken bij het minimaliseren van de complexiteit, waardoor functies voor aantrekkelijkere gebruikerservaringen, zoals aangepaste onderdelen en integraties, minder prioriteit krijgen.
Betrouwbaarheidsafwegingen met prestatie-efficiëntie
Betrouwbaarheidspatronen maken vaak gebruik van gegevensreplicatie om storingen in de replica te overleven. Replicatie zorgt voor extra latentie bij betrouwbare gegevensschrijfbewerkingen, wat een deel van het prestatiebudget voor een specifieke gebruiker of gegevensstroom in beslag neemt.
Betrouwbaarheid maakt soms gebruik van verschillende vormen van resourcebalancering om de belasting te verdelen of herverdelen over gezonde replica's. Een speciaal onderdeel dat wordt gebruikt voor balancering, heeft doorgaans invloed op de prestaties van de aanvraag of het proces dat wordt gebalanceerd.
Het distribueren van componenten over geografische grenzen of beschikbaarheidszones heen om een beperkte impact te overleven, leidt tot netwerklatentie in de communicatie tussen componenten die deze beschikbaarheidsgrenzen overschrijden.
Er worden uitgebreide processen gebruikt om de status van een werklast te observeren. Hoewel monitoring van cruciaal belang is voor de betrouwbaarheid, kan instrumentatie de systeemprestaties beïnvloeden. Naarmate de zichtbaarheid toeneemt, kunnen de prestaties afnemen.
Automatische schaalvergroting vindt niet onmiddellijk plaats en kan daarom niet op betrouwbare wijze omgaan met een plotselinge en dramatische piek in de vraag die niet kan worden gevormd of afgevlakt. Daarom is overprovisioning via grotere instanties of meer instanties een cruciale betrouwbaarheidstactiek om rekening te houden met de vertraging tussen vraagsignalen en aanbodcreatie. Ongebruikte capaciteit staat haaks op de doelstellingen van prestatie-efficiëntie.
Soms kan een component niet worden geschaald als reactie op de vraag, en is die vraag niet volledig voorspelbaar. Het gebruik van grote instanties om het ergste geval te dekken, leidt tot verspilling van overprovisioning in situaties die buiten dat gebruiksscenario vallen.