Entegrasyon çalışıyor görünüyor ama bazı kayıtlar kayboluyor

İki sistem arasında kurulan bir bağlantı, hiçbir şey bozulmadan da veri kaybedebilir. Çünkü bir çağrı yapıldı diye o çağrının karşı tarafa işlenerek ulaştığı garanti değildir. Entegrasyonun güvenilir olması, hiç hata vermemesinden değil, hata oluştuğunda bunu fark eden ve telafi eden bir yapısı olmasından gelir. Sahada en sık duyulan cümlelerden biri şudur: entegrasyon aylardır sorunsuz çalışıyordu, geçen hafta bir müşteri siparişinin sisteme düşmediğini fark ettik. Ardından geriye dönük bakılır ve tek bir kaydın değil, aylara yayılmış birkaç kaydın eksik olduğu görülür. Kimse bir hata mesajı görmemiştir, kimseye alarm gitmemiştir.

Burada anlatılan şey entegrasyonun ne olduğu ya da hangi yöntemle kurulacağı değil. Konu, kurulmuş ve çalışan bir bağlantının neden zamanla güvenilmez hâle geldiği ve bunun nasıl görülür kılınacağı.

Bir kaydın yolculuğu ve kırılma noktaları

Bir siparişin A sisteminden B sistemine geçmesi tek bir olay gibi görünür, oysa birbirinden bağımsız birkaç aşamadır. Kayıt A tarafında oluşur. A, B'ye bir çağrı yapar. Çağrı ağ üzerinden gider. B çağrıyı alır. B kaydı okur, doğrular ve kendi veri tabanına yazar. B bir cevap döner. A bu cevabı alır ve kaydı gönderilmiş olarak işaretler.

Bu zincirin her halkası ayrı ayrı başarısız olabilir. İlginç olan şudur: zincir ortada koptuğunda A tarafı çoğu zaman bunu kopma olarak görmez. Çünkü A'nın bildiği tek şey, çağrıyı yapıp yapmadığı ve bir cevap alıp almadığıdır. Cevabın gelmemesi, işin yapılmadığı anlamına gelmez. Cevabın gelmesi de işin doğru yapıldığı anlamına gelmez.

Tek yönlü çağrı: gönderdim, gerisi beni ilgilendirmiyor

Kayıpların en yaygın kaynağı, gönderimi bir kere denenen ve sonucu takip edilmeyen tasarımlardır. Kayıt oluştuğu anda karşı sisteme bir çağrı yapılır. Çağrı başarısız olursa ekrana bir şey yansımaz, bir yere de not düşülmez. Kayıt A tarafında durur, B tarafında hiç olmamıştır ve bu farkı kimse hesaplamaz.

Bu davranış özellikle şu anlarda işler: karşı sistem bakımdayken, ağ bir dakikalığına koptuğunda, sunucu yeniden başlatıldığında. Yani seyrek. Seyrek olması tehlikeyi büyütür. Ayda birkaç kaydı kaybeden bir sistem, günlük kullanımda kusursuz çalışıyor görünür; sorun ancak biri sayım yaptığında ortaya çıkar.

Çözümün adı yeniden deneme mantığıdır. Başarısız gönderim silinmez, beklemeye alınır ve gitgide seyrekleşen aralıklarla tekrar denenir. Karşı taraf ayağa kalktığında birikmiş iş kendiliğinden akar. Bunun için gönderilecek işlerin tutulduğu bir sıra, yani kuyruk gerekir. Kuyruk, entegrasyonun hafızasıdır; onsuz her çağrı tek atışlık bir şanstır.

Zaman aşımı: en belirsiz durum

Bir çağrı gönderilir, karşı taraf yanıt vermez ve belirlenen süre dolar. Bu noktada gönderen sistemin elinde hiçbir bilgi yoktur. Kayıt karşıya hiç ulaşmamış olabilir. Ulaşmış, işlenmiş ama cevabı dönerken bağlantı kopmuş olabilir. Ulaşmış, yarım işlenmiş olabilir.

