როგორ დააპროექტებთ audit log-ს წლების traceability-სთვის?

Question

IT Interview Practice · Accepted Answer

გახადეთ ის **append-only და უცვლელი**, დააკავშირეთ თითო ჩანაწერი წინასთან **hash**-ით, რომ ჩარევა აღმოჩენადი იყოს, **partition გააკეთეთ დროით**, რომ ძველი მონაცემი იაფად ბერდებოდეს, და არქივი ჩაბეჭდილი partition-ები **WORM object storage**-ში (write-once) retention policy-ით — არასდროს დაუშვათ `UPDATE`/`DELETE` ცოცხალ ჩანაწერებზე.

```text
service ──emit event──▶ append-only writer
                             │  hash = H(prev_hash || payload)
                             ▼
                     audit_2026_07 (hot partition)  ◀── query by actor/time
                             │ month sealed
                             ▼
                     WORM object store (S3 Object Lock)  ── retention: 7y
                             │
                     periodic anchor: publish latest hash externally
```

## Append-only და ჩარევის აღმოჩენადობა

audit log-ის მთელი ღირებულება ისაა, რომ მას **მოგვიანებით ენდობი**, ამიტომ schema-მ ცვლილება უნდა აკრძალოს. მიეცით app-ს მხოლოდ `INSERT` — არა `UPDATE`/`DELETE` — და დააწესეთ ეს DB role დონეზე, არა მხოლოდ კოდში. ამის თავზე ააგეთ **hash chain**: თითო მწკრივი ინახავს `hash = SHA256(prev_hash || this_row)`-ს. ნებისმიერი ისტორიული მწკრივის შეცვლა ყოველ მომდევნო hash-ს ტეხავს, ასე რომ ჩარევა *აღმოჩენადია* DB წვდომის მქონე ადამიანისთვისაც კი. პერიოდულად **anchor** გააკეთეთ უახლეს hash-ს სადმე, რასაც არ აკონტროლებთ (notary, საჯარო ledger, ხელმოწერილი email), რომ ადმინსაც კი, ვინც მთელ chain-ს გადაწერს, ვერ დაემთხვეს anchored მნიშვნელობას.

## დროის partitioning და retention

მრავალწლიანი ლოგები უსასრულოდ იზრდება, ამიტომ **partition გააკეთეთ დროით** (მაგ. თვიური range partition-ები). სარგებელი: query-ები partition-ით ფილტრავენ, და ძველი მონაცემის გატანა არის metadata `DETACH`/`DROP PARTITION` — მყისიერი, არა გიგანტური `DELETE`, რომელიც ცხრილს ბერავს. ჩაბეჭდილი partition-ები **WORM storage**-ში გადადის — S3 Object Lock *compliance mode*-ში ფიზიკურად უშლის ხელს წაშლას retention თარიღამდე, რაც აკმაყოფილებს რეგულაციებს, როგორიც SOX/HIPAA-ა. შეინახეთ უახლესი თვეები ცხელი Postgres-ში სწრაფი query-ებისთვის; ყველაფერი ძველი ცივია object storage-ში, query-ებადი on demand.

## ინტერვიუს პერსპექტივა

შემოწმება არის, გესმით თუ არა, რომ "audit log" ნიშნავს **უცვლელობასა და დამტკიცებადობას**, არა უბრალოდ "ცხრილს timestamp-ით". კარგი: append-only ცხრილი. შესანიშნავი: append-only *DB role-ით დაწესებული*, hash chain external anchoring-ით, დროის partitioning retention-ისთვის, WORM compliance-ისთვის. გავრცელებული ხაფანგი: audit მწკრივების იმავე ცვალებად app ცხრილში შენახვა (bug-ს ან ბოროტ DBA-ს შეუძლია ისტორია ჩუმად გადაწეროს) — auditor-ები ამას უარყოფენ.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **Hash chain write-ებს სერიალიზებს** — თითო ჩანაწერს წინა hash სჭირდება, ამიტომ გულუბრყვილო დიზაინი bottleneck-ია. batch გააკეთეთ ჩანაწერებს ან chain გააკეთეთ per-shard და პერიოდულად cross-link.
- **Storage სამუდამოდ იზრდება**; partitioning + tiering-ის გარეშე იაფ object storage-ში ღირებულება და query latency იფეთქებს.
- **WORM compliance mode შეუქცევადია** — არასწორი retention პარამეტრი მონაცემს ბლოკავს (ან უშვებს ვადის გასვლას) undo-ს გარეშე; ტესტი გააკეთეთ governance mode-ში ჯერ.
- **Clock skew / წესრიგგარეშე event-ები** დროზე დაფუძნებულ მსჯელობას აფუჭებს — აღრიცხეთ event time და ingest time ორივე, და არასდროს ენდოთ კლიენტის საათებს წესრიგისთვის.

Append-only და ჩარევის აღმოჩენადობა

დროის partitioning და retention

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები