De operationele geschiktheid beoordelenEstablish an operational fitness review

Als uw onderneming begint met het uitvoeren van werk belastingen in azure, is de volgende stap het maken van een proces voor de praktische beoordeling.As your enterprise begins to operate workloads in Azure, the next step is to establish a process for operational fitness review. Met dit proces worden de niet- functionele vereisten voor deze werk belastingen opgesomd, geïmplementeerd en herhaaldelijk geraadpleegd.This process enumerates, implements, and iteratively reviews the nonfunctional requirements for these workloads. Niet-functionele vereisten zijn gerelateerd aan het verwachte operationele gedrag van de service.Nonfunctional requirements are related to the expected operational behavior of the service.

Er zijn vijf essentiële categorieën van niet-functionele vereisten, ook wel bekend als de pijlers van de kwaliteit van de architectuur:There are five essential categories of nonfunctional requirements, known as the pillars of architecture excellence:

  • KostenoptimalisatieCost optimization
  • Operationele uitmuntendheidOperational excellence
  • Efficiëntie van prestatiesPerformance efficiency
  • BetrouwbaarheidReliability
  • BeveiligingSecurity

Een proces voor de praktische beoordeling zorgt ervoor dat uw bedrijfskritische workloads voldoen aan de verwachtingen van uw bedrijf ten opzichte van de pijlers.A process for operational fitness review ensures that your mission-critical workloads meet the expectations of your business with respect to the pillars.

Maak een proces voor de praktische beoordeling van de problemen die het gevolg zijn van het uitvoeren van werk belastingen in een productie omgeving en het herstellen en oplossen van deze problemen.Create a process for operational fitness review to fully understand the problems that result from running workloads in a production environment, and how to remediate and resolve those problems. In dit artikel vindt u een overzicht van het proces op hoog niveau voor operationele geschiktheid die uw bedrijf kan gebruiken om dit doel te verzorgen.This article outlines a high-level process for operational fitness review that your enterprise can use to achieve this goal.

Operationele geschiktheid bij micro softOperational fitness at Microsoft

Vanaf het begin zijn veel teams in micro soft betrokken bij de ontwikkeling van het Azure-platform.From the outset, many teams across Microsoft have been involved in the development of the Azure platform. Het is moeilijk om kwaliteit en consistentie te garanderen voor een project met een dergelijke grootte en complexiteit.It's difficult to ensure quality and consistency for a project of such size and complexity. U hebt een krachtig proces nodig om regel matig fundamentele niet-functionele vereisten te inventariseren en implementeren.You need a robust process to enumerate and implement fundamental nonfunctional requirements on a regular basis.

De processen die micro soft volgt, vormen de basis voor de processen die in dit artikel worden beschreven.The processes that Microsoft follows form the basis for the processes outlined in this article.

Het probleem begrijpenUnderstand the problem

Zoals beschreven in aan de slag: migratie versnellen, de eerste stap in de digitale trans formatie van een onderneming is het identificeren van de zakelijke problemen die moeten worden opgelost door Azure te gebruiken.As discussed in Get started: Accelerate migration, the first step in an enterprise's digital transformation is to identify the business problems to be solved by adopting Azure. De volgende stap is het bepalen van een oplossing op hoog niveau voor het probleem, zoals het migreren van een werk belasting naar de Cloud of het aanpassen van een bestaande on-premises service voor het toevoegen van Cloud functionaliteit.The next step is to determine a high-level solution to the problem, such as migrating a workload to the cloud or adapting an existing, on-premises service to include cloud functionality. Ten slotte ontwerpt en implementeert u de oplossing.Finally, you design and implement the solution.

Tijdens dit proces is de focus vaak de functies van de service: de set functionele vereisten die u de service wilt laten uitvoeren.During this process, the focus is often on the features of the service: the set of functional requirements that you want the service to perform. Een product leverings service vereist bijvoorbeeld functies voor het bepalen van de bron-en doel locatie van het product, het volgen van het product tijdens de levering en het verzenden van meldingen naar de klant.For example, a product-delivery service requires features for determining the source and destination locations of the product, tracking the product during delivery, and sending notifications to the customer.

