Compromissen tussen operationele uitmuntendheid

  • Artikel

Operational Excellence biedt workloadkwaliteit door de implementatie van duidelijke teamstandaarden, begrepen verantwoordelijkheid en verantwoordelijkheid, aandacht voor klantresultaten en teamcohesie. De implementatie van deze doelen is gebaseerd op DevOps, wat aanbeveelt om procesvariantie te minimaliseren, menselijke fouten te verminderen en uiteindelijk het rendement van waarde voor de workload te verhogen. Deze waarde wordt niet alleen gemeten aan de functionele vereisten van de onderdelen van de workload. Het wordt ook gemeten aan de waarde die het team levert bij het streven naar verbetering.

Tijdens de ontwerpfase van een workload en tijdens de levenscyclus ervan, is het belangrijk om te overwegen hoe beslissingen op basis van de ontwerpprincipes voor operationele uitmuntendheid en de aanbevelingen in de controlelijst voor ontwerpbeoordeling voor operationele uitmuntendheid van invloed kunnen zijn op de doelstellingen en optimalisaties van andere pijlers. Bepaalde beslissingen kunnen sommige pijlers ten goede komen, maar vormen compromissen voor andere. In dit artikel worden voorbeelden van afwegingen beschreven die een workloadteam kan tegenkomen bij het ontwerpen van workloadarchitectuur en -bewerkingen.

Operational Excellence-compromissen met betrouwbaarheid

Tradeoff: Verhoogde complexiteit. Betrouwbaarheid geeft prioriteit aan eenvoud, omdat een eenvoudig ontwerp onjuiste configuratie minimaliseert en onverwachte interacties vermindert.

  • Veilige implementatiestrategieën vereisen vaak enige 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.

  • Zeer gelaagde, modulaire of geparametriseerde infrastructuur als code kan de kans op onbedoelde onjuiste configuratie vergroten vanwege de complexiteit van de interactie tussen de codeonderdelen.

  • Cloudontwerppatronen die ten goede komen aan bewerkingen, vereisen soms de introductie van extra onderdelen, bijvoorbeeld het gebruik van een extern configuratiearchief of de coördinatie van sidecar-implementaties in een containertoepassingsplatform. De extra onderdelen vergroten de interactiepunten in het systeem, waardoor de oppervlakte voor storingen of onjuiste configuraties toeneemt.

  • Workloadonderdelen die zijn ontworpen om onafhankelijk te ontwikkelen ter ondersteuning van flexibele ontwikkeling en hosting, introduceren afhankelijkheden van servicedetectie of zelfs DNS als een laag van indirectie. Servicedetectie reageert mogelijk niet snel op wijzigingen en een storing kan moeilijk te diagnosticeren zijn.

Tradeoff: Toegenomen potentieel destabiliserende activiteiten. De pijler Betrouwbaarheid stimuleert het vermijden van activiteiten of ontwerpkeuzen die een systeem kunnen stabiliseren en kunnen leiden tot onderbrekingen, storingen of storingen.

  • Het implementeren van kleine, incrementele wijzigingen is een techniek om risico's te beperken, maar deze kleine wijzigingen worden naar verwachting ook vaker aan productie geleverd. Implementaties kunnen een systeem destabiliseren, dus als de implementatiesnelheid toeneemt, neemt dit risico ook toe.

  • Een cultuur die zichzelf meet met metrische snelheidsgegevens, zoals implementaties per week, en automatisering gebruikt die het introduceren van wijzigingen in een sneller tempo mogelijk maakt, zal waarschijnlijk ook meer implementaties in een kortere periode uitvoeren.

  • Het verhogen van de dichtheid om bewerkingen te vereenvoudigen door het aantal controle- en waarneembaarheidsoppervlakken te verminderen, kan ook leiden tot een verhoogd beschikbaarheidsrisico omdat storingen of onjuiste configuratie de impactradius van een stabiliserende gebeurtenis vergroten.

