ผมลบข้อมูลบัญชีตัวเองหายไปทั้งเดือน — AI กู้คืน + สร้างระบบ snapshot กันโดนซ้ำในเช้าเดียว

เช้าวันที่ 1 พ.ค. ผมจะปิดบัญชีเดือนเมษา เปิดระบบบัญชีของตัวเอง อัปโหลดบิลบัตรเครดิตเข้าไป — แล้วข้อมูลเดือน "มีนา" ที่ผมทำเสร็จไปแล้วก่อนหน้านี้ก็หายเรียบครับ 555

หายแบบไม่มี popup ไม่มีคำเตือน ไม่มีอะไรเลย ผมโดน autosave ของซอฟต์แวร์ที่ผม "เขียนเอง" เขียนทับข้อมูลตัวเองหายภายในไม่กี่วินาที

โชคดีที่ผมมี AI Agent ของตัวเองที่อยู่บน server เดียวกัน — ผมแค่ทักไปบอก "เฮ้ย ข้อมูลมีนาหาย" เช้าเดียวกันได้กลับมา + แถมยังได้ระบบ snapshot ใหม่ที่ทำให้เคสแบบนี้เกิดอีกไม่ได้แล้วครับ

ระบบบัญชีของผมชื่อ Accy — ผมเขียนเองให้ตัวเองใช้

เล่าก่อนว่า Accy คือซอฟต์แวร์บัญชีที่ AI Agent ของผมสร้างไว้ใช้กับธุรกิจตัวเอง ตัดเสียงตัด SaaS รายเดือนทิ้งทั้งหมด เปิดเข้ามาเลือกเดือน อัปโหลด PDF บัตรเครดิต ระบบจะ parse ออกมาเป็นรายการ แยกประเภทค่าใช้จ่ายให้อัตโนมัติ — เก็บใส่ database ของผม จบ

ผมยังต่อระบบดึงใบเสร็จจาก Gmail/Drive อัตโนมัติเข้าไปด้วย เพื่อให้บัญชีต้นเดือนใช้เวลาแค่ครึ่งชั่วโมงก็เสร็จ

ทุกอย่างไหลลื่นมาตลอดครับ — จนเช้านั้น

เกิดอะไรขึ้น — ผมอัปโหลดเดือนเมษา ข้อมูลเดือนมีนาหาย

ผมเปิด Accy ขึ้นมา ตอนนั้นหน้าจอ load เดือน "มีนา" ค้างอยู่ (เพราะผมเพิ่งดูก่อนหน้านี้)

กดปุ่ม "Upload PDF" → เลือกบิล KTC ของเดือนเมษา → เปิดมาดู → รายการที่เคยทำเดือนมีนาหายเรียบ กลายเป็นรายการเมษาแทน

ผมรู้ทันทีว่าเกิดอะไรขึ้น แต่ตอนนั้นยังไม่รู้ว่ามีจุดบั๊กอยู่กี่จุด — เลยส่งข้อความหาทิมทันที "ข้อมูล มีนา หายหมดเลย ช่วยดูให้หน่อย"

ทิมไล่ root cause — เจอบั๊ก 3 ชั้นซ้อน

ผมไปทำธุระอย่างอื่น ทิม SSH เข้าไปอ่าน database + log + source code ทั้ง backend ทั้ง frontend คู่กัน 30 นาทีก็มาสรุปให้ฟังว่ามีบั๊กซ้อนกันอยู่ 3 จุด:

ชั้นที่ 1 — Backend ใช้ pattern "DELETE-then-INSERT" ทุกครั้งที่ frontend ส่งข้อมูลเดือนเดิมขึ้นมา API ลบรายการเก่าทิ้งทั้งหมดก่อน แล้วค่อย INSERT ใหม่ ไม่มี snapshot ไม่มี audit log อะไรเลย — ถ้าข้อมูลที่ส่งขึ้นมาผิด ของเก่าก็หายไปกับสายลม