De niet- functionele vereisten, in tegens telling tot eigenschappen, zoals de Beschik baarheid, tolerantieen schaalbaarheid van de service.The nonfunctional requirements, in contrast, relate to properties such as the service's availability, resiliency, and scalability. Deze eigenschappen verschillen van de functionele vereisten, omdat ze niet rechtstreeks van invloed zijn op de eind functie van een bepaalde functie in de service.These properties differ from the functional requirements because they don't directly affect the final function of any particular feature in the service. Niet-functionele vereisten hebben echter betrekking op de prestaties en continuïteit van de service.However, nonfunctional requirements do relate to the performance and continuity of the service.

U kunt bepaalde niet-functionele vereisten opgeven in het kader van een Service Level Agreement (SLA).You can specify some nonfunctional requirements in terms of a service-level agreement (SLA). U kunt bijvoorbeeld service continuïteit uitdrukken als een percentage van de beschik baarheid: ' beschikbaar 99,99 procent van de tijd '.For example, you can express service continuity as a percentage of availability: "available 99.99 percent of the time". Andere niet-functionele vereisten kunnen lastiger zijn om te definiëren en kunnen veranderen naarmate de productie behoeften veranderen.Other nonfunctional requirements might be more difficult to define and might change as production needs change. Een consument gerichte service kan bijvoorbeeld leiden tot onverwachte doorvoer vereisten na een uitbrei ding van populariteit.For example, a consumer-oriented service might face unanticipated throughput requirements after a surge of popularity.

Notitie

Zie voor meer informatie over tolerantie vereisten betrouw bare Azure-toepassingen ontwerpen.For more information about resiliency requirements, see Designing reliable Azure applications. Dit artikel bevat uitleg over concepten zoals herstel punt doelstelling (RPO), recovery-time doelstelling (RTO) en SLA.That article includes explanations of concepts like recovery-point objective (RPO), recovery-time objective (RTO), and SLA.

Proces voor operationele geschiktheids beoordelingProcess for operational fitness review

De sleutel voor het onderhouden van de prestaties en continuïteit van de services van een onderneming is het implementeren van een proces voor de praktische beoordeling.The key to maintaining the performance and continuity of an enterprise's services is to implement a process for operational fitness review.

Een overzicht van het proces voor operationele geschiktheids beoordeling

Op hoog niveau heeft het proces twee fasen.At a high level, the process has two phases. In de vereisten fase worden de eisen vastgesteld en toegewezen aan ondersteunende services.In the prerequisites phase, the requirements are established and mapped to supporting services. Deze fase treedt zelden op: mogelijk jaarlijks of wanneer nieuwe bewerkingen worden geïntroduceerd.This phase occurs infrequently: perhaps annually or when new operations are introduced. De uitvoer van de vereisten fase wordt gebruikt in de stroom fase.The output of the prerequisites phase is used in the flow phase. De stroom fase wordt vaker uitgevoerd, zoals maandelijks.The flow phase occurs more frequently, such as monthly.

Fase van de vereistenPrerequisites phase

