Ontwerp principes en geavanceerde bewerkingen Toep assenApply design principles and advanced operations

In de eerste drie disciplines voor cloudbeheer wordt een basislijn voor beheer beschreven.The first three cloud management disciplines describe a management baseline. Een beheer basislijn moet mini maal een standaard zakelijke toezeg ging bevatten om zakelijke onderbrekingen te minimaliseren en herstel te versnellen als de service wordt onderbroken.At a minimum, a management baseline should include a standard business commitment to minimize business interruptions and accelerate recovery if service is interrupted. De meeste beheer basislijnen omvatten een discipline gericht op het onderhouden van ' inventaris en zicht baarheid ', ' operationele naleving ' en ' beveiliging en herstel '.Most management baselines include a disciplined focus on maintaining "inventory and visibility," "operational compliance," and "protection and recovery."

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.The purpose of a management baseline is to create a consistent offering that provides a minimum level of business commitment for all supported workloads. Met deze basis lijn van algemene, herhaal bare beheer aanbiedingen kan het team een zeer geoptimaliseerde mate van operationeel beheer bieden met minimale afwijking.This baseline of common, repeatable management offerings allows the team to deliver a highly optimized degree of operational management, with minimal deviation. Maar deze standaard aanbieding biedt mogelijk geen uitgebreide mogelijkheden voor het bedrijf.But that standard offering might not provide a rich enough commitment to the business.

In het diagram in de volgende sectie ziet u drie manieren om verder te gaan dan de beheer basislijn.The diagram in the next section illustrates three ways to go beyond the management baseline.

De beheer basislijn moet voldoen aan de minimum vereisten voor 80 procent van de laagste kritieke werk belastingen in de Port Folio.The management baseline should meet the minimum commitment required by 80 percent of the lowest criticality workloads in the portfolio. De basis lijn mag niet worden toegepast op essentiële workloads.The baseline should not be applied to mission-critical workloads. Het moet ook worden toegepast op algemene platformen die worden gedeeld via workloads.Nor should it be applied to common platforms that are shared across workloads. Deze werk belastingen vereisen een focus op ontwerp principes en geavanceerde bewerkingen.Those workloads require a focus on design principles and advanced operations.

Geavanceerde opties voor bewerkingenAdvanced operations options

Er zijn drie aanbevolen paden voor het verbeteren van zakelijke toezeg gingen buiten de beheer basislijn, zoals wordt weer gegeven in het volgende diagram:There are three suggested paths for improving business commitments beyond the management baseline, as shown in the following diagram:

Geavanceerde bewerkingen

Uitgebreide beheer basislijnEnhanced management baseline

Zoals beschreven in de Azure Management Guide, gebruikt een verbeterde beheer basislijn de Cloud-systeem eigen hulpprogram ma's om de uptime te verbeteren en herstel tijden te verlagen.As outlined in the Azure Management Guide, an enhanced management baseline uses cloud-native tools to improve uptime and decrease recovery times. De verbeteringen zijn aanzienlijk, maar minder dan bij het specialiseren van de werk belasting of het platform.The improvements are significant, but less so than with workload or platform specialization. Het voor deel van een uitgebreid beheer basislijn is de even aanzienlijke vermindering van de kosten en implementatie tijd.The advantage of an enhanced management baseline is the equally significant reduction in cost and implementation time.

Beheer specialisatieManagement specialization

Voor aspecten van workload-en platform bewerkingen zijn mogelijk wijzigingen in ontwerp-en architectuur principes vereist.Aspects of workload and platform operations might require changes to design and architecture principles. Deze wijzigingen kunnen enige tijd in beslag nemen, waardoor de operationele kosten kunnen stijgen.Those changes could take time and might result in increased operating expenses. Om het aantal workloads te verminderen dat dergelijke investeringen vereist, kan een verbeterde basislijn voor beheer voldoende verbetering bieden voor de bedrijfscommitment.To reduce the number of workloads requiring such investments, an enhanced management baseline could provide enough of an improvement to the business commitment.

Voor werk belastingen die een grotere investering garanderen om te voldoen aan een zakelijke toezeg ging, is een specialisatie van bewerkingen de sleutel.For workloads that warrant a higher investment to meet a business commitment, specialization of operations is key.

Gebieden van beheer specialisatieAreas of management specialization

