Ontwerpprincipes en geavanceerde bewerkingen toepassen

Artikel
07/11/2023

In de eerste drie disciplines voor cloudbeheer wordt een basislijn voor beheer beschreven. Een beheerbasislijn moet minimaal een standaardbedrijfstoezegging bevatten om bedrijfsonderbrekingen te minimaliseren en het herstel te versnellen als de service wordt onderbroken. De meeste beheerbasislijnen hebben een gedisciplineerde focus op het onderhouden van inventaris en zichtbaarheid, operationele naleving en beveiliging en herstel.

Het doel van een basislijn voor beheer is het maken van een consistente aanbieding die een minimumniveau van zakelijke commitment biedt voor alle ondersteunde workloads. Deze basislijn van algemene, herhaalbare beheeraanbiedingen stelt het team in staat om een zeer geoptimaliseerde mate van operationeel beheer te leveren, met minimale afwijking. Maar dat standaardaanbod biedt mogelijk niet voldoende betrokkenheid bij het bedrijf.

In het diagram in de volgende sectie ziet u drie manieren om verder te gaan dan de basislijn voor beheer.

De beheerbasislijn moet voldoen aan de minimale toezegging die 80 procent van de laagste kritieke workloads in de portfolio vereist. De basislijn mag niet worden toegepast op bedrijfskritieke workloads. Het moet ook niet worden toegepast op algemene platforms die worden gedeeld tussen workloads. Deze workloads vereisen een focus op ontwerpprincipes en geavanceerde bewerkingen.

Opties voor geavanceerde bewerkingen

Er zijn drie voorgestelde paden voor het verbeteren van zakelijke toezeggingen buiten de basislijn voor beheer, zoals wordt weergegeven in het volgende diagram:

Geavanceerde bewerkingen

Verbeterde basislijn voor beheer

Zoals beschreven in de Azure-beheerhandleiding, maakt een verbeterde basislijn voor beheer gebruik van cloudeigen hulpprogramma's om de uptime te verbeteren en de hersteltijden te verkorten. De verbeteringen zijn aanzienlijk, maar minder dan bij specialisatie van workloads of platformen. Het voordeel van een verbeterde basislijn voor beheer is dat de kosten en implementatietijd net zo aanzienlijk zijn verminderd.

Specialisatie van beheer

Voor aspecten van workload- en platformbewerkingen zijn mogelijk wijzigingen in ontwerp- en architectuurprincipes vereist. Deze wijzigingen kunnen tijd in beslag nemen en kunnen leiden tot hogere bedrijfskosten. Om het aantal workloads te verminderen dat dergelijke investeringen vereist, kan een verbeterde basislijn voor beheer voldoende verbetering bieden voor de bedrijfscommitment.

Voor workloads die een hogere investering rechtvaardigen om te voldoen aan een zakelijke toezegging, is specialisatie van bewerkingen essentieel.

Specialisatiegebieden voor beheer

Er zijn twee specialisatiegebieden:

Platformspecialisatie: Investeer in doorlopende activiteiten van een gedeeld platform, waarbij de investering over meerdere workloads wordt verdeeld.
Specialisatie van workloads: Investeer in doorlopende bewerkingen van een specifieke workload, doorgaans gereserveerd voor bedrijfskritieke workloads.

Centraal IT-team of CCoE (Cloud Center of Excellence)

Beslissingen tussen platformspecialisatie en workloadspecialisatie zijn gebaseerd op de ernst en impact van elke workload. Deze beslissingen zijn echter ook indicatief voor grotere culturele beslissingen tussen het centrale IT-team en CCoE-organisatiemodellen.

Specialisatie van workloads veroorzaakt vaak een cultuurverandering. Traditionele IT en gecentraliseerde IT bouwen beide processen die ondersteuning op schaal kunnen bieden. Schaalondersteuning is beter haalbaar voor herhaalbare services die te vinden zijn in een beheerbasislijn, verbeterde basislijn of zelfs platformbewerkingen. Specialisatie van workloads wordt vaak niet geschaald. Dit gebrek aan schaal maakt het moeilijk voor een gecentraliseerde IT-organisatie om de benodigde ondersteuning te bieden zonder de schaalbeperkingen van de organisatie te bereiken.

Een benadering van het Cloud Center of Excellence kan ook worden geschaald door doelgerichte delegatie van verantwoordelijkheid en selectieve centralisatie. Specialisatie van workloads is meestal beter afgestemd op de gedelegeerde verantwoordelijkheidsbenadering van een CCoE.

De natuurlijke uitlijning van rollen in een CCoE wordt als volgt beschreven:

Het cloudplatformteam helpt bij het bouwen van algemene platforms die ondersteuning bieden voor meerdere teams voor cloudimplementatie.
Het cloudautomatiseringsteam breidt deze platforms uit naar implementeerbare assets in een servicecatalogus.
Cloudbeheer levert de basislijn voor beheer centraal en ondersteunt het gebruik van de servicecatalogus.
Maar de business unit (in de vorm van een devOps-team of cloudacceptatieteam) is verantwoordelijk voor de dagelijkse bewerkingen van de workload, pijplijn of prestaties.

Wat betreft het afstemmen van beheergebieden, kunnen centrale IT-team- en CCoE-modellen over het algemeen zorgen voor platformspecialisatie, met minimale culturele verandering. Het uitvoeren van specialisatie van workloads kan complexer zijn voor centrale IT-teams.

Specialisatieprocessen voor beheer

