Ters gidebilecek her şey ters gidecektir.

1. Bölüm: Giriş (bu)
2. Bölüm: Geleneksel Mühendislik — Mimari modeller
3. Bölüm: Geleneksel Mühendislik — Programlama modelleri

Herhangi bir tür hizmet oluştururken, kullanım ömrü boyunca pek çok şey ters gidebilir; bu, tipik geliştirici hatalarından bir veri merkezinin çevrimdışı duruma geçmesi gibi siyah kuğu olaylarına kadar uzanır.

Sistemin karmaşıklığına ve içerdiği hatalara bakıldığında, aşağıdaki grafikte, bir tarafta başarısızlık olasılığımız, diğer tarafta ise en muhtemelden en aza doğru sırayla tanımlanan sıralamamız var.

Soldan sağa gidersek, en olası hatalara sahibiz: 1 hata, genel geliştirici hataları, geçici hatalar, kaynak yetersizliği vb . tekrar" veya "düzeltmesi için bu kişiyi arayın".

Ve son olarak, beklemediğimiz ve birdenbire ortaya çıkan bilinmeyen şeyler.

Yukarıdaki 3 kategori, aşağıdaki (kapsamlı olmayan liste) “düzeltmelere” ayrılabilir.

1. Geleneksel Mühendislik

• mimari desenler
• Programlama kalıpları
• Kodlama standartları
• Test yapmak

• Metrikler, Günlükler ve Uyarılar
• Özellik İşaretleme
• Kanarya Testi
• Belgeler
• Çağrı üzerine rotasyon
• kendi kendini iyileştirme
• otopsi

• Kaos Mühendisliği
• Ters Çalışma Süresi

Zarif bozulma

Bozulmuş bir durumda koşmak neredeyse her zaman hiç koşmamaktan daha iyidir.

Esneklik literatürünün ve düşüncesinin büyük bir kısmı, Zarif bozulma etrafında gelişir.

Hasat ( teknik inceleme burada )

Hasat , belirli bir sorgunun işlevi Data available / Total dataveya başka bir deyişle doğruluğudur .

Diyelim ki 100 veri bölümünden oluşan bir arama motorumuz var.

1 bölüm çökerse, %99'luk bir hasadımız olur ve bu çoğu durumda gayet iyi olur.

Bozulmuş bir durumda çalıştırma, Fallback modeli veya fallback yolları olarak da adlandırılabileceği için yakından ilişkilidir.

Başarısız olan bağımlılıklar için akıllı geri dönüş yolları kullanarak ve hizmetinizin bir hatayla karşı karşıya kalmamasını sağlayarak, yine de kullanıcılarınıza/yukarı bağımlı bağımlılarınıza sorgular sunabilirsiniz.

Kısacası, kullanıcı hiç deneyim yaşamamaktansa bir deneyim yaşamayı tercih eder.

Durum bilgisi olan ve Durum bilgisi olmayan hizmet dayanıklılığı

devlet nedir?

Basit bir sayma uygulaması düşünün;

Ya mevcut sayımı hafızasında tutabilir, bu durum bilgisi olan bir uygulama olarak kabul edilir.

Veya

Mevcut sayımı bir veritabanında tutabilir, bu durum bilgisi olmayan bir uygulama olacaktır.

Ancak bu, hizmetiniz bir şeyleri bir veritabanına kaydediyorsa, bunun durum bilgisi olmadığı anlamına gelmez.

Uzun süre çalışan çok adımlı hesaplamalar yapan bir uygulamanız olabilir, durum uygulama tarafından yönetildiği için bu durum bilgisi olan bir uygulama olarak kabul edilir.

Böyle bir uygulama için esneklik göz önüne alındığında olabilecek en kötü şey, hizmetin bir adımın ortasında uyarı vermeden kapatılmasıdır.

Hesap adımlarını veya ara hesaplamaları takip ederek ve bu durumu devam ettirerek, böyle bir senaryoyu ele almanın bir yolu olabilir.

Son derece güvenilir uygulamalar tasarlarken ve geliştirirken dikkate alınması gereken soru

• Uygulamanız için hangi güvenilirlik hedeflerini ve ölçümlerini tanımladınız?
• Uygulama mimarinizin hatalara karşı dirençli olmasını nasıl sağladınız?
• Hedeflenen bölgelerde gerekli kapasite ve hizmetlerin mevcut olmasını nasıl sağladınız?
• Bu iş yükü için olağanüstü durum kurtarmayla nasıl başa çıkıyorsunuz?
• Uygulama platformunun güvenilirlik gereksinimlerinizi karşılamasını sağlamak için hangi kararlar alındı?
• Veri platformunun güvenilirlik gereksinimlerinizi karşılamasını sağlamak için hangi kararlar alındı?
• Uygulama mantığınız istisnaları ve hataları nasıl ele alıyor?
• Ağ ve bağlantının güvenilirlik gereksinimlerinizi karşılamasını sağlamak için hangi kararlar alındı?
• Ölçeklenebilirlik ve performans için hangi güvenilirlik ödeneklerini yaptınız?
• Güvenlik için hangi güvenilirlik ödeneklerini yaptınız?
• Hataya dayanıklı olduğundan emin olmak için uygulamayı nasıl test edersiniz?
• Uygulama durumunu nasıl izler ve ölçersiniz?