Bu belirsizlik, kayıp ile mükerrer kayıt arasındaki gerilimi doğurur. Gönderen taraf tekrar denerse aynı sipariş iki kez işlenebilir. Denemezse hiç işlenmeyebilir. İki seçenek de kötüdür, ama biri önlenebilir. Doğru yaklaşım tekrar denemek ve tekrarın zarar vermemesini sağlamaktır.

Tekrar denemenin iki yan etkisi

Aynı kaydın iki kez işlenmesi

Mükerrer kayıt, veri kaybı kadar can sıkıcı bir sonuçtur ve çoğu zaman kaybı çözme çabasının yan ürünüdür. Bir sipariş iki kez düştüğünde stok iki kez düşer, müşteriye iki kez fatura çıkar, üretim listesine iki satır girer. Sonra biri elle siler ve bu sefer yanlış olanı silmiş olabilir.

Bunun önüne geçmenin yolu, her kaydın kaynak tarafta üretilmiş ve değişmeyen bir kimlikle taşınmasıdır. Alıcı sistem, aynı kimlikli bir kayıt daha önce işlendiyse yenisini yazmaz, sessizce kabul eder ve geçer. Böylece gönderen taraf istediği kadar tekrar deneyebilir. Yeniden deneme ancak bu davranışla birlikte güvenlidir; kimliksiz bir yeniden deneme, kayıp problemini mükerrer kayıt problemine çevirmekten başka işe yaramaz.

Sıralama bozulması ve eski verinin yenisini ezmesi

Kayıtların gönderilme sırası ile işlenme sırası aynı olmak zorunda değildir. Bir kayıt yeniden denendiği için gecikir, arkasından gelen güncelleme önce ulaşır ve sonra gecikmiş olan eski hâli üzerine yazar. Sonuçta veri kaybolmaz ama geçerli olmayan bir hâle döner ki pratikte aynı şeydir.

Bu özellikle durum değişikliklerinde acıtır: bir sipariş önce hazırlanıyor, sonra sevk edildi olur; sıra bozulursa sevk edilmiş sipariş yeniden hazırlanıyor görünür. Depo bunu görüyorsa iş ikinci kez yapılır. Çözüm, her güncellemenin bir zaman ya da sürüm bilgisiyle taşınması ve alıcı tarafın kendisinde duran bilgiden daha eski bir güncellemeyi uygulamamasıdır.

Kimlik eşleşmemesi: veri geldi ama tutmadı

Bazı kayıplar ağ ya da zaman aşımı kaynaklı değildir; iki sistemin aynı şeyi aynı isimle tanımamasından doğar. Bir tarafta müşteri kodu başka bir düzende yazılmıştır, bir tarafta ürün kodunun başında sıfır vardır diğerinde yoktur, bir tarafta birim adettir diğerinde kutudur.

Bu durumda çağrı başarılı döner, kayıt karşıya geçer, ama eşleşemediği için bir kenara bırakılır ya da yanlış kayda bağlanır. Teknik tarafta her şey yeşildir; iş tarafında kayıt yoktur. Bu tür kayıplar en geç fark edilenlerdir, çünkü hata sayacı artmaz. Önlenmesi için eşleşmeyen kayıtların sessizce atılmaması, ayrı bir listeye düşülmesi ve birinin bu listeye bakması gerekir.

Bu tür uyuşmazlıklar genellikle entegrasyon kurulduktan sonra ortaya çıkar, çünkü kurulum sırasında test edilen kayıtlar düzgün olanlardır. Zamanla yeni bir ürün grubu açılır, bir tedarikçinin kodları farklı bir düzende girilir, bir müşteri iki kez tanımlanır. Kod tarafında hiçbir şey değişmemiştir; değişen şey veridir. Bu yüzden eşleşme kurallarının bir kere yazılıp bırakılan değil, ara ara gözden geçirilen bir şey olarak düşünülmesi gerekir.

Sessiz hata: en pahalı tasarım tercihi