Met de stappen in deze fase worden de vereisten vastgelegd voor het uitvoeren van een regel matige beoordeling van de belang rijke Services.The steps in this phase capture the requirements for conducting a regular review of the important services.

  1. Kritieke bedrijfs activiteiten identificeren.Identify critical business operations. Identificeer de bedrijfskritische bedrijfs voering van de onderneming.Identify the enterprise's mission-critical business operations. Zakelijke bewerkingen zijn onafhankelijk van de ondersteunende service functionaliteit.Business operations are independent from any supporting service functionality. Met andere woorden, zakelijke activiteiten vertegenwoordigen de werkelijke activiteiten die het bedrijf moet uitvoeren en die worden ondersteund door een set IT-Services.In other words, business operations represent the actual activities that the business needs to perform and that are supported by a set of IT services.

    De term missie kritiek (of bedrijfs kritiek) weerspiegelt een ernstige impact op het bedrijf als de bewerking wordt belemmerd.The term mission-critical (or business critical) reflects a severe impact on the business if the operation is impeded. Een online winkel kan bijvoorbeeld een zakelijke bewerking hebben, zoals "een klant inschakelen om een item toe te voegen aan een winkel wagen" of "een creditcard betaling verwerken".For example, an online retailer might have a business operation, such as "enable a customer to add an item to a shopping cart" or "process a credit card payment." Als een van deze bewerkingen mislukt, kan een klant de trans actie niet volt ooien en kan de onderneming geen verkopen realiseren.If either of these operations fails, a customer can't complete the transaction and the enterprise fails to realize sales.

  2. Koppel bewerkingen aan services.Map operations to services. Wijs de essentiële bedrijfs activiteiten toe aan de services die ze ondersteunen.Map the critical business operations to the services that support them. In het winkel wagentje-voor beeld kunnen verschillende services betrokken zijn, inclusief een inventaris-management-service van de voor Raad en een winkel wagen service.In the shopping-cart example, several services might be involved, including an inventory stock-management service and a shopping-cart service. Als u een creditcard betaling wilt verwerken, kunt u een on-premises betaal service gebruiken met een service voor betalings verwerking van derden.To process a credit-card payment, an on-premises payment service might interact with a third-party, payment-processing service.

  3. Analyseer service afhankelijkheden.Analyze service dependencies. Voor de meeste zakelijke bewerkingen is het mogelijk om meerdere ondersteunende services te organiseren.Most business operations require orchestration among multiple supporting services. Het is belang rijk om inzicht te krijgen in de afhankelijkheden tussen de services en de stroom van bedrijfs kritieke trans acties via deze services.It's important to understand the dependencies between the services, and the flow of mission-critical transactions through these services.

    Houd ook rekening met de afhankelijkheden tussen on-premises Services en Azure-Services.Also consider the dependencies between on-premises services and Azure services. In het winkel wagentje-voor beeld kan de inventaris beheer service van de voor Raad on-premises worden gehost en gegevens opnemen die door werk nemers vanuit een fysiek magazijn zijn ingevoerd.In the shopping-cart example, the inventory stock-management service might be hosted on-premises and ingest data entered by employees from a physical warehouse. Er kunnen echter gegevens worden opgeslagen die niet-premises zijn in een Azure-service, zoals Azure Storage, of een Data Base, zoals Azure Cosmos DB.However, it might store data off-premises in an Azure service, such as Azure Storage, or a database, such as Azure Cosmos DB.

Een uitvoer van deze activiteiten is een set met metrische gegevens over de Score Card voor service bewerkingen.An output from these activities is a set of scorecard metrics for service operations. De Score Card meet criteria zoals Beschik baarheid, schaal baarheid en herstel na nood gevallen.The scorecard measures criteria such as availability, scalability, and disaster recovery. Met metrische gegevens van de Score Card worden de operationele criteria aangegeven waarvan u wordt verwacht dat de service voldoet.Scorecard metrics express the operational criteria that you expect the service to meet. Deze metrische gegevens kunnen worden uitgedrukt op elk niveau van granulariteit dat geschikt is voor de service bewerking.These metrics can be expressed at any level of granularity that's appropriate for the service operation.

De Score Card moet worden uitgedrukt in eenvoudige termen om zinvolle discussies tussen de eigen aren en engineering van het bedrijf mogelijk te maken.The scorecard should be expressed in simple terms to facilitate meaningful discussion between the business owners and engineering. Een score card-metriek voor schaal baarheid kan bijvoorbeeld op een eenvoudige manier worden gecodeerd.For example, a scorecard metric for scalability might be color-coded in a simple way. Groen betekent het voldoen aan de gedefinieerde criteria, geel betekent dat het niet voldoet aan de gedefinieerde criteria, maar dat er actief een geplande herstel bewerking wordt uitgevoerd, en dat het niet mogelijk is om te voldoen aan de gedefinieerde criteria zonder plan of actie.Green means meeting the defined criteria, yellow means failing to meet the defined criteria but actively implementing a planned remediation, and red means failing to meet the defined criteria with no plan or action.

