İki yönlü veri senkronizasyonu: çakışmayı kim kazanır kuralıyla yönetmek

Pazartesi sabahı muhasebe programında bir müşterinin telefon numarası düzeltilir. Aynı günün öğleden sonrasında bir satış temsilcisi aynı kişiyi CRM'de günceller, ama biraz farklı bir numarayla. Salıya kadar iki sistem tek bir küçük bilgi üzerinde anlaşamaz ve kimse hangisinin doğru olduğunu söyleyemez. Her iki yönlü veri senkronizasyonu'nun arkasındaki sessiz drama tam olarak budur ve iki aracı bağlamanın kendiliğinden çalışacağını sanan binlerce küçük işletmede yaşanır.

Bu yazı, iki sistemi verinizi el altından bozmadan aynı hizada tutmakla ilgili. İki yönlü senkronizasyonun gerçekte ne demek olduğunu, doğruluk kaynağını nasıl seçeceğinizi, "kim kazanır" sorusunu yanıtlayan çakışma kurallarını, tekilleştirmenin neden göründüğünden daha önemli olduğunu ve, dürüst olmak gerekirse, tam iki yönlü bir kurulumun ne zaman zahmete değmediğini konuşacağız.

Tek yönlü, çift yönlü ve farkın neden canınızı yaktığı

Tek yönlü senkronizasyon bir aynadır. Bir sistem efendidir, diğeri ise efendi değiştikçe güncellenen salt-okunur bir kopyadır. Web siteniz yeni siparişleri CRM'e iter ama CRM hiçbir şeyi geri göndermez. Basit, öngörülebilir, bozması zor.

Çift yönlü senkronizasyon ise her iki tarafın da aynı kayıtları oluşturup düzenlemesine izin verir ve değişiklikler iki yöne birden akar. Telefon numarasını iki yerden birinde düzeltin, bir iki dakika içinde diğeri de ona uyar. İlk hafta büyülü gelir. Sorun, iki sistemin de aynı alana yazabildiği an başlar, çünkü artık birbirleriyle çelişebilirler.

Bütün mesele bu. Tek yönlü senkronizasyon yanlış olabilir ama asla kafası karışık değildir. Çift yönlü senkronizasyon daha güçlüdür ve yepyeni bir arıza türü getirir: çakışma. İster kendiniz kurun ister hazır bir bağlayıcıya güvenin, yerel ve üçüncü parti entegrasyon arasındaki tercih çoğunlukla her birinin bu çakışmayı sizin adınıza ne kadar iyi çözdüğüne bakar.

Çarpışma: iki sistem, tek kayıt, iki düzenleme

Küçük bir mum atölyesini düşünün. Aynı sabah, işletme sahibi bir toptancı müşterinin teslimat adresini internet mağazasında güncellerken, asistanı bir telefon görüşmesinin ardından aynı müşterinin adresini CRM'de değiştirir. İki düzenleme, tek kayıt ve senkronizasyon motoru şimdi bir kazanan seçmek zorunda.

Kuralı önceden kimse belirlemediyse, araç kendi varsayılanına döner; genellikle "en son gelen değişiklik geçerli". Bu varsayılan, doğru adresin üzerine sessizce eskisini yazdığı güne kadar sorunsuzdur ve bir palet mum, müşterinin altı ay önce taşındığı bir depoya gönderilir.

Buradan çıkan ders "çift yönlü senkronizasyondan kaçının" değil. Ders şu: çakışma nadir bir kaza değil, normal ve beklenen bir olaydır. Aynı şeyi düzenleyebilen iki sisteminiz varsa çakışma yaşarsınız. Tek soru, bunu nasıl çözeceğinize sizin mi karar verdiğiniz, yoksa bir varsayılanın mı sizin yerinize karar verdiği.

Doğruluk kaynağını seçin: sistem başına değil, alan başına

İçgüdü, bir sistemi "efendi" ilan edip işi bitirmektir. Bu, gerçeklerle ilk temasta genellikle çöker, çünkü farklı sistemler farklı şeylerde yetkilidir. Dürüst yanıt, doğruluk kaynağını alan alan atamaktır.

Her bilgi parçasının gerçekte kime ait olduğunu düşünün. Muhasebe yazılımınız vergi numarasına, fatura adresine ve fatura tutarlarına sahiptir; bunların yasal olarak doğru olduğu yer orasıdır. CRM'iniz satış aşamasına, lead puanına ve son görüşme tarihine sahiptir. İnternet mağazanız sipariş durumuna ve stoğa sahiptir. Alanın gerçek sahibi olan sistemle kimse tartışmaz.

Sahipliği bu şekilde haritaladığınızda çakışmaların çoğu daha olmadan yok olur. Temiz bir muhasebe ve CRM entegrasyonu fatura verisinin bir yöne, satış verisinin diğer yöne akmasını sağlar; böylece iki sistem aynı alan için nadiren kapışır. Aynı mantık bir internet mağazasını CRM'e bağladığınızda da geçerlidir: siparişin sahibi mağaza, siparişin etrafındaki ilişkinin sahibi CRM'dir.

CRMMuhasebeİnternet mağazasıTakvimGelen kutusu

Çakışma kuralları: kim kazanır?

İki düzenleme gerçekten aynı alana düştüğünde, tek cümleyle açıklayabileceğiniz bir kurala ihtiyacınız var. Her biri gerçek bir ödünleşme taşıyan dört yaygın kural vardır.

• En son yazan kazanır. En güncel değişiklik eskisinin üzerine yazar. Kurması ve akıl yürütmesi kolaydır ama saatlere güvenir ve doğru bir değeri daha sonra gelen özensiz bir değerin altına gömebilir.
• Doğruluk kaynağı kazanır. Alanın sahibi olan sistem, zamanlamadan bağımsız olarak her zaman kazanır. Yukarıdaki sahiplik çalışmasını yaptıysanız genellikle en güvenli varsayılan budur.
• En yeni dolu değer kazanır. Gerçek veriyi boş bir değerle ezmeyi reddeden daha nazik bir sürüm. Bir sistem sık sık eksik kayıt gönderiyorsa işe yarar.
• İnsana gönder. Gerçek çakışmalar otomatik çözülmek yerine bir inceleme kuyruğuna düşer. Hepsinin en güvenlisi ve kuyruk kalabalıklaşınca insanların ilk kapattığı şey.

Çoğu küçük işletme bir karışımda karar kılar: önemli alanlar için (para, hukuk, iletişim bilgileri) doğruluk-kaynağı-kazanır, düşük riskli notlar için en-son-yazan-kazanır. Kuralı yazın. Sade bir dille açıklayamadığınız bir senkronizasyon, güvenemeyeceğiniz bir senkronizasyondur.

1Değişiklik algılandı2Kayıt eşleştir3Kuralı uygula4Yaz ve logla

Tek cümleyle yüksek sesle söyleyemediğiniz bir çakışma kuralı, kural değildir; bir temennidir.

Tekilleştirme: sessiz veri katili

İki kayıt çakışabilmeden önce, senkronizasyonun onların aynı kayıt olduğuna karar vermesi gerekir. Bunu yanlış yaparsanız ters sorunu alırsınız: mükerrer kayıtlar. Aynı müşteri iki kez görünür, her kopya hikâyenin yarısını tutar ve raporlarınız sessizce gerçeklikten uzaklaşır.

Tekilleştirme bir eşleştirme anahtarına dayanır; "bu ikisi aynı kişi" diyecek kadar kararlı bir alana. E-posta olağan tercihtir, telefon numarası iş görür, ortak bir dış kimlik ise hepsinin en iyisidir. Tek başına isimler bir tuzaktır, çünkü "Ahmet Yılmaz" ile "Ahmet Yilmaz" bilgisayara farklı, size aynı görünür.

Tam da bu yüzden gelen kutusunu CRM'e bağlamak kendini amorti eder: her e-posta eşleşen tek bir kişiye işlendiğinde, biri her yazdığında yarım dolu yeni bir kayıt oluşturmayı bırakırsınız. Eşleştirme anahtarınıza erkenden karar verin ve mümkün olan her yerde bulanık isim eşleştirmesi yerine kararlı bir kimliği tercih edin.

Neyin nereye akacağına karar verin, neyin akmayacağına da