Er zijn twee gebieden met specialisatie:There are two areas of specialization:

  • Platform specialisatie: Investeren in lopende activiteiten van een gedeeld platform, waarbij de investering over meerdere werk belastingen wordt verdeeld.Platform specialization: Invest in ongoing operations of a shared platform, distributing the investment across multiple workloads.
  • Specialisatie van werk belasting: Investeren in lopende activiteiten van een specifieke werk belasting, doorgaans gereserveerd voor essentiële workloads.Workload specialization: Invest in ongoing operations of a specific workload, generally reserved for mission-critical workloads.

IT-team van de centrale, het Cloud centrum (CCoE)Central IT team or cloud center of excellence (CCoE)

Beslissingen tussen platform specialisatie en de specialisatie van werk belastingen zijn gebaseerd op de ernst en de impact van elke werk belasting.Decisions between platform specialization and workload specialization are based on the criticality and impact of each workload. Deze beslissingen zijn echter ook indicatief voor grotere culturele beslissingen tussen het centrale IT-team en CCoE organisatie modellen.However, these decisions are also indicative of larger cultural decisions between central IT team and CCoE organizational models.

Specialisatie van workloads veroorzaakt vaak een cultuurverandering.Workload specialization often triggers a cultural change. In het gecentraliseerde IT-proces worden zowel de processen gebouwd die op schaal ondersteuning kunnen bieden.Traditional IT and centralized IT both build processes that can provide support at scale. Schaal ondersteuning is meer haalbaar voor Herhaal bare services die worden gevonden in een beheer basislijn, een verbeterde basis lijn of zelfs platform bewerkingen.Scale support is more achievable for repeatable services found in a management baseline, enhanced baseline, or even platform operations. Specialisatie van werk belastingen wordt niet vaak geschaald.Workload specialization doesn't often scale. Dit gebrek aan schaal maakt het moeilijk voor een gecentraliseerde IT-organisatie om de benodigde ondersteuning te bieden zonder dat er beperkingen gelden voor de schaal van de organisatie.This lack of scale makes it difficult for a centralized IT organization to provide necessary support without reaching organizational scale limitations.

U kunt ook een Cloud centrum van uitmuntendheid schalen door doel gericht delegering van verantwoordelijkheden en selectief centraliseren.Alternatively, a cloud center of excellence approach scales through purposeful delegation of responsibility and selective centralization. Specialisatie van werk belastingen is een beter afstemmen met de aanpak van de gedelegeerde verantwoordelijkheid van een CCoE.Workload specialization tends to better align with the delegated responsibility approach of a CCoE.

De natuurlijke uitlijning van rollen in een CCoE wordt als volgt beschreven:The natural alignment of roles in a CCoE is outlined as follows:

  • Het Cloud platform team helpt bij het bouwen van algemene platforms die ondersteuning bieden voor meerdere Cloud acceptatie teams.The cloud platform team helps build common platforms that support multiple cloud adoption teams.
  • Het Cloud Automation-team breidt deze platformen uit naar Implementeer bare assets in een service catalogus.The cloud automation team extends those platforms into deployable assets in a service catalog.
  • Cloud beheer levert de beheer basislijn centraal en helpt het gebruik van de Service catalogus te ondersteunen.Cloud management delivers the management baseline centrally and helps support the use of the service catalog.
  • De bedrijfs eenheid (in de vorm van een team van Business DevOps of een team voor Cloud acceptatie) houdt echter verantwoordelijkheid voor de dagelijkse werkzaamheden van de werk belasting, pijp lijn of prestaties.But the business unit (in the form of a business DevOps team or cloud adoption team) holds responsibility for day-to-day operations of the workload, pipeline, or performance.

Net als bij het uitlijnen van beheer gebieden kan het centrale IT-team en CCoE-modellen doorgaans worden geleverd op platform specialisatie, met minimale culturele veranderingen.As for aligning areas of management, central IT team and CCoE models can generally deliver on platform specialization, with minimal cultural change. Specialisatie van werk belastingen is mogelijk complexer voor centrale IT-teams.Delivering on workload specialization might be more complex for central IT teams.

Processen voor het beheer van specialisatieManagement specialization processes

