سجلات التدقيق في الإنتاج لخلفيات Go SaaS: التصميم والتخزين وما تخطئ فيه معظم الفرق

سجلات التدقيق هي الميزة الأقل استثماراً في معظم خلفيات SaaS. الفرق تضيفها متأخرة، تخزنها بشكل غير فعال، وتكتشف الفجوات فقط عندما يسأل عميل "من غير هذا ومتى" والإجابة مجهولة. الحصول على سجلات التدقيق الصحيحة من البداية أرخص بكثير من إعادة بنائها تحت الضغط.

في RTYLR، منصة المطاعم والتجزئة التابعة لـ Voxire والخادمة لشركات في لبنان ودول الخليج، سجلات التدقيق تُستخدم يومياً. مشغلو المطاعم يستعلمون عنها لتتبع تناقضات المخزون. فرق المالية تصدِّرها لمراجعات الامتثال. عندما يحدث شيء غير متوقع على طرفية نقطة بيع في الحادية عشرة مساءً، سجل التدقيق هو أول مكان يبحث فيه أي شخص.

ما الغرض الفعلي من سجلات التدقيق

سجلات التدقيق تخدم ثلاثة أغراض مختلفة كثيراً ما تُخلط:

سجلات الامتثال تُثبت أن النظام يلتزم بالمتطلبات التنظيمية أو التعاقدية. سلسلة مطاعم تحتاج إظهار أن تغييرات أسعار القائمة أجراها مستخدمون مصرح لهم.

التحقيق التشغيلي يجيب عن أسئلة مثل "لماذا عدد المخزون لا يطابق أمر الشراء" أو "من ألغى تفعيل هذا الحساب في الثالثة فجراً". هذا أكثر حالات الاستخدام شيوعاً ويحتاج إلى سرعة وقابلية بحث.

الشفافية للعملاء تتيح للمستخدمين النهائيين رؤية سجل نشاطهم الخاص.

مخطط الجدول

جدول سجل تدقيق جاهز للإنتاج في PostgreSQL:

CREATE TABLE audit_logs (
  id          BIGSERIAL PRIMARY KEY,
  tenant_id   UUID NOT NULL,
  actor_id    UUID,
  actor_type  TEXT NOT NULL DEFAULT 'user',
  action      TEXT NOT NULL,
  resource    TEXT NOT NULL,
  resource_id TEXT,
  before_data JSONB,
  after_data  JSONB,
  metadata    JSONB,
  ip_address  INET,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX audit_tenant_time_idx ON audit_logs (tenant_id, created_at DESC);
CREATE INDEX audit_resource_idx ON audit_logs (tenant_id, resource, resource_id, created_at DESC);

BIGSERIAL بدلاً من UUID للمفتاح الأساسي. سجلات التدقيق للإلحاق فقط وتُستعلم بترتيب زمني. BIGSERIAL يبقي الصفوف مرتبة فيزيائياً على القرص بترتيب الإدراج، مما يجعل عمليات الفحص بنطاق زمني أسرع بكثير.

الكتابة بدون كليشيهات

الخطأ الأكثر شيوعاً هو كتابة إدخالات سجل التدقيق يدوياً داخل كل طريقة خدمة. هذا يؤدي إلى تخطي استدعاءات السجل أثناء إعادة البناء وعدم اتساق أسماء الحقول عبر أجزاء مختلفة من الكود.

نهج أفضل هو مدقق بنمط middleware يتصل بطبقة الخدمة الخاصة بك:

type AuditLogger struct {
    db *sql.DB
}

func (a *AuditLogger) Log(ctx context.Context, entry AuditEntry) error {
    beforeJSON, _ := json.Marshal(entry.Before)
    afterJSON, _ := json.Marshal(entry.After)
    _, err := a.db.ExecContext(ctx, `
        INSERT INTO audit_logs
          (tenant_id, actor_id, action, resource, resource_id, before_data, after_data)
        VALUES ($1, $2, $3, $4, $5, $6, $7)
    `,
        entry.TenantID, entry.ActorID, entry.Action,
        entry.Resource, entry.ResourceID, beforeJSON, afterJSON,
    )
    return err
}

الكتابة المتزامنة مقابل غير المتزامنة

كتابة سجلات التدقيق بشكل متزامن في مسار الطلب تضيف كموناً. التوازن: الكتابات غير المتزامنة قد تضيع إذا أُعيد تشغيل الخدمة قبل اكتمال الكتابة. الكتابات المتزامنة دائماً ما تُسجَّل بشكل دائم.

بالنسبة لمعظم تطبيقات SaaS، النهج الصحيح يعتمد على نوع الإجراء. العمليات المالية وتغييرات الأذونات وحذف البيانات يجب تسجيلها بشكل متزامن. للمسارات غير المتزامنة، نمط Outbox هو التطبيق المناسب.

الاحتفاظ والتقسيم والنمو

جداول سجل التدقيق ستنمو إلى ما لا نهاية بدون سياسة احتفاظ. في RTYLR، مستأجر يدير مطعماً مشغولاً يمكنه إنشاء عشرات الآلاف من إدخالات التدقيق يومياً.

تقسيم جدول PostgreSQL بحسب created_at يجعل الاحتفاظ قابلاً للإدارة. إسقاط قسم شهري لتطبيق سياسة احتفاظ لمدة 12 شهراً هو عملية بيانات وصفية تكتمل في ميلي ثانية بغض النظر عن عدد الصفوف.

دروس من الإنتاج

ثلاثة أشياء فاجأت فريق RTYLR بعد تشغيل سجلات التدقيق في الإنتاج عبر نشرات لبنان والخليج لأكثر من عام:

أولاً، before_data يُستعلم عنه أكثر بكثير مما كان متوقعاً. السؤال التشغيلي الأكثر شيوعاً ليس "ما الحالة الحالية" بل "ما كانت الحالة قبل ذلك التغيير".

ثانياً، تسمية حقل action أهم مما توقعناه. التسمية غير المتسقة تجعل سجلات التدقيق غير قابلة للبحث. حدد مجموعة مسماة من أسماء الإجراءات وطبقها في مراجعة الكود.

ثالثاً، العملاء يطلبون تصدير سجلات التدقيق أكثر مما توقعنا. بناء نقطة نهاية تصدير CSV بسيطة في أول سبرينت تبين أنها واحدة من أكثر الميزات استخداماً في المستوى المؤسسي لـ RTYLR.