Operationele uitmuntendheid compromissen met beveiliging

Tradeoff: Toegenomen oppervlakte. De pijler Beveiliging beveelt een kleiner werklastoppervlak aan wat betreft onderdelen en blootstelling aan bewerkingen. Deze vermindering minimaliseert aanvalsvectoren en produceert een kleiner bereik voor beveiligingsbeheer en testen.

  • Onderdelen die de workload omringen en de bewerkingen ondersteunen, zoals automatisering of een aangepast besturingsvlak, moeten ook binnen het bereik vallen voor regelmatige beveiligingsbeveiliging en -tests.

  • Routine-, ad-hoc- en noodbewerkingen verhogen de contactpunten met de workload. Een zero trust-benadering vereist dat deze processen worden beschouwd als aanvalsvectoren en moeten worden opgenomen in de beveiligingscontroles en validatie voor de workload.

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

  • Buildagents, externe configuratie en functiewisselarchieven, en implementatiemethoden naast elkaar vergroten de toepassingsoppervlak waarvoor beveiliging is vereist.

  • Een hogere implementatiefrequentie die wordt veroorzaakt door kleine, incrementele wijzigingen of door 'get current, stay current' inspanningen, resulteert in meer beveiligingstests in de levenscyclus van softwareontwikkeling.

Compromis: Toegenomen verlangen naar transparantie. Een beveiligde workload is gebaseerd op ontwerpen die de vertrouwelijkheid beschermen van gegevens die door de onderdelen van het systeem stromen.

Waarneembaarheidsplatforms nemen gegevens van alle typen op om inzicht te krijgen in de status en het gedrag van een workload. Naarmate teams een hogere betrouwbaarheid van waarneembaarheidsgegevens proberen te bereiken, bestaat er een verhoogd risico dat besturingselementen voor gegevensclassificatie, zoals gegevensmaskering, van de bronsystemen niet worden uitgebreid naar de logboeken en logboeksinks van het waarneembaarheidsplatform.

Tradeoff: verminderde segmentatie. Een belangrijke beveiligingsbenadering voor het isoleren van toegang en functie is het ontwerpen van een sterke segmentatiestrategie. Dit ontwerp wordt geïmplementeerd via resource-isolatie en identiteitsbeheer.

  • Door verschillende toepassingsonderdelen te plaatsen in gedeelde reken-, netwerk- en gegevensresources om het beheer eenvoudiger te maken, wordt segmentatie omgedraaid of wordt segmentatie op basis van rollen moeilijker te realiseren. Co-locatieonderdelen moeten mogelijk ook een workloadidentiteit delen, wat kan leiden tot overtoewijzing van machtigingen of een gebrek aan traceerbaarheid.

  • Het verzamelen van alle logboeken in het hele systeem in een geïntegreerde logboeksink kan het uitvoeren van query's en het maken van waarschuwingen vereenvoudigen. Dit kan het echter ook moeilijker of onmogelijk maken om beveiliging op basis van rijen te bieden om gevoelige gegevens te behandelen met de vereiste controlecontroles.

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

Compromissen tussen operationele uitmuntendheid en kostenoptimalisatie

De pijler Operational Excellence beveelt nooit activiteiten aan die de productiviteit verlagen of het rendement van een workload in gevaar brengen. Aanbevelingen die de focus lijken te verschuiven van leveringsactiviteiten, houden rekening met de belangen op lange termijn voor de workload en het team. Als de einddatum van uw workload nadert, is het waarschijnlijk niet zinvol om veel te investeren in aanbevelingen die deze compromissen activeren.

