Güvenli toplu aktarımlar: önizle, doğrula, sonra onayla desenleri

Toplu değişiklikler neden yanlış gider (ve kullanıcılar ne bekler)

Toplu değişiklikler sıkıcı, gerçekçi nedenlerle başarısız olur. Dosya neredeyse doğru ama bir sütun adı farklıdır. Birkaç satırda zorunlu bir alan boş kalmıştır. ID'ler veritabanındakiyle eşleşmez çünkü biri geçen hafta dışa aktardı ve kayıtlar o zamandan beri değişti. Ya da veriler geçerli ama yanlış alana eşlenmiş, bu yüzden telefon numaraları notlar sütununa gider.

Bunu korkutucu kılan şey hızdır. Bir kötü varsayım yüzlerce ya da binlerce kayda kimse fark etmeden dokunabilir. Güvenli toplu aktarımlar sadece backend sorunu değildir. Güven meselesidir.

Kullanıcılar basit bir şey bekler: olacakları gerçekleşmeden önce gösterin. En güvenilir desen: önizleme, doğrulama, sonra onay.

• Önizleme: net bir özet ve gerçek değişiklik örneği gösterin.
• Doğrulama: eksik alanları, yanlış formatları ve uyuşmayan referansları yakalayacak kuralları çalıştırın.
• Onay: kullanıcı onay verdikten sonra riske uygun bir yaklaşımla değişiklikleri uygulayın.

İnsanlar ayrıca iki tür hataya karşı koruma bekler.

Düzeltilebilir sorunlar satır bazında ele alınmalı. Eğer 12 satır hatalı e-posta formatına veya eksik posta koduna sahipse, kullanıcı bu satırları düzeltmek (rapor indir, yerinde düzenle veya yeniden yükle) ve geri kalanını hazır tutmak ister.

Engelleyici sorunlar her şeyi durdurmalı. Eşleme yanlışsa, aktarım ana alanları üzerine yazacaksa veya dosya yanlış çalışma alanı/müşteri içinse, en iyi deneyim net bir açıklamayla tamamen durdurmaktır.

Kullanıcılar ayrıca bir iz bekler: bir run ID'si, zaman damgaları, kim başlattı, hangi dosya kullanıldı, nelerin değiştiği ve nelerin başarısız olduğu. Bu, desteği hızlandırır ve bir şey ters gittiğinde temizlemeyi mümkün kılar.

Önizleme-doğrulama-onay akışı basitçe

Toplu değişiklikler riskli hissettirir çünkü bir tıklama binlerce kayda dokunabilir. Riski azaltmanın en basit yolu işi üç aşamaya bölmektir; her aşamanın kendi çıktısı olmalı.

Aşama 1: Önizleme (partiyi hazırla)

Girdi (CSV, yapıştırılmış satırlar, seçili kayıtlar) alınıp hazırlanmış bir partiye dönüştürülür. Buradaki görev, sistemin değişiklikler hakkında ne düşündüğünü göstermektir; hiçbir şey değiştirilmeden önce.

İyi bir önizleme üç soruyu yanıtlamalı: ne değişecek, kaç öğe etkilenecek ve ne şüpheli görünüyor.

En azından sayıları (toplam satır, eşleşen kayıtlar, yeni kayıtlar, atlanan satırlar), gerçek satırlardan küçük bir örnek ve riskli olan her şey için net uyarılar (zorunlu alanların eksikliği, belirsiz eşleşmeler, olağandışı değerler) içermelidir. Ayrıca eşleme kuralını açıkça belirtin (ör. “e-posta ile eşleştir” veya “dış ID ile eşleştir”) ve partiye bir kimlik verin: bir ad, zaman damgası ve benzersiz batch ID.

Aşama 2: Doğrulama (kuru çalışma)

Kuru çalışma, veritabanına yazma anlamına gelmez. Gerçek güncellemede kullanacağınız aynı kontrolleri çalıştırın, ancak yalnızca bir rapor üretin.

Doğrulama hem satır kurallarını (bu satır geçerli mi?) hem de satırlar arası kuralları (bu satırlar birbirleriyle çelişiyor mu?) kapsamalıdır. Çıktı belirsiz bir başarılı/başarısız olmamalı; özet artı satırlara bağlı sorun listesi olmalı ki insanlar tahmin etmeden düzeltebilsin.

