Kayıtları bozmayacak şekilde iş kurallarını sürümlendirmeyi, güvenli saklama desenlerini, tutarlı geçmiş davranışı ve pratik kademeli geçiş adımlarını öğrenin.
Bir iş akışı kuralını değiştirdiğinizde, ileriye dönük daha iyi kararlar almak istersiniz. Sorun şu ki, eski kayıtlar ortadan kaybolmaz. Yeniden açılırlar, denetlenirler, raporlanırlar ve yeniden hesaplanırlar.
Bozulan şey nadiren açık bir çökme olur. Daha sık karşılaşılan durum, aynı kaydın bugün farklı bir sonuç üretmesi; çünkü bugün uygulanan mantığa göre değerlendiriliyordur.
Kural sürümlendirmesi davranışı tutarlı kılar: yeni işler için yeni davranış, eski işler için eski davranış. Bir kayıt, oluşturulduğunda veya karar verildiğinde geçerli olan mantığı korumalıdır; politika sonradan değişse bile.
Birkaç faydalı terim:
Somut bir örnek: masraf iş akışınız eskiden 75$'a kadar yemekleri yöneticinin onayı olmadan izin veriyordu. Limit 100$'a yükseltildi. Eğer eski raporlar yeni limite göre değerlendirilirse, daha önce doğru biçimde yükseltilmiş bazı raporlar denetim kayıtlarında artık “yanlış” görünür. Onay türüne göre toplamlarınız da kayabilir.
Küçük başlayıp sonra ölçekleyebilirsiniz. Basit bir yaklaşım bile —örneğin bir kaydın iş akışına girdiğinde üzerine "rule version 3" kaydetmek— çoğu sürprizi engeller.
Bir iş kuralı, iş akışınızda bir sonraki adımı, kaydedilen bilgiyi veya birinin gördüğünü etkileyen herhangi bir karardır. Bir mantık satırını değiştirmenin gerçek bir vaka için sonucu değiştirebileceği her durumda sürümlendirme değerlidir.
Çoğu kural birkaç kovaya girer: onay eşikleri, fiyatlandırma ve indirimler (vergiler, ücretler, yuvarlama dahil), uygunluk kontrolleri (KYC, kredi, bölge, plan seviyesi), yönlendirme (hangi kuyruk, ekip veya tedarikçiye gideceği) ve zamanlama (SLA'lar, vade tarihleri, eskalasyon kuralları).
Bir kural genellikle birden fazla adıma dokunur. "VIP müşteri" bayrağı onay yolunu değiştirebilir, yanıt süresi hedeflerini kısaltabilir ve biletleri özel bir kuyruğa yönlendirebilir. Sadece bir kısmı güncellerseniz, uyumsuz davranış elde edersiniz: kayıt VIP der, ama eskalasyon zamanlayıcısı hala standart olarak davranır.
Gizli bağımlılıklar kural değişikliklerini acı hale getiren şeydir. Kurallar sadece iş akışı adımlarını yönlendirmez. Raporları, denetimleri ve dış mesajları şekillendirirler. "Ne zaman kargıyı iade ederiz" gibi küçük bir değişiklik finans toplamlarını, müşteri e-postasındaki açıklamayı ve birkaç ay sonra bir uyum incelemesinin bekleyeceği şeyi değiştirebilir.
Farklı ekipler etkiyi farklı açılardan hisseder:
Kural sürümlendirme sadece teknik bir detay değildir. İş akışının evrilmesine izin verirken günlük işin tutarlı kalmasını sağlar.
Kural sürümlendirmeyi uygulamadan önce sistemin şu soruya nasıl cevap vereceğini karar verin: “Bu kayıt için şu anda hangi kural uygulanmalı?” Bunu atlarsanız, değişiklikler testte iyi görünür ama denetimlerde ve köşe vakalarda başarısız olur.
Üç seçim en çok önemlidir:
Zaman ekipleri en çok kafa karıştıran konudur. created_at kaydın ilk var olduğu zamandır. processed_at bir kararın alındığı zamandır ve bu günler sonra olabilir. Eğer sürümü created_at ile seçerseniz, talep dosyalandığında geçerli olan politikayı korursunuz. processed_at ile seçerseniz, onaycının "Onayla" dediği zamanki politikayı yansıtırsınız.
Belirlenebilirlik güven oluşturur. Aynı girdiler daha sonra farklı çıktılara yol açabiliyorsa geçmiş sonuçları açıklayamazsınız. Denetime uygun davranış için sürüm seçimi kararlı olmalıdır. Kayıt, aynı değerlendirmeyi tekrar çalıştırdığınızda aynı sonucu alacak kadar bağlam taşımalıdır.
Uygulamada ekipler stabil bir kural anahtarı (ExpenseApproval gibi) ve ayrı sürümler (v1, v2, v3) tutarlar.
Sürpriz olmadan sürümlendirme istiyorsanız, geçmişi neyin “kilitlediğine” karar verin: kayıt mı, takvim mi, yoksa sonuç mu. Bu üç desen gerçek sistemlerde kullanılır.
İlk kural uygulandığında iş nesnesine (sipariş, talep, bilet) bir rule_version_id saklayın.
Bu en basit modeldir. Kaydı daha sonra tekrar kontrol ettiğinizde aynı sürümü çalıştırırsınız. Denetimler basittir çünkü her kayıt kullandığı tam kurala işaret eder.
valid_from / valid_to)Sürümü kayda sabitlemek yerine, zamanı kullanarak kuralı seçin: “olay olduğunda aktif olan kuralı kullan.”
Bu, kurallar herkes için aynı anda değiştiğinde ve tetikleyici anın net olduğu durumlarda iyi çalışır (submitted_at, booked_at, policy_start). Zor kısmı zaman damgaları, zaman dilimleri ve hangi anın tek gerçek kaynak olduğu konusunda hassas olmaktır.
Kesinlikle değişmemesi gereken kararlar (fiyatlandırma, uygunluk, onaylar) için sonucu ve kullanılan ana girdileri saklayın.
Daha sonra kural mantığı, kural motoru veya veri modeli değişse bile bir kararın neden verildiğini tam olarak gösterebilirsiniz. Ortak bir hibrit: izlenebilirlik için rule_version_id saklamak ve sadece yüksek etkili kararları snapshot'lamaktır.
Takaslarının basit karşılaştırması:
Geçmiş sonuçları güvenle açıklayabileceğiniz en hafif seçeneği seçin.
Kuralları yerinde düzenlemek basitmiş gibi gelir ama risklidir. Bir koşulu veya eşiği üzerine yazdığınız anda şu gibi temel soruları cevaplayamazsınız: “Neden bu müşteri geçen Mart ayında onaylandı ama bugün reddedildi?” Aynı kuralı tam olarak yeniden oynatamıyorsanız tahminde bulunursunuz ve denetimler tartışmaya döner.
Daha güvenli yaklaşım eklemeye dayalı sürümlerdir. Her değişiklik yeni bir sürüm kaydı yaratır ve eski sürümler dondurulur. Sürümlendirmenin asıl amacı budur: bugünün mantığını ilerletirken dünü yeniden yazmamaktır.
Her sürüme açık bir yaşam döngüsü durumu verin, böylece insanlar neyin güvenle çalıştırılabileceğini bilsin:
Yayınlama kasıtlı bir işlem olmalıdır, kazara bir kaydetme ile olmamalıdır. Kim değişiklik önerebilir, kim onaylamalı ve kim bir sürümü Active yapabilir bunları kararlaştırın.
Her sürüm için değişiklik notlarını düz metin olarak saklayın. Gelecekteki bir okuyucu diyagramlara veya koda bakmadan neyin değiştiğini anlamalıdır. Her sürüm için tutarlı bir meta veri seti tutun:
Tarihsel tutarlılık basit bir sözle başlar: eski bir kaydı, o zaman verildiği biçimde yeniden değerlendirdiğinizde aynı sonucu almalısınız. Bu söz, kuralların bugünkü veriyi okuması, dış servisleri çağırması veya değerlendirme sırasında eylemler tetiklemesiyle bozulur.
Bir kuralın hangi girdilere dayanmasına izin verildiğini (inputs), ne döndürdüğünü (outputs) ve ne yapmaması gerektiğini (yan etkiler) yazılı hale getirin. Girdiler vaka üzerindeki açık alanlar veya bu alanların snapshot'ı olmalı; “müşteri profili şu an nasıl görünüyorsa” gibi belirsiz şeyler olmamalıdır. Çıktılar küçük ve stabil olmalı, örneğin “onay/red”, “gereken onaycılar” veya “risk skoru”.
Değerlendirmeyi saf tutun. E-posta göndermemeli, ödeme yaratmamalı veya tabloları güncellememelidir. Bu eylemler kararı tüketen iş akışı adımına ait olmalıdır. Bu ayrım, geçmişi yeniden oynatmayı gerçek dünya etkileri tetiklemeden mümkün kılar.
Denetimleri kolaylaştırmak için her karar olayında üç gerçeği saklayın:
Birisi “bu geçen yıl neden onaylandı” diye sorduğunda tahmine gerek kalmaz.
Gerekli bir girdi eksikse ne olacağını önceden kararlaştırın. “False olarak kabul et” ile “kapalı durumda başarısız et” tamamen farklı geçmişler üretir. Her kural için bir politika seçin ve bunu sürümler boyunca sabit tutun.
Ayrıca sonradan yapılan düzenlemelerin geçmiş sonuçları değiştirip değiştirmeyeceğine karar verin. Pratik bir yaklaşım: düzenlemeler ileriye dönük yeni bir değerlendirmeyi tetikleyebilir, ama geçmiş kararlar orijinal sürüm ve girdileriyle kalır. Bir müşteri onaydan sonra adresini güncellerse, kargoyla ilgili dolandırıcılığı tekrar kontrol edebilirsiniz ama orijinal onayı yeniden yazmazsınız.
Güvenli kural değişiklikleri isimlendirme ile başlar. Her kurala değişmeyen bir anahtar verin (pricing.discount.eligibility veya approval.limit.check gibi) ve sonra sıralanabilir bir sürüm şeması ekleyin (v1, v2) veya tarih (2026-01-01). Anahtar insanların kuraldan bahsetme biçimidir. Sürüm, sistemin ne çalıştıracağını belirler.
Sürüm seçiminde veri modelinizi açık yapın. Daha sonra değerlendirilebilecek herhangi bir kayıt (siparişler, talepler, onaylar) hangi sürümü kullandığını saklamalı veya bir sürüme eşleyen etkin bir tarih saklamalıdır. Bunu yapmazsanız, sonunda bir kaydı yeni mantıkla yeniden çalıştırır ve sonucun gizlice değişmesine neden olursunuz.
Yeni sürümü eskisinin yanına yayın. Eski sürümleri yerinde düzenlemekten kaçının, küçük düzeltmeler için bile yeni bir sürüm oluşturun.
Güvenli bir dağıtım genellikle şöyle görünür:
Örnek: bir satın alma onay eşiği 5.000$'dan 3.000$'a düşerse, tüm yeni talepleri v2'ye yönlendirirken daha eski talepler v1 üzerinde kalsın ki denetim izi anlamlı olsun.
Bir kuralı değiştirdiğinizde en büyük risk sessiz sürüklenmedir. İş akışı çalışmaya devam eder ama sonuçlar insanların beklediğiyle yavaşça uyuşmaz. Kademeli bir dağıtım karar vermeden önce kanıt sağlar ve bir sorun görünürse temiz bir geri dönüş yolu verir.
Herkes için anahtarı çevirmek yerine, eski kuralı bir süre doğruluk kaynağı olarak tutun ve yeni kuralı paralelde çalıştırın. Küçük bir örneklemle başlayın ve sonuçları karşılaştırın.
Basit bir yaklaşım: yeni kuralın ne yapacağını loglayın ama nihai sonucu değiştirmesine izin vermeyin. Yeni onayların %5'i için her iki kararı da hesaplayın ve eski karar, yeni karar ve neden kodlarını saklayın. Uyuşmazlık oranı beklentinin üzerindeyse dağıtımı durdurun ve kuralı düzeltin, verileri değil.
Hangi sürümün kime gideceğini kontrol etmek için feature flag veya yönlendirme koşulları kullanın. Açıklaması ve daha sonra yeniden üretmesi kolay koşullar seçin. Etkin tarih, bölge/iş birimi, müşteri katmanı veya iş akışı türü genellikle bir ay sonra kimse hatırlamayacağı karmaşık kurallardan daha iyidir.
Geçmişe dönük yeniden değerlendirme (backfill) hakkında ne yapacağınıza karar verin. Eski kayıtları yeni kuralla tekrar değerlendirecek misiniz yoksa orijinal sonuçları koruyacak mısınız? Çoğu durumda denetim ve adalet için orijinal sonucu koruyun; backfill yalnızca eski sonucun kesinlikle yanlış olduğu ve açık onay alındığı durumlarda yapılmalıdır.
Kısa bir göç planı yazın: ne değişiyor, kim doğrular (operasyon, finans, uyum), hangi raporları kontrol edeceksiniz ve tam olarak nasıl geri döneceksiniz.
Çoğu iş akışı kural değişikliği sessizce başarısız olur. Hiçbir şey çökmez ama sayılar kayar, müşteriler yanlış e-posta alır veya eski bir vaka aylar sonra açıldığında “yanlış” görünür.
En büyük neden eski bir sürümü yerinde düzenlemektir. Bu daha hızlı gelir ama denetim izini kaybedersiniz ve geçmiş kararların neden verildiğini açıklayamamaya başlarsınız. Eski sürümleri salt okunur olarak kabul edin ve küçük düzeltmeler için bile yeni bir sürüm oluşturun.
Diğer tuzaklar: etkin tarihlere güvenirken zamanı hassas bir şekilde ele almamak. Zaman dilimleri, yaz saati uygulamaları ve geç çalışan arka plan işleri bir kaydı yanlış sürüme sokabilir. Bir kayıt bir bölgede 00:05'te oluşturulmuş olabilir ve başka yerde hâlâ “dün” olabilir.
Dikkat edilmesi gereken diğer sessiz hata kalıpları:
Basit bir örnek: onay eşiğini değiştirirsiniz, sonra bir gece işi açık siparişler için "onay gerektirir" alanını yeniden hesaplar. Hangi siparişlerin yeniden hesaplandığını işaretlemezseniz, destek ekibi müşterinin geçen hafta gördüğü sonuçla farklı bir sonuç görür.
Bir kural değişikliğini yayınlamadan önce dün ne olduğunu ve yarın ne olması gerektiğini ispatlayabileceğinizden emin olun. İyi sürümlendirme süslü mantıktan çok, alınan kararları açıklayabilmek ve yeniden üretebilmekle ilgilidir.
Başlangıç olarak bir kaydın aldığı kararı nasıl “hatırladığını” kontrol edin. Bir sipariş, bilet veya talep daha sonra yeniden değerlendirilebiliyorsa, ana karar noktasında (onay, fiyatlandırma, yönlendirme, uygunluk) hangi sürümün kullanıldığını açıkça işaretleyen bir göstergeye ihtiyacı vardır.
Kontrol listesi:
Ekipleri ileride kurtaracak bir diğer unsur sahipliktir. Onay ve dokümantasyondan sorumlu adlandırılmış bir kişi veya küçük bir grup belirleyin. Ne değiştiğini, neden değiştiğini ve hangi kayıtların etkilendiğini yazın.
Yaygın bir vaka iadelerdir. Önceki politika 200$ üzeri iadeler için yönetici onayı gerektiriyordu, şimdi eşik 150$ oldu. Sorun: hâlâ açık olan eski biletleriniz var ve bunların kararlarının açıklanabilir kalması gerekiyor.
Onay mantığını sürümlendirilmiş bir kural seti olarak ele alın. Yeni biletler yeni kuralı kullanır. Mevcut biletler başladıkları sürümü korur.
Her vakada saklayabileceğiniz küçük, somut bir kayıt şekli:
case_id: "R-10482"
created_at: "2026-01-10T09:14:00Z"
rule_version_id: "refund_threshold_v1"
decision: "auto-approved"
Şimdi davranış nettir:
Eğer bir bilet geçen hafta rule_version_id = refund_threshold_v1 ile oluşturulduysa, bugün işleme alınsa bile $200 eşiğini kullanmaya devam eder. Dağıtımdan sonra oluşturulan bir bilet refund_threshold_v2 alır ve $150 eşiğini kullanır.
v2'yi yayınlayın ama önce yeni biletlerin küçük bir dilimine atayın (bir kanal veya bir ekip). Destek personelinin vaka ekranında iki şey görmesi iyi olur: sürüm ve düz metinle açıklama (örneğin, “v1 eşik $200”). Müşteri “neden bu onaylandı” diye sorduğunda, personel tahminde bulunmadan cevap verebilir.
Politikanın beklendiği gibi çalıştığını doğrulamak için birkaç sinyali takip edin:
Basit başlayın. Bir kural değişikliğinden etkilenen her kayda rule_version_id (veya workflow_version) alanı ekleyin. Bir kural değiştiğinde yeni bir sürüm oluşturun ve eskisini emekliye ayırın, ama asla silmeyin. Eski kayıtlar, iş akışına girdiklerinde veya karar verildiğinde kullanılmış olan sürüme işaret etmeye devam etsin.
Bunu kalıcı hale getirmek için kural değişikliklerini rastgele bir düzenleme gibi değil, gerçek bir süreç gibi ele alın. Hafif bir kural kayıt defteri işe yarar; başlangıçta bir tablo veya spreadsheet olarak başlayabilirsiniz. Sahibi, amacı, sürüm listesiyle kısa değişiklik notları, durum (draft/active/retired) ve kapsam (hangi iş akışları ve kayıt türlerine uygulandığı) gibi bilgileri takip edin.
Karmaşıklık arttıkça bir sonraki katmanı sadece gerektiğinde ekleyin. Birisi “o tarihte karar ne olurdu?” diye soruyorsa etkin tarihler ekleyin. Denetçiler “hangi girdiler kullanıldı?” diye soruyorsa kurala kullanılan gerçekleri (ana alanlar, eşikler, onaycı listesi) saklayın. Değişiklikler riskliyse onay zorunluluğu koyun ki yeni bir sürüm gözden geçirme olmadan canlıya geçemesin.
Eğer ekibiniz hızlanmak istiyor ama geçmişi kaybetmek istemiyorsanız, no-code bir platform yardımcı olabilir. AppMaster (appmaster.io) tam uygulamalar oluşturmak için tasarlanmıştır; böylece bir kural kaydı modelleyebilir, kayıtlara sürüm kimlikleri ekleyebilir ve eski vakaları onları oluşturan mantığa bağlı tutarak iş akışlarını evrimleştirebilirsiniz.
What is rule versioning, and why do I need it?Kural sürümlendirmesi, eski bir kaydın oluşturulduğu ya da karar verildiği sırada geçerli olan mantığı korumasını sağlar. Bunu yapmazsanız, bir kaydı yeniden açmak veya yeniden hesaplamak, başlangıçtakiyle farklı bir sonuca yol açabilir; bu da denetim ve raporlama karışıklığı yaratır.
Why do rule changes break old records even if nothing crashes?Eski kayıtlar yeniden açılır, denetlenir ve yeniden hesaplanır; dolayısıyla işlem geçmişte yapılmış olsa bile sisteminiz üzerinden tekrar “çalıştırılır”. Eğer o kayıtlara bugünkü mantık uygulanırsa, aynı girdiler farklı çıktılara yol açabilir; veri hatası olmadan sonuçlar değişmiş görünür.
What counts as a business rule that should be versioned?Gerçek bir vaka için sonucu değiştirebilecek herhangi bir mantığı sürümlendirin. Yaygın örnekler: onay eşikleri, fiyatlandırma ve vergi hesapları, uygunluk kontrolleri, ekip veya tedarikçiye yönlendirme ve SLA/eskalasyon gibi zaman kurallarıdır.
Should I pin a rule version to the record or use effective dates?Kayıda bir rule_version_id sabitlemek, kural ilk uygulanırken sürüm kimliğinin kaydedilmesidir; daha sonra her zaman o sürümü çalıştırırsınız. Etkin tarih yaklaşımı ise submitted_at veya karar zamanı gibi bir zaman damgasına göre sürümü seçer; bu işe yarar ama çok hassas zaman yönetimi gerektirir.
Which timestamp should determine the rule version: created time or decision time?Eğer ‘dosyalandığı sıradaki politika’yı korumak istiyorsanız, sürümü kaydın oluşturulduğu veya gönderildiği zamana göre seçin. ‘Karar anındaki politika’yı yansıtmak istiyorsanız, onaylayanın eylemde bulunduğu processed_at zamanını kullanın; önemli olan tutarlı olmak ve değerlendirme zamanını kaydetmektir.
When should I snapshot the rule result instead of re-running old logic?Bir kararın daha sonra asla değişmemesi gerekiyorsa (ör. son fiyatlandırma, uygunluk, onay), değerlendirmenin sonucunu ve ana girdileri snapshot'layın. Böylece kural mantığı veya veri modeli değişse bile geçmiş açıklanabilir kalır.
How do I avoid losing audit history when updating a rule?Kural sürümlerini yalnızca eklemeye dayalı olarak tutun; eski sürümleri üzerine yazmayın. Her sürüme açık bir durum verin (draft, active, retired) ve yayınlamayı kasıtsız kaydın üstüne yazılabilecek bir işlem olmaktan çıkarın.
How do I keep rule evaluation reproducible without triggering side effects?Değerlendirme saf olmalı: karar döndürür ama e-posta göndermemeli, kart çekmemeli veya alakasız tabloları güncellememelidir. Yan etkiler, kararı tüketen iş akışı adımına ait olmalıdır; böylece eski bir kararı yeniden yürütmek gerçek dünyada tekrar eden etkiler yaratmaz.
What’s a safe way to roll out a new rule version gradually?Yeni ve eski kuralları paralel çalıştırın; yeni kuralın ne yapacağını loglayın ama hemen son kararı yeni kuralın vermesine izin vermeyin. Küçük bir örneklemle başlayın ve uyuşmazlık oranını ölçün; eğer beklenenden yüksekse yayını durdurun ve kuralı düzeltin.
How can I implement rule versioning quickly in a workflow app?Kritik karar noktalarından geçen kayıtlara rule_version_id ve karar zaman damgası ekleyerek başlayın. No-code bir platform olan AppMaster (appmaster.io) gibi araçlarda kural kayıt defterini modelleyebilir, kayıtlara sürüm bağlamı atayabilir ve eski vakaları onları oluşturan sürüme bağlı tutarak iş akışlarını evrimleştirebilirsiniz.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
