Güvenilir Azure uygulamaları tasarlamaDesigning reliable Azure applications

Bulutta güvenilir bir uygulama oluşturma, geleneksel uygulama geliştirme süreçlerinden farklıdır.Building a reliable application in the cloud is different from traditional application development. Geçmişte ölçek artırmak için pahalı donanımlar satın almış olabilirsiniz, ancak bulut ortamında ölçeği artırmak yerine genişletirsiniz.While historically you may have purchased higher-end hardware to scale up, in a cloud environment you scale out instead of up. Hedef, hataları tamamen önlemeye çalışmak yerine hata veren bir bileşenin etkilerini en aza indirmektir.Instead of trying to prevent failures altogether, the goal is to minimize the effects of a single failing component.

Güvenilir uygulamalar şu özelliklere sahiptir:Reliable applications are:

  • Dayanıklıdır ve hata durumunda düzgün bir şekilde kurtarılır, tam kurtarma gerçekleştirilmeden önce en düşük çalışmama süresi ve en az veri kaybı ile çalışmaya devam eder.Resilient and recover gracefully from failures, and they continue to function with minimal downtime and data loss before full recovery.
  • Yüksek oranda kullanılabilir (HA) durumdadır ve önemli kapalı kalma süresi yaşamadan çalışır durumda kalacak şekilde tasarlanmıştır.Highly available (HA) and run as designed in a healthy state with no significant downtime.

Bu öğelerin birlikte nasıl çalıştığını ve maliyeti nasıl etkilediğini anlamak, güvenilir bir uygulama oluşturmanın temelidir.Understanding how these elements work together — and how they affect cost — is essential to building a reliable application. Bunlar ne kadar kapalı kalma süresinin kabul edilebilir olacağını, işletmenize maliyetinin ne olacağını ve kurtarma sırasında gerekli olan işlevleri belirlemenize yardımcı olabilir.It can help you determine how much downtime is acceptable, the potential cost to your business, and which functions are necessary during a recovery.

Bu makalede Azure uygulama tasarım sürecinin her adımını güvenilir hale getirmek için yapılması gerekenler genel hatlarıyla anlatılmıştır.This article provides a brief overview of building reliability into each step of the Azure application design process. Her bölümde süreçteki belirli bir adıma güvenilirlik eklemek için yapılması gerekenleri belirten ayrıntılı makaleye bağlantı verilmiştir.Each section includes a link to an in-depth article on how to integrate reliability into that specific step in the process. Belirli Azure hizmetleri için güvenilirlik konusunda bilgi edinmek için Belirli Azure hizmetleri için dayanıklılık denetim listesini inceleyebilirsiniz.If you're looking for reliability considerations for individual Azure services, review the Resiliency checklist for specific Azure services.

Güvenilirlik odaklı oluşturmaBuild for reliability

Bu bölümde, güvenilir bir Azure uygulaması oluşturmanın altı adımı anlatılmaktadır.This section describes six steps for building a reliable Azure application. Her adımda sürecin ve terimlerin ayrıntılı bir şekilde tanımlandığı bölüme bağlantı verilmiştir.Each step links to a section that further defines the process and terms.

  1. Gereksinimleri tanımlayın. Define requirements. Ayrı iş yüklerine ve işletme ihtiyaçlarına uygun kullanılabilirlik ve kurtarma gereksinimleri belirleyin.Develop availability and recovery requirements based on decomposed workloads and business needs.
  2. Mimari en iyi yöntemlerini kullanın. Use architectural best practices. Etkisi kanıtlanmış yöntemleri uygulayın, mimarideki olası hata noktalarını tanımlayın ve uygulamanın hatalara nasıl yanıt vereceğini belirleyin.Follow proven practices, identify possible failure points in the architecture, and determine how the application will respond to failure.
  3. Simülasyonlar ve zorlamalı yük devretme işlemleriyle test edin. Test with simulations and forced failovers. Hata simülasyonu yapın, zorlamalı yük devretme tetikleyin ve bu hatalarla ilgili algılama ve kurtarma süreçlerini test edin.Simulate faults, trigger forced failovers, and test detection and recovery from these failures.
  4. Uygulamayı tutarlı bir şekilde dağıtın. Deploy the application consistently. Güvenilir ve yinelenebilir işlemleri kullanarak üretim ortamında yayımlayın.Release to production using reliable and repeatable processes.
  5. Uygulamanın durumunu izleyin. Monitor application health. Hataları algılayın, olası hata göstergelerini izleyin ve uygulamalarınızın durumunu takip edin.Detect failures, monitor indicators of potential failures, and gauge the health of your applications.
  6. Hatalara ve olağanüstü durumlara yanıt verin. Respond to failures and disasters. Oluşan hataları tanımlayın ve belirlenen stratejilere göre nasıl ele alınacağını belirleyin.Identify when a failure occurs, and determine how to address it based on established strategies.