Aşama 3: Onay (değişiklikleri uygula)

Onay dönüşü olmayan noktadır, bu yüzden yalnızca başarılı bir kuru çalışmadan sonra kullanılabilir olmalıdır. Kullanıcı “dosyayı” onaylamaz; önizlenen ve doğrulanan belirli bir hazırlanmış partiyi onaylar.

Bu karar noktası önemlidir. Dosya değişirse, eşleme değişirse veya veri yeniden yüklendiyse yeni bir parti oluşturun ve yeniden onay isteyin.

Örnek: 5.000 müşteriyi içe aktarıyorsunuz. Önizleme e-posta ile 4.920 eşleşme, 60 yeni, e-posta eksikliği nedeniyle 20 atlama gösterir. Kuru çalışma 12 satırı hatalı telefon formatı nedeniyle işaretler. Yalnızca bu 12 düzeltildikten sonra o belirli batch ID için “Partiyi onayla” kullanılabilir hale gelir.

Girdiler, eşleme ve kayıtları nasıl tanımlarsınız

Birçok toplu iş doğrulama başlamadan önce başarısız olur. Girdi dağınıktır, sütunlar alanlarla uyuşmaz veya sistem bir satırın yeni kayıt mı oluşturması yoksa eski bir kaydı mı güncellemesi gerektiğini söyleyemez.

Toplu işlemler genellikle bir CSV dışa aktarımından, yapıştırılmış tablo satırlarından, uygulama içinden seçili kayıtlardan (toplu güncelleme) veya API tetikli batch işinden başlar. Kaynağı ne olursa olsun, kullanıcının sahip olduğu şey ile sisteminizin sakladığı şey arasında net bir eşleme olmalı.

Eşleme sütun-ala ilişkinin yanı sıra küçük dönüşümleri (boşluk kırpma, tarih ayrıştırma, telefon normalizasyonu) ve eksik değerler için varsayılanları kapsamalıdır. Bir sütun boş olduğunda ne olacağını saklamayın. Kullanıcılar boş hücrenin mevcut değeri olduğu gibi bırakıp bırakmayacağını, temizleyip temizlemeyeceğini veya bir varsayılan uygulayıp uygulamayacağını bilmelidir.

Kimlik bir sonraki büyük karardır: her satırı mevcut bir kayda nasıl eşlersiniz?

Kararlı tanımlayıcıları tercih edin ve eşleşme olmadığında veya birden çok eşleşme olduğunda ne olacağını açıkça belirtin. Yaygın seçenekler arasında iç ID'ler (kullanıcıların dışa aktarabiliyorsa en iyisi), dış sistem ID'leri (entegrasyonlar için harika) ve e-postalar (yararlı ama çoğaltma ve büyük/küçük harf sorunlarına dikkat) bulunur. Bazen account_id + invoice_number gibi bileşik bir anahtar doğru seçimdir. Bazı durumlarda yalnızca oluşturma modu sunabilirsiniz; bu mod daima yeni kayıt oluşturur ve eşleştirme yapmaz.

Son olarak, izin kurallarını toplu ölçekte uygulayın. Bir kaydı düzenleyebilen biri otomatik olarak binlerce kayıt üzerindeki her alanı güncelleme hakkına sahip olmamalıdır. Hangi rollerin içe aktarımları çalıştırabileceğine, hangi alanların değiştirilebileceğine ve ne zaman ekstra onay gerektiğine karar verin.

Güven oluşturan bir önizleme tasarlamak

Önizleme, insanların “Onayla”ya güvenle tıklayıp tıklamayacağına karar verdiği yerdir. Önizleme belirsizse kullanıcılar sistemin tahmin yürüttüğünü düşünür. İyi bir önizleme bir makbuz gibi okunur: ne değişecek, sistem ne kadar emin ve hangi durumlar güncellemeyi engeller.

