Uyumluluk için: veritabanı denetim tabloları ve uygulama logları

Bir sorun çıktığında uyumluluk ekiplerinin ihtiyaç duyduğu şeyler

Bir şey ters gittiğinde, uyumluluk ekipleri sadece dosya toplamakla kalmaz, olayı yeniden inşa etmeye çalışır. Sorular basittir, ancak yanıtların ispatlanabilir olması gerekir.

Kimin yaptığını (kullanıcı, rol, servis hesabı), neyin değiştiğini (önce ve sonra), ne zaman olduğunu (zaman dilimi ve sıra dahil), nerede olduğunu (ekran, API uç noktası, cihaz, IP) ve neden olduğunu (talep, gerekçe alanı, onay adımı) bilmek isterler.

Bu yüzden "loglarımız var" demek gerçek denetimlerde sık sık yetersiz kalır. Loglar kesintiler sırasında kaybolabilir, çok hızlı dönebilir, çok fazla sistemde dağılmış olabilir veya ihtiyacınız olan tek olayı gürültü içinde saklayabilir. Ayrıca birçok log, uygulamanın ne yapmaya çalıştığını anlatır, veritabanında gerçekte neyin değiştiğini değil.

Yararlı bir soruşturma iki tür kanıtı ayırır:

• Veri değişiklikleri nihai durumu kanıtlar: hangi kayıtların değiştiği, kesin önce/sonra değerleri.
• Eylemler niyeti ve bağlamı açıklar: hangi ekran veya API çağrısının kullanıldığı, hangi kuralın çalıştığı ve bir onay adımının olup olmadığı.

Basit bir kural kapsamı belirlemenize yardımcı olur. Bir değişiklik para, erişim, yasal koşullar, güvenlik veya müşteri güvenini etkileyebiliyorsa, onu denetlenebilir bir olay olarak ele alın. Eylemi ve ortaya çıkan veri değişikliğini gösterebilmelisiniz; bunlar farklı yerlerde (örneğin veritabanı denetim tabloları ve uygulama logları) yer alabilir.

AppMaster gibi bir platformda araçlar inşa ediyorsanız, bunu erken tasarlamak faydalıdır: gerekçeleme alanları ekleyin, aktör kimliğini tutarlı takip edin ve kilit iş akışlarının net bir iz bırakmasını sağlayın. Bu temelleri bir olaydan sonra eklemek, denetimleri yavaş ve stresli hale getirir.

Veritabanı denetim tablolarının iyi yakaladığı şeyler

Veritabanı denetim tabloları, uygulamanın ne yaptığını söylediğinden daha güvenilir bir veri geçmişine ihtiyaç duyduğunuzda en güçlüdür. Bir soruşturmada genellikle şu sorulara yanıt verir: hangi kayıt değişti, hangi değerler değişti, kim yaptı ve ne zaman.