Het is belang rijk om te benadrukken dat deze metrische gegevens rechtstreeks moeten overeenkomen met de bedrijfs behoeften.It's important to emphasize that these metrics should directly reflect business needs.

Service-beoordelings faseService-review phase

De service-beoordelings fase is de kern van de operationele geschiktheids beoordeling.The service-review phase is the core of the operational fitness review. Hiervoor moeten de volgende stappen worden uitgevoerd:It involves these steps:

  1. Metrische service gegevens meten.Measure service metrics. Gebruik de metrische gegevens van de Score Card om de services te controleren om ervoor te zorgen dat de services voldoen aan de zakelijke verwachtingen.Use the scorecard metrics to monitor the services, to ensure that the services meet the business expectations. Service bewaking is essentieel.Service monitoring is essential. Als u een set services niet kunt bewaken ten aanzien van de niet-functionele vereisten, moet u rekening houden met de overeenkomstige metrische scores van de scorekaart om rood te zijn.If you can't monitor a set of services with respect to the nonfunctional requirements, consider the corresponding scorecard metrics to be red. In dit geval is de eerste stap voor herstel het implementeren van de juiste service bewaking.In this case, the first step for remediation is to implement the appropriate service monitoring. Als het bedrijf bijvoorbeeld verwacht dat een service wordt uitgevoerd met een Beschik baarheid van 99,99 procent, maar er geen productie-telemetrie is om de beschik baarheid te meten, wordt ervan uitgegaan dat u niet aan de vereiste voldoet.For example, if the business expects a service to operate with 99.99 percent availability, but there is no production telemetry in place to measure availability, assume that you're not meeting the requirement.

  2. Herstel plannen.Plan remediation. Bepaal voor elke service bewerking waarvoor metrische gegevens onder een aanvaard bare drempel waarde vallen, de kosten voor het herstellen van de service om de werking van een acceptabel niveau te brengen.For each service operation for which metrics fall below an acceptable threshold, determine the cost of remediating the service to bring operation to an acceptable level. Als de kosten voor het herstellen van de service hoger zijn dan de verwachte omzet van de service, gaat u verder met de onlichamelijke kosten, zoals de ervaring van de klant.If the cost of remediating the service is greater than the expected revenue generation of the service, move on to consider the intangible costs, such as customer experience. Als klanten bijvoorbeeld moeite hebben met het plaatsen van een geslaagde order door gebruik te maken van de service, kunnen ze in plaats daarvan een concurrent kiezen.For example, if customers have difficulty placing a successful order by using the service, they might choose a competitor instead.

  3. Implementeer herstel.Implement remediation. Nadat de bedrijfs eigen aren en het technische team op een plan akkoord zijn gegaan, implementeert u dit.After the business owners and engineering team agree on a plan, implement it. Rapporteert de status van de implementatie wanneer u metrische gegevens over de Score Card bekijkt.Report the status of the implementation whenever you review scorecard metrics.

Dit proces wordt herhaald en in het ideale geval uw onderneming heeft een team dat hiervoor is toegewezen.This process is iterative, and ideally your enterprise has a team dedicated to it. Dit team moet regel matig aan de slag gaan met het beoordelen van bestaande herstel projecten, het starten van de fundamentele beoordeling van nieuwe workloads en het volgen van de totale score card van de onderneming.This team should meet regularly to review existing remediation projects, kick off the fundamental review of new workloads, and track the enterprise's overall scorecard. Het team moet ook beschikken over de machtiging om herstel teams te bewaren als ze zich achter de planning bevinden of niet voldoen aan de metrische gegevens.The team should also have the authority to hold remediation teams accountable if they're behind schedule or fail to meet metrics.

Structuur van het beoordelings teamStructure of the review team