Dar bir özetle başlayın. Çoğu kullanıcı sadece bir kaç sayıya bakmak ister: toplam satır, kaçının atlanacağı, oluşturma vs güncelleme sayıları (ve izin veriyorsanız silmeler), kaç satırın uyarı vs hata verdiği ve kullanılan eşleme kuralı (ör. “e-posta ile eşleşti”). Eğer mümkünse en yaygın uyarı kategorilerini gruplayın ki kullanıcılar hızlıca desenleri görsün.

Sonra kullanıcıların gerçek veriyi kontrol etmesine izin verin. Küçük, kaydırılabilir bir örnek gösterin ve güncellemeler için öncesi vs sonrası görünümü ekleyin. “eski değer -> yeni değer” görmek, bir telefon numarasının boş bir hücreyle üzerine yazılmasını önler. Pratik bir UI deseni 10–50 satır göstermek, arama ve filtreler (ör. “sadece uyarılar”) sunmak ve tam dosyayı arka planda işlemektir.

Belirsizlik görünür olmalı. Bir satır birden fazla kayda eşleşebiliyorsa bunu belirtin ve adayları gösterin. Bir zorunlu alan boşsa tam hücreyi işaretleyin. Aktarım yinelenen kayıtlar oluşturacaksa kısa bir nedenle belirtin (ör. “aynı e-posta dosyada iki kez görünüyor”). Sistem bilmediği şeyleri itiraf ettiğinde kullanıcılar daha çok güvenir.

Ayrıca sonraki adımları netleştirin. Kullanıcılar satır numaraları ve tam mesajlarla bir hata raporu indirebilmeli, eşlemeyi yeniden kurmadan düzeltip yeniden yükleyebilmeli, değişiklik olmadan iptal edebilmeli veya yalnızca risk düşük ve izinleri uygunsa ilerleyebilmelidir.

Sorunları erken yakalayan doğrulama kuralları

İyi doğrulama, toplu aktarımların gergin değil sakin hissetmesini sağlar. Amaç, herhangi bir şey değişmeden önce sorunları bulmak ve insanların bunları nasıl düzelteceğini açıklamaktır.

Doğrulamayı net türlere ayırın

Tek bir büyük “geçersiz” mesajı kafa karıştırır. Kontrolleri ayrı kovalar olarak ele alın; her kova farklı bir düzeltme önerir.

Format kontrolleri türler, tarih formatları, sayı aralıkları ve telefon/e-posta desenleri gibi şeyleri kapsar. Zorunlu alan kontrolleri eksik değerleri, boş stringleri ve 0 ile boş arasındaki kafa karıştırıcı durumları yakalar. Referans kontrolleri ID'lerin var olduğunu ve durumların izinli olduğunu doğrular. İş kuralları gerçek kısıtları uygular: kredi limitleri, rol izinleri veya “açık öğeleri olan bir siparişi kapatamazsınız.”

Önemli bir kural: doğrulama ile onayda aynı mantığı kullanın. Eğer önizleme ve onay farklı kurallar kullanırsa kullanıcılar hızla güven kaybeder. Aynı doğrulayıcıları, aynı veri sorgularını ve aynı izin kontrollerini baştan sona yeniden kullanın.

Doğrulamayı hızlı ve öngörülebilir yapın

Büyük dosyalar zaman alır; bu yüzden doğrulama cevap veriyormuş gibi hissettirmeli. Doğrulamayı parçalara ayırın (örneğin 500–2.000 satır), ilerlemeyi ve tahmini süreyi gösterin ve tekrar tekrar aynı referans verileri çekmemek için önbelleğe alın.

Satırlar arası kurallar özel bakım gerektirir çünkü tüm yüklemeyi görmeyi gerektirir. Yaygın örnekler dosya içindeki çoğaltmalar (aynı e-posta iki kez) veya çatışmalar (iki satır aynı kayıt için farklı değerler set etmeye çalışıyor). Ayrıştırma sırasında hafif bir indeks oluşturun ve her iki satırı da işaretleyin ki kullanıcı hangi sürümü koruyacağını seçebilsin.

Satır düzeyinde hatalar: korkutucu değil, uygulanabilir olsun

Satır düzeyindeki hatalar güvenin kazanıldığı veya kaybedildiği yerdir. Kırmızı metin duvarı insanları durdurur. Açık, düzeltilebilir maddeler onları ilerletir.