Yukarıdaki maddelerin hepsinin ortak paydası şudur: sistem hatayı yaşamış ama kimseye söylememiştir. Sessiz hata çoğu zaman iyi niyetli bir tercihin sonucudur. Entegrasyon çalışırken kullanıcıyı rahatsız etmemek için hatalar yutulur, ekrana yansıtılmaz, sadece bir kütüğe yazılır ve o kütüğe kimse bakmaz.

Güvenilir bir entegrasyonda başarısız olan iş kaybolmaz, bir hata kuyruğuna düşer. Bu kuyruk işleri saklamakla kalmaz, görünür olur: kaç kayıt bekliyor, en eskisi ne zamandan kalma, hangi sebeple duruyor. Ve o kayıtlar düzeltildikten sonra baştan işlenebilir olmalıdır. Yeniden işleme imkânı olmayan bir hata listesi, sadece bir şikâyet defteridir.

Sessiz hatanın bir başka biçimi de karşı sistemin başarılı görünen ama aslında iş yapmayan cevabıdır. Bazı sistemler geçersiz bir kaydı reddetmek yerine kabul edilmiş gibi cevap döner, sonra kendi içinde bir kenara koyar. Gönderen taraf için işlem tamamlanmıştır. Bu yüzden gönderim sonucuna güvenmek, gönderilen kaydın karşı tarafta gerçekten oluştuğunu ara ara doğrulamanın yerini tutmaz.

Mutabakat ve izleme: sayılar tutuyor mu

Bütün bu önlemler alınsa bile tek başına yeterli değildir, çünkü hepsi sistemin kendi bildiği şeylere dayanır. Sistemin fark edemediği kayıplar için başka bir şeye ihtiyaç vardır: iki tarafı bağımsız olarak sayıp karşılaştırmak.

Mutabakat, yani karşılaştırma raporu bunu yapar. Belirli bir dönem için A tarafında oluşan kayıtlarla B tarafına işlenen kayıtlar yan yana konur; sayılar ve kimlikler karşılaştırılır. Fark varsa hangi kayıtların eksik olduğu tek tek listelenir. Bu rapor günlük çalıştığı sürece, kaybın fark edilme süresi aylardan bir güne iner. Önemli olan, raporun sonucunun bir ekranda beklemesi değil, fark çıktığında birine haber gitmesidir.

Kurulup unutulan değil, izlenen bir şey

Entegrasyon bir defa kurulup bitirilen bir iş gibi düşünülür; oysa iki tarafı da zamanla değişen, yaşayan bir bağlantıdır. Karşı sistem sürüm atlar, bir alan zorunlu hâle gelir, bir kod biçimi değişir, sunucu taşınır. Bunların hiçbiri size haber verilerek olmaz.

Bu yüzden entegrasyonun kendisi kadar, durumunu gösteren birkaç basit göstergesi de olmalıdır: bekleyen iş sayısı, hata kuyruğundaki kayıt sayısı, en son başarılı aktarım zamanı, günlük karşılaştırma farkı. Bu dört bilgiye bakan biri olduğu sürece sessiz kayıp diye bir kategori kalmaz. Sorulması gereken soru entegrasyon çalışıyor mu değil, çalışmadığını nasıl anlarız sorusudur.

Kısaca

• Çağrının gönderilmiş olması, karşı tarafta işlenmiş olması anlamına gelmez; kayıpların çoğu bu farktan doğar.
• Başarısız gönderim silinmemeli, kuyruğa alınıp yeniden denenmelidir; kuyruksuz entegrasyon tek atışlık bir şanstır.
• Yeniden deneme ancak her kaydın değişmeyen bir kimliği varsa güvenlidir, yoksa kayıp yerine mükerrer kayıt üretir.
• Kayıtlar sırasız ulaşabilir; güncellemeler sürüm ya da zaman bilgisiyle taşınmalı, eski olan yeniyi ezmemelidir.
• Hatalar yutulmamalı, görünür bir hata kuyruğuna düşmeli ve düzeltildikten sonra yeniden işlenebilmelidir.
• Günlük karşılaştırma raporu, sistemin kendi fark edemediği kayıpları yakalayan tek yöntemdir.