Gereksinimleri tanımlamaDefine requirements

İşletmenizin gereksinimlerini tanımlayın ve bunları ele alacak güvenilirlik planınızı oluşturun.Identify your business needs, and build your reliability plan to address them. Aşağıdaki topluluklara bir göz atın:Consider the following:

  • İş yüklerini ve kullanımı tanımlayın.Identify workloads and usage. İş yükü, iş mantığı ve veri depolama gereksinimleri açısından diğer görevlerden mantıksal olarak ayrılabilen, farklı bir özellik veya görevdir.A workload is a distinct capability or task that is logically separated from other tasks, in terms of business logic and data storage requirements. Her iş yükü kullanılabilirlik, ölçeklenebilirlik, veri tutarlılığı ve olağanüstü durum kurtarma konularında farklı gereksinimleri olabilir.Each workload has different requirements for availability, scalability, data consistency, and disaster recovery.

  • Kullanım biçimlerine göre plan yapın.Plan for usage patterns. Kullanım biçimleri de gereksinimler açısından önemli bir rol oynar.Usage patterns also play a role in requirements. Kritik ve kritik olmayan dönemlerdeki gereksinimler arasındaki farkları tanımlayın.Identify differences in requirements during critical and non-critical periods. Örneğin bir vergi iade uygulamasının iadelerin son gününde hata vermemesi gerekir.For example, a tax-filing application can't fail during a filing deadline. Bölgelerden birinde hata oluşması durumunda uygulamanın çalışır durumda kalmasını sağlamak için birden fazla bölgeye yayılan bir yedeklilik planı yapın.To ensure uptime, plan redundancy across several regions in case one fails. Diğer taraftan kritik olmayan dönemlerde maliyetleri en aza indirmek için uygulamanızı tek bir bölgede çalıştırabilirsiniz.Conversely, to minimize costs during non-critical periods, you can run your application in a single region.

  • Ortalama kurtarma süresi (MTTR) ve hatalar arasındaki ortalama süre (MTBF) olmak üzere kullanılabilirlik ölçümlerini belirleyin.Establish availability metrics — mean time to recovery (MTTR) and mean time between failures (MTBF). MTTR, hata sonrasında bir bileşeni geri yüklemek için gereken ortalama süredir.MTTR is the average time it takes to restore a component after a failure. MTBF, bileşenin kesintiler arasında çalışmaya devam etmesi beklenebilecek çalışma zamanıdır.MTBF is how long a component can reasonably expect to last between outages. Bu ölçümleri kullanarak yedeklilik eklenmesi gereken noktaları ve müşteriler için hizmet düzeyi sözleşmelerini (SLA) belirleyebilirsiniz.Use these measures to determine where to add redundancy and to determine service-level agreements (SLAs) for customers.

  • Kurtarma süresi hedefi ve kurtarma noktası hedefi (RPO) kurtarma olmak üzere kurtarma ölçümlerini belirleyin.Establish recovery metrics — recovery time objective and recovery point objective (RPO). RTO, bir olay sonrasında uygulamanın kullanılamıyor olmasının kabul edilebileceği en uzun süredir.RTO is the maximum acceptable time an application can be unavailable after an incident. RPO, olağanüstü bir durum sırasında en uzun ne kadar sürelik veri kaybının kabul edilebilir olduğudur.RPO is the maximum duration of data loss that is acceptable during a disaster. Bu değerleri elde etmek için risk değerlendirmesi yapın ve kuruluşunuzdaki kapalı kalma süresi veya veri kaybı maliyetini ve riskini anladığınızdan emin olun.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.

    Not

    Yüksek oranda kullanılabilir düzenlerde herhangi bir kritik bileşenin MTTR değerinin sistem RTO değerinden yüksek olması halinde sistemde hata oluşması, kabul edilemeyecek düzeyde iş kesintisine neden olabilir.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. Başka bir deyişle tanımlanan RTO içinde sistemi geri yüklemek mümkün olmaz.That is, you can't restore the system within the defined RTO.

  • İş yükü kullanılabilirlik hedeflerini belirleyin.Determine workload availability targets. Uygulama mimarisinin iş gereksinimlerinize uygun olduğundan emin olmak için her iş yükü için hedef SLA'ları tanımlayın.To ensure that application architecture meets your business requirements, define target SLAs for each workload. Uygulama bağımlılıklarına ek olarak kullanılabilirlik gereksinimlerinin maliyetini ve karmaşıklığını da hesaba katın.Account for the cost and complexity of meeting availability requirements, in addition to application dependencies.

  • Hizmet düzeyi sözleşmelerini anlayın.Understand service-level agreements. Azure’da SLA, Microsoft’un çalışma süresi ve bağlantı hakkındaki taahhütlerini belirtir.In Azure, the SLA describes the Microsoft commitments for uptime and connectivity. Belirli bir hizmet için SLA yüzde 99,9 ise hizmetin zamanın yüzde 99,9’unda kullanılabilir durumda olmasını bekleyebilirsiniz.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.

    Mimarinin işletme gereksinimlerini karşılayıp karşılamadığını belirlemek için çözümünüzdeki her iş yükü için kendi hedef SLA'larınızı tanımlayın.Define your own target SLAs for each workload in your solution, so you can determine whether the architecture meets the business requirements. Örneğin, bir iş yükü için yüzde 99,99 çalışma süresi gerekliyse ancak bu iş yükü SLA’sı yüzde 99,9 olan bir hizmete bağlıysa, söz konusu hizmet sistemde tek hata noktası konumunda olamaz.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.