Afweging: verhoogde resource-uitgaven. Een belangrijke kostenoorzaken voor een workload zijn de kosten van de resources. Door minder resources te implementeren, de juiste grootte van resources te bepalen en het verbruik te verminderen, blijven de kosten over het algemeen laag.

  • Het implementeren van veilige implementatieprocedures, zelfs als de wijzigingen relatief klein zijn, kan leiden tot een toename van het aantal resources dat gelijktijdig wordt geïmplementeerd. Deze patronen vereisen de implementatie van meerdere gelijktijdige exemplaren van het toepassings- of infrastructuuronderdeel, zodat verkeer op een gecontroleerde manier kan worden verplaatst. Deze toename komt meer tot uiting in een workload die gebruikmaakt van een onveranderbare infrastructuurbenadering.

  • Het team moet mogelijk extra workloadonderdelen introduceren om operationeel afgestemde cloudontwerppatronen of workloadautomatisering te implementeren. Ter ondersteuning van implementatieflexibiliteit kunnen ze bijvoorbeeld een gatewayrouteringsonderdeel toevoegen. Ter ondersteuning van beter configuratiebeheer kunnen ze een extern configuratiearchief toevoegen. Ter ondersteuning van levenscyclus gebeurtenissen van tenants kunnen ze een besturingsvlak bouwen. Deze resources zijn ook van invloed op de kosten van preproductieomgevingen.

  • Door het aantal preproductieomgevingen te verhogen om de ontwikkel- en testervaring via isolatie te verbeteren, neemt ook het aantal resources toe. Deze resources, die niet worden gebruikt voor het leveren van aanbod ten opzichte van de productievraag, verhogen de kosten van de oplossing.

  • Het verhogen van de pariteit van preproductieomgevingen met de productieomgeving, wat betreft het aantal resources, SKU's en gegevensvolumes, verbetert het proces voor kwaliteitsbewaking. De kosten nemen toe naarmate de pariteit toeneemt.

  • Hoewel telemetriegegevens niet direct een resource zijn, moeten deze gegevens behouden blijven om de effectiviteit van waarneembaarheidsplatformen mogelijk te maken. De meeste operationele gegevensarchieven hebben prijzen die zijn gebaseerd op een combinatie van opnamesnelheden en volume. Over het algemeen nemen de kosten ook toe naarmate de hoeveelheid telemetrie met lage latentie en hoge diversiteit toeneemt. Voor implementaties in meerdere regio's worden deze operationele gegevenssinks naar verwachting per regio geïmplementeerd, zodat eventuele kosten per resource een factor worden.

Tradeoff: Verminderde focus op leveringsactiviteiten. Leden van het workloadteam leveren een hogere workloadwaarde door taken efficiënt uit te voeren die zijn afgestemd op hun mogelijkheden.

  • Workloadteams die tijd besteden aan het maken en verfijnen van een gezonde en verantwoordelijke ondersteuningsstructuur en incidentrespons bieden een waardevolle service aan de gebruikers van de workload. Naarmate de ondersteuningsinspanning toeneemt (bijvoorbeeld formele rotaties op oproep), meestal vanwege een wijziging in bedrijfskritiek, nemen de kosten van deze activiteiten toe. Deze kostenstijging kan het gevolg zijn van een toename van het personeel of indirect in de vorm van aandacht die wordt verschoven van leveringsactiviteiten naar ondersteunende functies.

  • Training is een essentieel onderdeel van het persoonlijke continue verbeteringsproces van een workloadteam. Deze training kan formeel of zelfgestuurd zijn tijdens persoonlijke verrijkingstijd. Naarmate de hoeveelheid trainingstijd toeneemt, neemt de hoeveelheid tijd die beschikbaar is voor directe ontwikkeling van de workload af. De investering in training neemt af wanneer de training niet op rollen is gebaseerd of niet specifiek relevant is voor de workload of de toekomst ervan.

  • Gestandaardiseerde routine operationele taken voor het beschermen van de betrouwbaarheid, beveiliging en prestatie-efficiëntie van een workload kost tijd om te definiëren, te verfijnen en uit te voeren. Deze tijd wordt niet direct besteed aan bezorging. Enkele voorbeelden van deze taken zijn uitgebreide wijzigingseffectanalyse, wijzigingsbeheerprocessen, grondig testen en verbeterd patchbeheer. Naarmate de frequentie, uitgebreidheid of operationele belasting van deze taken toeneemt, neemt ook de geïnvesteerde tijd toe.

