Kendi kendini iyileştirecek şekilde tasarlayınDesign for self healing

Uygulamanızı hata gerçekleştiğinde kendi kendini iyileştirecek şekilde tasarlayınDesign your application to be self healing when failures occur

Dağıtılmış bir sistemde hatalar kaçınılmazdır.In a distributed system, failures happen. Donanım hatası olabilir.Hardware can fail. Ağda geçici hatalar yaşanabilir.The network can have transient failures. Nadiren de olsa bir hizmet veya bölgenin tamamında kesintiyle karşılaşılabilir, ancak bu durumlar için bile hazırlıklı olmak gerekir.Rarely, an entire service or region may experience a disruption, but even those must be planned for.

Bu nedenle, uygulamaları hata gerçekleştiğinde kendi kendini iyileştirecek şekilde tasarlayın.Therefore, design an application to be self healing when failures occur. Bunun için üç başlı bir yaklaşım gerekir:This requires a three-pronged approach:

  • Hataları algılama.Detect failures.
  • Hatalara düzgün bir şekilde yanıt verme.Respond to failures gracefully.
  • İşletimsel öngörüler elde etmek için hataları günlüğe kaydetme ve izleme.Log and monitor failures, to give operational insight.

Belirli bir hata türüne nasıl yanıt vereceğiniz, uygulamanızın kullanılabilirlik gereksinimlerine bağlı olabilir.How you respond to a particular type of failure may depend on your application's availability requirements. Örneğin, çok yüksek kullanılabilirlik gerekiyorsa bölgesel bir kesinti sırasında otomatik olarak ikincil bir bölgeye yük devretmek isteyebilirsiniz.For example, if you require very high availability, you might automatically fail over to a secondary region during a regional outage. Ancak bu, tek bölgeli bir dağıtımdan daha yüksek maliyete yol açar.However, that will incur a higher cost than a single-region deployment.

Ayrıca, genellikle nadir olan bölgesel kesintiler gibi büyük olaylardan daha fazlasını göz önünde bulundurun.Also, don't just consider big events like regional outages, which are generally rare. Ağ bağlantısı sorunları veya başarısız veritabanı bağlantıları gibi yerel, kısa süreli hatalara da en az bunlar kadar, hatta bunlardan daha çok odaklanmalısınız.You should focus as much, if not more, on handling local, short-lived failures, such as network connectivity failures or failed database connections.

ÖnerilerRecommendations

Başarısız işlemleri yeniden deneme.Retry failed operations. Anlık ağ bağlantısı kaybı, kopan bir veritabanı bağlantısı veya hizmet meşgul olduğunda yaşanan bir zaman aşımı nedeniyle geçici hatalar oluşabilir.Transient failures may occur due to momentary loss of network connectivity, a dropped database connection, or a timeout when a service is busy. Uygulamanızı yerleşik olarak geçici hataları işlemeye yönelik bir yeniden deneme mantığı içerecek şekilde tasarlayın.Build retry logic into your application to handle transient failures. Çoğu Azure hizmeti için istemci SDK’sı tarafından otomatik yeniden deneme uygulanır.For many Azure services, the client SDK implements automatic retries. Daha fazla bilgi için [geçici hata işleme] transient-fault-handling ve yeniden deneme düzeni.For more information, see Transient fault handling and the Retry pattern.

Başarısız olan uzak hizmetleri koruma (Devre Kesici).Protect failing remote services (Circuit Breaker). Geçici bir hatadan sonra yeniden deneme iyidir, ancak hata devam ederse zaten başarısız olan bir hizmeti çağrı bombardımanına tutabilirsiniz.It's good to retry after a transient failure, but if the failure persists, you can end up with too many callers hammering a failing service. Bu, istekler biriktikçe hataların zincirleme bir şekilde yayılmasına neden olabilir.This can lead to cascading failures, as requests back up. Kullanım [devre kesici düzeni] circuit-breaker hızlı (uzak çağrı gerçekleştirilmeden) başarısız bir işlem olduğunda büyük olasılıkla başarısız olacak.Use the Circuit Breaker pattern to fail fast (without making the remote call) when an operation is likely to fail.