ชั้นที่ 2 — Frontend autosave ทุก 1 วินาที ทุกครั้งที่ผมพิมพ์อะไร เปลี่ยนแถวอะไร ระบบจะ POST ส่งรายการทั้งเดือนกลับขึ้นไป — แปลว่าทันทีที่รายการเดือนเมษาโดน parse แล้วโชว์บนหน้าจอ autosave ก็ยิงไปทับเดือนมีนาในจังหวะถัดไปทันทีโดยไม่ต้องกดปุ่มอะไรเลย

ชั้นที่ 3 — PDF parser มี fallback ที่ผิด ตัวที่อ่านบิล KTC จะหาวันที่ "CLOSING DATE" ในไฟล์ PDF แล้วใช้เป็นเดือนของรายการ — แต่ถ้า regex ไม่ match (เช่น ตัวอักษรเพี้ยนนิดเดียว) มันจะ fallback ไปใช้ "เดือนที่กำลังเปิดดูอยู่" ทันที — แทนที่จะ error ออก

3 อย่างนี้รวมกันเลยกลายเป็น "อัปโหลดบิลเดือนใหม่ → parser อ่านวันไม่ออก → fallback มาเป็นเดือนเก่า → autosave ยิงทับเดือนเก่าใน 1 วินาที" — โดยที่ผมไม่ได้กดอะไรเลยสักปุ่ม

ทุกชั้นมีเหตุผลของมันตอนเขียน — แต่พอมารวมกันมันกลายเป็นกับดักที่ผมเดินเข้าไปเองโดยไม่รู้ตัว

กู้ข้อมูล — โชคดีที่ผมเคย export ขึ้น Google Sheet

ทิมไม่มี backup ของ database ตัวเอง (ตอนนั้น Accy ยังไม่ได้ตั้ง backup อัตโนมัติ — บทเรียนข้อ 2)

แต่โชคดีว่าตอนปิดบัญชีเดือนมีนา ผมเคย export รายการของเดือนนั้นไปไว้ใน Google Sheet เพื่อส่งให้สำนักงานบัญชีของผม — Sheet นั้นยังอยู่

ทิมเลยทำงาน 2 ทาง:

• ดึงข้อมูลจาก Google Sheet — ใช้ Drive API อ่านไฟล์ Sheet ตามชื่อโฟลเดอร์ ดึงรายการ INC ของเดือนมีนากลับมาได้ 35 รายการ รวม 79,132 บาท
• เก็บข้อมูลที่ contaminated เอาไว้ — ก่อนทำอะไรกับ database ทิม snapshot รายการที่อยู่ในนั้นตอนนั้น (84 แถว ที่เป็นส่วนผสมของมีนาบางส่วน + เมษาทั้งเดือน) ใส่ตารางใหม่ไว้กันเผื่อ

หลังจากนั้นเอา 35 รายการจาก Sheet กลับเข้า database + เทียบ snapshot เพื่อดึงรายการช่วง 25-31 มี.ค. ที่ Sheet ไม่มี (เพราะเป็นช่วงคาบรอบบิลใหม่) เพิ่มเข้าไปอีก 9 รายการ — สรุปเดือนมีนากู้กลับมาได้ 44 รายการ 86,233 บาท

ส่วนรายการเมษาที่อัปโหลดมาทับ ผมก็แค่อัปโหลดใหม่ — ก็จบครับ (และเดือนถัดมาทิมก็เขียน skill ใหม่ render ใบคุมรายการ PDF ส่งสำนักงานบัญชีให้อัตโนมัติทุกเดือน — จบลูปงานบัญชีให้ผมจริงๆ)

หลังจากกู้ข้อมูลเสร็จ ทิมไม่หยุด — ลงมือสร้างระบบ snapshot ทันที

นี่คือจุดที่ผมชอบที่สุดเกี่ยวกับการมี AI Agent อยู่ข้างๆ ครับ — แทนที่จะเป็นแค่ "ช่างซ่อมที่มาแก้บั๊กแล้วกลับ" ทิมเสนอเลยว่า "เคสนี้ไม่ควรเกิดอีก ขออนุญาตสร้างระบบกันท่าใหม่ให้เลยนะครับ"

ผมพยักหน้า ทิมก็จัดการในชั่วโมงถัดมา:

1. ตาราง statement_snapshots ใหม่ — เก็บภาพรายการของแต่ละเดือนทุกครั้งที่จะมีการ DELETE