Tradeoff: Verhoogde eisen aan tooling en diversiteit. De pijler Kostenoptimalisatie beveelt het verminderen van de wildgroei van hulpprogramma's, consolidatie van leveranciers en een benadering van de juiste grootte voor alle tooling-aankopen aan.

Een workloadteam koopt hulpprogramma's en hardware ter ondersteuning van activiteiten die worden uitgevoerd tijdens de volledige softwareontwikkelingslevenscyclus (SDLC), inclusief planning en ontwerp, ontwikkeling en testen en bewaking. De marketplace voor hulpprogramma's in deze ruimte groeit. Hulpprogramma's worden aangeboden tegen verschillende prijspunten die meestal overeenkomen met de functies en mogelijkheden van de tools. Met uitzondering van gratis aanbiedingen, worden voor deze hulpprogramma's initiële licentiekosten in rekening gebracht, die per seat of locatiebreed kunnen zijn. Ze vereisen vaak ook doorlopende onderhoudscontracten. Mogelijk moeten er nieuwe leveranciersrelaties tot stand worden gebracht. Hier volgen enkele voorbeelden van verwachte hulpprogramma's of hardware-uitgaven die zijn gekoppeld aan de principes van operationele uitmuntendheid:

  • Vereisten en achterstandsbeheer
  • Ontwerphulpprogramma's voor architectuur
  • Hulpprogramma's voor ui-/UX-ontwerp
  • Hosting van code en assets
  • Ontwikkelomgevingen met code en weinig code
  • Automatiseringsprogramma's
  • Werkstations voor ontwikkeling en kwaliteitscontrole
  • Ontwikkelings- en implementatiepijplijnen
  • Uitvoering en tracering van tests
  • Hulpprogramma's voor waarneembaarheid

Operationele uitmuntendheid compromissen met prestatie-efficiëntie

Afweging: verhoogd resourcegebruik. In de pijler Prestatie-efficiëntie wordt aanbevolen om zoveel mogelijk van de beschikbare rekenkracht en het netwerk toe te passen aan de vereisten van de workload.

  • Het waarneembaarheidsframework van een workload vereist dat de onderdelen in de architectuur tijd en resources toewijzen voor het maken, verzamelen en streamen van logboeken en metrische gegevens. Deze gegevenspunten zorgen ervoor dat effectieve waarschuwingen en bewaking mogelijk zijn voor betrouwbaarheid, beveiliging en prestaties. Naarmate het instrumentatieniveau toeneemt, kan de belasting van systeembronnen ook toenemen.

  • Sommige implementatiemodellen, zoals blauw/groen, die een workload kan gebruiken voor een veilige implementatie, kunnen implementaties naast elkaar introduceren op het productietoepassingsplatform. Deze implementaties vereisen preventieve schaalaanpassing om voldoende aanbod te bieden om te voldoen aan de toekomstige vraag, of een meestal inactieve implementatie gedurende een bepaalde periode behouden om terugdraaiactie te ondersteunen.

Afweging: verhoogde latentie. Om goed presterende workloads te maken, zoeken teams naar manieren om de tijd en resources te verkorten die workloads verbruiken om hun taken uit te voeren.

  • Veel implementatiemodellen vereisen het gebruik van toegangspatronen voor gatewayroutering, wat latentie kan veroorzaken. Deze latentie wordt vergeleken met het prestatiedoelbudget voor de gerelateerde stromen.

  • Sommige cloudontwerppatronen die 'onafhankelijke verandering in de loop van de tijd' ondersteunen ter ondersteuning van de idealen van incrementele verbetering, kunnen latentie veroorzaken vanwege het doorkruisen van extra onderdelen. Deze latentie kan worden geïntroduceerd door gateways, berichtenbrokers of anti-corruptielagen.

Verken de compromissen voor de andere pijlers: