Ugrás a tartalomhoz
← Blog'a dön

İlk commit'ten itibaren denetim kaydı — sonradan eklenen bir etiket değil

Çoğu denetim kaydı projesi iş işten geçtikten sonra doğar. Bizimki ilk migration ile birlikte gelir — ve tüm desen 200 satır TypeScript'tir.

Denetim kaydını “sonra eklemek” mümkün değildir — ya ilk günden vardır ya da hiçbir zaman eksiksiz olmaz.

Yeni bir müşteriyle tanıştığımızda sık sık şu cümleyi duyarız: “Denetim kaydına ihtiyacımız var, uyumluluk sprintinde ekleyeceğiz.” Bu cümle neredeyse her zaman 6 ay sonra, uyumluluk sprintinin ya hiç gelmeyeceği ya da geldiğinde sonradan eklemenin ilk günden yapmaya göre 3 kat emek gerektireceği anlaşıldığında gelir.

“İlk günden denetim kaydı” ne demek

  • “audit_logs” tablosu 40. değil, ilk migration'da yer alır
  • Her yazma uç noktası tek bir interceptor'dan geçer
  • Interceptor şunları kaydeder: tenantId, userId, action, resourceType, resourceId, before, after
  • Alan hassas ise öncesi/sonrası verileri kişisel veri maskelemesinden geçer
  • Tablo aylık olarak bölümlenir — dev indeks şişmesi olmaz
  • Saklama süresi: GDPR ile muhasebe mevzuatının kesişimini karşılamak için 7 yıl

200 satırlık desen

Tüm denetim deseni bir NestJS interceptor'ı (~120 satır), bir TypeORM entity'si (~40 satır) ve bir maskeleme yardımcısından (~40 satır) oluşur. Hepsi bu. Controller'a hiç dokunmadan her yazma rotası otomatik olarak kaydedilir. Aynı deseni beş ürünümüzde ve üç müşteri sisteminde çalıştırıyoruz — ve girdiği her denetimden geçti.

En ucuz denetim kaydı, ilk migration'da yazdığınızdır. En pahalısı ise üçüncü müşteri sorusundan sonra sonradan eklediğinizdir.

Bölümleme: neden tek bir sonsuz tablo değil

Denetim kaydı aylık bölümlenmiş bir tabloda tutulur. Her ayın kendi bölümü vardır ve 7 yıldan eski bölümler otomatik olarak Parquet formatında S3'e arşivlenir. Bu, üç sorunu birden çözer: günlük yazmalar 3 yıl sonra bile yavaşlamaz, uyumluluk sağlanır (7 yıllık saklama) ve BI raporları canlı veritabanına yük bindirmeden geçmiş verileri okuyabilir.

Denetim kaydımızın YAPMADIKLARI

  • GET isteklerini kaydetmeyiz (çok fazla gürültü, yetersiz değer)
  • Parolaları veya API anahtarlarını asla düz metin olarak saklamayız
  • Açık bir saklama süresi olmadan sağlık verisi kaydetmeyiz
  • İstek gövdesinin tamamını değil, yalnızca değişen alanları kaydederiz
  • Denetim kaydını “hata ayıklama” için kullanmayız — bunun için ayrı bir gözlemlenebilirlik altyapısı vardır

Gerçek bir denetim kaydı ile “her şeyi kaydet” sistemi arasındaki fark tam olarak şudur: gerçek bir denetim kaydındaki her satır, hukuki ya da güven açısından gerçek değeri olan bir iş olayıdır. Hata ayıklama kaydı farklı amaca hizmet eden farklı bir araçtır ve ikisi asla karıştırılmamalıdır — aksi halde ikisi de işe yaramaz hale gelir.

Bir konuyu ele almamızı ister misiniz?

Bize yazın — bu konuda gerçek deneyimimiz varsa yayımlarız.