Binnen elke specialisatie wordt het volgende vierstappenproces geleverd in een gedisciplineerde, iteratieve benadering. Deze aanpak vereist samenwerking tussen experts op het gebied van cloudacceptatie, cloudplatform, cloudautomatisering en cloudbeheer om een levensvatbare en geïnformeerde feedbacklus te creëren.

Systeemontwerp verbeteren: Verbeter het ontwerp van algemene systemen (platforms) of specifieke workloads om onderbrekingen effectief te minimaliseren.
Herstel automatiseren: Sommige verbeteringen zijn niet rendabel. In dergelijke gevallen kan het zinvoler zijn om herstel te automatiseren en de impact van onderbrekingen te verminderen.
De oplossing schalen: Naarmate het systeemontwerp en geautomatiseerd herstel worden verbeterd, kunt u deze wijzigingen in de hele omgeving schalen via de servicecatalogus.
Continue verbetering: U kunt verschillende bewakingsprogramma's gebruiken om incrementele verbeteringen te ontdekken die in de volgende stap van systeemontwerp, automatisering en schaal worden aangepakt.

Systeemontwerp verbeteren

Het verbeteren van het systeemontwerp is de meest efficiënte benadering van functionele verbeteringen voor een veelgebruikt platform. Verbeteringen in het systeemontwerp kunnen helpen de stabiliteit te vergroten en bedrijfsonderbrekingen te verminderen. Het ontwerp van afzonderlijke systemen valt buiten het bereik van de omgevingsbenadering die voor het Cloud Adoption Framework is bepaald.

Als aanvulling op dit framework biedt het Microsoft Azure Well-Architected Framework richtlijnen om de kwaliteit van een platform of een specifieke workload te verbeteren. Het framework richt zich op verbetering in vijf pijlers op het gebied van architectuur:

Kostenoptimalisatie: Kosten beheren om de geleverde waarde te maximaliseren.
Operationele topprestaties: Operationele processen volgen die ervoor zorgen dat een systeem blijft werken.
Prestatie-efficiëntie: Systemen schalen om deze aan te passen op wijzigingen in de belasting.
Betrouwbaarheid: Systemen ontwerpen om te herstellen van fouten en te kunnen blijven functioneren.
Beveiliging: Toepassingen en gegevens beveiligen tegen bedreigingen.

De meeste bedrijfsonderbrekingen zijn gekoppeld aan een vorm van technische schuld of tekortkoming in de architectuur. Voor bestaande implementaties kunnen verbeteringen in het systeemontwerp worden gezien als aflossingen van bestaande technische schulden. Voor bestaande implementaties kunnen verbeteringen in het systeemontwerp worden gezien als aflossingen van bestaande technische schulden. In de volgende sectie ziet u hoe u omgaat met technische schulden die niet kunnen of moeten worden aangepakt.

Meer informatie over het Microsoft Azure Well-Architected Framework om het systeemontwerp te verbeteren. Naarmate het systeemontwerp verbetert, gaat u terug naar dit artikel om nieuwe mogelijkheden te vinden om de verbeteringen in uw omgeving te verbeteren en te schalen.

Geautomatiseerde oplossing van risico's

Sommige technische schulden kunnen of moeten niet worden aangepakt. Het kan te duur zijn om deze problemen op te lossen. Het kan worden gepland, maar kan een lange projectduur hebben. De bedrijfsonderbreking heeft mogelijk geen aanzienlijke bedrijfsimpact of de bedrijfsprioriteit is om snel te herstellen in plaats van te investeren in tolerantie.

Wanneer niet wordt gekozen om de technische schuld af te lossen, is automatisch herstel doorgaans de gewenste volgende stap. De meestgebruikte methode is met behulp van Azure Automation en Azure Monitor trends te detecteren en automatisch herstel te realiseren.

Zie Azure Automation en waarschuwingen voor hulp bij automatisch herstel.

De schaal van de oplossing aanpassen met een servicecatalogus

De hoeksteen van platformspecialisatie en platformgebruik is een goed beheerde servicecatalogus. Dit is hoe verbeteringen in systeemontwerp en herstel in een omgeving worden opgeschaald. De Cloud Platform- en Cloud Automation-teams werken samen om herbruikbare oplossingen te maken voor de meest voorkomende platforms in een omgeving. Als deze oplossingen echter niet consistent worden toegepast, kan cloudbeheer weinig meer bieden dan een basislijnaanbod.

Om de acceptatie te maximaliseren en de onderhoudsoverhead van een geoptimaliseerd platform te minimaliseren, moet het platform worden toegevoegd aan een servicecatalogus. Elke toepassing in de catalogus kan voor intern verbruik via de servicecatalogus worden geïmplementeerd of als Marketplace-aanbod voor externe gebruikers.

Zie de reeks over publiceren naar een servicecatalogus voor meer informatie over het publiceren naar een servicecatalogus.

Doorlopende verbetering

Platformspecialisatie en platformgebruik zijn beide afhankelijk van sterke terugkoppeling tussen de teams voor acceptatie, platform, automatisering en beheer. Door deze terugkoppeling op gegevens te baseren, kan elk team de juiste beslissingen nemen. Voor platformbewerkingen om zakelijke toezeggingen op lange termijn te realiseren, is het belangrijk om te profiteren van inzichten die specifiek zijn voor het gecentraliseerde platform. Omdat containers en SQL Server de twee meest voorkomende centraal beheerde platforms zijn, kunt u overwegen om te beginnen met het verzamelen van gegevens voor continue verbetering door de volgende artikelen te lezen: