Entegrasyonun en tehlikeli hali, çöktüğü değil sessizce çalışmayı bıraktığı andır. Ekran hata vermez, kimse uyarı almaz ve herkes verinin aktığını varsayar.
Sorun genellikle günler sonra, bir mutabakat sırasında ortaya çıkar. O noktada biriken fark büyümüştür ve hangi kayıtların eksik olduğunu bulmak ciddi emek gerektirir.
Bu yazıda hata kuyruğu yapısını, tekrar deneme mantığını, uyarı kurallarını ve kök neden analizini anlattık.
İçindekiler
Sessiz hata neden tehlikeli?
Görünür bir hata, hemen müdahale edilir ve etkisi sınırlı kalır. Sessiz hata ise fark edilene kadar büyümeye devam eder.
Aktarılamayan her kayıt, iki sistem arasındaki farkı biraz daha açar. Bir hafta sonra bu fark yüzlerce kayda ulaşabilir.
Daha kötüsü, bu süre boyunca yanlış veriyle karar verilir. Eksik stok bilgisiyle sipariş alınır veya eksik cari bakiyeyle sevkiyat yapılır.
Düzeltme maliyeti de zamanla artar; hangi kayıtların eksik olduğunu bulmak giderek zorlaşır.
Bu nedenle izleme, entegrasyonun isteğe bağlı bir eki değil zorunlu bir parçasıdır.
Hata türleri
Entegrasyon hataları birkaç gruba ayrılır ve her grup farklı müdahale gerektirir.
Bağlantı hataları geçicidir ve genellikle kendiliğinden düzelir. Bunlarda tekrar deneme yeterli bir çözümdür.
Veri hataları ise insan müdahalesi gerektirir. Karşılığı bulunmayan bir kart kodu, kendiliğinden düzelmez.
Yetki hataları da ayrı bir gruptur; erişim bilgileri değiştiğinde tüm aktarım durur.
Kural hataları ise eşleme tanımlarındaki eksiklerden doğar ve kurgu düzeltilmeden çözülmez.
Hata kuyruğu
Başarısız olan kayıtların kaybolmaması için bir kuyruk yapısı gerekir. Bu yapı, entegrasyonun güvenlik ağıdır.
Kuyrukta bekleyen her kaydın hata nedeni saklanmalıdır. Genel bir başarısız etiketi, düzeltmeye yardımcı olmaz.
Kaydın kendisi de saklanmalıdır; böylece düzeltme sonrası yeniden gönderilebilir.
Kuyruk uzunluğu izlenmesi gereken bir göstergedir. Sürekli büyüyen bir kuyruk, çözülmeyen bir sorun demektir.
Kuyruğun düzenli boşaltılması da gerekir; birikmiş eski kayıtlar gerçek sorunu gizler.
Tekrar deneme mantığı
Geçici hatalar için otomatik tekrar deneme, çoğu sorunu insan müdahalesi olmadan çözer.
Denemeler arasındaki sürenin kademeli olarak artması önerilir. Saniyede tekrarlanan denemeler, karşı sistemi gereksiz yorar.
Deneme sayısı sınırlandırılmalıdır; sonsuz tekrar, gerçek bir hatayı sonsuza kadar gizler.
Sınıra ulaşan kayıtlar insan müdahalesi bekleyen listeye alınmalı ve uyarı üretmelidir.
Veri hatalarında ise tekrar deneme anlamsızdır; bu kayıtlar doğrudan düzeltme listesine gitmelidir.
Uyarı kuralları
Uyarıların doğru kurgulanması, izlemenin işe yarayıp yaramayacağını belirler.
Her hata için uyarı göndermek, kısa sürede tüm uyarıların göz ardı edilmesine yol açar. Bu, izlemenin en yaygın başarısızlık biçimidir.
Doğru yaklaşım, eşik değerlere göre uyarı üretmektir. Belirli sayıyı aşan hata veya belirli süre kesinti uyarı tetikler.
Kritik akışlar için ise tek bir hata bile uyarı gerektirebilir; fatura aktarımı buna örnektir.
Uyarının doğru kişiye gitmesi de şarttır; bildirim yönetimi yazısına bakabilirsiniz.
İzleme ekranı
İyi bir izleme ekranı, entegrasyonun durumunu tek bakışta gösterir ve ayrıntıya inmeyi de sağlar.
Son başarılı senkron zamanı en pratik göstergedir; bu tek bilgi, çoğu sorunu anında ortaya çıkarır.
Bekleyen kayıt sayısı da görünmelidir. Normalde sıfıra yakın olan bu sayı, sorun anında hızla yükselir.
Hata listesinin türe göre gruplanması, önceliklendirmeyi kolaylaştırır. Tek bir uzun liste okunmaz.
Ekranın günlük bakılan bir yerde olması da önemlidir; ayrı bir sayfada duran ekran unutulur.
Mutabakat kontrolleri
Hata listesi boş olsa bile veri tutarlılığı ayrıca doğrulanmalıdır. Bazı sorunlar hata üretmeden gerçekleşir.
Kayıt sayısı karşılaştırması en basit kontroldür ve günlük yapılabilir. İki taraftaki belge sayısı tutmalıdır.
Tutar toplamları da karşılaştırılmalıdır; sayı tutup tutarın tutmaması, alan eşleme hatasını gösterir.
Bakiye mutabakatı ise dönemsel yapılır ve birikmiş farkları ortaya çıkarır.
Fark bulunduğunda kaynağı araştırılmalı; elle düzeltme yapılıp geçilmesi sorunu tekrarlatır.
Kök neden analizi
Hataları tek tek düzeltmek gereklidir; ancak yeterli değildir. Aynı hata tekrarlıyorsa kök neden aranmalıdır.
Hata nedenlerinin kategorik kaydedilmesi, bu analizi mümkün kılar. Serbest metin açıklamalar gruplanamaz.
En sık görülen üç neden incelendiğinde, genellikle yapısal bir eksik ortaya çıkar.
Eksik kart tanımları buna tipik bir örnektir; çözüm, kart açma sürecine bir kontrol eklemektir.
Kök neden giderildiğinde hata sayısı kalıcı olarak düşer ve izleme yükü de azalır.
Sorumluluk ve rutin
İzlemenin işlemesi için bir sahibi olması gerekir. Herkesin sorumlu olduğu bir ekran, kimse tarafından bakılmaz.
Günlük kontrol rutini belirlenmelidir; sabah ilk iş olarak bakılan bir liste, sorunları erken yakalar.
Kontrolün ne kadar süreceği de gerçekçi olmalıdır; birkaç dakikalık bir rutin sürdürülebilir.
Yedek sorumlu tanımlanması, izin ve devir dönemlerinde takibin kopmasını önler.
Çözülemeyen sorunların kime aktarılacağı da baştan belirlenmelidir.
Dikkat edilecek noktalar
Aşırı uyarı üretmek, izlemenin en yaygın başarısızlık nedenidir; göz ardı edilen uyarılar gerçek sorunları da gizler.
Hata listesinin hiç temizlenmemesi de aynı sonucu doğurur; eski kayıtlar yeni sorunları görünmez kılar.
Yalnızca hataya bakıp mutabakat yapmamak, sessiz sapmaları kaçırmaya yol açar.
Tek tek düzeltme yapıp kök nedene bakmamak ise aynı işi sonsuza kadar tekrarlatır.
İzleme kurgusu, senkron planının ayrılmaz parçası olarak ele alınmalıdır; ERP senkronu yazısına bakın.
Sık sorulanlar
Hata listesi ne sıklıkta kontrol edilmeli?
Günlük kontrol çoğu işletme için yeterlidir; kritik akışlarda uyarı ile anlık bildirim kurulabilir.
Başarısız kayıtlar otomatik düzeltilebilir mi?
Geçici hatalarda otomatik tekrar yeterlidir; veri hataları insan müdahalesi gerektirir.
Mutabakat otomatikleştirilebilir mi?
Sayı ve tutar karşılaştırmaları otomatik üretilebilir; fark bulunduğunda inceleme insanda kalır.
Kesinti sırasında veri kaybolur mu?
Kuyruk yapısı kuruluysa kaybolmaz; on-prem agent yazısında ele aldık.
Entegrasyonda asıl risk, çöken sistem değil sessizce çalışmayı bırakan akış. İzleme kurgusu olmadan bu durum günler sonra fark ediliyor.
Son başarılı senkron zamanını her gün bakılan bir yere koyun; tek bir gösterge, sorunların çoğunu anında ortaya çıkarıyor.
Uyarıları eşik değerlere bağlayın; her hata için bildirim gönderen bir kurgu kısa sürede tamamen göz ardı ediliyor.
Mutabakat kontrolünü de ihmal etmeyin; bazı sapmalar hiç hata üretmeden gerçekleşiyor.
Tekrarlayan hatalarda kök nedene inin; tek tek düzeltme, aynı işi sonsuza kadar tekrarlatıyor.
EQLEM ekibiyle görüşerek izleme kurgunuzu planlayabilirsiniz.