Binnen elke specialisatie wordt het volgende proces van vier stappen geleverd in een bedisciplinede, iteratieve benadering.Within each specialization, the following four-step process is delivered in a disciplined, iterative approach. Deze benadering vereist samen werking tussen Cloud-acceptatie, Cloud platform, Cloud automatisering en Cloud Management experts om een levensvat bare en weloverwogen feedback-lus te maken.This approach requires partnership among cloud adoption, cloud platform, cloud automation, and cloud management experts to create a viable and informed feedback loop.

  • Systeem ontwerp verbeteren: Verbeter het ontwerp van algemene systemen (platformen) of specifieke workloads om de onderbrekingen effectief te minimaliseren.Improve system design: Improve the design of common systems (platforms) or specific workloads to effectively minimize interruptions.
  • Automatisch herstel: Enkele verbeteringen zijn niet kosten effectief.Automate remediation: Some improvements are not cost effective. In dergelijke gevallen kan het zinvol zijn om herstel te automatiseren en de impact van onderbrekingen te verminderen.In such cases, it might make more sense to automate remediation and reduce the impact of interruptions.
  • De oplossing schalen: Naarmate het ontwerp van systemen en geautomatiseerde herstel bewerkingen verbeterd zijn, kunt u deze wijzigingen in de hele omgeving schalen via de Service catalogus.Scale the solution: As systems design and automated remediation are improved, you can scale those changes across the environment through the service catalog.
  • Voortdurende verbetering: U kunt verschillende controle hulpprogramma's gebruiken om incrementele verbeteringen aan te sporen in de volgende fase van het systeem ontwerp, de automatisering en de schaal.Continuous improvement: You can use various monitoring tools to discover incremental improvements to address in the next pass of system design, automation, and scale.

Systeemontwerp verbeterenImprove system design

Het verbeteren van het systeemontwerp is de meest efficiënte benadering van functionele verbeteringen voor een veelgebruikt platform.Improving system design is the most effective approach to improving operations of any common platform. Verbeteringen aan het systeem ontwerp kunnen bijdragen aan een betere stabiliteit en het afnemen van zakelijke onderbrekingen.System design improvements can help increase stability and decrease business interruptions. Het ontwerp van afzonderlijke systemen valt buiten het bereik van de omgevingsbenadering die voor het Cloud Adoption Framework is bepaald.Design of individual systems is out of scope for the environment view taken throughout the Cloud Adoption Framework.

Als aanvulling op dit kader biedt het Microsoft Azure Well-Architected-Framework richt zich op de leidende grond beginselen voor het verbeteren van de kwaliteit van een platform of een bepaalde werk belasting.As a complement to this framework, the Microsoft Azure Well-Architected Framework provides guiding tenets for improving the quality of a platform or a specific workload. Het Framework is gericht op verbetering van vijf pijlers op het gebied van architectuur:The framework focuses on improvement across five pillars of architecture excellence:

  • Kostenoptimalisatie: Kosten beheren om de geleverde waarde te maximaliseren.Cost optimization: Manage costs to maximize the value delivered.
  • Operationele topprestaties: Operationele processen volgen die ervoor zorgen dat een systeem blijft werken.Operational excellence: Follow operational processes that keep a system running in production.
  • Prestatie-efficiëntie: Systemen schalen om deze aan te passen op wijzigingen in de belasting.Performance efficiency: Scale systems to adapt to changes in load.
  • Betrouwbaarheid: Systemen ontwerpen om te herstellen van fouten en te kunnen blijven functioneren.Reliability: Design systems to recover from failures and continue to function.
  • Beveiliging: Toepassingen en gegevens beveiligen tegen bedreigingen.Security: Protect applications and data from threats.

De meeste bedrijfsonderbrekingen zijn gekoppeld aan een vorm van technische schuld of tekortkoming in de architectuur.Most business interruptions equate to some form of technical debt, or deficiency in the architecture. Voor bestaande implementaties kunnen verbeteringen in het systeemontwerp worden gezien als aflossingen van bestaande technische schulden.For existing deployments, systems design improvements can be viewed as payments against existing technical debt. Voor bestaande implementaties kunnen verbeteringen in het systeemontwerp worden gezien als aflossingen van bestaande technische schulden.For new deployments, systems design improvements can be viewed as avoidance of technical debt. In de volgende sectie, ' automatisch door voeren ', wordt gekeken naar manieren om technische schulden te verhelpen die niet of niet kunnen worden opgelost.The next section, "Automated remediation," looks at ways to address technical debt that can't or shouldn't be addressed.