Şiddeti ayırarak başlayın. Engelleyici bir hata satırı olduğu gibi uygulamaya engel olur (zorunlu alan eksik, geçersiz format, kayıt bulunamadı). Uyarı satırı ise uygulanabilir ama kullanıcı bir seçim yapmalı (değer kırpılacak, bir varsayılan uygulanacak, potansiyel çoğaltma var).

İyi satır geri bildirimi spesifik ve tekrarlanabilir olmalıdır. Her sorun satır tanımlayıcısı (dosya satır numarası artı e-posta veya dış ID gibi sabit bir anahtar), alan adı (sütun ve hedef alan), düz bir mesaj (“Telefon E.164 formatında olmalı”, “Validation failed” yerine) ve önerilen düzeltmeyi (örnek değer veya izin verilen aralık) içermelidir. Şiddet etiketlerini tutarlı tutun.

Kısmi başarı kasıtlı bir seçenek olmalıdır, kazara değil. Satırlar bağımsızsa ve sonuç bozuk bir durum yaratmayacaksa buna izin verin. Müşteri etiketlerini güncellemek kısmi olabilir. Faturalar ve satır öğelerini güncellemek genellikle olmamalıdır.

Yeniden denemeler UX’in bir parçası olmalı. Kullanıcılar kaynak dosyayı düzeltebilmeli ve eşlemeyi tekrar yapmadan yeniden çalıştırabilmelidir. Pratik bir desen, eşleme seçimlerini ve satır düzeyindeki sonuçları saklayan bir “import run” kaydı tutmaktır; böylece sonraki çalışmada “halen başarısız” ve “şimdi düzeldi” kolayca vurgulanır.

Onay (commit) desenleri: atomik, kısmi ve idempotent

Onay adımı, toplu aktarımların ya güven kazanacağı ya da bozacağı yerdir. Kullanıcılar zaten önizlemeyi gördü ve sorunları düzeltti. Şimdi sistemin doğrulananı tam olarak uygulamasını beklerler.

Bir commit modu seçin ve kuralı baştan gösterin

İki commit modu yaygındır ve kurallar açık olduğu sürece her ikisi de işe yarayabilir.

Atomic (her şey ya da hiçbiri) herhangi bir satır başarısız olursa hiçbir şey yazılmaz. Para, stok, izinler ve tutarlılığın hayati olduğu durumlar için en iyisidir. Kısmi commit (en iyi çaba) geçerli satırları uygulayıp geçersizleri atlar ve raporlar. CRM güncellemeleri veya profil zenginleştirme gibi bazı durumlarda kısmi ilerleme hiç olmamasından iyidir. Bazı ekipler hibrit bir eşik kullanır: örneğin hata oranı %2'yi geçerse durdur.

Ne seçerseniz seçin, commit ekranında ve son özette görünür kılın.

Onayı tam doğrulanmış partiye bağlayın

Önizleme sırasında oluşturulan bir import job ID (batch ID) kullanın. Commit isteği o ID'yi referans almalı, yeniden yüklenen veriyi değil.

Bu, sık yapılan bir hatayı önler: biri bir dosyayı önizledi, sonra başka bir dosya yükledi ve commit’e bastı. Ayrıca birden fazla yöneticinin aynı anda çalıştığı durumlarda yardımcı olur.

İdempotentlik: çift uygulatmaya karşı koruma

İnsanlar çift tıklar. Tarayıcılar yeniden dener. Sekmeler yenilenir. Bir commit iki kez çalıştırıldığında güvenli olmalıdır.

En basit yaklaşım idempotentliktir: iş başına benzersiz bir idempotency anahtarı kullanın (gerekirse satır başına da), veri modeli izin verdikçe upsert kullanın ve iş durumunu Validated -> Committing -> Committed şeklinde yalnızca bir kez ilerleyecek şekilde kilitleyin.

Sonuçları bir makbuz gibi takip edin

Commit sonrası sıkı bir özet gösterin ve kullanıcıların sonuçları indirip kopyalamasına izin verin. Oluşturulan, güncellenen, atlanan ve başarısız sayıları ile kısa nedenleri ekleyin. Bu, korkutucu bir toplu değişikliği kullanıcıların doğrulayabileceği ve açıklayabileceği bir şeye çevirir.