Sağlam bir denetim satırı çıkarımlardan kaçınarak olguları yakalar: tablo adı ve kayıt tanımlayıcısı, eylem (insert, update, delete), zaman damgası, aktör (kullanıcı ID'si veya servis hesabı) ve önce/sonra değerleri. Bir istek veya oturum ID'si saklarsanız, değişikliği belirli bir iş akışına bağlamak çok daha kolay olur.

Satır seviyesinde geçmiş, bir kaydı zaman içinde yeniden inşa etmek gerektiğinde iyidir. Genellikle her değişiklik için JSON olarak saklanan “before” ve “after” sütunları şeklinde anlık görüntü olarak çalışır. Alan düzeyinde geçmiş, soruşturmacıların sık sık "telefon numarasını kim değiştirdi?" gibi sorular sorduğu durumlarda veya daha küçük, aranabilir kayıtlar istediğinizde daha iyidir. Ancak alan düzeyinde takip satır sayısını çoğaltabilir ve raporlamayı karmaşıklaştırabilir.

Silmeler, denetim tablolarının gerçekten fayda sağladığı alandır, tabii ki doğru şekilde temsil edildiklerinde. Birçok ekip silme eylemini kaydeder ve silinen kaydın son bilinen “önce” anlık görüntüsünü saklar, böylece neyin kaldırıldığını kanıtlayabilirler. "Geri yükleme" destekliyorsanız bunu ayrı bir eylem (veya durum değişikliği) olarak ele alın; sanki silme hiç olmamış gibi davranmayın. Bu, zaman çizelgesinin dürüst kalmasını sağlar.

Veritabanı tetikleyicileri, birisi uygulamayı atlayıp doğrudan yazdığında bile değişiklikleri yakaladıkları için yardımcı olabilir. Ancak şemalar hızlı evrilirken, tablolara göre farklı mantık olduğunda veya gürültülü alanları hariç tutmanız gerektiğinde yönetimleri zorlaşır. Denetim tabloları en iyi, tutarlı şekilde oluşturulduğunda ve şema değişiklikleriyle senkron tutulduğunda çalışır.

İyi yapıldığında, denetim tabloları zaman noktasına göre yeniden inşa etmeyi destekler. Değişiklikleri sırayla tekrar oynatarak bir kaydın belirli bir andaki halini yeniden oluşturabilirsiniz. Bu, uygulama loglarının tek başına genellikle sağlayamadığı bir kanıttır.

Uygulama loglarının iyi yakaladığı şeyler

Uygulama logları bir olay etrafındaki hikâye için daha iyidir, sadece nihai veritabanı değişikliği için değil. Bu loglar sisteminizin kenarında, isteklerin geldiği, kontrollerin yapıldığı ve kararların alındığı yerde oturur.

Soruşturmalar için loglar yapılandırılmış olduğunda (alanlar, cümleler değil) en iyi sonucu verir. Pratik bir temel, bir korelasyon/istek ID'si, kullanıcı ID'si (ve mümkünse rol), bir eylem adı, bir sonuç (izin/verme, başarı/hata) ve gecikme veya hata kodunu içeren bir kayıttır.

Loglar veritabanının asla bilemeyeceği bağlamı da yakalayabilir: kullanıcının hangi ekranda olduğu, cihaz türü, uygulama sürümü, IP adresi, UI “gerekçe kodları” ve eylemin insan tıklaması mı yoksa otomatik bir iş mi olduğu. Birisi "Bunu asla onaylamadım" iddiasında bulunduğunda, bu bağlam genellikle belirsiz bir iddiayı net bir zaman çizelgesine dönüştürür.

Hata ayıklama logları, güvenlik logları ve denetim logları aynı şey değildir

Hata ayıklama (debug) logları mühendislerin hataları düzeltmesine yardımcı olur. Genellikle gürültülüdür ve yanlışlıkla hassas veri içerebilir.

Güvenlik logları tehditlere ve erişime odaklanır: başarısız girişler, izin reddleri, şüpheli desenler.

Denetim logları hesap verebilirlik içindir. Zaman içinde tutarlı olmalı ve uyumluluk ekibinizin arayabileceği ve dışa aktarabileceği bir formatta yazılmalıdır.

Sık yapılan bir hata sadece API katmanında loglama yapmaktır. Doğrudan veritabanı yazıları (yönetici scriptleri, migration'lar), istek yolunun dışında veri değiştiren arka plan çalışanları, bir eylemi iki kez uygulayan tekrar denemeler ve ödemeler veya mesajlaşma gibi entegrasyonların tetiklediği eylemler kaçabilir. "Yakın kaçışlar" da önemlidir: reddedilen denemeler, engellenen dışa aktarımlar, başarısız onaylar.

AppMaster gibi bir platform kullanıyorsanız, logları bağlayıcı doku olarak ele alın. Bir istek ID'sinin bir kullanıcı eylemini UI, iş mantığı ve dışa giden entegrasyonlar boyunca takip etmesi soruşturma süresini dramatik şekilde kısaltabilir.

Hangi yaklaşım hangi soruları yanıtlar

Denetim tabloları ile uygulama logları arasında karar vermenin en iyi yolu, soruşturmacıların soracağı soruları yazmaktır. Pratikte nadiren ya/veya durumu vardır. İki kaynak hikâyenin farklı parçalarını yanıtlar.

Denetim tabloları, soru veri gerçeğiyle ilgiliyse en iyisidir: hangi satır değişti, hangi alanlar değişti, önce/sonra değerleri ve değişikliğin ne zaman işleneceği. Birisi "Dün saat 15:12'de hesap limiti neydi?" diye soruyorsa, bir denetim tablosu bunu net şekilde yanıtlayabilir.

Uygulama logları ise niyet ve bağlamla ilgili soruları yanıtlar: kullanıcı veya sistem ne yapmaya çalıştı, hangi ekran veya API uç noktası kullanıldı, hangi parametreler sağlandı ve hangi doğrulamalar veya hatalar oldu. "Kullanıcı bu değişikliği denedi ve engellendi mi?" sorusuna genellikle sadece loglar cevap verir.

Basit bir eşleme yardımcı olur:

• "Kayıtta tam olarak ne değişti?" Denetim tablolarıyla başlayın.
• "Eylemi kim başlattı, nereden ve hangi yolla?" Uygulama loglarıyla başlayın.
• "Engellendi mi, tekrarlandı mı veya kısmen tamamlandı mı?" Genellikle loglar anlatır.
• "Her şey tamamlandıktan sonra veritabanında ne kaldı?" Denetim tabloları bunu doğrular.

Bazı alanlar neredeyse her zaman her iki kaynağı gerektirir: hassas verilere erişim, onaylar, ödemeler/iadeler, izin değişiklikleri ve yönetici eylemleri. İstekte bulunan ve nihai durumu gösterecek kanıtlara sahip olmak istersiniz.

Kapsamı yönetilebilir tutmak için kısa bir düzenlenen alanlar ve eylemler listesiyle başlayın: KVK/PII, banka bilgileri, fiyatlandırma, roller ve parayı veya erişimi değiştiren her şey. Bu alanları tutarlı şekilde denetleyin ve etraflarındaki ana olayları loglayın.

Ayrıca otomatik işleri ve entegrasyonları ilk sınıf aktörler olarak ele alın. Aktör türünü (insan, zamanlanmış iş, API istemcisi) ve kararlı bir tanımlayıcıyı (kullanıcı ID, servis hesabı, entegrasyon anahtarı) kaydedin, böylece soruşturmacılar bir kişinin eylemlerini otomasyondan ayırabilir. AppMaster gibi platformlar iş mantığını merkezileştirerek aynı aktör meta verisinin hem veri değişikliklerine hem de log olaylarına eklenmesini kolaylaştırabilir.

Aranabilirlik: baskı altındayken hızlıca yanıt bulma

Gerçek bir soruşturmada kimse her şeyi baştan okumaya başlamaz. Amaç hızdır: bir şikayetten doğru eylemler, kayıtlar ve kişiler bulunabiliyor mu?

Çoğu soruşturma birkaç filtreyle başlar: aktör, kayıt/nesne ID'si, dar bir zaman aralığı (zaman dilimi ile), eylem türü (create, update, delete, export, approve) ve kaynak (web, mobil, entegrasyon, arka plan işi).

Denetim tabloları sorgular için tasarlandığında aranabilir kalır. Pratikte bu, insanların nasıl aradığıyla eşleşen indeksler demektir: hedef kayıt için bir indeks (nesne türü + kayıt ID), aktör için bir indeks ve zaman için bir indeks (zaman damgası). Bir eylem alanı ve bir istek/işlem ID'si saklarsanız, filtreleme tablonun büyümesiyle birlikte hızlı kalır.

Uygulama logları da yapılandırılmışlarsa aynı şekilde aranabilir olabilir. Serbest metin loglar her aramayı bir anahtar kelime avına çevirir. JSON benzeri tutarlı alanları tercih edin: actor_id, action, object_type, object_id ve request_id. Korelasyon ID'leri önemlidir çünkü bir kullanıcı tıklamasının birden fazla API çağrısını ve arka plan adımlarını nasıl tetiklediğini anlamanızı sağlar.

Pratik bir desen, her iki kaynağı birleştiren bir "denetim görünümü"dür. Denetim tablosu veri değişikliklerinin yetkili listesini sağlar. Seçilmiş log olayları bağlam sunar: giriş, izin kontrolleri, onay adımları ve reddedilen denemeler. AppMaster ile oluşturulan araçlarda bu genellikle iş süreçlerine güzelce uyar; tek bir istek kimliği UI eylemini, backend mantığını ve nihai veritabanı güncellemesini birbirine bağlar.

Uyumluluk ve güvenlik ekiplerinin sorduğu raporlar genellikle tahmin edilebilirdir: tek bir kayıt için değişim geçmişi, hassas veriye erişim geçmişi (görüntüleme veya dışa aktarma), onay izleri, yönetici eylemleri (rol değişiklikleri, parola sıfırlama, hesap devre dışı bırakma) ve istisnalar (reddedilen erişimler, doğrulama hataları).

Geçmişi değiştirilemez kılmak ama abartmamak

Uyumluluk çalışmaları için hedef genellikle değiştirilemezin kanıtlanmasıdır, tamamen "değiştirilemez" bir geçmiş değil. Değişiklikleri yapmak zor, tespit etmek kolay ve iyi kayıt altına almak istersiniz; uygulamayı yavaş bir evrak makinesine dönüştürmeden.

Append-only (sadece ekleme) bir tasarımla başlayın. Denetim kayıtlarını fiş gibi değerlendirin: yazıldıktan sonra düzenlenmez. Bir şey düzeltilmesi gerekirse eski girdiyi yeniden yazmak yerine düzeltmeyi açıklayan yeni bir olay ekleyin.

Sonra veritabanı düzeyinde kimin ne yapabileceğini kilitleyin. Yaygın bir desen şöyledir: uygulama denetim satırlarını ekleyebilir, soruşturmacılar okuyabilir ve normal işlemlerde hiçbir kimse (uygulama dahil) bunları silemez. Silmeler gerekliyse, bunları ekstra onaylar ve otomatik uyarılarla ayrı bir break-glass rolünün arkasına koyun.

Olası manipülasyonları tespit etmek için hafif bütünlük kontrolleri ekleyin. Her satırda sır saklamanız gerekmez, ama her denetim olayının anahtar alanlarının karmasını saklayabilir, olayları zincirleyecek şekilde önceki olayın karmasını dahil edebilir ve periyodik olarak (örneğin saatlik) bu karmaların imzalarını daha sıkı erişime sahip bir yerde saklayabilirsiniz. Risk düzeyiniz yüksekse, denetim olaylarını iki farklı yere (veritabanı + değiştirilemez depolama) yazmak bir seçenektir. Ayrıca sadece iş eylemlerini değil, denetim tablolarına erişimi de loglayıp inceleyin.

Saklama politikasını yakalama kadar önemli görün. Denetim kanıtlarının ne kadar süreyle tutulduğunu, neyin temizlendiğini ve bir soruşturma başladığında silme işlemlerinin nasıl durdurulacağını tanımlayın.

Son olarak, operasyonel logları denetim kanıtından ayırın. Operasyonel loglar mühendislerin hata ayıklamasına yardımcı olur ve genellikle gürültülüdür veya hızlı döner. Denetim kanıtı yapılandırılmış, minimal ve stabil olmalıdır. AppMaster ile inşa ediyorsanız, iş olayları denetim tablolarına, teknik hatalar ve performans ayrıntıları uygulama loglarına gitmeli; ayrımı net tutun.

Performans: denetimin kullanıcı deneyimini bozmasını önlemek

Eğer denetim izi uygulamayı yavaşlatıyorsa, insanlar onu atlatmak için yollar bulur. İyi performans uyumluluğun bir parçasıdır çünkü eksik veya atlanan eylemler daha sonra açıklanamaz boşluklar yaratır.

Yaygın darboğazlar

Çoğu yavaşlık, denetimin kullanıcının isteğine ağır işler eklemesinden kaynaklanır. Yaygın sebepler arasında UI yanıtı vermeden önce tamamlanması gereken eş zamanlı yazmalar, tetikleyicilerin ekstra sorgular yapması veya her değişiklikte büyük JSON blob'ları yazması, geniş ve hızlı büyüyen indeksli denetim tabloları ve "her şeyi logla" tasarımları bulunur. Bir diğer sorun da tek bir tabloda aylarca veri tarayan denetim sorgularıdır.

Pratik bir kural: kullanıcı denetim için bekliyorsa, sıcak yolda (hot path) çok fazla iş yapıyorsunuz demektir.

Kanıtı korurken düşük etkili desenler

Yakalama ile soruşturma adımını ayırarak deneyimi hızlı tutabilirsiniz. Gerekli minimum kanıtı hızla yazın, sonra detayları arka planda zenginleştirin.

Bir yaklaşım, hemen değişikliğin "kimi, hangi kaydı, ne zaman" bilgilerini kaydetmek, ardından bir arka plan işinin (background worker) ek bağlamı veya hesaplanmış alanları eklemesine izin vermektir. AppMaster'da bu genellikle hafif bir İş Süreci (Business Process) ile çekirdek olayı kaydetmek ve detayları asenkron bir süreçle zenginleştirmek şeklinde eşleşir.

Denetim tablolarını zamanla partition edin (günlük veya aylık) ki eklemeler tahmin edilebilir kalsın ve aramalar hızlı olsun. Ayrıca saklamayı daha güvenli kılar: eski partitionları düşürerek büyük silme işleri ve kilitlenmeleri önleyebilirsiniz.

Hata ayıklama logları için örnekleme (örneğin her 100 isteğin 1'i) uygundur, ancak denetim kanıtı için genellikle kabul edilemez. Bir eylem soruşturmada önemli olabiliyorsa, her seferinde kaydedilmelidir.

Büyüme sürpriz olmadan önce saklama süresini erkenden belirleyin. Hangi verinin denetimler için tutulması gerektiğini (genellikle daha uzun), hangi verinin sorun giderme için gerektiğini (genellikle daha kısa) ve hangi verinin toplanabileceğini kararlaştırın. Politikayı belgeleyin ve partition rollover veya planlı temizleme işleriyle otomatik uygulayın.

Adım adım: soruşturmalar için denetim izi tasarlama

Bir soruşturma başladığında, ne yakalamış olmanız gerektiği tartışacak zaman yoktur. İyi bir tasarım hikâyeyi kolayca yeniden kurar: ne değişti, kim yaptı, ne zaman oldu ve nereden geldi.

1. Sizi en çok zarara uğratabilecek eylemlerle başlayın. Kanıtlanması "olmazsa olmaz" anları belirleyin: izin değişiklikleri, ödemeler, iadeler, hesap kapatmaları, fiyat düzenlemeleri ve dışa aktarmalar. Her biri için hangi alanların kesin olarak kanıtlanması gerektiğini (eski değer, yeni değer ve ait olduğu kayıt) listeleyin.
2. Net bir aktör modeli tanımlayın. Bir kişiyi, yöneticiyi ve otomatik işi nasıl tanımlayacağınızı kararlaştırın. Her seferinde aktör türü ve aktör ID'sini ekleyin; ayrıca tenant/hesap, istek ID'si ve gerektiğinde bir gerekçe notu gibi bağlamları da ekleyin.
3. Sorumlulukları tablolara ve loglara bölün; kritik olaylarda örtüşme sağlayın. Kesin sorgulanması gereken veri değişiklikleri için denetim tablolarını kullanın (önce/sonra değerleri). Etrafındaki hikâye (doğrulama hataları, iş akışı adımları, dış çağrılar) için logları kullanın. Yüksek riskli eylemler için her iki kaynağı da kaydedin ki "ne değişti" ve "neden oldu" sorularını yanıtlayabilesiniz.
4. Olay adlandırmasını ve şemaları erkenden kilitleyin. Stabil olay adları seçin (örneğin user.role.updated) ve tutarlı bir alan seti belirleyin. Değişiklik bekliyorsanız, şemayı versiyonlayın ki eski olaylar daha sonra da mantıklı kalsın.
5. Arama, saklama ve erişimi baştan planlayın, sonra tatbik edin. Soruşturmacıların filtrelediği alanları indeksleyin (zaman, aktör, kayıt ID, olay adı). Saklama kurallarını politika ile eşleştirin. Denetim deposuna yazma erişimini kısıtlayın ve gerçek arama senaryolarını zaman baskısı altında test edin.

Örnek: bir yönetici bir müşterinin ödeme hesap bilgisini değiştiriyorsa, denetim tablonuz eski ve yeni hesap tanımlayıcılarını göstermelidir. Loglar yönetici oturumunu, herhangi bir onay adımını ve arka plan işinin güncellemeyi tekrar denemiş olup olmadığını yakalamalıdır.

Örnek: anlaşmazlığa düşülen bir yönetici değişikliğinin soruşturulması

Bir müşteri, planının onay olmadan yükseltildiğini iddia ediyor. Destek temsilciniz sadece hesabı açtığını ve faturalamayı değiştirmediğini söylüyor. Uyumluluk net bir zaman çizelgesine ihtiyaç duyuyor: ne değişti, kim tetikledi ve sistem bunu izin verdi mi?

Denetim tablosu veri değişiklikleri hakkında somut gerçekler verir. Tek bir customer_id için şu tür bir giriş çekebilirsiniz: plan_id 2026-01-12 10:14:03 UTC'de Basic'ten Pro'ya değişti, actor_id 1942 tarafından. Denetim tasarımınız alan bazlı eski ve yeni değerleri (veya tam satır anlık görüntüsünü) saklıyorsa, tam önce ve sonra değerlerini tahmin etmeden gösterebilirsiniz.

Uygulama logları ise denetim tablolarının genellikle veremediği soruları yanıtlar. İyi bir log kaydı başlatan eylemi gösterir: temsilci yönetici ekranda "Plan değiştir" düğmesine tıkladı, istek izin kontrollerinden geçti, fiyatlandırma kuralı uygulandı ve API 200 döndü. Ayrıca veritabanına ait olmayan bağlamı yakalar: IP adresi, user agent, özellik bayrağı durumu ve UI'ye girilen gerekçe kodu.

Aradaki köprü bir korelasyon ID'sidir. API bir request_id (veya trace_id) üretir ve her adım için uygulama loglarına yazar. Veritabanı güncellemesi gerçekleştiğinde aynı ID denetim tablosu satırına (veya denetim metadata'sına) yazılır. Bu sayede iki yönden çalışabilirsiniz:

• Denetim tablosundan: plan değişikliğini bulun, request_id alın ve eşleşen log dizisini çekin.
• Loglardan: yönetici eylemini bulun, request_id alın ve hangi satırların değiştiğini doğrulayın.

Denetçilere kanıt verirken, olayı doğrulayanı dışa aktarın, tüm müşteri kaydını değil. Temiz bir paket genellikle zaman aralığını kapsayan denetim satırlarını (eski ve yeni değerlerle), request_id ile filtrelenmiş eşleşen log girdilerini (yetkilendirme ve kontrolleri gösteren), actor_id'nin hangi destek temsilcisine denk geldiğini gösteren bir eşlem dosyasını ve request_id'nin nasıl üretildiği ve saklandığına dair kısa bir açıklamayı içerir.

AppMaster üzerinde inşa ediyorsanız, request_id'yi backend iş akışlarında birinci sınıf alan yapın ki aynı ID API çağrısından saklanan denetim geçmişine kadar takip edilebilsin.

Denetimleri zorlaştıran yaygın hatalar

En büyük başarısızlıklar sadece eksik veri değildir. Güvenilmez, aranamaz veya bir kişiye ve belirli bir ana bağlanamayan veriye sahip olmaktır.

Yaygın bir tuzak, serbest metin mesajlarına güvenmektir. "Müşteri ayarları güncellendi" gibi bir satır faydalı görünür, ta ki alan adına, eski değere, yeni değere veya etkilenen kayda göre filtrelemek gerektiğinde binlerce satırı elle okumak zorunda kalana kadar. Yapılandırılmamışsa işe yaramaz.

Bir diğer hata her şeyi denetlemektir. Ekipler "tüm olayları logla" moduna geçirir ve öyle bir gürültü oluştururlar ki gerçek olaylar kaybolur. İyi bir denetim izi seçicidir: veriyi değiştiren, erişimi değiştiren veya parayı hareket ettiren eylemlere odaklanın.

Soruşturmaları en çok yavaşlatan sorunlar şunlardır: tutarlı alanlar olmadan serbest metin loglar (actor, action, entity, entity_id, before, after), düşük değere sahip olayların aşırı hacmi, arka plan işleri ve entegrasyonlar için eksik aktör kimliği, normal uygulama rolleri tarafından düzenlenebilen veya silinebilen denetim satırları ve gerçek soruların hızlı yanıtlanabilirliğini doğrulamak için provaların yapılmaması.

Arka plan işler özel dikkat ister. Bir gece senkronizasyonu 5.000 kayıt değiştiriyorsa, "system" bir aktör değildir. Hangi entegrasyonun çalıştığını, hangi sürümün kullanıldığını ve hangi girdinin bunu tetiklediğini kaydedin. Birden çok aracın uygulamanıza yazabildiği durumlarda bu kritik hale gelir.

Basit bir "10 dakikalık test" çoğu problemi erken yakalar. Gerçekçi üç soru seçin ("Kimin ödeme e-postasını değiştirdi? Önceki değer neydi? Nereden?" gibi) ve kendinizi zamanlayın. 10 dakikada cevap veremiyorsanız, şemayı, filtreleri ve izinleri şimdi düzeltin, olay sırasında değil.

AppMaster ile inşa ediyorsanız, denetim olaylarını yapılandırılmış, kilitlenmiş ve kolay sorgulanabilir birincil veriler olarak ele alın; sonradan doğru log satırının var olacağına umut bağlamayın.

Hızlı kontrol listesi ve sonraki adımlar

Bir soruşturma geldiğinde tekrarlanabilir yanıtlar istersiniz: kim ne yaptı, hangi kayda, ne zaman ve hangi yoldan.

Hızlı bir sağlık kontrolü:

• Her önemli değişiklik bir aktör (kullanıcı ID, servis hesabı veya net tanımlı bir sistem kimliği) ve stabil bir eylem adı kaydeder.
• Zaman damgaları tek bir politika izler (zaman dilimi dahil) ve gecikmeler mümkünse hem "ne zaman oldu" hem de "ne zaman kaydedildi" saklanır.
• Bir korelasyon ID'si vardır, böylece bir olay loglar ve denetim girdileri arasında takip edilebilir.
• Denetim geçmişi pratikte eklemeye dayalıdır: geçmiş girişlerin silinmesi ve düzenlenmesi engellenir ve yalnızca küçük bir grup ham denetim tablolarına erişebilir.
• Kullanıcı ve kayıt ID'ye göre arama yapabilir ve yoğun saatlerde bile hızlı sonuç alabilirsiniz.

Bunlardan biri başarısızsa, düzeltme genellikle küçük bir alandır: bir alan eklemek, bir indeks eklemek veya bir izni sıkılaştırmak.

Hemen işe yarayan sonraki adımlar: ekibinizin cevaplayabileceği bir olay tarzı soru yazın (örneğin "Geçen Salı bu müşterinin ödeme ayarlarını kim değiştirdi ve hangi ekrandan?"), kısa bir denetim tatbikatı yapın, uçtan uca süreyi ölçün ve saklama kurallarının net ve uygulanabilir olduğundan emin olun.

İç araç veya yönetici portalı inşa ediyorsanız ve bunu ilk günden itibaren dahil etmek istiyorsanız, AppMaster (appmaster.io) veri modellemenize, tutarlı aktör meta verileriyle iş süreçleri tanımlamanıza ve denetimin sonradan düşünülmediği üretim hazır backend'ler ve uygulamalar oluşturmanıza yardımcı olabilir.

Denetim izini bir ürün özelliği gibi ele alın: test edin, ölçün ve ihtiyacınız olmadan önce geliştirin.