Het team dat verantwoordelijk is voor de operationele geschiktheids beoordeling bestaat uit de volgende rollen:The team responsible for operational fitness review is composed of the following roles:

  • Bedrijfs eigenaar: Geeft kennis van het bedrijf voor het identificeren en priori teren van elke bedrijfsspecifieke bedrijfs activiteit.Business owner: Provides knowledge of the business to identify and prioritize each mission-critical business operation. Deze rol vergelijkt ook de risico kosten voor de bedrijfs impact en verstuurt de definitieve beslissing over herbemiddeling.This role also compares the mitigation cost to the business impact, and drives the final decision on remediation.

  • Zakelijk advocaat: Hiermee worden zakelijke bewerkingen onderverdeeld in onopvallende delen en worden deze onderdelen toegewezen aan services en infra structuur, ongeacht of deze on-premises of in de Cloud zijn.Business advocate: Breaks down business operations into discreet parts, and maps those parts to services and infrastructure, whether on-premises or in the cloud. De rol vereist grondige kennis van de technologie die aan elke bedrijfs activiteit is gekoppeld.The role requires deep knowledge of the technology associated with each business operation.

  • Engineering eigenaar: Implementeert de services die zijn gekoppeld aan de bedrijfs bewerking.Engineering owner: Implements the services associated with the business operation. Deze personen kunnen deel nemen aan het ontwerp, de implementatie en de implementatie van oplossingen voor niet-functionele vereiste problemen die door het beoordelings team worden gedetecteerd.These individuals might participate in the design, implementation, and deployment of any solutions for nonfunctional requirement problems that are uncovered by the review team.

  • Eigenaar van service: Werkt met de toepassingen en services van het bedrijf.Service owner: Operates the business's applications and services. Deze personen verzamelen logboek registratie en gebruiks gegevens voor deze toepassingen en services.These individuals collect logging and usage data for these applications and services. Deze gegevens worden gebruikt om problemen te identificeren en om oplossingen te controleren nadat ze zijn geïmplementeerd.This data is used both to identify problems and to verify fixes after they're deployed.

Vergadering controlerenReview meeting

We raden aan dat uw beoordelings team regel matig aan de slag gaat.We recommend that your review team meet on a regular basis. Het team kan bijvoorbeeld maandelijks voldoen en vervolgens de status en de metrische gegevens rapporteren aan het hoge leiderschap op kwartaal basis.For example, the team might meet monthly, and then report status and metrics to senior leadership on a quarterly basis.