Güvenilir uygulamalar için geliştirme gereksinimleri hakkında daha fazla bilgi için bkz. Dayanıklı Azure uygulamaları için geliştirme gereksinimleri.For more information about developing requirements for reliable applications, see Developing requirements for resilient Azure applications.

Mimari en iyi yöntemleri kullanmaUse architectural best practices

Mimari aşamasında işletme gereksinimlerinizi karşılayan, hata noktalarını tanımlayan ve hata kapsamını en aza indiren yöntemleri uygulamaya odaklanın.During the architectural phase, focus on implementing practices that meet your business requirements, identify failure points, and minimize the scope of failures.

  • Hata modu analizi (FMA) gerçekleştirin.Perform a failure mode analysis (FMA). FMA, tasarım aşamasının başında uygulamaya dayanıklılık katar.FMA builds resiliency into an application early in the design stage. Uygulamanızın karşı karşıya kalabileceği hata türlerini, her birinin olası etkilerini ve olası kurtarma stratejilerini tanımlamanıza yardımcı olur.It helps you identify the types of failures your application might experience, the potential effects of each, and possible recovery strategies.

  • Yedeklilik planı oluşturun.Create a redundancy plan. Her iş yükü için gerekli yedeklilik düzeyi, işletme gereksinimlerine göre değişir ve uygulamanızın genel maliyetini etkiler.The level of redundancy required for each workload depends on your business needs and factors into the overall cost of your application.

  • Ölçeklenebilirlik için tasarlayın.Design for scalability. Bulut uygulamalarının kullanımdaki değişiklikleri karşılayacak şekilde ölçeklendirilebilmesi gerekir.A cloud application must be able to scale to accommodate changes in usage. Ayrı bileşenlerle başlayın ve uygulamayı, yük değişikliklerine otomatik olarak yanıt verecek şekilde tasarlayın.Begin with discrete components, and design the application to respond automatically to load changes whenever possible. Uygulamayı ileride kolayca genişletebilmek için tasarım aşamasında ölçeklendirme sınırlarını göz önünde bulundurun.Keep scaling limits in mind during design so you can expand easily in the future.

  • Abonelik ve hizmet gereksinimlerine göre plan yapın.Plan for subscription and service requirements. Depolama, bağlantılar, aktarım hızı ve farklı birçok bileşen için işletme gereksinimlerinizi karşılamak üzere yeterli kaynak sağlama amacıyla ek aboneliklere ihtiyaç duyabilirsiniz.You might need additional subscriptions to provision enough resources to meet your business requirements for storage, connections, throughput, and more.

  • İstekleri dağıtmak için yük dengeleme özelliğinden faydalanın.Use load-balancing to distribute requests. Yük dengeleme, uygulamanızın isteklerini iyi durumdaki hizmet örneklerine dağıtır ve iyi durumda olmayan örnekleri sistemden çıkarır.Load-balancing distributes your application's requests to healthy service instances by removing unhealthy instances from rotation.

  • Dayanıklılık stratejileri uygulayın.Implement resiliency strategies. Dayanıklılık, bir sistemin hatalardan kurtularak çalışmaya devam edebilme özelliğidir.Resiliency is the ability of a system to recover from failures and continue to function. Mümkün olduğunda kritik kaynakları yalıtma, telafi işlemleri kullanma ve zaman uyumsuz işlemler gerçekleştirme gibi dayanıklılık odaklı tasarım düzenleri uygulayın.Implement resiliency design patterns, such as isolating critical resources, using compensating transactions, and performing asynchronous operations whenever possible.

  • Kullanılabilirlik gereksinimlerini tasarımınıza dahil edin.Build availability requirements into your design. Kullanılabilirlik, sisteminizin iş görür ve çalışır olduğu sürenin oranıdır.Availability is the proportion of time your system is functional and working. Uygulama kullanılabilirliğinin hizmet düzeyi sözleşmenize uygun olmasını sağlamak için gerekli adımları atın.Take steps to ensure that application availability conforms to your service-level agreement. Örneğin tek hata noktalarından kaçının, iş yüklerini hizmet düzeyi hedefine göre parçalara ayırın ve yüksek hacimli kullanıcılara kısıtlama uygulayın.For example, avoid single points of failure, decompose workloads by service-level objective, and throttle high-volume users.

  • Verilerinizi yönetin.Manage your data. Verileri depolama, yedekleme ve çoğaltma yöntemleriniz kritik öneme sahiptir.How you store, back up, and replicate data is critical.

    • Uygulamanızın verileri için çoğaltma yöntemlerini belirleyin.Choose replication methods for your application data. Uygulamanızın verileri, farklı veri depolarında depolanır ve kullanılabilirlik gereksinimleri de farklı olabilir.Your application data is stored in various data stores and might have different availability requirements. Gereksinimlerinizi karşıladığından emin olmak için her bir veri deposu türü için çoğaltma yöntemlerini ve konumlarını değerlendirin.Evaluate the replication methods and locations for each type of data store to ensure that they satisfy your requirements.
    • Yük devretme ve yeniden çalışma işlemlerinizi belgeleyin ve test edin.Document and test your failover and failback processes. Yeni veri deposuna yük devretme yönergelerini net bir şekilde belgeleyin ve düzenli olarak test ederek sürecin doğru ve uygulaması kolay olduğundan emin olun.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.
    • Verilerinizi koruyun.Protect your data. Verileri düzenli olarak yedekleyip doğrulayın ve hem üretim hem de yedekleme verilerine erişimi olan tek bir kullanıcı hesabı olmadığından emin olun.Back up and validate data regularly, and make sure no single user account has access to both production and backup data.
    • Veri kurtarma planı yapın.Plan for data recovery. Yedekleme ve çoğaltma stratejinizin hizmet düzeyi sözleşmelerinize uygun veri kurtarma süresine sahip olduğundan emin olun.Make sure that your backup and replication strategy provides for data recovery times that meet your service-level requirements. Başvuru verileri ve veritabanları dahil olmak üzere uygulamanızın kullandığı tüm veri türlerini dikkate alın.Account for all types of data your application uses, including reference data and databases.