Kritik kaynakları yalıtma (Bölme Perdesi).Isolate critical resources (Bulkhead). Bazen tek bir alt sistemdeki hatalar zincirleme bir şekilde yayılabilir.Failures in one subsystem can sometimes cascade. Böyle bir durum, hata nedeniyle iş parçacıkları veya yuvalar gibi bazı kaynaklar zamanında serbest kalmıyor ve bu da kaynak tükenmesine yol açıyorsa görülebilir.This can happen if a failure causes some resources, such as threads or sockets, not to get freed in a timely manner, leading to resource exhaustion. Bunu önlemek için sistemi yalıtılmış gruplar halinde bölümlere ayırın. Bu sayede, bir bölümdeki hata tüm sistemin çökmesine neden olmaz.To avoid this, partition a system into isolated groups, so that a failure in one partition does not bring down the entire system.

Yük dengeleme gerçekleştirme.Perform load leveling. Uygulamaların trafiğinde yaşanan ani artışlar arka uçtaki hizmetleri zor duruma sokabilir.Applications may experience sudden spikes in traffic that can overwhelm services on the backend. Bunu önlemek için [kuyruk tabanlı yük düzeyi eşitleme düzeni] load-level zaman uyumsuz olarak çalıştırmak için iş öğelerini kuyruğa.To avoid this, use the Queue-Based Load Leveling pattern to queue work items to run asynchronously. Kuyruk, yükteki çıkışları düzleştiren bir arabellek görevini görür.The queue acts as a buffer that smooths out peaks in the load.

Yük devretme.Fail over. Bir örneğe ulaşılamıyorsa başka bir örneğe yük devri gerçekleştirin.If an instance can't be reached, fail over to another instance. Web sunucusu gibi durum bilgisi olmayan öğeler için bir yük dengeleyicisinin veya trafik yöneticisinin arkasına birkaç örnek yerleştirin.For things that are stateless, like a web server, put several instances behind a load balancer or traffic manager. Veritabanı gibi durum bilgisi depolayan öğeler için çoğaltmaları kullanın ve yük devretme gerçekleştirin.For things that store state, like a database, use replicas and fail over. Veri deposuna ve bunun nasıl çoğaltıldığına bağlı olarak, uygulamanın son tutarlılık gereksinimleri olabilir.Depending on the data store and how it replicates, this may require the application to deal with eventual consistency.

Başarısız işlemleri telafi etme.Compensate failed transactions. Genel olarak, dağıtılmış işlemler farklı hizmet ve kaynaklar arasında koordinasyon gerektirdiği için bunlardan kaçının.In general, avoid distributed transactions, as they require coordination across services and resources. Bunun yerine, daha küçük ve tekil işlemlerden oluşan bir işlem oluşturun.Instead, compose an operation from smaller individual transactions. İşlem sürecin yarısında başarısız olursa, zaten tamamlanmış olan adımları geri almak için Telafi İşlemleri kullanın.If the operation fails midway through, use Compensating Transactions to undo any step that already completed.

Uzun süre çalışan işlemler için denetim noktası kullanma.Checkpoint long-running transactions. Denetim noktaları, uzun süre çalışan bir işlemin başarısız olması durumunda dayanıklılık sağlar.Checkpoints can provide resiliency if a long-running operation fails. İşlem yeniden başlatıldığında (örneğin, başka bir VM tarafından devralındığında) son denetim noktasından sürdürülebilir.When the operation restarts (for example, it is picked up by another VM), it can be resumed from the last checkpoint.