Pratikte işe yarayan geri alma planları

Geri alma planı, toplu aktarımları “umarım işe yarar” olmaktan çıkarıp Pazartesi sabahı çalıştırılabilir hale getirir. Sonuçlar yanlışsa önceki duruma tahmin yürütmeden geri dönebilmelisiniz.

Doğru yaklaşım batch boyutuna, işlemin süresine ve harici sistemlere (e-posta, ödeme, mesajlar) dokunup dokunmadığınıza bağlıdır — bunlar geri alınamaz olabilir.

Üç pratik geri alma yaklaşımı

Hızlı biten küçük partiler için tek bir veritabanı işlemi (transaction) en basit güvenlik ağıdır. Tüm değişiklikleri uygulayın ve herhangi bir adım başarısız olursa veritabanı her şeyi geri alır. Bu, yalnızca kendi PostgreSQL tablolarınızı güncelliyorsanız ve birkaç yüz veya binlerce satırla sınırlıysanız iyi çalışır.

Daha büyük aktarımlar için önce staging genellikle daha güvenlidir. Dosyayı bir staged tabloya yükleyin, orada doğrulayın ve sonra staged veriyi üretim tablolarına terfi ettirin. Bir şey ters görünüyorsa staged veriyi silin; üretime dokunulmaz. Bu ayrıca yeniden denemeleri kolaylaştırır çünkü staged veri tutulup eşleme veya kurallar ayarlanarak tekrar kullanılabilir.

Gerçek geri alma mümkün değilse telafi edici (compensating) eylemler planlayın. Toplu güncellemeniz e-posta veya ödeme tetikliyorsa zamanı geri saramazsınız. Geri alma planınız “kayıtları iptal et”, “geri ödemeler yap” veya “düzeltme mesajı gönder” olabilir. Geri alma adımlarını işi çalıştırmadan önce tanımlayın, sonra değil.

Basit bir seçim yolu:

• Batch küçükse ve yalnızca kendi veritabanınıza dokunuyorsa tek transaction kullanın.
• Batch büyük, yavaş veya yüksek riskliyse staging ve promotion kullanın.
• Harici yan etkiler tetikliyorsanız telafi edici eylemler planlayın.
• Aynı girdinin iki kez uygulanmaması için yeniden çalıştırılabilir bir tekrar planı her zaman olsun.

Denetim günlükleri (audit logs) geri almayı gerçekçi kılar

Geri alma, tam olarak ne olduğunu bilmeye bağlıdır. Kimi çalıştırdı, ne zaman çalıştı, kaynak dosya veya job ID'si ve hangi kayıtların değiştiğini (öncesi/sonrası değerleri veya en azından bir değişim özeti) yakalayın.

Somut örnek: bir destek lideri 5.000 müşteri durumunu topluca güncelliyor. Staging ile terfiden önce 200 uyuşmayan satır görüldü. Yine de commit yapıp daha sonra eşlemenin ters olduğunu fark ederlerse, denetim günlüğü yalnızca etkilenen kayıtlar için hedeflenmiş bir geri alma çalıştırmayı sağlar; tüm sistemi geri almak zorunda kalmazlar.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Toplu işler öngörülebilir şekillerde başarısız olur. Çoğu problem "kötü veri" değil, beklenti uyuşmazlığıdır: kullanıcı bir şey olacağını düşündü, sistem başka bir şey yaptı.

Büyük tuzaklardan biri farklı kurallarla doğrulama yapıp farklı kurallarla commit etmektir. Bu, önizlemenin hızlı kontroller kullandığı veya farklı bir servisle çalıştığı ve commit yolunun ekstra kısıtlar veya farklı varsayılanlar içerdiği durumlarda olur. Kullanıcılar “her şey yolunda” görür, sonra gerçek iş başarısız olur veya daha kötüsü farklı sonuçlarla başarıyla tamamlanır. Tek bir paylaşılan ayrıştırıcı, tek bir kural seti ve baştan sona aynı eşleme mantığını kullanın.

