Cevap.

Dağıtık BT sistemlerinin gelişiminde hata işlemenin ve arıza senaryolarının sorunları uzun süre ikincil bir rol oynamıştır, iş mantığına yer açmıştır. Ancak, ölçeklerin artması ve altyapının karmaşıklaşması, zamanla tam işlenmemiş hata işlemlerinin geniş çaplı arızalara ve veri kaybına yol açtığını göstermiştir.

Sorun, karmaşık sistemlerin birçok hata türüne maruz kalmasıdır: bireysel hizmetlerin kullanılmamasından veri tutarsızlıklarına veya iletişim kanallarının kısmi arızalarına kadar. Genellikle müşteriler "arayüz arızalarını" sadece belirgin arızalarla (örneğin, sunucu erişilemez) anlamaktadırlar, hizmetler arası hata zincirlerini veya kullanıcı deneyiminin bozulmasını göz ardı ederler.

Etkili bir çözüm, sistematik bir yaklaşım üzerine kuruludur:

Tüm mümkün arıza noktalarının saptanması.
Mimarlar, QA, tasarımcılar ve işletim mühendisleri ile birlikte bu noktaların ortaya çıkma senaryolarının kapsamlı bir şekilde geliştirilmesi.
İşle sistemin davranışının iş ile uzlaştırılması (örneğin, siparişlerin ertelenip ertelenemeyeceği veya işlemlerin önbelleğe alınıp alınamayacağı).
Hata mesajlarının ve işleme yollarının tüm türlerinin net bir belgelenmesi.

Temel özellikler:

Sadece ölümcül değil, aynı zamanda yumuşak/yüzer hataların da işlenmesi (örneğin, dış hizmetin geçici olarak kullanılamaması).
UI ve işlevsellikteki bozulma senaryolarının dahil edilmesi.
İş hata ve teknik arızaların gereksinimlerin işlenmesi aşamasında ayrıştırılması.

Kandırma Soruları.

Uygulama düzeyindeki istisna ile altyapı düzeyindeki istisna arasındaki fark nedir?

Genellikle adaylar, iş hatalarını (örneğin, "kullanıcı bulunamadı") gerçek arızalarla (örneğin, "veritabanı erişilemez") karıştırmaktadır. Uygulama her zaman iki istisna türünü net bir şekilde ayırmalı ve farklı işleme stratejileri (geri alma, bildirimler, alarm) sağlamalıdır.

Hangi arıza senaryoları iç API için modellenmeli, eğer kamuya açık değilse?

Arıza senaryoları, herhangi bir API için geçerlidir: API içsel olsa bile, her zaman arızalar mümkündür (bir otomasyon çevresinin içinde bile), ve güvenilir/eksik verilerle çalışırken bunları açıkça modellemek gerekir.

Sistem, en iyi kullanıcı deneyimi için tüm hataları kullanıcıdan gizlemeli midir?

Hayır, hataların tamamen gizlenmesi kullanıcıyı yanılgıya düşürmektedir. Kullanıcının ne yapması gerektiğini anlaması için bilgilendirme ile güvenlik arasında bir denge bulunması önemlidir (uygulama detaylarının açığa çıkarılmadan).

Tipik Hatalar ve Antipatternler

Şekilsiz hata işleme ("varsayılan" catch'lerin bırakılması).
Kısmi hatalarda bozulma senaryolarının olmaması (mikro hizmetler örneğinde — çalışmayan sepet tamamen sipariş verimini engeller).
"Saklanan" hataların birikiminin göz ardı edilmesi (istisnai durumlar için bir alarm/izleme yok).

Gerçek Hayattan Örnek

Olumsuz durum: Büyük bir e-ticaret projesinde bir sistem analisti tüm ağ hatalarının işlevselliği mimariye bırakmıştır. Acil güncellemeler ve e-posta hizmetinin arızasında sistem sipariş bildirimlerini iletemedi ve kullanıcılar siparişlerinin oluşturulup oluşturulmadığını anlayamadılar.

Artılar:

Gereksinimlerin açıklamasının basitleştirilmesi.

Eksiler:

Veri kaybı (siparişin oluşturulduğunu kanıtlamak imkansızdır).
Ürün lansmanından sonra destek maliyetleri arttı.

Olumlu durum: Sistem analisti mimar ile birlikte her kritik hizmet için ayrı senaryolar modeli: e-posta kuyruğunun kullanılamaması, ödeme geçitlerinin düşmesi, arama hizmetinin bozulması. Müşteriler için kullanıcı dostu mesajlar yazıldı.