2. Helper ฟังก์ชัน _snapshot_statement() — ทุกครั้งที่ API จะ DELETE รายการก่อน INSERT ใหม่ ต้องเรียกฟังก์ชันนี้ก่อน บันทึกของเดิมไว้ก่อน

3. Debounce 60 วินาที — กัน autosave ที่ยิงทุก 1 วิ ไม่ให้ snapshot ซ้ำๆ จนตารางแตก เก็บแค่ snapshot ละ 1 ครั้ง / นาที

4. Auto-prune เก็บแค่ 30 snapshot ล่าสุดต่อเดือน — กัน database โต

5. Endpoint สำหรับ restore — GET /api/statements/{month}/snapshots ดู list, POST /api/statements/{month}/restore/{snapshot_id} เรียก snapshot ก่อนหน้ากลับมาใส่ — ก่อน restore ก็ snapshot ปัจจุบันไว้ก่อนอีกที (จะได้ rollback ได้ถ้า restore ผิด)

6. แก้ PDF parser ให้ refuse แทนที่จะ fallback — ถ้าหา CLOSING DATE ไม่เจอ → throw error แล้วไม่บันทึกอะไรเลย และถ้าตรวจเจอเดือนที่กำลังจะ overwrite มีข้อมูลอยู่ก่อน → confirm dialog ให้กดยืนยัน

ทั้งหมดนี้ทิมเขียน + commit + restart service เสร็จในชั่วโมงเดียวครับ — ผมแค่กดเปิด Accy แล้วเห็นข้อมูลกลับมาแล้ว

บทเรียน 3 ข้อจากเรื่องนี้

1. Autosave ที่ดี ต้องมี snapshot คู่เสมอ — ของผมพลาดเพราะคิดแค่ว่า "autosave สะดวก" ไม่ได้คิดถึงเคส "ถ้าข้อมูลที่ autosave ส่งมามันผิด" ระบบ database ที่ไม่มี undo / snapshot = บอม time bomb ที่รอวันระเบิด

2. Backup ของ Backup ของ Backup — ผมไม่มี backup database เลยตอนนั้น ที่กู้ได้เพราะ Google Sheet เป็น "ทางออกฉุกเฉิน" บังเอิญ — โชคล้วนๆ ตอนนี้ทุก service ของผมกำลังโดนทิมไล่เซ็ต backup อัตโนมัติ

3. ความเร็วในการแก้ = ความเสียหายที่ถูกจำกัด — ถ้าเรื่องนี้เกิดขึ้นกับซอฟต์แวร์ของคนอื่น ผมต้องเปิด ticket รอ support 2-3 วัน ระหว่างนั้นทำอะไรต่อไม่ได้เลย — แต่เพราะทิมอยู่บน server ของผมเอง อ่าน source code ของ Accy ตรงๆ ได้ คุยกับ database ตรงๆ ได้ เรื่อง 2-3 วันเลยจบในเช้าเดียว

เคสนี้ไม่ใช่ครั้งแรกที่การมี AI Agent อยู่บน infrastructure ของตัวเองช่วยผมรอด — เคยมีเคสลูกค้า 2 คนจ่ายเงินผมแล้วระบบไม่รู้ ที่ทิมเจอ Stripe webhook ขาด event แล้ว backfill ให้ในชั่วโมงเดียว เคสนั้นกับเคสนี้ pattern เดียวกันครับ — เห็นปัญหา → ไล่ root cause → แก้ + ป้องกันให้เกิดซ้ำไม่ได้ → เสร็จก่อนผมจะมีเวลาเครียดด้วย

ทำไมผมถึงเลือก "เขียนเอง" แทน SaaS — ทั้งๆ ที่บั๊กแบบนี้ก็เกิดได้

มีคนถามผมตลอดว่า "ทำไมไม่ใช้ QuickBooks / Xero / FlowAccount ไปเลย? ทำไมต้องเขียนเอง?"

คำตอบมันชัดมากหลังเคสนี้ครับ — ถ้าผมใช้ SaaS แล้วเจอบั๊กแบบนี้:

