İş uygulamaları için veri saklama politikaları: saklama pencereleri ve iş akışları

Bir saklama politikasının gerçekten çözdüğü sorun nedir

Bir saklama politikası, uygulamanızın verilerle ilgili takip ettiği net kurallar kümesidir: neyi saklarsınız, ne kadar süre saklarsınız, nerede durur ve süre dolunca ne olur. Amaç "her şeyi silmek" değil. İhtiyacınız olanı işletmek ve geçmiş olayları açıklamak için tutmak; artık ihtiyacınız olmayanı ise kaldırmaktır.

Plan yoksa üç sorun hızla ortaya çıkar. Depolama sessizce büyür ve gerçek maliyetler ortaya çıkar. Kişisel verinin her ekstra kopyasıyla gizlilik ve güvenlik riski artar. Ve eski kayıtlar bugünün mantığıyla uyuşmadığında ya da insanlar rastgele silme yaptığında raporlama güvenilmez hale gelir; paneller aniden değişir.

Pratik bir saklama politikası günlük operasyonlar, delil ve müşteri koruması arasında denge kurar:

• Operasyonlar: insanlar işlerini yapmaya devam edebilsin.
• Delil: bir işlemi sonra açıklayabilin.
• Müşteriler: kişisel veriyi gereğinden uzun tutmayın.

Çoğu iş uygulamasında adlar farklı olsa da benzer geniş veri alanları vardır: kullanıcı profilleri, işlemler, denetim kayıtları, mesajlar ve yüklenen dosyalar.

Politika kısmen kurallar, kısmen iş akışları, kısmen de araçlardır. Kural “destek taleplerini 2 yıl tut” diyebilir. İş akışı bunun pratikte ne anlama geldiğini tanımlar: eski talepleri arşiv alanına taşı, müşteri alanlarını anonimleştir ve ne olduğunu kaydet. Araçlar bunu tekrarlanabilir ve denetlenebilir kılar.

AppMaster üzerine inşa ediyorsanız, saklamayı tek seferlik temizlik değil ürün davranışı olarak ele alın. Zamanlanmış Business Process'ler verileri aynı şekilde her seferinde arşivleyebilir, silebilir veya anonimleştirebilir; böylece raporlama tutarlı kalır ve insanlar sayılara güvenir.

Herhangi bir zaman penceresi seçmeden önce netleştirmeniz gereken kısıtlar

Tarihler belirlemeden önce veriyi neden sakladığınızı netleştirin. Saklama kararları genellikle gizlilik yasaları, müşteri sözleşmeleri ve denetim/vergilendirme kurallarıyla şekillenir. Bu adımı atlarsanız ya çok fazla tutarsınız (artan risk ve maliyet) ya da sonradan ihtiyaç duyacağınız bir şeyi silersiniz.

Önce “kesin tutulmalı” ile “olsa iyi olur”u ayırın. Kesin tutulması gereken veriler genellikle fatura, muhasebe kayıtları ve kim ne zaman ne yaptı diye kanıt sağlayan denetim loglarını içerir. İyi olur kategorisine eski sohbet dökümleri, ayrıntılı tıklama geçmişi veya nadiren kullanılan ham olay logları girebilir.

Gereksinimler ülkeye ve sektöre göre değişir. Bir sağlık sağlayıcısına yönelik destek portalının kısıtları, bir B2B yönetim aracından çok farklıdır. Aynı şirket içinde bile birden çok ülkedeki kullanıcılar aynı kayıt türü için farklı kurallar anlamına gelebilir.

Kararları düz bir dille yazın ve bir sorumlu atayın. "Talepleri 24 ay tutuyoruz" demek yeterli değil. Nelerin dahil olduğunu, nelerin hariç olduğunu ve pencere bittiğinde ne olacağını (arşivle, anonimleştir, sil) tanımlayın. Ürün veya kanun değiştiğinde güncellemelerin tıkanmaması için bir kişi veya ekip sorumlu olsun.

Mühendislik bir şey inşa etmeden önce onayları alın. Hukuk asgari gereklilikleri ve silme yükümlülüklerini doğrular. Güvenlik riski, erişim kontrolleri ve loglamayı onaylar. Ürün hangi bilgilerin kullanıcılar tarafından hâlâ görülmesi gerektiğini doğrular. Finans kayıt tutma ihtiyaçlarını doğrular.

Örnek: fatura kayıtlarını 7 yıl saklayabilir, destek taleplerini 2 yıl tutabilir ve hesap kapandıktan sonra kullanıcı profil alanlarını anonimleştirirken toplanmış metrikleri saklayabilirsiniz. AppMaster içinde bu yazılı kurallar zamanlanmış süreçlere ve rol tabanlı erişime doğrudan eşlenebilir, sonraki belirsizlikleri azaltır.

Verilerinizi tür, duyarlılık ve konumlarına göre haritalayın

Ekipler "2 yıl tut" diyerek neyi kastettiklerini bilmediğinde saklama politikaları başarısız olur. Sahip olduğunuz verilerin basit bir haritasını oluşturun. Mükemmellik hedeflemeyin; destek lideri ile finans liderinin ikisinin de anlayabileceği bir şey hedefleyin.

Tür ve hassasiyete göre sınıflandırma

Pratik bir başlangıç seti:

• Müşteri verisi: profiller, destek talepleri, siparişler, mesajlar
• Çalışan verisi: İK kayıtları, erişim logları, cihaz bilgileri
• Operasyonel veri: iş akışları, sistem olayları, denetim kayıtları
• Finansal veri: faturalar, ödemeler, vergi alanları
• İçerik ve dosyalar: yüklemeler, dışa aktarımlar, ekler

