Delen via


Operationele excellentie-afwegingen voor Power Platform werklasten

Operationele Excellentie ondersteunt de kwaliteit van de werklast door de implementatie van duidelijke teamnormen, begrepen verantwoordelijkheid en aansprakelijkheid, aandacht voor klantresultaten en teamcohesie. De implementatie van deze doelen is geworteld in DevOps. Aanbevolen wordt om procesvariantie te minimaliseren, menselijke fouten te verminderen en uiteindelijk het rendement op de workload te vergroten. Die waarde wordt niet alleen gemeten aan de functionele vereisten waaraan de onderdelen van de werklast voldoen. Het wordt ook gemeten aan de hand van de waarde die het team levert in het streven naar verbetering.

Tijdens de ontwerpfase van een workload en gedurende de levenscyclus ervan, naarmate er voortdurend verbeteringsstappen worden genomen, is het belangrijk om te overwegen hoe beslissingen op basis van de ontwerpprincipes van Operational Excellence en de aanbevelingen in de checklist voor ontwerpbeoordeling voor Operational Excellence de doelen en optimalisaties van andere pijlers kunnen beïnvloeden. Bepaalde beslissingen kunnen sommige pijlers ten goede komen, maar vormen voor andere afwegingen. In dit artikel worden voorbeelden van afwegingen beschreven waarmee een workloadteam te maken kan krijgen bij het ontwerpen van workloadarchitectuur en -bewerkingen.

Afwegingen ten aanzien van operationele uitmuntendheid met betrekking tot betrouwbaarheid

Nadeel: verhoogde complexiteit. Betrouwbaarheid geeft prioriteit aan eenvoud, omdat een eenvoudig ontwerp onjuiste configuraties minimaliseert en onverwachte interacties vermindert.

  • Veilige implementatiestrategieën vereisen vaak een zekere mate van voorwaartse en achterwaartse compatibiliteit tussen toepassingslogica en gegevens in de workload. Deze extra complexiteit verhoogt de testlast en kan leiden tot complexiteit of integriteitsproblemen met de gegevens van de workload.

  • Sterk gelaagde, gemodulariseerde of geparametriseerde structuren kunnen de kans op onbedoelde verkeerde configuratie vergroten vanwege de complexiteit van de interactie tussen de onderdelen van de workload.

  • Cloudontwerppatronen die de bedrijfsvoering ten goede komen, vereisen soms de introductie van meer componenten, bijvoorbeeld het gebruik van geheime opslag of het nemen van een afhankelijkheid van Application Insights. De extra componenten vergroten het aantal interactiepunten in het systeem, waardoor de kans op storingen of verkeerde configuraties toeneemt.

Afweging: Toename van potentieel destabiliserende activiteiten. De betrouwbaarheidspijler stimuleert het vermijden van activiteiten of ontwerpkeuzen die een systeem kunnen destabiliseren en tot verstoringen, uitval of storingen kunnen leiden.

  • Het doorvoeren van kleine, stapsgewijze wijzigingen is een techniek om risico's te beperken, maar gebruikers verwachten dat die kleine wijzigingen vaker in de productieomgeving worden doorgevoerd. Implementaties kunnen een systeem destabiliseren, dus naarmate de implementatiesnelheid toeneemt, neemt dit risico ook toe.

  • Een cultuur die zichzelf de maat neemt met snelheidsstatistieken zoals implementaties per week en gebruikmaakt van automatisering waarmee veranderingen eenvoudiger in een sneller tempo kunnen worden geïntroduceerd, voert waarschijnlijk ook meer implementaties in een kortere periode uit.

  • Het verhogen van de dichtheid om de werkzaamheden te vereenvoudigen door het aantal controle- en observatiepunten te verminderen, kan ook leiden tot een groter beschikbaarheidsrisico, omdat storingen of verkeerde configuraties het effect van een destabiliserende gebeurtenis versterken.

Afwegingen ten aanzien van operationele uitmuntendheid met betrekking tot beveiliging