• เปิด ticket → รอ 2-3 วัน
• เขาบอก "เป็น expected behavior" → ผมทำอะไรไม่ได้
• ขอให้แก้ pattern parser → "เพิ่มในรายการ feature request นะครับ" → 1 ปี ยังไม่ได้
• ต่อให้แก้ให้จริง ผมก็ไม่มีทางสร้าง snapshot system + restore endpoint ได้เอง

เพราะผมเลือกสร้างเครื่องมือเอง + มี AI Agent ส่วนตัว ที่อยู่บน server เดียวกัน — บั๊กที่อาจจะเป็น "rip data ของลูกค้าตลอดไป" เลยกลายเป็นแค่ "เช้าหนึ่งของผม" ที่จบไปแล้ว มี snapshot กันท่าใหม่เพิ่มมาด้วย

คำถามที่พบบ่อย

ข้อมูลบัญชีที่ถูกลบไปแล้วกู้คืนได้ไหม?

ขึ้นอยู่กับว่าถูก delete แบบไหนครับ ถ้า delete จาก database ตรงๆ โดยไม่มี backup โอกาสกู้คืนน้อยมาก แต่ถ้าระบบมี soft delete หรือ transaction log ยังอยู่ มีโอกาสกู้ได้ วิธีที่ดีที่สุดคือออกแบบให้ระบบเก็บ snapshot อัตโนมัติก่อนทุก operation ที่ destructive

จะออกแบบ autosave ให้ระบบบัญชีไม่สูญข้อมูลได้ยังไง?

Pattern ที่ใช้ได้ดีคือ snapshot-before-write ครับ ทุกครั้งก่อน update หรือ delete ให้บันทึก state ปัจจุบันลง snapshot table พร้อม timestamp และ user ที่ทำ ถ้ามีข้อผิดพลาดสามารถ restore จาก snapshot ล่าสุดได้เสมอ ไม่ต้องพึ่งแค่ transaction rollback

AI parse PDF เอกสารบัญชีได้ถูกต้องแค่ไหน?

ขึ้นอยู่กับ format ของ PDF ครับ ถ้าเป็น digital PDF ที่มี text layer สกัดได้เกือบ 100% แต่ถ้าเป็น scan มี noise หรือตัวอักษรไทย encoding พิเศษ อาจมี error ได้ วิธีที่ robust คือให้ AI ตรวจสอบผลลัพธ์แล้ว flag ตัวเลขที่ไม่น่าเชื่อถือแทนที่จะ fail เงียบๆ

ระบบ software custom กับ SaaS สำเร็จรูปต่างกันยังไงเรื่องกู้ข้อมูล?

SaaS สำเร็จรูปมักมี backup ที่ provider จัดการให้ แต่การเข้าถึงข้อมูลมักต้องผ่าน support ครับ ระบบ custom ที่รันบน server ของคุณเองให้ access โดยตรงถึง database สามารถ query ได้ทุกเมื่อ และออกแบบ recovery flow เองได้ตาม requirement ของธุรกิจ

อยากมี AI ส่วนตัวที่กู้ข้อมูล + สร้างระบบใหม่ให้คุณได้แบบนี้ไหม?

ทิมไม่ใช่ของวิเศษอะไรครับ — เป็น Claude Code ที่รันอยู่บน server ของผมเอง คุยกับผมผ่าน chat ทักทายมา → SSH เข้าไปอ่าน code ได้ → แก้ไฟล์ได้ → restart service ได้ → กู้ข้อมูลให้ → commit push ขึ้น git ได้เอง

ปัญหาคือการตั้ง server + Claude + chat + ระบบ memory ให้ AI Agent จำได้ข้ามวัน — ปกติใช้เวลาเป็นวันๆ ตั้ง

เลยกลายเป็น Newton — ผมจัด server พร้อม AI Agent (เหมือนทิมเด๊ะ) ให้คุณใช้ได้ใน 10 นาที ไม่ต้องตั้งเอง ลองดูได้ที่หน้านี้ครับ — มีระยะ trial 7 วันให้ลองว่ามันทำงานแทนคุณได้จริงไหมก่อนตัดสินใจ

— ปอนด์