Güvenilir uygulama mimarisi oluşturma hakkında daha fazla bilgi için bkz. Dayanıklı ve kullanılabilir Azure uygulaması mimarileri oluşturma.For more information about architecting reliable applications, see Architecting Azure applications for resiliency and availability.

Simülasyonlar ve zorlamalı yük devretme işlemleriyle test etmeTest with simulations and forced failovers

Güvenilirlik testi için yalnızca zaman zaman ortaya çıkan hata koşulları altında uçtan uca iş yükünün göstereceği performansı test etmeniz gerekir.Testing for reliability requires measuring how the end-to-end workload performs under failure conditions that only occur intermittently.

  • Gerçek hataları tetikleyerek veya bunların simülasyonunu yaparak yaygın hata senaryoları için test edin.Test for common failure scenarios by triggering actual failures or by simulating them. Yaygın senaryoları (farklı hataların bir arada olduğu senaryolar dahil) test ve kurtarma süresini test etmek için hata ekleme testi yöntemini kullanın.Use fault injection testing to test common scenarios (including combinations of failures) and recovery time.
  • Yalnızca yük altında ortaya çıkan hataları tanımlayın.Identify failures that occur only under load. Uygulamanın gerçek dünya koşullarında nasıl çalıştığını görmek için üretim verileri veya üretim verilerine mümkün olduğunca yakın yapay veriler kullanarak en üst düzeydeki yük miktarıyla test edin.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.
  • Olağanüstü durum kurtarma alıştırmaları yapın.Run disaster recovery drills. Olağanüstü durum kurtarma planı oluşturun ve düzenli aralıklarla test ederek çalıştığından emin olun.Have a disaster recovery plan in place, and test it periodically to make sure it works.
  • Yük devretme ve yeniden çalışma testi gerçekleştirin.Perform failover and failback testing. Uygulamanızın bağımlı olduğu hizmetlerin doğru sırada yük devretme ve yeniden çalışma gerçekleştirdiğinden emin olun.Ensure that your application's dependent services fail over and fail back in the correct order.
  • Simülasyon testleri çalıştırın.Run simulation tests. Gerçek dünya senaryolarını test ederek ele alınması gereken sorunları tespit edebilirsiniz.Testing real-life scenarios can highlight issues that need to be addressed. Senaryoların denetlenebilir ve işleri kesintiye uğratmayacak nitelikte olması gerekir.Scenarios should be controllable and non-disruptive to the business. Test planı simülasyonlarıyla ilgili yönetime bilgi verin.Inform management of simulation testing plans.
  • Sistem durumu araştırmalarını test edin.Test health probes. Kritik sistem bileşenlerini denetleme amacıyla yük dengeleyiciler ve trafik yöneticileri için sistem durumu araştırmaları yapılandırın.Configure health probes for load balancers and traffic managers to check critical system components. Bunları test ederek doğru şekilde yanıt verdiklerinden emin olun.Test them to make sure that they respond appropriately.
  • İzleme sistemlerini test edin.Test monitoring systems. İzleme sistemlerinin olası hataların tanımlanmasına yardımcı olması için kritik bilgileri ve doğru verileri güvenilir bir şekilde bildirdiğinden emin olun.Be sure that monitoring systems are reliably reporting critical information and accurate data to help identify potential failures.
  • Üçüncü taraf hizmetleri test senaryolarına dahil edin.Include third-party services in test scenarios. Üçüncü taraf hizmetlerdeki kesintilerden kaynaklanan olası hata noktalarını ve kurtarma süreçlerini test edin.Test possible points of failure due to third-party service disruption, in addition to recovery.