Pas de details van het proces en de vergadering aan aan uw specifieke behoeften.Adapt the details of the process and meeting to fit your specific needs. We raden u aan de volgende taken uit te voeren als uitgangs punt:We recommend the following tasks as a starting point:

  1. De bedrijfs eigenaar en de onderneming hebben voor het inventariseren en bepalen van de niet-functionele vereisten voor elke bedrijfs activiteit, met invoer van de technische en service-eigen aren.The business owner and business advocate enumerate and determine the nonfunctional requirements for each business operation, with input from the engineering and service owners. Controleer en controleer de prioriteit voor bedrijfs activiteiten die eerder zijn geïdentificeerd.For business operations that have been identified previously, review and verify the priority. Wijs een prioriteit toe aan de bestaande lijst voor nieuwe bedrijfs bewerkingen.For new business operations, assign a priority in the existing list.

  2. De technische en service-eigen aren wijzen de huidige status van de bedrijfs activiteiten toe aan de bijbehorende on-premises en Cloud Services.The engineering and service owners map the current state of business operations to the corresponding on-premises and cloud services. De toewijzing is een lijst van de onderdelen in elke service, georiënteerd als een afhankelijkheids structuur.The mapping is a list of the components in each service, oriented as a dependency tree. De engineering-en service-eigen aren bepalen vervolgens de kritieke paden via de boom structuur.The engineering and service owners then determine the critical paths through the tree.

  3. De technische en service-eigen aren bekijken de huidige status van operationele logboek registratie en bewaking voor de services die in de vorige stap worden weer gegeven.The engineering and service owners review the current state of operational logging and monitoring for the services listed in the previous step. Robuuste logboek registratie en controle zijn essentieel: ze identificeren service onderdelen die bijdragen aan een fout om niet-functionele vereisten te voldoen.Robust logging and monitoring are critical: they identify service components that contribute to a failure to meet nonfunctional requirements. Als voldoende logboek registratie en bewaking niet worden uitgevoerd, moet het team ze op locatie zetten door een plan te maken en te implementeren.If sufficient logging and monitoring aren't in place, the team must put them in place by creating and implementing a plan.

  4. Het team maakt Score Card-metrische gegevens voor nieuwe bedrijfs bewerkingen.The team creates scorecard metrics for new business operations. De Score Card bestaat uit de lijst met onderdeel onderdelen voor elke service die in stap 2 is geïdentificeerd.The scorecard consists of the list of constituent components for each service identified in step 2. De oplossing is afgestemd op de niet-functionele vereisten en bevat een meting van de manier waarop elk onderdeel aan de vereisten voldoet.It's aligned with the nonfunctional requirements, and includes a measure of how well each component meets the requirements.

  5. Voor onderdelen die niet voldoen aan niet-functionele vereisten, ontwerpt het team een oplossing op hoog niveau en wijst hij een technische eigenaar toe.For constituent components that fail to meet nonfunctional requirements, the team designs a high-level solution, and assigns an engineering owner. Op dit moment maken de bedrijfs eigenaar en het bedrijf een budget voor het herstel werk, op basis van de verwachte omzet van de bedrijfs activiteit.At this point, the business owner and business advocate establish a budget for the remediation work, based on the expected revenue of the business operation.

  6. Ten slotte voert het team een beoordeling uit van het doorlopende herstel werk.Finally, the team conducts a review of the ongoing remediation work. Elk van de Score Card-metrische gegevens voor onderhanden werk wordt gecontroleerd op basis van de verwachte criteria.Each of the scorecard metrics for work in progress is reviewed against the expected criteria. Voor samenstellende onderdelen die voldoen aan metrische criteria, presenteert de service-eigenaar logboek registratie-en controle gegevens om te bevestigen dat aan de criteria wordt voldaan.For constituent components that meet metric criteria, the service owner presents logging and monitoring data to confirm that the criteria are met. Voor deze samenstellende onderdelen die niet voldoen aan de metrische criteria, legt elke technische eigenaar de problemen uit die voor komen dat er criteria worden vervuld en worden nieuwe ontwerpen voor herstel gepresenteerd.For those constituent components that don't meet metric criteria, each engineering owner explains the problems that are preventing criteria from being met, and presents any new designs for remediation.

  • Microsoft Azure Well-Architected Framework: meer informatie over het verrijken van de grond beginselen voor het verbeteren van de kwaliteit van een werk belasting.Microsoft Azure Well-Architected Framework: Learn about guiding tenets for improving the quality of a workload. Het Framework bestaat uit vijf pijlers van hoogwaardige architectuur:The framework consists of five pillars of architecture excellence:
    • KostenoptimalisatieCost optimization
    • Operationele uitmuntendheidOperational excellence
    • Efficiëntie van prestatiesPerformance efficiency
    • BetrouwbaarheidReliability
    • BeveiligingSecurity
  • Tien ontwerp principes voor Azure-toepassingen.Ten design principles for Azure applications. Volg de volgende richtlijnen om uw toepassing in grotere mate schaalbaar, flexibel en beheerbaar te maken.Follow these design principles to make your application more scalable, resilient, and manageable.
  • Flexibele toepassingen ontwerpen voor Azure.Designing resilient applications for Azure. Ontwikkel en onderhoud betrouw bare systemen met behulp van een gestructureerde benadering gedurende de levens duur van een toepassing, van ontwerp en implementatie tot implementatie en bewerkingen.Build and maintain reliable systems using a structured approach over the lifetime of an application, from design and implementation to deployment and operations.
  • Ontwerp patronenin de Cloud.Cloud design patterns. Gebruik ontwerp patronen om toepassingen te bouwen op de pijlers van de expertise van de architectuur.Use design patterns to build applications on the pillars of architecture excellence.
  • Azure Advisor.Azure Advisor. Azure Advisor biedt persoonlijke aanbevelingen op basis van uw gebruik en configuraties om uw resources te optimaliseren voor hoge Beschik baarheid, beveiliging, prestaties en kosten.Azure Advisor provides personalized recommendations based on your usage and configurations to help optimize your resources for high availability, security, performance, and cost.