Afweging: groter oppervlak. De beveiligingspijler raadt een kleiner workloadoppervlak aan in termen van onderdelen en blootstelling aan bewerkingen. Door deze vermindering worden kwetsbaarheden geminimaliseerd en is er minder ruimte voor beveiligingscontrole en -testen.

  • Onderdelen die de workload omringen en de activiteiten ervan ondersteunen, zoals automatisering of een aangepast besturingsvlak, moeten ook regelmatig worden verscherpt en getest.

  • Routinematige, ongeplande en noodgevallen vergroten het aantal contactmomenten met de werklast. Bij een zero trust-aanpak moeten deze processen als kwetsbaarheden worden beschouwd en moeten ze worden opgenomen in de beveiligingsmaatregelen en validatie voor de werklast.

  • Het waarneembaarheidsplatform van het systeem verzamelt logboeken en metrische gegevens over de workload, wat een openbaarmaking van waardevolle informatiebronnen kan zijn. Daarom moet de beveiliging van de workload worden uitgebreid om data-sinks te beschermen tegen interne en externe bedreigingen.

  • Het bouwen van agents, externe configuratie en opslagplaatsen voor functieschakelopties vergroten allemaal het toepassingsoppervlak dat beveiliging vereist.

  • Een hogere implementatiefrequentie als gevolg van kleine, incrementele wijzigingen of door inspanningen om up-to-date te blijven, resulteert in meer beveiligingstests in de softwareontwikkelingscyclus (SDLC).

Afweging: Grotere behoefte aan transparantie. Een veilige workload is gebaseerd op ontwerpen die de vertrouwelijkheid beschermen van gegevens die door de onderdelen van het systeem stromen.

Waarneembaarheidsplatforms nemen allerlei soorten gegevens op om inzicht te krijgen in de status en het gedrag van een workload. Terwijl teams proberen een hogere betrouwbaarheid van de waarneembaarheidsgegevens te bereiken, bestaat er een groter risico dat de controles op gegevensclassificatie, zoals gegevensmaskering, van de bronsystemen zich niet uitstrekken tot de logboeken en log-sinks van het waarneembaarheidsplatform.

Nadeel: verminderde segmentatie. Een belangrijke beveiligingsaanpak voor het isoleren van toegang en functionaliteit is het ontwerpen van een sterke segmentatiestrategie. Dit ontwerp wordt geïmplementeerd via resource-isolatie en identiteitscontroles.

  • Door afzonderlijke toepassingsonderdelen in gedeelde omgevingen en gegevensbronnen samen te plaatsen om het beheer eenvoudiger te maken, wordt de segmentatie ongedaan gemaakt of wordt op rollen gebaseerde segmentatie moeilijker te realiseren. Onderdelen die zich op dezelfde locatie bevinden, moeten mogelijk ook een workloadidentiteit delen, wat kan leiden tot overmatige toewijzing van machtigingen of een gebrek aan traceerbaarheid.

  • Het verzamelen van alle logboeken uit het hele systeem in een uniforme log-sink kan het opvragen en opstellen van waarschuwingen eenvoudiger maken. Dit kan het echter ook lastiger of onmogelijk maken om rijgebaseerde beveiliging te bieden voor het behandelen van gevoelige gegevens met de vereiste auditcontroles.

  • Het vereenvoudigen van het beheer van op kenmerken of rollen gebaseerde beveiliging door de granulariteit van rollen en hun toewijzingen te verminderen, kan leiden tot ongepast brede machtigingen.

Afwegingen ten aanzien van operationele uitmuntendheid met betrekking tot ervaringsoptimalisatie

Afweging: Concurrerende prioriteiten. De pijler voor ervaringsoptimalisatie beveelt een gebruikersgerichte mentaliteit aan.

  • Ontwikkeling van gebruikerservaringen die veel middelen vereisen, kan minder prioriteit krijgen. Hierdoor kan de ervaring niet de bruikbaarheid, interacties en het visuele ontwerp hebben die gebruikers nodig hebben.

  • De ontwikkeling van gebruikersinterfaces verloopt vaak Gereed in snellere iteraties en verzendcycli, wat de SDLC-processen van het team kan belasten.

Operationele excellentie en prestatie-efficiëntie in evenwicht

Nadeel: Beter gebruik van hulpbronnen. De pijler Prestatie-efficiëntie adviseert om zoveel mogelijk van de beschikbare reken- en netwerkbronnen toe te wijzen aan de vereisten van de werklast.

  • Het monitoringframework van een workload vereist dat de componenten in de architectuur tijd en middelen vrijmaken om logboeken en statistieken te maken, verzamelen en streamen. Deze datapunten zorgen ervoor dat effectieve waarschuwingen en bewaking mogelijk zijn voor betrouwbaarheid, beveiliging en prestaties. Naarmate het niveau van instrumentatie toeneemt, kan ook de belasting van de systeembronnen toenemen.

Nadeel: verhoogde latentie. Om werklasten zo goed mogelijk te laten presteren, zoeken teams naar manieren om de tijd en middelen die werklasten verbruiken om hun taken uit te voeren, te beperken.

  • Sommige cloudontwerppatronen die 'onafhankelijke verandering in de loop van de tijd'-benaderingen ondersteunen ter ondersteuning van de idealen van incrementele verbetering, kunnen latentie veroorzaken vanwege het doorlopen van extra componenten.