Test etme, yinelemeli bir işlemdir.Testing is an iterative process. Uygulamayı test edin, sonuçları ölçün, hataları analiz edip giderin ve tüm süreci yineleyin.Test the application, measure the outcome, analyze and address any failures, and repeat the process.

Uygulamanızın güvenilirliğini test etme hakkında daha fazla bilgi için bkz. Azure uygulamalarında dayanıklılık ve kullanılabilirlik testi yapma.For more information about testing for application reliability, see Testing Azure applications for resiliency and availability.

Uygulamayı tutarlı bir şekilde dağıtmaDeploy the application consistently

Dağıtıma, Azure kaynaklarının sağlanması, uygulama kodunun dağıtılması ve yapılandırma ayarlarının uygulanması dahildir.Deployment includes provisioning Azure resources, deploying application code, and applying configuration settings. Bir güncelleştirme bu görevlerin üçünü veya sadece bazılarını içerebilir.An update may involve all three tasks or a subset of them.

Uygulama üretime dağıtıldıktan sonra güncelleştirmeler olası bir hata kaynağı haline gelir.After an application is deployed to production, updates are a possible source of errors. Tahmin edilebilir ve yinelenebilir dağıtım süreçleriyle hataları en aza indirin.Minimize errors with predictable and repeatable deployment processes.

  • Uygulama dağıtım sürecinizi otomatikleştirin.Automate your application deployment process. Mümkün olduğu kadar çok süreci otomatikleştirin.Automate as many processes as possible.
  • Yayın sürecinizi kullanılabilirliği en üst düzeye çıkaracak şekilde tasarlayın.Design your release process to maximize availability. Yayın süreciniz, dağıtım sırasında hizmetlerin çevrimdışı duruma geçmesini gerektiriyorsa uygulamanız çevrimiçi duruma dönene kadar kullanım dışı kalır.If your release process requires services to go offline during deployment, your application is unavailable until they come back online. Platform hazırlama ve üretim özelliklerinden faydalanın.Take advantage of platform staging and production features. Güncelleştirmeleri dağıtmak için mavi-yeşil veya kanarya sürümlerini kullanın. Bu sayede olası hatalarda güncelleştirmeyi hızlıca geri alabilirsiniz.Use blue-green or canary releases to deploy updates, so if a failure occurs, you can quickly roll back the update.
  • Dağıtım için geri alma planı oluşturun.Have a rollback plan for deployment. Dağıtımın başarısız olması durumunda bilinen son iyi sürüme dönmek ve kesinti süresini en aza indirmek için bir geri alma süreci tasarlayın.Design a rollback process to return to a last known good version and to minimize downtime if a deployment fails.
  • Dağıtımları günlüğe kaydedin ve denetleyin.Log and audit deployments. Aşamalı dağıtım tekniklerini kullandığınızda üretim ortamında uygulamanızın birden fazla sürümü çalışır.If you use staged deployment techniques, more than one version of your application is running in production. Mümkün olduğunca çok sürüme özgü bilgi toplamak için sağlam bir günlük kaydı stratejisi uygulayın.Implement a robust logging strategy to capture as much version-specific information as possible.
  • Uygulama yayın sürecini belgeleyin.Document the application release process. Yayın sürecinizi net bir şekilde tanımlayıp belgeleyin ve operasyon ekibinin tamamının erişimine açık olduğundan emin olun.Clearly define and document your release process, and ensure that it's available to the entire operations team.

