Neredeyse her işletme sahibi "bizim panelde log var" der. Sonra bir kod iki kez teslim edilir, bir bakiye açıklanamaz şekilde eksilir, bir müşteri ödemesini reddeder ve o loglara bakılır. Görülen şey genellikle şudur: sunucu hataları, birkaç uyarı, bir yığın teknik satır. Yani sistemin kendi hatalarının kaydı vardır ama kimin ne yaptığının kaydı yoktur. Bu ikisi aynı şey değildir ve aralarındaki fark, bir itirazı kazanmakla kaybetmek kadar büyüktür.
Bir e-pin satış scriptinde asıl ihtiyaç duyduğun şey hata günlüğü değil, denetim izidir. Denetim izi bir soruyu cevaplar: bu kayıt hangi tarihte, hangi kullanıcı tarafından, hangi adresten, hangi eski değerden hangi yeni değere çevrildi? Hata günlüğü sistemin sağlığıyla, denetim izi ise sorumlulukla ilgilenir. Bu yazıda dijital ürün satış yazılımında denetim izini hangi olaylardan kuracağını, ne kadar süre saklayacağını, nasıl bozulmaz hâle getireceğini ve bunun hangi noktada doğrudan paraya dönüştüğünü anlatacağım.
Log tutmakla denetim izi tutmak aynı şey mi?
Değil. Log, teknik ekibin sorun ararken okuduğu akıştır; kısa ömürlüdür, gürültülüdür, sıklıkla döngüyle silinir. Denetim izi ise ticari bir defterdir; yapılandırılmıştır, aranabilir ve uzun ömürlüdür. Birincisi "neden 500 hatası aldık" sorusuna cevap verir, ikincisi "bu 40 kodu havuzdan kim çıkardı" sorusuna. E-pin satan bir işletmenin hayatını kurtaran ikincisidir.
Ayrımı netleştirmenin en kolay yolu şu testtir: kaydı okuyan kişi teknik biri olmak zorunda mı? Denetim izi, muhasebeciye, avukata veya bir ödeme sağlayıcısının inceleme ekibine gösterilebilecek kadar anlaşılır olmalıdır. Bu yüzden satırlar serbest metin değil, alanlara ayrılmış kayıtlar olmalı: aktör, eylem tipi, hedef kayıt, eski değer, yeni değer, zaman, adres, oturum referansı. Bu sekiz alan, bir epin yazılım panelinde denetimin bel kemiğini kurar.
Hangi olaylar mutlaka yazılmalı, hangileri gürültü?
Her şeyi kaydetmek, hiçbir şeyi kaydetmemekle aynı sonuca çıkar: içinde arama yapılamayan bir yığın. Bu yüzden seçici olmalısın. Kural basit: bir eylem parayı, stoku, yetkiyi ya da müşterinin verisini değiştiriyorsa kayda girer. Sayfa görüntülemeleri, listeleme istekleri ve rutin okumalar denetim izine değil, en fazla erişim loguna aittir.
Bu ayrımı yaptığında kayıt hacmi şaşırtıcı biçimde yönetilebilir hâle gelir. Günlük binlerce satır yerine, gerçekten sonuç doğuran yüzlerce satır kalır. Ve her biri okunmaya değer olur. Aşağıdaki tablo, bir dijital ürün satış scriptinde denetim izine girmesi gereken olayları ve her birinden ne beklediğini gösteriyor.
| Olay | Kaydedilecek Ek Alan | Neden Kritik | Öncelik |
|---|---|---|---|
| Kod teslimi | Sipariş no, kod kimliği, alıcı | Çift teslim ve itiraz savunması | Pazarlıksız |
| Stok silme / düzenleme | Etkilenen satır sayısı, eski durum | Kaybolan kod soruşturması | Pazarlıksız |
| Bakiye hareketi | Eski/yeni bakiye, gerekçe | Açıklanamayan bakiye farkı | Pazarlıksız |
| Fiyat ve kâr marjı değişimi | Eski/yeni fiyat | Yetkisiz indirim ve zarar | Yüksek |
| Yetki ve rol değişimi | Eski/yeni rol, işlemi yapan | Sessiz yetki yükseltme | Pazarlıksız |
| Başarılı / başarısız giriş | Adres, cihaz özeti | Hesap ele geçirme tespiti | Yüksek |
| Ödeme ayarı değişimi | Değişen anahtar adı (değeri değil) | Ödemenin başka hesaba yönlendirilmesi | Pazarlıksız |
| İade ve iptal | Gerekçe, onaylayan kişi | Suistimal ve iç risk | Yüksek |
Saklama süresi: 7 gün mü, 24 ay mı?
Bu sorunun tek bir cevabı yok ama bir mantığı var: saklama süresi, olayın ne kadar süre sonra sorun olarak geri dönebileceğine göre belirlenir. Teknik hata logu bir haftada işini yapar. Giriş kayıtları üç ila altı ay anlamlıdır, çünkü bir hesap ele geçirmesi genellikle o pencerede fark edilir. Ödeme, teslim ve bakiye kayıtları ise ticari itiraz ve muhasebe döngüleri nedeniyle en az bir yıl, çoğu durumda iki yıl tutulmalıdır.
Katmanlı saklama burada işi kolaylaştırır. Son 30 günü hızlı erişilebilir tutarsın, sonrasını sıkıştırıp arşive alırsın, en eskiyi soğuk depoya indirirsin. Böylece hem sorgu performansını korursun hem de geçmişi kaybetmezsin. Kritik nokta şudur: arşiv de erişilebilir olmalı. Bir yıl önceki teslim kaydını iki günde çıkaramıyorsan o kayıt pratikte yok demektir.
Denetim izine yapılan başvuruların sebep dağılımı
- Teslim ve ödeme itirazı 45%
- Stok ve bakiye uyuşmazlığı 25%
- Hesap erişimi soruşturması 20%
- İç denetim ve personel devri 10%
Log bütünlüğü: kaydı silen kişi izini de silebiliyor mu?
Denetim izinin en zayıf noktası, panele giren yetkili birinin o izi düzenleyebilmesidir. Eğer yönetim ekranında "log temizle" düğmesi varsa ve bu düğmeye basan kişinin kendisi kayda girmiyorsa, sistemin bütün denetim değeri sıfırdır. Çünkü kayıt, en çok ihtiyaç duyulacağı anda değiştirilebilir durumdadır.
Çözüm üç katmanlıdır. Birincisi sadece ekleme ilkesidir: denetim izi kayıtları güncellenemez ve tek tek silinemez, yalnızca yeni satır eklenir. İkincisi ayrıştırmadır: izler ana veritabanından farklı bir yerde, farklı yetkilerle tutulur; uygulama kullanıcısının silme izni olmaz. Üçüncüsü zincirlemedir: her kayıt kendinden öncekinin özetini taşır, böylece aradan bir satır çıkarıldığında zincir kırılır ve bu fark edilir. Pinova gibi bir altyapıda bu üç önlemin birlikte kurulması, sonradan tek tek eklemekten hem daha güvenli hem daha ucuzdur.
KVKK ve maskeleme: kaydın kendisi risk olmasın
Denetim izi bir varlıktır ama yanlış kurulursa yükümlülüğe dönüşür. İçine tam kart bilgisi, açık e-pin kodu, düz metin şifre veya gereğinden fazla kişisel veri yazarsan, koruman gereken şeyi tek dosyada toplamış olursun. Bir sızıntı senaryosunda en pahalı kayıp, veritabanı değil bu dosya olur.
Doğru yaklaşım maskeleme ve referanslamadır. E-pin kodunun kendisini değil, kodun kimliğini ve son dört karakterini yaz. Kartın numarasını değil, sağlayıcının işlem referansını yaz. Şifreyi hiç yazma; "şifre değiştirildi" olayını yaz. E-posta ve telefon gibi verileri kısmi maskeyle tut. Kişisel veri işlerken saklama süresini, erişim yetkisini ve silme prosedürünü yazılı hâle getir; denetim izi, denetlenebilir olduğu kadar savunulabilir de olmalı. Aşağıdaki kontrol listesi bu dengeyi kurmanı sağlar.
| # | Kontrol | Test | Beklenen |
|---|---|---|---|
| 1 | Denetim izi hata logundan ayrı | Yönetim panelinde iki ayrı ekran var mı | Ayrı olmalı |
| 2 | Sekiz temel alan kayıtlı | Bir fiyat değiştir, kaydı oku | Eski/yeni değer görünmeli |
| 3 | Kayıtlar düzenlenemiyor | Panelden bir izi silmeyi dene | Mümkün olmamalı |
| 4 | Yetki değişimi kayda giriyor | Bir bayiyi yönetici yap | İz oluşmalı |
| 5 | Tam kod ve şifre yazılmıyor | Teslim kaydını incele | Maskeli olmalı |
| 6 | Arşiv erişilebilir | 6 ay öncesine ait kayıt sorgula | Sonuç dönmeli |
| 7 | Saklama süreleri tanımlı | Politika belgesini kontrol et | Yazılı olmalı |
| 8 | Kritik olayda bildirim var | Ödeme ayarını değiştir | Uyarı gelmeli |
Denetim izinin iyi olup olmadığını anlamanın tek yolu şudur: bugün rastgele bir siparişi seç ve o kodun havuza girişinden müşteriye tesliminE kadar olan zinciri beş dakikada çıkar. Çıkaramıyorsan izin eksiktir.
Denetim izi hazır kurulu bir altyapıyla ilerle
Sadece-ekleme mantığıyla çalışan denetim izi, maskeli teslim kayıtları, rol ve ödeme ayarı değişimi bildirimleri ve katmanlı arşiv yapısı bir e-pin satış yazılımının temel parçası olmalı. Özellikleri incele, paketleri karşılaştır.
Hata logları denetim izi yerine geçer mi?
Geçmez. Hata logu sistemin kendi arızalarını anlatır, denetim izi ise kimin hangi kaydı nasıl değiştirdiğini anlatır. İtiraz ve soruşturmalarda işe yarayan ikincisidir.
Logları ne kadar süre saklamalıyım?
Teknik logları haftalarla, giriş kayıtlarını aylarla, ödeme ve teslim kayıtlarını yıllarla ölçmelisin. Ticari itirazların geri dönüş süresi genellikle bir yılı bulur; bu yüzden asgari 12 ay makul bir taban kabul edilir.
E-pin kodunun tamamını kayda yazmalı mıyım?
Hayır. Kodun kimliği ve son karakterleri, teslim zincirini kanıtlamak için yeterlidir. Tam kodu kayda yazmak, satılabilir değeri ikinci bir yerde daha çoğaltmak anlamına gelir.
Denetim izini kim görebilmeli?
Sınırlı bir yetki grubu. Görüntüleme yetkisi rol bazlı olmalı, silme yetkisi hiç kimsede bulunmamalı. İzi görüntüleyen kişinin bu erişimi de ayrıca kayda girmeli.
Denetim izi, iyi günlerde kimsenin bakmadığı ama kötü günde tek dayanağın olan defterdir. Hangi olayların yazılacağını bugün belirle, saklama sürelerini yazıya dök, kayıtları değiştirilemez hâle getir ve kritik değişikliklerde kendine bildirim kur. Böylece bir kod kayboldığında, bir bakiye tutmadığında ya da bir ödeme itiraz edildiğinde tahmin yürütmek yerine kayıt gösterirsin. Bu yapının gerçek bir panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinden bir işlem yapıp denetim izi ekranında kendi bıraktığın izi takip edebilirsin.