En yaygın hata, yapabildiğiniz için her şeyi senkronize etmektir. Her alana iki sistemde birden ihtiyacınız yok. Her ekibin gerçekten kullandığı alanlara, mantıklı olan yönde akarak ihtiyacınız var.

Tek sayfada haritalayın: alan, yön, sahip. Sipariş durumu mağazadan CRM'e akar. İletişim bilgileri CRM'den mağazaya akar. Randevu saatleri iki yöne birden akar, çünkü hem takviminiz hem de CRM'iniz meşru şekilde randevu oluşturabilir; bir takvim ve CRM entegrasyonu tam da burada, çift rezervasyonu önleyerek hakkını verir.

Senkronizasyonun dışında bıraktığınız her şey, bozulabilecek bir şeyin eksilmesi demektir. Dar kapsam burada bir kısıtlama değil, bir özelliktir.

Çift yönlü senkronizasyon ne zaman zahmete değmez

Dürüst olmak gerekirse, pek çok küçük işletmenin çift yönlü senkronizasyona hiç ihtiyacı yoktur. Bir sistem açıkça efendiyse ve diğerinin yalnızca veriyi okuması gerekiyorsa, tek yönlü senkronizasyon daha basit, daha ucuz ve gece 2'de canınızı yakma ihtimali çok daha düşüktür.

Çift yönlü senkronizasyon arıza yüzeyinizi kabaca ikiye katlar. İki taraftan da yazılabilen her alan; çakışabilen, döngüye girebilen veya üzerine yazılabilen bir alandır. Raporlama en net örnektir: CRM verisini bir panoya ya da raporlama için bir veri ambarına ittiğinizde bu akış kesinlikle tek yönlü olmalı. Ambarınız okur, asla geri yazmaz.

İyi bir pratik kural: çift yönlü senkronizasyonu yalnızca her iki ekibin de gerçekten aynı şeyi düzenlediği birkaç alan için açın. Gerisi tek yönlü kalabilir ve gelecekteki siz buna teşekkür edecek.

Bir şeyleri bozmadan devreye almak

Taze bir senkronizasyonu asla canlı verinize doğrultup en iyisini ummayın. Devreye almayı, suyu açmadan önce test ettiğiniz bir tesisat gibi görün.

• Kum havuzunda başlayın. Senkronizasyonu önce test kayıtlarında çalıştırın ve nasıl çözdüğünü görmek için kasıtlı olarak bir çakışma yaratın. Sonucu tahmin edemiyorsanız canlıya geçmeyin.
• Kuru bir prova yapın. Çoğu araç, hiçbir şeyi değiştirmeden neyi değiştireceğini gösterebilir. O listeyi taahhüt etmeden önce okuyun.
• Önce küçük bir grubu senkronize edin. On kayıt, sonra yüz, sonra hepsi. Mükerrerler ve hatalı eşleşmeler küçük ölçekte hızlı ve ucuza ortaya çıkar.
• Bir log ve bir yedek tutun. Senkronize edilen her değişiklik kaydedilmeli ve başlamadan önce iki sistemi de dışa aktarabilmelisiniz.

Senkronizasyonunuz webhook'larla çalışıyorsa (sistemler arasında ateşlenen anlık mesajlar) biraz şüphecilik ekleyin. Yeniden denemeler, tekrarlanan olayları tekilleştirme ve temel bir webhook imza doğrulaması, bir aksaklığın veri karmaşasına dönüşmesini engeller. Gerçek zamanlılık hoştur, ta ki bir mesaj iki kez gelene kadar.

Sıkça sorulan sorular

Çift yönlü senkronizasyon aslında teknik bir sorun değil; teknik kılığına girmiş bir karar sorunudur. Her alanın sahibine karar verin, kimin kazanacağının kuralını yazın, kayıtları eşleştirmek için kararlı bir anahtar seçin ve küçük başlayın. Rocketly gibi araçlar mekaniği üstlenebilir; her değişikliği eşleştirmek, çözmek ve loglamak. Ama kurallar sizindir ve verinizi dürüst tutan da onlardır. Bunları doğru kurun, senkronizasyon arka plana çekilir; tam da iyi bir senkronizasyonun ait olduğu yere.