Uygulama güvenilirliği ve dağıtımı hakkında daha fazla bilgi için bkz. Dayanıklı ve kullanılabilir Azure uygulamaları dağıtma.For more information about application reliability and deployment, see Deploying Azure applications for resiliency and availability.

Uygulamanın durumunu izlemeMonitor application health

Hataları algılamak ve bir operatörü bunları onarmak üzere uyarmak için uygulamanıza izleme ve uyarı en iyi yöntemlerini dahil edin.Implement best practices for monitoring and alerts in your application so you can detect failures and alert an operator to fix them.

  • Sistem durumu araştırmaları ve denetim işlevleri ekleyin.Implement health probes and check functions. Uygulama sistem durumundaki ve performansındaki düşüşleri tanımlamak için bunları uygulamanın dışından düzenli olarak çalıştırın.Run them regularly from outside the application to identify degradation of application health and performance.

  • Uzun süreli iş akışlarını denetleyin.Check long-running workflows. Sorunları erkenden belirlemek iş akışının tamamını geriye alma veya birden fazla telafi işlemi yürütme gereksinimini ortadan kaldırabilir.Catching issues early can minimize the need to roll back the entire workflow or to execute multiple compensating transactions.

  • Uygulama günlüklerini saklayın.Maintain application logs.

    • Uygulamaların üretim ve hizmet sınırlarında günlük oluşturun.Log applications in production and at service boundaries.
    • Semantik ve zaman uyumsuz günlük kaydı yöntemlerini kullanın.Use semantic and asynchronous logging.
    • Uygulama günlüklerini denetim günlüklerinden ayırın.Separate application logs from audit logs.
  • Uzak çağrı istatistiklerini ölçün ve verileri uygulama ekibiyle paylaşın.Measure remote call statistics, and share the data with the application team. Operasyon ekibinizin, uygulamanın durumunu tek bakışta anlaması için gecikme süresi, aktarım hızı ve hataları 99 ve 95 yüzdebirlik oranda özetleyin.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. Her bir yüzdebirlik dilimde ortaya çıkan hataları belirlemek için ölçümlerde istatistiksel analiz gerçekleştirin.Perform statistical analysis on the metrics to uncover errors that occur within each percentile.

  • Uygun bir zaman diliminde gerçekleşen geçici özel durumları ve yeniden deneme işlemlerini izleyin.Track transient exceptions and retries over an appropriate time frame. Özel durumların zaman içinde artan bir eğilime sahip olması, hizmetin sorun yaşadığını ve hata verebileceğini belirtir.A trend of increasing exceptions over time indicates that the service is having an issue and may fail.

  • Erken uyarı sistemi oluşturun.Set up an early warning system. Geçici özel durumlar ve uzak çağrı gecikme süresi gibi uygulamanın durumuyla ilgili ana performans göstergelerini (KPI) tanımlayın ve her biri için uygun eşik değerleri belirleyin.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. Eşik değerine ulaşıldığında operasyon ekibine uyarı gönderin.Send an alert to operations when the threshold value is reached.

  • Azure abonelik sınırları dahilinde çalışın.Operate within Azure subscription limits. Azure aboneliklerinde kaynak grubu, çekirdek ve depolama hesabı sayısı gibi belirli kaynak türlerinde sınırlar vardır.Azure subscriptions have limits on certain resource types, such as the number of resource groups, cores, and storage accounts. Kullandığınız kaynak türlerini izleyin.Watch your use of resource types.

  • Üçüncü taraf hizmetlerini izleyin.Monitor third-party services. Yapılan çağrıları günlüğe kaydedin ve benzersiz tanıtıcı kullanarak bunları uygulamanızın durumu ve tanılama günlüğüyle ilişkilendirin.Log your invocations and correlate them with your application's health and diagnostic logging using a unique identifier.

  • Uygulamayı izlemek ve el ile kurtarma adımı gerçekleştirmek üzere birden fazla operatör eğitin.Train multiple operators to monitor the application and to perform manual recovery steps. Her zaman en az bir eğitimli operatörün etkin durumda olduğundan emin olun.Make sure there is always at least one trained operator active.