Meer informatie over de Microsoft Azure Well-Architected Frameworkom het systeem ontwerp te verbeteren.To improve system design, learn more about the Microsoft Azure Well-Architected Framework. Als uw systeem ontwerp wordt verbeterd, keert u terug naar dit artikel om nieuwe mogelijkheden te vinden voor het verbeteren en schalen van de verbeteringen in uw omgeving.As your system design improves, return to this article to find new opportunities to improve and scale the improvements across your environment.

Automatisch herstelAutomated remediation

Sommige technische schulden kunnen niet of niet worden opgelost.Some technical debt can't or shouldn't be addressed. Het kan te duur zijn om deze problemen op te lossen.Resolution could be too expensive to correct. Het kan worden gepland, maar kan een lange project duur hebben.It could be planned but might have a long project duration. De zakelijke onderbreking heeft mogelijk geen aanzienlijke gevolgen voor het bedrijf of de bedrijfs prioriteit is om snel te herstellen in plaats van in tolerantie te investeren.The business interruption might not have a significant business impact, or the business priority is to recover quickly instead of investing in resiliency.

Wanneer niet wordt gekozen om de technische schuld af te lossen, is automatisch herstel doorgaans de gewenste volgende stap.When resolution of technical debt isn't the desired path, automated remediation is commonly the desired next step. De meestgebruikte methode is met behulp van Azure Automation en Azure Monitor trends te detecteren en automatisch herstel te realiseren.Using Azure Automation and Azure Monitor to detect trends and provide automated remediation is the most common approach to automated remediation.

Zie Azure Automation en waarschuwingen voor hulp bij automatisch herstel.For guidance on automated remediation, see Azure Automation and alerts.

De schaal van de oplossing aanpassen met een servicecatalogusScale the solution with a service catalog

De hoeksteen van platformspecialisatie en platformgebruik is een goed beheerde servicecatalogus.The cornerstone of platform specialization and platform operations is a well-managed service catalog. Dit is hoe verbeteringen in systeemontwerp en herstel in een omgeving worden opgeschaald.This is how improvements to systems design and remediation are scaled across an environment. De Cloud Platform- en Cloud Automation-teams werken samen om herbruikbare oplossingen te maken voor de meest voorkomende platforms in een omgeving.The cloud platform team and cloud automation team align to create repeatable solutions to the most common platforms in any environment. Als deze oplossingen echter niet consistent worden toegepast, kan Cloud beheer iets meer bieden dan een basislijn aanbieding.However, if those solutions aren't consistently applied, cloud management can provide little more than a baseline offering.

Om de acceptatie te maximaliseren en de onderhouds overhead van elk geoptimaliseerd platform te minimaliseren, moet het platform worden toegevoegd aan een service catalogus.To maximize adoption and minimize maintenance overhead of any optimized platform, the platform should be added to a service catalog. Elke toepassing in de catalogus kan voor intern verbruik via de servicecatalogus worden geïmplementeerd of als Marketplace-aanbod voor externe gebruikers.Each application in the catalog can be deployed for internal consumption via the service catalog, or as a marketplace offering for external consumers.

Zie de serie over publiceren naar een service catalogusvoor informatie over het publiceren naar een service catalogus.For information about publishing to a service catalog, see the series on publishing to a service catalog.

Voortdurende verbeteringContinuous improvement

Platformspecialisatie en platformgebruik zijn beide afhankelijk van sterke terugkoppeling tussen de teams voor acceptatie, platform, automatisering en beheer.Platform specialization and platform operations both depend on strong feedback loops between adoption, platform, automation, and management teams. Door deze terugkoppeling op gegevens te baseren, kan elk team de juiste beslissingen nemen.Grounding those feedback loops in data empowers each team to make wise decisions. Voor platform bewerkingen om langlopende zakelijke verbintenissen te verkrijgen, is het belang rijk om te profiteren van inzichten die specifiek zijn voor het centrale platform.For platform operations to achieve long-term business commitments, it's important to take advantage of insights that are specific to the centralized platform. Omdat containers en SQL Server de twee meest voorkomende centraal beheerde platformen zijn, kunt u beginnen met het verzamelen van gegevens over continue verbetering door de volgende artikelen te bekijken:Because containers and SQL Server are the two most common centrally managed platforms, consider beginning with continuous improvement data collection by reviewing the following articles: