Overzicht van de betrouw bare pijlerOverview of the reliability pillar

Een betrouwbare toepassing bouwen in de cloud is anders dan traditioneel toepassingen bouwen.Building a reliable application in the cloud is different from traditional application development. In het verleden hebt u mogelijk het aantal redundante, hogere hardware gekocht om de kans op een volledig toepassings platform in de cloud te minimaliseren, dan bevestigen we dat er fouten optreden.While historically you may have purchased levels of redundant higher-end hardware to minimize the chance of an entire application platform failing, in the cloud, we acknowledge up front that failures will happen. In plaats van fouten helemaal te proberen te voorkomen, is het doel de effecten van een onderdeel met een storing te beperken.Instead of trying to prevent failures altogether, the goal is to minimize the effects of a single failing component.

Raadpleeg de beoordeling van Microsoft Azure Well-Architected Framework om uw werkbelasting te beoordelen op basis van de pijlers in Microsoft Azure Well-Architected Framework.To assess your workload using the tenets found in the Microsoft Azure Well-Architected Framework, see the Microsoft Azure Well-Architected Review.

Betrouwbare toepassingen zijn:Reliable applications are:

  • Tolerant , herstellen zonder problemen van fouten en blijven functioneren met minimale downtime en gegevensverlies voor een volledig herstel.Resilient and recover gracefully from failures, and they continue to function with minimal downtime and data loss before full recovery.
  • Hebben hoge beschikbaarheid en worden uitgevoerd met een gezonde status zonder significante downtime.Highly available (HA) and run as designed in a healthy state with no significant downtime.

Begrip van hoe deze elementen samenwerken (en hoe deze van invloed zijn op kosten) is van groot belang voor het bouwen van een betrouwbare toepassing.Understanding how these elements work together — and how they affect cost — is essential to building a reliable application. Het helpt u te bepalen hoeveel downtime acceptabel is, wat de mogelijke kosten voor uw bedrijf zijn en welke functies nodig zijn tijdens een herstel.It can help you determine how much downtime is acceptable, the potential cost to your business, and which functions are necessary during a recovery.

In dit artikel beschrijven we kort hoe u in elke stap van het ontwerpproces van een Azure-toepassing betrouwbaarheid inbouwt.This article provides a brief overview of building reliability into each step of the Azure application design process. Elke sectie bevat een koppeling naar een uitgebreid artikel over hoe u betrouwbaarheid integreert in die specifieke stap in het proces.Each section includes a link to an in-depth article on how to integrate reliability into that specific step in the process. Als u op zoek bent naar overwegingen voor afzonderlijke Azure-services, bekijkt u de Resiliency checklist for specific Azure services (Controlelijst voor tolerantie voor specifieke Azure-services).If you're looking for reliability considerations for individual Azure services, review the Resiliency checklist for specific Azure services.

Bouwen voor betrouwbaarheidBuild for reliability

In dit gedeelte worden zes stappen beschreven om een betrouwbare Azure-toepassing te bouwen.This section describes six steps for building a reliable Azure application. Elke stap is gekoppeld aan een gedeelte dat het proces en de voorwaarden verder definieert.Each step links to a section that further defines the process and terms.

  1. Definieer de vereisten.Define requirements. Ontwikkel de vereisten voor beschikbaarheid en herstel op basis van opgesplitste workloads en bedrijfsbehoeften.Develop availability and recovery requirements based on decomposed workloads and business needs.
  2. Gebruik best practices voor de architectuur.Use architectural best practices. Volg bewezen stappen, identificeer mogelijke foutpunten in de architectuur en bepaal hoe de toepassing reageert op fouten.Follow proven practices, identify possible failure points in the architecture, and determine how the application will respond to failure.
  3. Test met simulaties en geforceerde failovers.Test with simulations and forced failovers. Simuleer fouten, activeer geforceerde failovers en test detectie en herstel van deze fouten.Simulate faults, trigger forced failovers, and test detection and recovery from these failures.
  4. Implementeer de toepassing consistent.Deploy the application consistently. Breng de toepassing uit voor productie met betrouwbare en herhaalbare processen.Release to production using reliable and repeatable processes.
  5. Controleer de status van de toepassing.Monitor application health. Detecteer fouten, bewaak indicatoren van mogelijke fouten en meet de status van uw toepassingen.Detect failures, monitor indicators of potential failures, and gauge the health of your applications.
  6. Reageer op fouten en noodsituaties.Respond to failures and disasters. Identificeer wanneer een fout zich voordoet en bepaal hoe u deze fout aanpakt op basis van vastgestelde strategieën.Identify when a failure occurs, and determine how to address it based on established strategies.

Vereisten definiërenDefine requirements

Identificeer uw bedrijfsbehoeften en bouw uw betrouwbaarheidsplan voor die behoeften.Identify your business needs, and build your reliability plan to address them. Overweeg de volgende:Consider the following:

  • Identificeer workloads en gebruik.Identify workloads and usage. Een workload is een op zichzelf staande mogelijkheid of taak die logisch is gescheiden van andere taken, in termen van bedrijfslogica en gegevensopslagvereisten.A workload is a distinct capability or task that is logically separated from other tasks, in terms of business logic and data storage requirements. Elke workload heeft verschillende vereisten voor beschikbaarheid, schaalbaarheid, gegevensconsistentie en noodherstel.Each workload has different requirements for availability, scalability, data consistency, and disaster recovery.

  • Plan voor gebruikspatronen.Plan for usage patterns. Gebruikspatronen spelen ook een rol in de vereisten.Usage patterns also play a role in requirements. Identificeer verschillen in vereisten tijdens kritieke en niet-kritieke perioden.Identify differences in requirements during critical and non-critical periods. Een toepassing die bijvoorbeeld belastingen invult, kan niet tijdens een deadline vastlopen.For example, a tax-filing application can't fail during a filing deadline. Plan redundantie in verschillende regio's voor het geval dat één ervan mislukt. Zo zorgt u voor uptime.To ensure uptime, plan redundancy across several regions in case one fails. Als u daarentegen kosten wilt besparen tijdens niet-kritieke perioden, kunt u uw toepassing uitvoeren in een enkele regio.Conversely, to minimize costs during non-critical periods, you can run your application in a single region.

  • Kritieke onderdelen en paden identificeren.Identify critical components and paths. Niet alle onderdelen van uw systeem zijn mogelijk zo belang rijk als andere.Not all components of your system might be as important as others. U kunt bijvoorbeeld een optioneel onderdeel hebben dat incrementele waarde toevoegt, maar dat de werk belasting zonder indien nodig kan worden uitgevoerd.For example, you might have an optional component that adds incremental value, but that the workload can run without if necessary. Begrijpen waar deze onderdelen zich bevinden en omgekeerd, waar de kritieke onderdelen van uw werk belasting zijn.Understand where these components are, and conversely, where the critical parts of your workload are. Dit helpt u bij het bereiken van uw Beschik baarheid en reliablity metrische gegevens en om uw herstel strategieën te plannen voor het priori teren van de meest belang rijke onderdelen.This will help to scope your availability and reliablity metrics and to plan your recovery strategies to prioritise the highest-importance components.

  • Bij het instellen van de beschikbaarheids gegevens wordt — geduurd voor herstel (MTTR) en de gemiddelde tijd tussen storingen (MBTF).Establish availability metrics — mean time to recovery (MTTR) and mean time between failures (MTBF). MTTR is de gemiddelde tijd die nodig is om een onderdeel te herstellen na een storing.MTTR is the average time it takes to restore a component after a failure. MBTF is hoelang wordt verwacht dat een onderdeel het tussen storingen volhoudt.MTBF is how long a component can reasonably expect to last between outages. Gebruik deze metingen om te bepalen waar u redundantie toevoegt en om service level agreements (SLA's) te bepalen voor klanten.Use these measures to determine where to add redundancy and to determine service-level agreements (SLAs) for customers.

  • Stel herstel metrische gegevens in voor herstel — tijd doelstelling (RTO) en Recovery Point Objective (RPO).Establish recovery metrics — recovery time objective (RTO) and recovery point objective (RPO). RTO is de maximaal acceptabele tijd dat een toepassing onbeschikbaar kan zijn na een incident.RTO is the maximum acceptable time an application can be unavailable after an incident. RPO is de maximale duur dat gegevensverlies acceptabel is tijdens een noodgeval.RPO is the maximum duration of data loss that is acceptable during a disaster. Als u deze waarden wilt afleiden, voert u een risicoanalyse uit en zorgt u ervoor dat u de kosten en risico's van downtime of gegevensverlies voor uw organisatie begrijpt.To derive these values, conduct a risk assessment and make sure you understand the cost and risk of downtime or data loss in your organization.

    Notitie

    Als de MTTR van een kritiek onderdeel in een hoog beschikbare installatie de RTO van een systeem overschrijdt, veroorzaakt een fout in het systeem mogelijk een onacceptabele bedrijfsonderbreking.If the MTTR of any critical component in a highly available setup exceeds the system RTO, a failure in the system might cause an unacceptable business disruption. Dat betekent dat u het systeem niet binnen de gedefinieerde RTO kunt herstellen.That is, you can't restore the system within the defined RTO.

  • Stel beschikbaarheidsdoelen van workloads vast.Determine workload availability targets. Definieer doel-SLA's voor elke workload om ervoor te zorgen dat de toepassingsarchitectuur voldoet aan uw zakelijke vereisten.To ensure that application architecture meets your business requirements, define target SLAs for each workload. Houd rekening met de kosten en complexiteit van het voldoen aan de beschikbaarheidsvereisten, naast de afhankelijkheden van de toepassing.Account for the cost and complexity of meeting availability requirements, in addition to application dependencies.

  • Zorg ervoor dat u de serviceovereenkomsten begrijpt.Understand service-level agreements. In Azure beschrijft de SLA de Microsoft-toezeggingen voor uptime en connectiviteit.In Azure, the SLA describes the Microsoft commitments for uptime and connectivity. Als de SLA voor een bepaalde service 99,9% is, betekent dit dat u kunt verwachten dat de service 99,9% van de tijd beschikbaar is.If the SLA for a particular service is 99.9 percent, you should expect the service to be available 99.9 percent of the time.

    Definieer uw eigen doel-SLA's voor elke workload in uw oplossing, zodat u kunt bepalen of de architectuur voldoet aan bepaalde bedrijfsbehoeften.Define your own target SLAs for each workload in your solution, so you can determine whether the architecture meets the business requirements. Als een werkbelasting bijvoorbeeld 99,99% van de tijd in bedrijf moet zijn maar afhankelijk is van een service met een SLA van 99,9%, kan die service geen Single Point of Failure in het systeem zijn.For example, if a workload requires 99.99 percent uptime but depends on a service with a 99.9 percent SLA, that service can't be a single point of failure in the system.

Zie voor meer informatie over het ontwikkelen van vereisten voor betrouw bare toepassingen toepassings ontwerp voor tolerantie.For more information about developing requirements for reliable applications, see Application design for resiliency.

Best practices voor de architectuur gebruikenUse architectural best practices

Tijdens de architectuurfase richt u zich op implementatiemethoden die voldoen aan uw zakelijke behoeften, identificeert u zwakke punten en minimaliseert u het bereik van fouten.During the architectural phase, focus on implementing practices that meet your business requirements, identify failure points, and minimize the scope of failures.

  • Voer een foutmodusanalyse (FMA) uit.Perform a failure mode analysis (FMA). Vroeg in de ontwerpfase bouwt FMA tolerantie in een toepassing in.FMA builds resiliency into an application early in the design stage. Hiermee kunt u de typen fouten die uw toepassing mogelijk ondervindt, de mogelijke effecten van elke fout en herstelstrategieën voor die fouten bepalen.It helps you identify the types of failures your application might experience, the potential effects of each, and possible recovery strategies.

  • Maak een redundantieplan.Create a redundancy plan. Het redundantieniveau dat nodig is voor elke workload hangt af van uw zakelijke behoeften en heeft invloed op de algemene kosten van uw toepassing.The level of redundancy required for each workload depends on your business needs and factors into the overall cost of your application.

  • Ontwerp voor schaalbaarheid.Design for scalability. Een cloudtoepassing moet kunnen schalen om wijzigingen in gebruik mogelijk te maken.A cloud application must be able to scale to accommodate changes in usage. Begin met discrete onderdelen en ontwerp de toepassing zo dat de toepassing, wanneer mogelijk, automatisch reageert op wijzigingen in de werkbelasting.Begin with discrete components, and design the application to respond automatically to load changes whenever possible. Houd rekening met schaallimieten tijdens het ontwerp, zodat u in de toekomst eenvoudig kunt uitbreiden.Keep scaling limits in mind during design so you can expand easily in the future.

  • Plan voor abonnements- en servicevereisten.Plan for subscription and service requirements. U hebt mogelijk extra abonnementen nodig om genoeg resources in te richten om te voldoen aan uw zakelijke behoeften voor opslag, verbindingen, doorvoer en meer.You might need additional subscriptions to provision enough resources to meet your business requirements for storage, connections, throughput, and more.

  • Gebruik taakverdeling om aanvragen te distribueren.Use load-balancing to distribute requests. Met taakverdeling distribueert u de verzoeken van uw toepassing naar gezonde service-exemplaren door niet-gezonde exemplaren uit de rotatie te halen.Load-balancing distributes your application's requests to healthy service instances by removing unhealthy instances from rotation.

  • Implementeer tolerantie strategieën.Implement resiliency strategies. Flexibiliteit is het vermogen van een systeem om te herstellen van fouten en te kunnen blijven functioneren.Resiliency is the ability of a system to recover from failures and continue to function. Implementeer ontwerppatronen voor tolerantie, zoals kritieke resources isoleren, gebruikmaken van compenserende transacties en, wanneer mogelijk, asynchrone bewerkingen uitvoeren.Implement resiliency design patterns, such as isolating critical resources, using compensating transactions, and performing asynchronous operations whenever possible.

  • Bouw beschikbaarheids vereisten in uw ontwerp.Build availability requirements into your design. Beschikbaarheid geeft het deel van de tijd aan dat uw systeem functioneert en goed werkt.Availability is the proportion of time your system is functional and working. Neem stappen om ervoor te zorgen dat toepassingsbeschikbaarheid voldoet aan uw service level agreement.Take steps to ensure that application availability conforms to your service-level agreement. Vermijd bijvoorbeeld Single Points of Failure, verdeel workloads over doelen op serviceniveau en beperk grote aantallen gebruikers.For example, avoid single points of failure, decompose workloads by service-level objective, and throttle high-volume users.

  • Beheer uw gegevens.Manage your data. Het is van groot belang hoe u uw gegevens bewaart, repliceert en er een back-up van maakt.How you store, back up, and replicate data is critical.

    • Replicatiemethoden kiezen voor uw toepassingsgegevens.Choose replication methods for your application data. Uw toepassingsgegevens worden bewaard in verschillende gegevensarchieven en hebben mogelijk verschillende beschikbaarheidsvereisten.Your application data is stored in various data stores and might have different availability requirements. Evalueer de replicatiemethoden en -locaties voor elk type gegevensopslag om ervoor te zorgen dat deze voldoen aan uw vereisten.Evaluate the replication methods and locations for each type of data store to ensure that they satisfy your requirements.
    • Documenteer en test uw processen voor failover en failback.Document and test your failover and failback processes. Documenteer heldere instructies voor failover naar een nieuwe gegevensopslag en test deze regelmatig om ervoor te zorgen dat deze actueel en eenvoudig te volgen zijn.Clearly document instructions to fail over to a new data store, and test them regularly to make sure they are accurate and easy to follow.
    • Beveilig uw gegevens.Protect your data. Maak regelmatig een back-up van gegevens en valideer deze en zorg ervoor dat geen enkele gebruikersaccount toegang heeft tot zowel productie- als back-upgegevens.Back up and validate data regularly, and make sure no single user account has access to both production and backup data.
    • Plan voor gegevensherstel.Plan for data recovery. Zorg ervoor dat uw back-up- en replicatiestrategie gegevenshersteltijden biedt die voldoen aan uw vereisten op serviceniveau.Make sure that your backup and replication strategy provides for data recovery times that meet your service-level requirements. Houd rekening met alle typen gegevens die uw toepassing gebruikt, inclusief referentiegegevens en databases.Account for all types of data your application uses, including reference data and databases.

Azure-service afhankelijkhedenAzure service dependencies

Microsoft Azure Services zijn wereld wijd beschikbaar om uw Cloud bewerkingen op een optimaal niveau te stimuleren.Microsoft Azure services are available globally to drive your cloud operations at an optimal level. U kunt de beste regio voor uw behoeften kiezen op basis van technische en reglementaire overwegingen: service mogelijkheden, gegevens locatie, nalevings vereisten en latentie.You can choose the best region for your needs based on technical and regulatory considerations: service capabilities, data residency, compliance requirements, and latency.

Azure-Services die worden geïmplementeerd op Azure-regio's, worden weer gegeven op de pagina Azure Global Infrastructure Products .Azure services deployed to Azure regions are listed on the Azure global infrastructure products page. Zie regio's en Beschikbaarheidszones in azurevoor een beter begrip van regio's en Beschikbaarheidszones in Azure.To better understand regions and Availability Zones in Azure, see Regions and Availability Zones in Azure.

Azure-Services zijn gebouwd voor flexibiliteit, inclusief hoge Beschik baarheid en herstel na nood gevallen.Azure services are built for resiliency including high availability and disaster recovery. Er zijn geen services die afhankelijk zijn van één logisch Data Center (om afzonderlijke storings punten te voor komen).There are no services that are dependent on a single logical data center (to avoid single points of failure). Niet-regionale services die worden vermeld in Azure Global Infrastructure-producten zijn services waarvoor geen afhankelijkheid geldt voor een specifieke Azure-regio.Non-regional services listed on Azure global infrastructure products are services for which there is no dependency on a specific Azure region. Niet-regionale services worden geïmplementeerd in twee of meer regio's en als er sprake is van een regionale fout, blijft het exemplaar van de service in een andere regio het onderhoud van klanten voort.Non-regional services are deployed to two or more regions and if there is a regional failure, the instance of the service in another region continues servicing customers. Met bepaalde niet-regionale Services kunnen klanten de regio opgeven waarin de onderliggende virtuele machine (VM) waarop Service wordt uitgevoerd, wordt geïmplementeerd.Certain non-regional services enable customers to specify the region where the underlying virtual machine (VM) on which service runs will be deployed. Zo kunnen klanten met virtuele Bureau bladen van Windows bijvoorbeeld de regio locatie opgeven waar de virtuele machine zich bevindt.For example, Windows Virtual Desktop enables customers to specify the region location where the VM resides. Alle Azure-Services die klant gegevens opslaan, kunnen de klant de specifieke regio's opgeven waarin hun gegevens worden opgeslagen.All Azure services that store customer data allow the customer to specify the specific regions in which their data will be stored. De uitzonde ring is Azure Active Directory (Azure AD), die geografische plaatsing heeft (zoals europa of Noord-Amerika).The exception is Azure Active Directory (Azure AD), which has geo placement (such as Europe or North America). Voor meer informatie over locatie voor gegevens opslag raadpleegt u de locatie-toewijzing.For more information about data storage residency, see the Data residency map.

Testen met simulaties en geforceerde failoversTest with simulations and forced failovers

Voor testen op betrouwbaarheid is het nodig dat u meet hoe de end-to-end-workload presteert bij storingen die alleen zo nu en dan optreden.Testing for reliability requires measuring how the end-to-end workload performs under failure conditions that only occur intermittently.

  • Test veelvoorkomende foutscenario's door werkelijke storingen te veroorzaken of door deze te simuleren.Test for common failure scenarios by triggering actual failures or by simulating them. Gebruik tests met foutinjectie om veelvoorkomende scenario's (inclusief combinaties van fouten) en hersteltijd te testen.Use fault injection testing to test common scenarios (including combinations of failures) and recovery time.
  • Identificeer fouten die alleen onder belasting optreden.Identify failures that occur only under load. Test de piekbelasting met behulp van productiegegevens of met synthetische gegevens die zo dicht mogelijk in de buurt komen van productiegegevens, zodat u ziet hoe de toepassing zich gedraagt in echte omstandigheden.Test for peak load, using production data or synthetic data that is as close to production data as possible, to see how the application behaves under real-world conditions.
  • Voer analyses voor herstel na noodgevallen uit.Run disaster recovery drills. Zorg voor een herstelplan na noodgevallen en test het plan periodiek om er zeker van te zijn dat het werkt.Have a disaster recovery plan in place, and test it periodically to make sure it works.
  • Voer tests voor failover en failback uit.Perform failover and failback testing. Zorg ervoor dat de afhankelijke services van uw toepassingen in de juiste volgorde een failover en failback uitvoeren.Ensure that your application's dependent services fail over and fail back in the correct order.
  • Voer simulatietests uit.Run simulation tests. Als u scenario's test die in het echt ook kunnen voorkomen, ontdekt u problemen die opgelost moeten worden.Testing real-life scenarios can highlight issues that need to be addressed. Scenario's moeten beheersbaar zijn en de dagelijkse zaken niet verstoren.Scenarios should be controllable and non-disruptive to the business. Informeer het management over plannen voor simulatietests.Inform management of simulation testing plans.
  • Test statuscontroles.Test health probes. Configureer statuscontroles voor load balancers en traffic managers om te controleren op kritieke systeemonderdelen.Configure health probes for load balancers and traffic managers to check critical system components. Test deze om er zeker van te zijn dat ze op de juiste manier reageren.Test them to make sure that they respond appropriately.
  • Test bewakingssystemen.Test monitoring systems. Zorg ervoor dat bewakingssystemen op een betrouwbare manier essentiële informatie en nauwkeurige gegevens rapporteren om mogelijke problemen te identificeren.Be sure that monitoring systems are reliably reporting critical information and accurate data to help identify potential failures.
  • Neem services van derden op in testscenario's.Include third-party services in test scenarios. Test mogelijke foutpunten door storingen in services van derden en test ook het herstel.Test possible points of failure due to third-party service disruption, in addition to recovery.

Testen is een iteratief proces.Testing is an iterative process. Test de toepassing, meet het resultaat, analyseer eventuele fouten, los ze op en herhaal het proces.Test the application, measure the outcome, analyze and address any failures, and repeat the process.

Voor meer informatie over het testen op de betrouwbaarheid van een toepassing, raadpleegt u Azure-toepassingen testen op tolerantie en beschikbaarheid.For more information about testing for application reliability, see Testing Azure applications for resiliency and availability.

De toepassing consistent implementerenDeploy the application consistently

Implementatie omvat het inrichten van Azure-resources, het implementeren van toepassings code en het Toep assen van configuratie-instellingen.Deployment includes provisioning Azure resources, deploying application code, and applying configuration settings. Bij een update kan het gaan om alle drie de taken of een aantal daarvan.An update may involve all three tasks or a subset of them.

Nadat een toepassing eenmaal voor de productie is ingezet, vormen updates een mogelijke bron van storingen.After an application is deployed to production, updates are a possible source of errors. Beperk fouten met voorspelbare en herhaalbare implementatieprocessen.Minimize errors with predictable and repeatable deployment processes.

  • Automatiseer het implementatieproces van uw toepassing.Automate your application deployment process. Automatiseer zoveel mogelijk processen.Automate as many processes as possible.
  • Ontwerp uw releaseproces om beschikbaarheid te maximaliseren.Design your release process to maximize availability. Als het voor uw releaseprocessen nodig is dat uw services offline gaan tijdens de implementatie, is uw toepassing niet beschikbaar tot ze terug online komen.If your release process requires services to go offline during deployment, your application is unavailable until they come back online. Profiteer van platformfasering en productiefuncties.Take advantage of platform staging and production features. Gebruik blue-green- of canary-releases om updates te implementeren, zodat als er een fout optreedt, u de update snel kunt terugdraaien.Use blue-green or canary releases to deploy updates, so if a failure occurs, you can quickly roll back the update.
  • Zorg ervoor dat u een plan voor terugdraaiacties hebt.Have a rollback plan for deployment. Ontwerp een proces voor terugdraaiacties om uw toepassing terug te zetten naar de laatste goede versie en om downtime te minimaliseren als een implementatie mislukt.Design a rollback process to return to a last known good version and to minimize downtime if a deployment fails.
  • Registreer en controleer implementaties.Log and audit deployments. Als u gebruikmaakt van gefaseerde implementatietechnieken, wordt meer dan één versie van uw toepassing uitgevoerd in productie.If you use staged deployment techniques, more than one version of your application is running in production. Implementeer een robuuste registratiestrategie om zoveel mogelijk versiespecifieke informatie vast te leggen.Implement a robust logging strategy to capture as much version-specific information as possible.
  • Documenteer het releaseproces van de toepassing.Document the application release process. Definieer en documenteer uw releaseproces duidelijk en zorg ervoor dat het beschikbaar is voor uw gehele team.Clearly define and document your release process, and ensure that it's available to the entire operations team.

Voor meer informatie over de betrouwbaarheid en implementatie van toepassingen raadpleegt u Azure-toepassingen implementeren voor tolerantie en beschikbaarheid.For more information about application reliability and deployment, see Deploying Azure applications for resiliency and availability.

De status van de toepassing bewakenMonitor application health

Implementeer best practices voor bewaking en waarschuwingen in uw toepassing, zodat u fouten kunt detecteren en een operator kunt waarschuwen om de fouten op te lossen.Implement best practices for monitoring and alerts in your application so you can detect failures and alert an operator to fix them.

  • Implementeer statuscontroles en controlefuncties.Implement health probes and check functions. Voer deze regelmatig van buiten de toepassing uit om vermindering van de toepassingsstatus en -prestaties te identificeren.Run them regularly from outside the application to identify degradation of application health and performance.

  • Controleer langlopende werkstromen.Check long-running workflows. Als u problemen vroeg ondervangt, hoeft u geen terugdraaiactie uit te voeren voor de gehele werkstroom of meerdere compenserende acties uit te voeren.Catching issues early can minimize the need to roll back the entire workflow or to execute multiple compensating transactions.

  • Onderhoud toepassingslogboeken.Maintain application logs.

    • Registreer toepassingen in productie en op servicegrenzen.Log applications in production and at service boundaries.
    • Gebruik semantische en asynchrone logboekregistratie.Use semantic and asynchronous logging.
    • Scheid toepassingslogboeken af van auditlogboeken.Separate application logs from audit logs.
  • Meet statistieken van externe aanroepen en deel de gegevens met het toepassingsteam.Measure remote call statistics, and share the data with the application team. Als u uw bewerkingsteam een direct overzicht wilt geven van de toepassingsstatus, vat u de metrische gegevens van externe aanroepen samen, zoals latentie, doorvoer en fouten in het 99e en 95e percentiel.To give your operations team an instantaneous view into application health, summarize remote call metrics, such as latency, throughput, and errors in the 99 and 95 percentiles. Voer een statistische analyse uit van de metrische gegevens om fouten te ontdekken die binnen elk percentiel optreden.Perform statistical analysis on the metrics to uncover errors that occur within each percentile.

  • Houd tijdelijke uitzonderingen en nieuwe pogingen bij in een geschikt tijdsbestek.Track transient exceptions and retries over an appropriate time frame. Telkens meer uitzonderingen naar verloop van tijd geeft aan dat de service een probleem heeft en dat er mogelijk een storing optreedt.A trend of increasing exceptions over time indicates that the service is having an issue and may fail.

  • Stel een systeem voor vroege waarschuwingen in.Set up an early warning system. Identificeer de Key Performance Indicators van de status van een toepassing, bijvoorbeeld tijdelijke uitzonderingen en latentie in externe aanroepen, en stel daarvoor passende drempelwaarden in.Identify the key performance indicators (KPIs) of an application's health, such as transient exceptions and remote call latency, and set appropriate threshold values for each of them. Verstuur een waarschuwing wanneer de drempelwaarde is bereikt.Send an alert to operations when the threshold value is reached.

  • Werk binnen de limieten van het Azure-abonnement.Operate within Azure subscription limits. Azure-abonnementen hebben limieten voor bepaalde resourcetypen, zoals het aantal resourcegroepen, kernen en opslagaccounts.Azure subscriptions have limits on certain resource types, such as the number of resource groups, cores, and storage accounts. Houd het gebruik van resourcetypen in de gaten.Watch your use of resource types.

  • Bewaak services van derden.Monitor third-party services. Registreer uw aanroepen en stem deze af op de status van uw toepassing en registraties in diagnoselogboeken met een unieke id.Log your invocations and correlate them with your application's health and diagnostic logging using a unique identifier.

  • Train meerdere operators om de toepassing te bewaken en om handmatige herstelstappen uit te voeren.Train multiple operators to monitor the application and to perform manual recovery steps. Zorg ervoor dat er altijd één getrainde operator actief is.Make sure there is always at least one trained operator active.

Voor meer informatie over het bewaken voor toepassingsbetrouwbaarheid, raadpleegt u Status van Azure-toepassing bewaken.For more information about monitoring for application reliability, see Monitoring Azure application health.

Reageren op fouten en noodsituatiesRespond to failures and disasters

Maak een herstelplan en zorg ervoor dat het gegevensherstel dekt, evenals netwerkstoringen, fouten van afhankelijke services en regiobrede serviceonderbrekingen.Create a recovery plan, and make sure that it covers data restoration, network outages, dependent service failures, and region-wide service disruptions. Houd in uw herstelstrategie rekening met uw VM's, opslag, databases en andere Azure-platformservices.Consider your VMs, storage, databases, and other Azure platform services in your recovery strategy.

  • Plan voor interactie met de ondersteuning van Azure.Plan for Azure support interactions. Stel voordat het nodig is een proces vast om contact op te nemen met ondersteuning voor Azure.Before the need arises, establish a process for contacting Azure support.
  • Documenteer en test uw noodherstelplan.Document and test your disaster recovery plan. Schrijf een noodherstelplan dat de impact van fouten in de toepassing op uw bedrijf weerspiegelt.Write a disaster recovery plan that reflects the business impact of application failures. Automatiseer het herstelproces zoveel mogelijk en documenteer handmatige stappen.Automate the recovery process as much as possible, and document any manual steps. Test regelmatig uw noodherstelproces om het plan te valideren en te verbeteren.Regularly test your disaster recovery process to validate and improve the plan.
  • Voer indien nodig een handmatige failover uit.Fail over manually when required. Sommige systemen kunnen geen automatische failover uitvoeren. Hier is een handmatige failover vereist.Some systems can't fail over automatically and require a manual failover. Als een toepassing een failover-overschakeling uitvoert naar een secundaire regio, voert u een test voor operationele gereedheid uit.If an application fails over to a secondary region, perform an operational readiness test. Controleer of de primaire regio een gezonde status heeft en weer klaar is om verkeer te ontvangen voordat u een failback uitvoert.Verify that the primary region is healthy and ready to receive traffic again before failing back. Bepaal wat de verminderde toepassingsfunctionaliteit is en hoe de app gebruikers informeert over tijdelijke problemen.Determine what the reduced application functionality is and how the app informs users of temporary problems.
  • Bereid u voor op toepassingsfouten.Prepare for application failure. Bereid u voor op meerdere soorten fouten, inclusief fouten die automatisch worden verwerkt, fouten die leiden tot verminderde functionaliteit en fouten die ervoor zorgen dat toepassingen niet meer beschikbaar zijn.Prepare for a range of failures, including faults that are handled automatically, those that result in reduced functionality, and those that cause the application to become unavailable. De toepassing zou gebruikers moeten informeren over tijdelijke problemen.The application should inform users of temporary issues.
  • Herstellen van beschadigde gegevens.Recover from data corruption. Als er een storing optreedt in een gegevensopslag, controleert u op gegevensinconsistenties wanneer de opslag weer beschikbaar wordt, met name als de gegevens zijn gerepliceerd.If a failure happens in a data store, check for data inconsistencies when the store becomes available again, especially if the data was replicated. Herstel beschadigde gegevens vanuit een back-up.Restore corrupt data from a backup.
  • Herstellen na een netwerkstoring.Recover from a network outage. U kunt mogelijk gegevens in cache gebruiken om uw toepassing lokaal uit te voeren met verminderde functionaliteit.You might be able to use cached data to run locally with reduced application functionality. Zo niet, overweeg dan downtime van de toepassing of een failover naar een andere regio.If not, consider application downtime or fail over to another region. Sla uw gegevens in een alternatieve locatie op tot de verbinding is hersteld.Store your data in an alternate location until connectivity is restored.
  • Herstellen van een fout van een afhankelijke service.Recover from a dependent service failure. Bepaal welke functionaliteit nog beschikbaar is en hoe de toepassing moet reageren.Determine which functionality is still available and how the application should respond.
  • Herstellen van een onderhouds onderbreking voor de hele regio.Recover from a region-wide service disruption. Serviceonderbrekingen in de hele regio komen niet veel voor, maar u moet een strategie hebben om er op te reageren, vooral voor essentiële toepassingen.Region-wide service disruptions are uncommon, but you should have a strategy to address them, especially for critical applications. Mogelijk moet u de toepassing opnieuw implementeren in een andere regio of verkeer omleiden.You might be able to redeploy the application to another region or redistribute traffic.

Voor meer informatie over reageren op fouten en noodherstel, raadpleegt u Herstel na fouten en noodgevallen voor Azure-toepassingen.For more information about responding to failures and disaster recovery, see Failure and disaster recovery for Azure applications.