Daha önce test veritabanlarının neden var olduğunu yazdık. Bu yazı, platform ekiplerinin hemen ardından karşılaştığı soruyu yanıtlıyor:
“Tamam, test verisine ihtiyacımız var. O halde üretimi klonlayıp maskeleriz. Sorun çözülür, değil mi?”
Bu güvenli bir cevap gibi görünür. Tam doğruluk, tam kapsam, eksik hiçbir şey yok. Ancak neredeyse her zaman yanlış cevaptır.
Tam replika tuzağı
Tam maskelenmiş replika ihtiyatlı görünür. Pratikte listedeki en pahalı ve riskli seçenektir:
- Üretim maliyetini, üretim dışı değer için ödersiniz. Yüzlerce gigabayt veya terabayt depolama, yedekleme ve ağ aktarımı; geliştiricilerin yalnızca 200 satırlık dilimler halinde sorguladığı veri için düzenli olarak yenilenir.
- Hazırlama bir komut değil, proje haline gelir. Tam klon saatler, alt küme dakikalar sürer. Bunu her geliştirici, CI pipeline’ı ve geçici ortamla çarptığınızda haftada günlerce boş bekleme ortaya çıkar.
- Tam replikayı maskelemek etki alanını (blast radius) küçültmez; yalnızca yeniden boyar. Her satır yine güven sınırının ötesine taşınır. Her kolon, JSON nesnesi ve serbest metin alanındaki her maskeleme kuralı kusursuz çalışmak zorundadır.
customer_commentkolonunda kaçan tek bir desen, gerçek e-posta adresini geliştirici laptop’una taşıyabilir. - Maskelemenin sessizce bozulduğu yer referans bütünlüğüdür. Deterministik hash’leri, token değişimlerini ve format koruyan maskeleri join’ler boyunca doğru uygulamak zordur. Foreign-key grafiği üzerinden çıkarılan alt küme ilişkileri tasarım gereği korur; maskelerin hizalanmasını ummak yerine satırların doğru geldiğini garanti edersiniz.
Testleriniz gerçekte neye ihtiyaç duyar?
Rahatsız edici gerçek şudur: neredeyse hiçbir test verinizin tamamına ihtiyaç duymaz.
Testlerin ihtiyaç duyduğu şey verinin biçimidir:
- doğru ilişkilerle bağlanmış doğru tablolar
- gerçekçi değer dağılımları ve edge case’ler
- orphan içermeyen foreign key’ler
- sayfalama, batching ve sorgu planlarını çalıştırmaya yetecek satır
- o zor %0,1: NULL değerler, composite key’ler ve saat dilimi hataları
500 milyon satırlık bir replika bunların tümünü sağlar. 500 bin satırlık doğru bir alt küme de sağlar. Kalan 499,5 milyon satır yalnızca yüktür.
Alt küme neden kazanır?
1. Veri minimizasyonu taviz değil, özelliktir.
GDPR Madde 5, KVKK Madde 4 ve CCPA aynı ilkeyi söyler: yalnızca gerekli olan asgari veriyi toplayın ve işleyin. Tam replika tanımı gereği minimizasyonun tersidir. Alt kümeleme ise minimizasyonun sistematik hale gelmiş biçimidir.
2. Daha küçük yüzey, daha küçük denetimdir.
Yine sınıflandırır, maskeler ve kalan PII için tarama yaparsınız. Ancak 500 milyon yerine 50 bin satırı denetlersiniz. Maskeleme motoru saniyeler içinde çalışır, residual PII taraması gerçekten tamamlanır ve güvenlik incelemesi bir formalite olmaktan çıkar.
3. Hızın etkisi katlanır.
Saatler yerine dakikalar, geliştiricilerin eski bir ortamı paylaşmak yerine talep üzerine yeni ortam kurabilmesi demektir. Her CI çalışması taze bir veritabanı alır; “benim verimde çalışıyor” hataları staging’de değil kod incelemesinde yakalanır.
4. Graf farkındalıklı extraction bütünlük açısından satır düzeyi maskelemeden üstündür.
FK grafiğini köklerden aşağı bağımlılıklara kadar izleyen ve orphan satırları temizleyen bir alt küme, ilişkileri doğru şekilde hazırlanmış olarak gelir. Maskelenmiş tam klonda ise doğruluk; her join yolu üzerindeki maskelerin deterministik, tutarlı ve çakışmasız olmasına bağlıdır.
5. Maliyet üretimle birlikte büyümeyi bırakır.
Üretim veritabanınız büyümeye devam eder; test veritabanınız aynı hızda büyümemelidir. Tablo başına 1.000 satır veya üst sınırı olan %5 gibi bir alt küme politikası, test altyapısı maliyetini üretim büyümesinden ayırır.
Atlanmaması gereken ayrıntı
Bu yaklaşım “maskeleme yerine alt kümeleme” değildir. Alt kümeleme ve maskelemedir.
Alt kümede hâlâ gerçek e-posta adresleri, adlar, telefon numaraları ve koordinatlar bulunabilir. Örnekleme hacmi azaltır, hassasiyeti ortadan kaldırmaz. Veri üretim güven sınırından çıkmadan önce sınıflandırma, deterministik maskeleme, serbest metinde NER tabanlı kimliksizleştirme ve residual PII denetimi gerekir.
Fark ölçek ve güvendir: bu kontrolleri yalnızca çalışmasını umabileceğiniz dev bir kopya yerine, doğrulayabileceğiniz kadar küçük bir veri kümesine uygularsınız.
Ekibinize sormanız gereken soru
“Test için tüm bu veriye ihtiyacımız var mı?” diye sormayın; cevap neredeyse her zaman hayırdır.
Şunu sorun: “Üretimin, bu testi anlamlı kılacak referans bütünlüğü korunmuş ve maskelenmiş en küçük dilimi nedir?”
Sonra tam olarak onu oluşturun. Her seferinde. Talep üzerine. Dakikalar içinde.
Bu, doğruluktan taviz vermek değildir. Mühendislik disiplinidir.
Ark’ın referans bütünlüğü korunmuş ve maskelenmiş alt kümeleri ağınızın içinde nasıl çıkardığını görmek için başlangıç rehberiyle başlayın veya ürün dokümantasyonunu okuyun.