Cevap.

Soru geçmişi

Mikroservis mimarilerine ve dağıtık sistemlere geçişle birlikte, servisler arasındaki etkileşimlerde ortaya çıkma olasılığı yüksek hatalar ve bunların işlenmesi zorlaşıyor. Önceki yaklaşımlar genellikle ağ etkileşiminin kararsızlığını dikkate almamış, bu da üretim ortamında büyük çaplı olaylara yol açmıştır.

Sorun

Ana sorun, karmaşık arıza senaryoları, servislerin degrade olması ve entegrasyon hatalarıyla ilgili yeterince yapılandırılmamış gereksinimlerdir. Bu nedenle, geliştiriciler hataları işlemek için kendi takdirlerine göre kararlar almak zorunda kalmakta, bu da durumların çeşitliliğine ve test etme zorluklarına yol açmaktadır.

Çözüm

Hataların etkili bir şekilde tanımlanması şunları içermelidir:

• Hata türlerinin belirlenmesi (ağ kesintileri, zaman aşımı, üçüncü taraf hizmetlerinin başarısızlığı, iş mantığı hataları, veri tutarsızlığı).
• Her hata türü için tepki seçeneklerinin yazılması: deneme tekrarları, işlem geri alma, işlevsellikte azalma, uyarılar, kullanıcı mesajları.
• Arıza test etme için net senaryolar oluşturulması (fail-over, nazik degrade olma), genel ve zincirleme olayları içermek üzere.
• Hata sözleşmelerinin ve hata formatlarının belgelenmesi (örneğin, standart JSON hata yanıtı sözleşmesi).

Ana özellikler:

• Servisler arasında hata işleme şablonlarının standartlaştırılması.
• Degrasyon senaryolarının doğrulanması ve iş ile uyumlandırılması.
• Hataların izlenmesi ve olayların sonraki analizleri için günlüklerin tutulması.

Kandırmaca soruları.

Hataların teknik işlenişini gereksinimlerde tanımlamak zorunlu mu — bu geliştiricinin görevi değil mi?

Zorunludur. Hata işleme politikası dikkate alınmadığında, çalışmada hatalara ve yanlış anlamalara yol açar. Sistem analistinin hatalardaki davranışları dile getirmesi gerekmektedir.

Son derece nadir meydana gelen durumları (örneğin, servisler arasında kısmi bağlantı kaybı) tanımlamak gerekiyor mu?

Evet, çünkü nadir meydana gelen hatalar en karmaşık olaylara yol açar. Sonuçları iş için kritik olabilir.

Hatalar sırasında kullanıcıya gösterilecek mesajların iş ile onaylanması gerekiyor mu?

Evet. Doğru, bilgilendirici ancak aşırı veya korkutucu olmayan mesajlar, iş ile onaylanmalıdır; aksi takdirde kullanıcı deneyimi ve sadakati zarar görür.

Tipik hatalar ve anti-patentler

• Sadece mutlu yolun tanımlanması, arıza senaryolarının göz ardı edilmesi.
• Sistemin degrade olmasının dikkate alınmaması (yedek senaryolar tanımlanmamış).
• Kullanıcı için uyumsuz veya teknik olarak karmaşık hata mesajları.

Hayattan bir örnek

Olumsuz durum: Projede servisler arasındaki zaman aşımı işleme senaryoları tanımlanmamıştı. Sonuç olarak, kararsız ağ nedeniyle servisler cevap veremedi. Artılar: Ana senaryoların hızlı işlenmesi. Eksiler: Prodüksiyon ortamında büyük çaplı aksaklıklar, müşterilerden olumsuz geri dönüş, "manuel" olay kapatma.

Pozitif durum: Analist degrade ve yeniden başlatma senaryolarını, tekrarların ve doğru mesajların tanımlanmasını yaptı. Artılar: Aksaklıklar sırasında yüksek hizmet kararlılığı, kaza sayısında azalma. Eksiler: Senaryo mimarisi üzerinde daha fazla zaman harcama.