Entegrasyon hatalarını kullanıcı şikâyetinden önce görmek

Örnek bir iş senaryosu

Sipariş aktarımı her beş dakikada bir çalışıyor fakat belirli bir ürün eşleşmediği için bazı siparişler atlanıyor olsun. Genel görev başarılı görünürken iş kaybı yaşanabilir. Başarılı, başarısız ve bekleyen kayıt sayıları ayrı raporlanmalıdır. Hatanın ilgili siparişe bağlantısı olmalı; personel uzun teknik günlükler içinde kimlik aramak zorunda kalmamalıdır.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

İzleme ekranının amacı teknik günlükleri olduğu gibi kullanıcıya dökmek değildir. İşe etkisi anlaşılır olmalıdır: üç sipariş aktarılmadı, bir stok güncellemesi bekliyor veya bağlantı yetkisi sona erdi gibi. Ayrıntılı teknik hata yetkili ekip için erişilebilir kalabilir. Aynı hata yüzlerce kez tekrarlandığında tek olay altında gruplanması bildirim gürültüsünü azaltır. Çözüm sonrası yalnızca uyarıyı kapatmakla yetinmeyin; etkilenen kayıtların gerçekten işlendiğini kontrol edin. Bir hata tekrar oluşursa önceki çözüm notu yardımcı olur. Böylece destek süreci kişisel hafızaya değil, gözden geçirilebilir olay kayıtlarına dayanır.

Bağlantıyı zor koşullarda doğrulama

Entegrasyon denemesine başarılı tek bir kayıtla başlayın, ardından kontrollü olarak hata koşulları ekleyin. Eksik zorunlu alan, bilinmeyen ürün kimliği, aynı olayın tekrarı ve geçici bağlantı kesintisi iyi örneklerdir. Her senaryoda beklenen sonucu önceden yazın. Hangi kayıt tekrar denenecek, hangisi insan incelemesine düşecek ve hangisi reddedilecek açık olmalıdır. İşlem günlüğünde kaynak kimlik ile hedef kayıt arasında bağlantı bulunmalıdır. Böylece sorun araştırılırken farklı sistemlerde aynı işin peşinden gidilebilir. Test anahtarları ve üretim anahtarları birbirinden ayrı tutulmalıdır.

Yeniden deneme politikasını dış servisin kurallarıyla uyumlu tasarlayın. Her hatayı aynı hızla tekrar göndermek kota sınırına takılabilir ve diğer işlerin de gecikmesine neden olabilir. Geçici bağlantı hatasıyla kalıcı veri hatası farklı davranış gerektirir. Kuyruğun en eski kaydı ve toplam bekleyen iş sayısı birlikte izlenmelidir. Az sayıda çok eski kayıt sessiz bir soruna işaret edebilir. Başarılı kaydın tekrar işlenmemesi kadar yarım kalan işlemin güvenli devamı da önemlidir. Bu nedenle işlem durumları yalnızca başarılı ve başarısız ikilisinden daha ayrıntılı olabilir.

İş birimi için okunabilir bir hata ekranı hazırlayın. Teknik hata kodunun yanında etkilenen kayıt, yapılabilecek işlem ve sorumlu ekip yer alsın. API sırları, parolalar ve gereksiz kişisel bilgiler günlüklerde bulunmamalıdır. Saklanan teknik kayıtların erişimi ve süresi belirlenmelidir. Canlıya geçmeden önce bağlantı kesildiğinde işin nasıl sürdürüleceğini de konuşun. Manuel işlem gerekiyorsa daha sonra senkronizasyon sırasında mükerrer oluşmaması için bu kayıtların işaretlenmesi gerekir. Başarı ölçütü yalnızca isteklerin yanıt alması değil, hedef işin doğru ve bir kez tamamlanmasıdır.

Ekibinize sorabileceğiniz sorular

• En eski bekleyen işlem kaç saatlik?
• Hata kaydı iş kaydına bağlı mı?
• Uyarıyı alan kişinin yapacağı işlem belli mi?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.