Belirsiz eşleme mantığı başka klasik bir hatadır. “E-posta ile eşleştir” basit görünür ama çoğaltmalar, büyük/küçük harf farkları veya kullanıcıların e-postalarını değiştirmesi ortaya çıkabilir. UI eşlemenin tam olarak nasıl çalıştığını ve birden fazla veya hiç eşleşme olmadığında ne olacağını belirtmelidir. Örnek: bir satış yöneticisi 2.000 kişiyi güncellemek beklerken sistem yarısını yeni kayıt olarak oluşturur çünkü eşleme yalnızca e-posta kontrol ediyordu ve dosyanın yarısında telefon numarası kullanılmıştı.

“Yardımcı” otomatik düzeltmelere dikkat edin. Sessiz kısaltma, otomatik kırpma veya tarih formatını tahmin etme veri kaybını gizleyebilir. Normalizasyon yapıyorsanız bunu önizlemede gösterin (eski değer -> yeni değer) ve riskli dönüşümleri işaretleyin. Bir alan kesilecekse bunu görünür bir uyarı yapın.

Kullanıcıların sonucu kaybetmesine izin vermeyin. Sekmeyi kapatırlarsa rapor yok oluyorsa destek talepleri gelir. Her import çalışmasını durum, sonuç dosyası ve net bir özet ile bir nesne olarak saklayın.

Ölçek için de plan yapın. Partionlama olmadan zaman aşımı ve kısmi yazma gerçek hacimde ortaya çıkar. Sistemizi batching ve ilerleme güncellemeleri, hız sınırlamaları ve geri çekilme (backoff), idempotency anahtarları, kısmi başarı için net işlem ve “başarısız satırları yeniden çalıştır” seçeneği ile koruyun.

Basit bir kontrol listesi ve sonraki adımlar

Toplu değişiklikler, herkes ne olacağını, nelerin ters gidebileceğini ve sorunları hızlıca nasıl fark edeceğinizi bildiğinde güvenli hisseder.

Commit’e basılmadan önce hızlı ön kontrol (preflight)

UI değil verinin kendisi üzerinde küçük bir gerçeklik kontrolü yapın. Yaygın ve kenar durumları temsil eden birkaç satır seçin.

• Küçük bir örnek kontrol edin (örneğin 20 satır): isimler, tarihler ve sayılar doğru mu.
• Alan eşlemesinin kaynak sütunlarla uyuştuğunu doğrulayın (ve boş hücrelerin ne yaptığına karar verin).
• Eşleme anahtarının (e-posta, SKU, dış ID) yeterince benzersiz ve mevcut olduğunu doğrulayın.
• Toplamları karşılaştırın: kaç satır oluşturulacak, güncellenecek veya atlanacak.
• Uyarıları yüksek sesle okuyun ki herkes kabul ettiğini netleştirsin.

Bir insan kararına ara verin. Aktarım müşterileri, faturalamayı veya envanteri etkiliyorsa, önizleme ve sayıları onaylayacak bir sahip atayın. Bir satış yöneticisi 1.200 kişinin güncelleneğini beklerken önizleme 12.000 gösteriyorsa, nedenini bilmeden ilerlemeyin.

Commit sonrası kontroller (sorunlar sürmesin diye)

Commit bitince gerçeği yine odaklı şekilde doğrulayın.

• Küçük bir set güncellenen kaydı açıp ana alanların doğru değiştiğini kontrol edin.
• Satır bazlı durum, oluşturulan ID'ler ve hatalarla bir sonuç raporu dışa aktarın.
• Ne olduğunu kaydedin: kim çalıştırdı, ne zaman, hangi dosya/sürüm ve özet sayılar.
• Hatalar olduysa hızlı karar verin: başarısız satırları düzeltip yeniden çalıştırın veya geri almayı planlayın.

Eğer bu iş akışını bir kodsuz platformda kuruyorsanız, importları tek seferlik betik değil gerçek bir ürün özelliği gibi ele almak yardımcı olur. Örneğin AppMaster (appmaster.io) içinde ekipler genellikle PostgreSQL'de bir Import Run kaydı oluşturur, kuru çalışma ve commit mantığını Business Process Editor'de uygular ve böylece toplu güncellemeler tekrarlanabilir ve desteklenebilir hale gelir.