Performansı düzgün bir şekilde düşürme.Degrade gracefully. Bir soruna geçici çözüm bulamadığınız, ancak daha az olmasına rağmen kullanışlı olan işlevler sağlayabileceğiniz durumlar olabilir.Sometimes you can't work around a problem, but you can provide reduced functionality that is still useful. Bir kitap kataloğu gösteren bir uygulama düşünün.Consider an application that shows a catalog of books. Uygulama kitap kapağına ait küçük resmi alamıyorsa bunun yerine yer tutucu bir resim gösterebilir.If the application can't retrieve the thumbnail image for the cover, it might show a placeholder image. Uygulama için bazı alt sistemler kritik olmayabilir.Entire subsystems might be noncritical for the application. Örneğin, bir e-ticaret sitesinde büyük olasılıkla ürün önerilerinin gösterilmesi siparişlerin işlenmesinden daha az önemlidir.For example, in an e-commerce site, showing product recommendations is probably less critical than processing orders.

İstemcileri kısıtlama.Throttle clients. Bazen az sayıda kullanıcı aşırı miktarda yük oluşturarak diğer kullanıcılar için uygulamanızın kullanılabilirliğini azaltabilir.Sometimes a small number of users create excessive load, which can reduce your application's availability for other users. Bu durumda, istemciyi belirli bir süreliğine kısıtlayın.In this situation, throttle the client for a certain period of time. Bkz: azaltma düzeni.See the Throttling pattern.

Kötü aktörleri engelleyin.Block bad actors. Bir istemcinin kısıtlanması, kötü amaçlı olduğu anlamına gelmez.Just because you throttle a client, it doesn't mean client was acting maliciously. Yalnızca hizmet kotasını aştığı anlamına gelir.It just means the client exceeded their service quota. Ancak bir istemci tutarlı olarak hizmet kotasını aşıyor veya başka bir kötü davranış sergiliyorsa bu istemciyi engelleyebilirsiniz.But if a client consistently exceeds their quota or otherwise behaves badly, you might block them. Kullanıcının engellemesinin kaldırılmasını istemesi bir bant dışı işlemi tanımlayın.Define an out-of-band process for user to request getting unblocked.

Öncü seçimi kullanma.Use leader election. Bir görevi koordine etmeniz gerektiğinde düzenleyici seçmek için Öncü Seçimi kullanın.When you need to coordinate a task, use Leader Election to select a coordinator. Böylece, düzenleyici tek bir hata noktası olmaz.That way, the coordinator is not a single point of failure. Düzenleyici başarısız olursa, yeni bir düzenleyici seçilir.If the coordinator fails, a new one is selected. Sıfırdan öncü seçim algoritması oluşturmak yerine Zookeeper gibi kullanıma hazır bir çözümü göz önünde bulundurun.Rather than implement a leader election algorithm from scratch, consider an off-the-shelf solution such as Zookeeper.

Hata ekleme ile test etme.Test with fault injection. Çoğu zaman başarıya giden yollar iyi test edilse de başarısızlığa giden yollar pek test edilmez.All too often, the success path is well tested but not the failure path. Bir sistem, başarısızlığa neden olan bir yöntem uygulanmadan önce üretimde uzun süre çalışabilir.A system could run in production for a long time before a failure path is exercised. Sistemin hatalara karşı dayanıklılığını, gerçek hatalar tetikleyerek veya bunların benzetimini yaparak test etmek için hata ekleme yöntemini kullanın.Use fault injection to test the resiliency of the system to failures, either by triggering actual failures or by simulating them.

Kaos mühendisliğini benimseme.Embrace chaos engineering. Kaos mühendisliği, üretim örneklerine rastgele hatalar ve anormal koşullar ekleyerek hata ekleme kavramının sınırlarını genişletir.Chaos engineering extends the notion of fault injection, by randomly injecting failures or abnormal conditions into production instances.

Uygulamalarınızı kendi kendini iyileştirebilir hale getirmeye yönelik yapılandırılmış bir yaklaşım için bkz. Azure için dayanıklı uygulamalar tasarlama.For a structured approach to making your applications self healing, see Design resilient applications for Azure.