Sayfa yükleniyor
Entegrasyonlar bozulduğunda genellikle gürültü çıkarmazlar. Çalışmayı bırakırlar ve kimse bir şey duymaz. ERP ile üretim sistemi arasındaki aktarım mesai bitiminde durabilir ve durum ancak bir sonraki iş gününde fark edilir.
Bu ayrım önemli, çünkü arızanın maliyeti çoğu zaman arızanın kendisinden değil, fark edilme süresinden gelir. Aşağıdaki başlıklar, o süreyi kısaltmak için kurulan basit mekanizmalar üzerine.
Bir akış, başarısızlık durumunu hiç hata mesajı üretmeden de geçebilir. Servis ayaktadır, kuyruk boştur, kayıt dosyasında satır yoktur; çünkü tetikleyici hiç çalışmamıştır. Yalnızca hata satırlarına bakan bir izleme böyle bir durumu göremez.
İkinci sebep, sorunun karşı tarafta olmasıdır. Sağlayıcının uç noktası sessizce boş yanıt döndürmeye başlar, sizin taraf bunu geçerli bir “kayıt yok” cevabı sayar. Teknik olarak hata yoktur ama veri akmıyordur.
Sağlık kontrolünün servisin açık olduğunu söylemesi yeterli değildir. İzlenmesi gereken şey, beklenen işin beklenen sürede olup olmadığıdır: son başarılı aktarımın üzerinden geçen süre, aktarılan kayıt adedi, reddedilen kayıtların payı.
Bu ölçütlerin her biri için normal aralığı iş birimiyle birlikte belirleyin. Vardiya düzeni, hafta sonu ve tatil takvimi bu aralığı değiştirir; bunları hesaba katmayan bir kurgu kısa sürede güvenilirliğini kaybeder.
En ucuz mekanizma, her başarılı çalıştırmanın zaman damgasını tek bir tabloya yazmaktır. İzleme tarafı bu damgaya bakar ve belirlenen süre boyunca güncellenmemişse uyarı üretir. Böylece “hiç tetiklenmedi” durumu da görünür hâle gelir.
Uyarının yalnızca teknik ekibe gitmesi yetmez. İşin durduğunu ilk fark eden birim çoğu zaman sevkiyat ya da muhasebe olur; onların da bir bildirim kanalı olmalı ki iş telefon trafiği yerine ortak bir kayıt üzerinden yürüsün.
Uyarı sayısını az tutun. Her küçük dalgalanma bildirim üretirse ekip bir süre sonra bildirimleri susturur ve gerçek arıza aynı gürültünün içinde kaybolur.
Kimsenin ne yapacağını bilmediği bir mesaj uyarı sayılmaz. Her uyarının karşılığında yazılı ve tek bir ilk adım bulunmalı.
Arızaların bir kısmı geçicidir ve kendiliğinden düzelir: ağ kesintisi, kilitlenmiş kayıt, karşı tarafta anlık yoğunluk. Bunlar için yeniden deneme aralığı kademeli açılmalı; sabit aralıkla ısrar etmek zaten zorlanan tarafı daha da zorlar.
Yeniden denemenin güvenli olması, aynı kaydın iki kez işlenmemesine bağlıdır. Her mesaja tekil bir anahtar verin ve alıcı taraf aynı anahtarı ikinci kez gördüğünde işlemi tekrarlamasın.
Deneme hakkı dolduğunda kayıt kaybolmamalı, ayrı bir bekleyen kuyruğa alınmalı. Bu kuyruğun görünür bir ekranı olmalı; içinde bekleyen kayıt adedi de izlenmesi gereken ölçütlerden biridir.
İzleme akışın durduğunu söyler, mutabakat ise akan verinin eksiksiz olduğunu söyler. Bunlar farklı sorulardır ve ikisine de cevap gerekir.
Basit hâli şudur: her gün kaynak sistemdeki kayıt adedi ile hedef sistemdeki adedi aynı ölçütle karşılaştıran bir rapor üretin. Fark varsa rapor, eksik kayıtların anahtarlarını da listelemelidir; yalnızca adet farkı vermek işi çözmez.
Raporu kimsenin açmadığı bir klasöre bırakmayın. Farkın olmadığı günlerde de gönderilen kısa bir özet, raporun kendisinin çalıştığını doğrulamanın en kolay yoludur.
Her akışın tek bir sahibi olmalı ve bu kişi kurum içinden olmalı. Geliştirmeyi dış ekip yapabilir; ancak “bu durursa kim karar verecek?” sorusunun cevabı bir kurum içi isim değilse kesinti süresi uzar.
Karşı tarafın arayüzü değişebilir. Sağlayıcının duyurularını takip edecek birini belirleyin; kullandığınız sürümü ve son değişiklik tarihini kayıt altında tutun.
Test ortamı sunan sağlayıcılarda her değişiklik önce orada denenmeli. Test ortamı yoksa, canlıda küçük bir örnek kümeyle doğrulama yapacak bir yöntem baştan tasarlanmalı.
Aşağıdaki maddeler tek bir entegrasyon için sırayla gözden geçirilebilir. Eksik çıkanlar, bir sonraki kesintide fark edilme sürenizi belirler.
Ücretsiz bir değerlendirmeyle başlıyoruz. Mevcut durumunuzu çıkarıyor, riskleri ve eksikleri önceliklendirilmiş bir yol haritası halinde sunuyoruz.
Ücretsiz değerlendirme