Uygulamanın güvenilirlik durumunu izleme hakkında daha fazla bilgi için bkz. Azure uygulamalarının durumunu izleme.For more information about monitoring for application reliability, see Monitoring Azure application health.

Hatalara ve olağanüstü durumlara yanıt vermeRespond to failures and disasters

Bir kurtarma planı oluşturun ve bunun verileri geri yükleme, ağ kesintileri, bağımsız hizmet hatalar ve bölge genelindeki hizmet kesintileri bileşenlerini kapsadığından emin olun.Create a recovery plan, and make sure that it covers data restoration, network outages, dependent service failures, and region-wide service disruptions. Kurtarma stratejilerinizi oluştururken VM'lerinizi, depolama alanlarınızı, veritabanlarınızı ve Azure platformundaki diğer hizmetleri göz önünde bulundurun.Consider your VMs, storage, databases, and other Azure platform services in your recovery strategy.

  • Azure desteği etkileşimleri için plan yapın.Plan for Azure support interactions. İhtiyaç duymadan önce Azure desteği ile iletişim kurmak üzere bir süreç oluşturun.Before the need arises, establish a process for contacting Azure support.
  • Olağanüstü durum kurtarma planınızı belgeleyin ve test edin.Document and test your disaster recovery plan. Uygulama hatalarının iş üzerindeki etkisini yansıtan bir olağanüstü durum kurtarma planı yazın.Write a disaster recovery plan that reflects the business impact of application failures. Kurtarma sürecini mümkün olduğunca otomatikleştirin ve el ile gerçekleştirilecek adımları belgeleyin.Automate the recovery process as much as possible, and document any manual steps. Planı doğrulamak ve geliştirmek için olağanüstü durum kurtarma sürecinizi düzenli olarak test edin.Regularly test your disaster recovery process to validate and improve the plan.
  • Gerektiğinde el ile yük devretme yapın.Fail over manually when required. Bazı sistemler otomatik olarak yük devredemez ve el ile yük devretme yapılması gerekir.Some systems can't fail over automatically and require a manual failover. Uygulamanın yükünün ikincil bölgeye devredilmesi durumunda çalışmaya hazırlık testi gerçekleştirin.If an application fails over to a secondary region, perform an operational readiness test. Yeniden çalışma öncesinde birincil bölgenin iyi durumda ve yeniden trafik almaya hazır olduğunu doğrulayın.Verify that the primary region is healthy and ready to receive traffic again before failing back. Kısıtlanan uygulama işlevlerini ve uygulamanın kullanıcılara geçici sorunları nasıl bildirdiğini belirleyin.Determine what the reduced application functionality is and how the app informs users of temporary problems.
  • Uygulama hataları için hazırlıklı olun.Prepare for application failure. Otomatik olarak işlenenler, işlevlerin kısıtlanmasına neden olanlar ve uygulamanın kullanılamaz duruma gelmesine neden olanlar dahil olmak üzere farklı hata türleri için hazırlık yapın.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. Uygulamanın kullanıcıları geçici sorunlar hakkında bilgilendirmesi gerekir.The application should inform users of temporary issues.
  • Bozulan verileri kurtarın.Recover from data corruption. Bir veri deposunda hata oluşması durumunda depo yeniden kullanılabilir hale geldiğinde, özellikle de veriler çoğaltıldıysa veri tutarsızlığı olup olmadığın kontrol edin.If a failure happens in a data store, check for data inconsistencies when the store becomes available again, especially if the data was replicated. Bozulan verileri yedekten geri yükleyin.Restore corrupt data from a backup.
  • Ağ kesintisinden kurtarın.Recover from a network outage. Önbelleğe alınmış verileri kullanarak uygulamanın yerel ortamda işlevleri kısıtlanmış bir şekilde çalıştırılmasını sağlayabilirsiniz.You might be able to use cached data to run locally with reduced application functionality. Bu mümkün değilse uygulama kapalı kalma süresini göz önünde bulundurun veya başka bir bölgeye yük devretme gerçekleştirin.If not, consider application downtime or fail over to another region. Bağlantı yeniden kurulana kadar verilerinizi alternatif bir konumda depolayın.Store your data in an alternate location until connectivity is restored.
  • Bağımlı hizmet hatasından kurtarın.Recover from a dependent service failure. Kullanılabilir durumda olan işlevleri ve uygulamanın nasıl yanıt vereceğini belirleyin.Determine which functionality is still available and how the application should respond.
  • Bölge genelinde hizmet kesintisinden kurtarın.Recover from a region-wide service disruption. Bölge genelinde hizmet kesintisi çok sık yaşanmasa da özellikle kritik uygulamalar için bunlara yönelik bir stratejiye sahip olmanız gerekir.Region-wide service disruptions are uncommon, but you should have a strategy to address them, especially for critical applications. Uygulamayı başka bir bölgeye dağıtabilir veya trafiği yeniden dağıtabilirsiniz.You might be able to redeploy the application to another region or redistribute traffic.

Hatalara yanıt verme veya olağanüstü durum kurtarma hakkında daha fazla bilgi için bkz. Azure uygulamaları için hata ve olağanüstü durum kurtarma.For more information about responding to failures and disaster recovery, see Failure and disaster recovery for Azure applications.

Sonraki adımlarNext steps