Sonra duyarlılığı düz bir dille işaretleyin: kişisel veri (isim, e-posta), finansal (banka bilgileri, ödeme tokenları), kimlik bilgileri (parola hash'leri, API anahtarları) veya düzenlemeye tabi veriler (örneğin sağlık bilgisi). Emin değilseniz "potansiyel olarak hassas" etiketi koyun ve doğrulanana kadar dikkatle davranın.

Nerede durduğunu ve kimlerin bağımlı olduğunu haritalayın

"Nerede durduğu" genellikle ana veritabanınızdan daha fazlasıdır. Tam konumu not edin: veritabanı tabloları, dosya depolama, e-posta/SMS logları, analiz araçları veya veri ambarları. Ayrıca her veri setine kimlerin bağımlı olduğunu (destek, satış, finans, liderlik) ve ne sıklıkla kullandıklarını not edin. Bu, çok agresif silerseniz nelerin bozulacağını gösterir.

Yararlı bir alışkanlık: her veri setinin amacını bir cümleyle belgeleyin. Örnek: "Destek talepleri anlaşmazlıkları çözmek ve yanıt süresi trendlerini izlemek için saklanır."

AppMaster ile inşa ediyorsanız, bu envanteri Data Designer modellerinizi, dosya işlemlerinizi ve etkin entegrasyonları gözden geçirerek dağıtımdaki durumla hizalayabilirsiniz.

Harita hazır olduğunda, saklama büyük bir tahminden küçük, net tercihlere dönüşür.

İnsanların uygulayabileceği saklama pencereleri nasıl belirlenir

Bir pencere yalnızca açıklanması kolay ve uygulanması daha da kolay ise işe yarar. Birçok ekip, verinin kullanım biçimine uyan basit katmanlarla iyi işler: sıcak (günlük kullanılan), ılık (ara sıra kullanılan), soğuk (kanıt için saklanan) ve ardından silme veya anonimleştirme. Bu katmanlar soyut politikayı rutin hale çevirir.

Kategorilere göre pencereler belirleyin; tek bir küresel sayı kullanmayın. Fatura ve ödeme kayıtları genellikle vergi ve denetimler için uzun bir soğuk dönem gerektirir. Destek sohbetleri değeri hızla kaybedebilir.

Ayrıca saatin ne zaman başladığını kararlaştırın. "2 yıl sakla" ifadesi, "ne zaman itibariyle 2 yıl" tanımlanmadıkça anlamsızdır. Her kategori için bir tetik seçin: oluşturulma tarihi, son müşteri aktivitesi, talep kapanış tarihi veya hesap kapanışı gibi. Eğer tetikler net değilse insanlar tahminde bulunur ve saklama kayar.

İstisnaları baştan yazın ki ekipler sonra doğaçlama yapmasın. Yaygın istisnalar arasında hukuki bekletme, chargeback'ler ve dolandırıcılık soruşturmaları bulunur. Bunlar silmeyi durdurmalıdır; gizli kopyalara yol açmamalıdır.

Nihai kuralları kısa ve test edilebilir tutun:

• Destek sohbetleri: yasal bekletme yoksa son mesajdan 6 ay sonra anonimleştir
• Pazarlama lead'leri: sözleşme yoksa son aktiviteden 12 ay sonra sil
• Müşteri hesapları: kapatmadan 30 gün sonra sil; faturalar 7 yıl saklanır
• Güvenlik logları: 90 gün sıcak, inceleme için 12 ay soğuk
• legal_hold=true olarak işaretlenmiş herhangi bir kayıt: temizlenmez

Arşivleme stratejileri: veriyi kullanılabilir ve daha ucuz tutmak

Arşiv yedek değildir. Yedekler hatalar veya kesintiler sonrası kurtarma içindir. Arşivler kasıtlıdır: eski veri sıcak tablolardan çıkar ve daha ucuz depolamaya gider, ancak denetimler, itirazlar ve tarihsel sorular için erişilebilir kalır.

Çoğu uygulama her ikisine de ihtiyaç duyar. Yedekler sık ve geniştir. Arşivler seçici ve kontrollüdür; genellikle sadece gerekenler geri getirilir.

Daha ucuz ama aranabilir depolama seçin

Daha ucuz depolama yalnızca insanlar hala aradıklarını bulabiliyorsa işe yarar. Birçok ekip, ayrı bir veritabanı veya okuma ağırlıklı sorgular için ayarlanmış şema kullanır ya da dosyalara dışa aktarım + arama için bir indeks tablosu tutar. Uygulamanız PostgreSQL etrafında modellenmişse (AppMaster dahil), bir "archive" şeması veya ayrı veritabanı üretim tablolarını hızlı tutarken yetkili raporlama yapmaya izin verebilir.

Formatı seçmeden önce işiniz için "aranabilir"in ne anlama geldiğini tanımlayın. Destek e-posta veya talep ID'siyle arama yapabilmek isteyebilir. Finans aylık toplamlara ihtiyaç duyabilir. Denetimler sipariş ID'siyle iz sürmeyi isteyebilir.

Tam kayıt mı özet mi arşivlenecek karar verin

Tam kayıtlar detay korur ama daha maliyetli ve gizlilik riski yüksek olur. Özetler (aylık toplamlar, sayımlar, ana durum değişiklikleri) daha ucuzdur ve çoğu raporlama için yeterlidir.

Pratik yaklaşım:

• Denetim açısından kritik nesneler (faturalar, iadeler, erişim logları) için tam kayıtları arşivleyin
• Yüksek hacimli olaylar (tıklamalar, sayfa görünümleri, sensör pingleri) için özetleri arşivleyin
• Sıcak depoda küçük bir referans dilimi tutun (genellikle son 30-90 gün)

Önceden indeks alanlarını planlayın. Yaygın olanlar: birincil ID, kullanıcı/müşteri ID'si, tarih kovası (ay), bölge ve durum. Bunlar yoksa arşivlenmiş veri var ama geri getirmesi zahmetli olur.

Geri yükleme kurallarını da tanımlayın: kim talep edebilir, kim onaylar, geri getirilen veri nereye düşer ve beklenen zamanlama nedir. Geri getirme kasıtlı olarak yavaş olabilir ama öngörülebilir olmalı.

Silme vs anonimleştirme: doğru yaklaşımı seçmek

Saklama politikaları genellikle bir seçim gerektirir: kayıtları silmek mi, yoksa kişisel detayları kaldırarak olayı tutmak mı. İkisi de doğru olabiliyor ama farklı sorunları çözer.

Hard delete (kesin silme) kaydı fiziksel olarak kaldırır. Verinin varlığının risk yarattığı ve yasal/iş gerekçesi bulunmadığı durumlarda uygundur (örneğin hassas bilgili eski sohbetler).

Soft delete satırı tutar ama genelde deleted_at zaman damgasıyla işaretler ve normal ekranlardan/APİ'lerden gizler. Soft delete, kullanıcıların geri yükleme beklentisi olduğunda veya bağlı sistemler kayıtla hala referans ihtiyacı duyduğunda işe yarar. Dezavantajı, soft-silinen verinin hâlâ mevcut olması, depolama tüketmesi ve dışa aktarımlarda kaçak yapabilmesidir.

Anonimleştirme olayı veya işlemi tutar ama kişiyi tanımlayan her şeyi kaldırır veya değiştirir. Doğru yapıldığında geri döndürülemez. Pseudonimleştirme farklıdır: e-postayı bir token ile değiştirir ama yeniden tanımlama yapabilecek ayrı bir eşleme saklar. Bu dolandırıcılık soruşturmalarına yardımcı olabilir, ama anonim olmakla aynı şey değildir.

İlgili veriler konusunda açık olun; politikalar genellikle burada bozulur. Bir kaydı silip ekleri, küçük resimleri, önbellekleri, arama indekslerini veya analiz kopyalarını bırakmak tüm amaca gölge düşürebilir.

Ayrıca silmenin gerçekleştiğine dair kanıt da gerek. Basit bir silme makbuzu tutun: ne kaldırıldı veya anonimleştirildi, ne zaman çalıştı, hangi iş akışı çalıştı ve başarıyla tamamlandı mı. AppMaster'da bu, bir Business Process'in iş bittiğinde bir denetim girdisi yazması kadar basit olabilir.

Kişisel veriyi kaldırırken raporlamanın değerini nasıl korursunuz

Kayıtları silmek veya anonimleştirmek panellerinizin zaman içinde birbiriyle kıyaslanmasını bozabilir. Herhangi bir değişiklik yapmadan önce hangi sayıların ay bazında karşılaştırılabilir kalması gerektiğini yazın. Aksi halde sonra "geçen yılın grafiği neden değişti?" diye zaman harcarsınız.

Öncelikle doğru kalması gereken kısa bir metrik listesi oluşturun:

• Günlük/haftalık/aylık gelir ve iadeler
• Ürün kullanımı: aktif kullanıcılar, olay sayıları, özellik benimsemesi
• SLA metrikleri: yanıt süresi, çözüm süresi, çalışma süresi
• Funnel ve dönüşüm oranları
• Destek hacmi: talepler, kategoriler, bekleyen yaş

Sonra raporlama için ne saklayacağınızı yeniden tasarlayın ki kişisel tanımlayıcılar gerekmesin. En güvenli yaklaşım agregasyondur. Her zaman ham satırı saklamak yerine günlük toplamlar, haftalık kohortlar ve kişiye izlenemeyecek sayımlar saklayın. Örneğin, orijinal içerikleri sonradan silseniz bile "kategori başına günlük oluşturulan talep sayısı" ve "haftalık median ilk yanıt süresi" gibi veri tutabilirsiniz.

Kimlik tutmadan stabil analiz anahtarları saklayın

Bazı raporlar yine de zaman içinde davranışı gruplayacak stabil bir anahtar ister. Gerçek kullanıcı ID'sine doğrudan bağlanmayan bir analitik anahtarı kullanın (örneğin sadece analitik için rastgele oluşturulmuş bir UUID) ve saklama penceresi dolduğunda gerçek kullanıcı ID'sine giden herhangi bir eşlemeyi kaldırın veya kilitleyin.

Ayrıca operasyonel tabloları raporlama tablolarından ayırın. Operasyonel veri değişir ve silinir. Raporlama tabloları append-only anlık görüntüler veya agregatlar olmalı.

Anonimleştirmeden sonra nelerin değişeceğini tanımlayın

Anonimleştirmenin sonuçları olur. Ekipler şaşırmasın diye nelerin değişeceğini belgeleyin:

• Belirli tarihten sonra kullanıcı düzeyinde ayrıntılı inceleme durabilir
• Tarihsel segmentler bazı öznitelikler silindiğinde “bilinmiyor” olabilir
• E-posta veya telefon kaldırılırsa deduplikasyon değişebilir
• Bazı denetimler kişisel olmayan zaman damgaları ve ID'ler gerektirebilir

AppMaster içinde anonimleştirmeyi bir iş akışı olarak ele alın: önce agregatları yazın, rapor çıktılarınızı doğrulayın, sonra kaynak kayıtlardaki alanları anonimleştirin.

Adım adım: politikayı gerçek iş akışları olarak uygulayın

Bir saklama politikası yazılım davranışı haline geldiğinde işe yarar. Girdi/çıktıları tanımlayın, eylemleri tanımlayın ve sonuçları görünür yapın.

Bir sayfa uzunluğunda bir matrisle başlayın. Her veri türü için saklama penceresini, tetikleyiciyi ve sonra ne olacağını (tut, arşivle, sil, anonimleştir) kaydedin. İnsanlar bir dakikada açıklayamıyorsa, uygulanmaz.

Kayıtların "gizemli şekilde kaybolmaması" için net yaşam döngüsü durumları ekleyin. Çoğu uygulama üç durumla idare eder: active, archived ve pending delete. Durumu kaydın kendisinde saklayın, sadece bir tabloda değil.

Pratik uygulama sırası:

1. Saklama matrisini oluşturun ve ürün, hukuk ve operasyonun erişebileceği bir yerde saklayın.
2. Yaşam döngüsü alanları ekleyin (archived_at, delete_after gibi) ve ekranları ile API'leri bu alanları dikkate alacak şekilde güncelleyin.
3. Zamanlanmış işler uygulayın (günlük yaygın): biri arşivlesin, diğeri süre geçmiş olanları temizlesin veya anonimleştirsin.
4. İstisna yolunu ekleyin: kim silmeyi durdurabilir, ne kadar süreyle ve hangi gerekçe kaydedilmeli.
5. Üretime benzer bir kopyada test edin, sonra kilit raporları (sayım, toplam, funnel) önce ve sonra karşılaştırın.

Örnek: destek talepleri 90 gün aktif kalıp sonra 18 ay arşivde kalabilir, ardından anonimleştirilebilir. İş akışı talepleri arşivlenmiş olarak işaretler, büyük ekleri daha ucuz depolamaya taşır, talep ID'lerini ve zaman damgalarını tutar ve isim/eposta gibi alanları anonim değerlerle değiştirir.

AppMaster içinde yaşam döngüsü durumları Data Designer'da tutulabilir ve arşiv/purge mantığı zamanlanmış Business Process'ler olarak çalıştırılabilir. Amaç, tekrarlanabilir koşular ve kolay denetlenebilir loglardır.

Veri kaybına veya bozuk raporlara yol açan yaygın hatalar

Çoğu saklama hatası seçilen zaman penceresinden kaynaklanmaz. Yanlış tabloların silinmesi, ilişkili dosyaların atlanması veya raporların dayandığı anahtarların değiştirilmesi ile olur.

Yaygın bir senaryo: destek ekibi "eski talepleri" siler ama eklerin ayrı bir tabloda veya dosya depolamada durduğunu unutur. Sonra bir denetçi iade kanıtı ister; talep metni varsa ama ekran görüntüleri yoktur.

Diğer tuzaklar:

• Ana kaydı silip yan tablolarda (ekler, yorumlar, denetim logları) yetim kayıtlar bırakmak
• Finans, güvenlik veya uyumun hala toplamları uzlaştırmak için ihtiyaç duyduğu ham olayları yok etmek
• Soft delete'e sonsuza kadar güvenmek, veritabanının büyümesine ve silinmiş verinin dışa aktarımlarda görünmesine neden olmak
• Anonimleştirme sırasında tanımlayıcıları (ör. user_id) değiştirip panoları, joinleri ve kaydedilmiş sorguları güncellememek
• İstisnalar ve hukuki bekletmeler için sorumlu atanmadığı için insanların kuralları atlaması

Başka bir sık hataysa raporların kişi tabanlı anahtarlarla kurulmasıdır. E-posta ve isimlerin üzerine yazmak genellikle sorun olmaz. Ancak dahili kullanıcı ID'sini değiştirmek bir kişinin geçmişini sessizce birden çok kimliğe böler; aylık aktif kullanıcı veya yaşam boyu değer raporları kayar.

İki çözüm çoğu ekibe yardımcı olur. Birincisi, asla değişmeyen raporlama anahtarları tanımlayın (örneğin dahili hesap ID'si) ve bunları anonimleştirilecek kişisel alanlardan ayırın. İkincisi, silmeyi tüm ilişkili veriyi kapsayacak bir iş akışı olarak uygulayın; dosyalar ve loglar dahil. AppMaster'da bu genellikle bir Business Process ile kullanıcı veya hesaptan başlayıp bağımlılıkları toplayıp sonra güvenli sırayla silme/anonimleştirme şeklinde olur.

Son olarak, kimlerin hukuki bekletmeyi durdurabileceğini ve bu durdurmanın nasıl kaydedileceğini belirleyin. Kimsenin istisna sahibi yoksa politika tutarsız uygulanacaktır.

Her şeyi açmadan önce hızlı kontroller

Silme veya arşivleme işlerini çalıştırmadan önce gerçekçi bir kontrole tabi tutun. Çoğu başarısızlık, verinin kimin sorumluluğunda olduğunun, kopyaların nerede saklandığının veya raporların bunlara nasıl bağımlı olduğunun bilinmemesinden kaynaklanır.

Bir saklama politikası net sorumluluk ve test edilebilir bir plan gerektirir; sadece bir doküman değil.

Başlatma öncesi kontrol listesi

• Her veri seti için bir sahip atayın (değişiklikleri onaylayacak ve soruları yanıtlayacak kişi).
• Her kategori için bir saklama penceresi ve tetik doğrulayın (örnek: "talep kapandıktan 90 gün sonra" veya "son girişten 2 yıl sonra").
• Aynı kaydı göründüğü her yerde bulabileceğinizi kanıtlayın: veritabanı, dosya depolama, dışa aktarımlar, loglar, analiz kopyaları ve yedekler.
• Arşivlerin kullanışlı kalmasını doğrulayın: arama ve join için minimal alanları tutun (ID'ler, tarihler, durum) ve nelerin atıldığını belgeleyin.
• Kanıt üretebildiğinizden emin olun: ne silindi veya anonimleştirildi, ne zaman çalıştı ve hangi kural takip edildi.

Basit bir doğrulama kuru çalışma (dry run) yapmaktır: küçük bir parti (örneğin bir müşterinin eski vakaları) alıp iş akışını test ortamında çalıştırın, sonra kilit raporları önce ve sonra karşılaştırın.

"Kanıt" nasıl görünmeli

Kişisel veriyi yeniden getirmeyecek şekilde kanıt saklayın:

• İş çalıştırma logları: zaman damgaları, kural adı ve kayıt sayıları
• Eylemi (silindi veya anonimleştirildi) ve kayıt ID'lerini içeren değiştirilemez bir denetim tablosu
• Hukuki bekletmede olan öğeler için kısa bir istisna listesi
• Beklenenin sabit kaldığını gösteren bir rapor anlık görüntüsü

AppMaster üzerine inşa ediyorsanız, bu kontroller uygulanabilir: Data Designer'da saklama alanları, Business Process Editor'da zamanlanmış işler ve açık denetim çıktıları.

Örnek: raporlamayı bozmadan çalışan bir müşteri portalı saklama planı

Bir müşteri portalı düşünün: destek talepleri, faturalar ve iadeler ile ham etkinlik loglarını (girişler, sayfa görüntülemeleri, API çağrıları) saklıyor. Amaç, risk ve depolama maliyetini azaltmak; faturalama, denetim veya trend raporlamayı bozmayacak şekilde.

Önce muhafaza edilmesi gereken veriyi günlük destek için kullanılan veriden ayırın.

Basit bir saklama programı şöyle olabilir:

• Destek talepleri: kapanıştan sonra 18 ay boyunca tam içerik saklanır
• Faturalar ve ödeme kayıtları: 7 yıl saklanır
• Ham etkinlik logları: 30 gün saklanır
• Güvenlik denetim olayları (yönetici değişiklikleri, izin güncellemeleri): 12 ay saklanır

Eski talepler için bir arşiv adımı ekleyin. Her mesajı sonsuza kadar ana tablolarda tutmak yerine, kapanmış ve 18 aydan eski talepleri arşiv alanına taşıyın ve küçük bir aranabilir özet tutun: talep ID, tarihler, ürün alanı, etiketler, çözüm kodu ve son temsilci notundan kısa bir alıntı. Bu, tam kişisel detayı tutmadan bağlamı korur.

Kapatılmış hesaplar için eğilimleri korumak istiyorsanız silme yerine anonimleştirmeyi seçin. Kişisel tanımlayıcıları (isim, e-posta, adres) rastgele tokenlarla değiştirin; ancak plan tipi ve aylık toplamlar gibi kimliksiz alanları tutun. Uzun vadeli kullanım trendleri ayrı bir raporlama tablosunda (günlük aktif kullanıcı sayıları, aylık bilet sayıları, aylık gelir) saklansın; bu tabloda kişisel veri olmasın.

Aylık raporlama değişebilir ama planlıysa daha kötüye gitmemeli:

• Talep hacmi trendleri etiketler ve çözüm kodları sayesinde bozulmaz; tam metne ihtiyaç yoktur
• Gelir raporlaması faturalar sayesinde stabil kalır
• Uzun vadeli kullanım trendleri ham loglar yerine agregatlardan türetilebilir
• Kohortlar kimlikten hesap seviyesine kayabilir

AppMaster içinde arşiv ve anonimleştirme adımları zamanlanmış Business Process'ler olarak çalıştırılabilir, böylece politika her seferinde aynı şekilde işler.

Sonraki adımlar: politikayı tekrarlanabilir otomasyona dönüştürün

Saklama politikası insanlarca takip edilebilir ve sistem tarafından tutarlı uygulanırsa işler. Basit bir saklama matrisiyle başlayın: her veri seti, sahip, pencere, tetik, sonraki eylem (arşivle, sil, anonimleştir) ve onay. Hukuk, güvenlik, finans ve destek ekibiyle gözden geçirin.

Her şeyi bir anda otomatikleştirmeyin. Önce bir veri kümesini uçtan uca alın; genelde destek talepleri veya giriş logları gibi yaygın bir şeyi seçin. İş akışını gerçek yapın, bir hafta çalıştırın ve raporlamanın iş beklentisiyle uyuştuğunu doğrulayın. Sonra aynı deseni kalan veri kümelerine tekrar edin.

Otomasyonu gözlemlenebilir kılın. Temel izleme genellikle şunları kapsar:

• İş hataları (arşiv veya temizleme çalıştı mı ve bitti mi?)
• Arşiv büyümesi (depolama eğilimi)
• Silme birikimi (uygun ama işlenmemiş öğeler)
• Rapor sapması (saklama çalıştırıldıktan sonra kilit metriklerde değişim)

Kullanıcı tarafını da planlayın. Kullanıcıların ne isteyebileceğine karar verin (dışa aktarma, silme, düzeltme), kim onaylar ve sistem ne yapar. Desteğe kısa bir dahili senaryo verin: hangi veriler etkilenir, ne kadar sürer ve silindikten sonra ne geri alınamaz.

Eğer özel kod yazmadan uygulamak istiyorsanız, AppMaster (appmaster.io) saklama otomasyonu için pratik bir çözüm sunar: Data Designer'da yaşam döngüsü alanlarını modelleyip, zamanlanmış arşiv ve anonimleştirme Business Process'leri ile denetim logları üretebilirsiniz. Bir veri kümesiyle başlayın, işleri sıkıcı ve güvenilir kılın, sonra deseni tekrarlayın.