เมื่อหลายเดือนก่อน ทิม (AI Agent ของผม) เคยสร้างระบบเตือนภัย server ของลูกค้า Newton ให้ผมครับ — CPU พุ่ง, RAM ใกล้เต็ม, ดิสก์เหลือน้อย → ส่งเมลหาลูกค้า + Telegram หาผม เป็นระบบเฝ้าระวังที่ดูดีมาก

เมื่อวานนี้ ทิมขอลบมันทิ้งทั้งระบบ — โค้ด 419 บรรทัด เหลือ 170 บรรทัด หายไป 250 บรรทัดเลย

เหตุผลตรงไปตรงมามาก — "ไม่มีใครฟังมันครับ"

ระบบเตือนภัยที่ทำงานถูกต้อง 100% — แต่ไม่มีใครทำอะไรกับมัน

ก่อนเล่า ขอเล่าก่อนว่า Newton คือบริการที่ผมจัด server พร้อม AI Agent ส่วนตัวให้ลูกค้าใช้ครับ — ลูกค้าจ่ายรายเดือน ได้ server เต็มลูก + AI Agent (เหมือนทิมที่ผมใช้) คอยทำงานบน server ให้ตลอด 24 ชม. รายละเอียดเล่าที่บล็อกนี้ละเอียด

ทุกๆ 15 นาที ทิมจะรันสคริปต์เช็ค server ของลูกค้าทุกคนพร้อมกัน 13 เครื่อง — เช็ค CPU, RAM, ดิสก์, สถานะของ Claude (AI Agent) — ถ้าค่าไหนเกิน threshold ก็ยิงเมลแจ้งลูกค้าและ Telegram แจ้งผมพร้อมกัน

เริ่มแรกผมตื่นเต้นมากครับ — มีระบบ monitoring ของตัวเองแล้ว ไม่ต้องไปจ่าย Datadog หรือ New Relic เดือนละพันกว่าบาท

ผ่านไป 2 เดือน — Telegram ผมเริ่มดังบ่อย วันละ 5-6 ครั้งก็มี "server ของลูกค้า X CPU 95% มา 10 นาทีแล้ว"

ผมเริ่มสังเกตอย่างนึง — ไม่มีลูกค้าคนไหนตอบเมลเตือนเลยสักคน และทุกครั้งที่ผมไปถามลูกค้าเอง คำตอบเหมือนกันหมด — "อ๋อครับ เห็นเมลแล้ว แต่ไม่รู้จะทำอะไรเลย"

ระบบเตือนภัยที่ดี ต้องบอกได้ว่า "แล้วยังไงต่อ"

เนื้อความเมลที่ทิมส่งให้ลูกค้าจะประมาณว่า:

"Server ของคุณ CPU ใช้งาน 92% มา 15 นาทีแล้ว อาจเกิดจากการรัน workload หนัก โปรดตรวจสอบ"

ดูดีในกระดาษ — แต่ลูกค้า Newton ส่วนใหญ่ไม่ใช่ engineer ครับ เป็นคนทำธุรกิจที่อยากใช้ AI ทำงานให้ ไม่ได้รู้ว่า "CPU 92%" คืออะไร ไม่รู้จะ SSH เข้าไปดูยังไง ไม่รู้ว่าควร kill process ไหน ไม่รู้ว่าอยากแก้แล้วต้อง upgrade tier server ไหม

เมลที่บอกเหตุการณ์แต่ไม่บอกว่าจะแก้ยังไง = noise ครับ — สวยใน inbox แต่กดอ่านปุ๊ปก็ปิดทิ้งทันที

แล้วฝั่งผมเองก็ไม่ได้ทำอะไรกับ Telegram ที่ดังบ่อยๆ เหมือนกัน — เพราะผมรู้ว่า server CPU จะพุ่งบางช่วงเป็นเรื่องปกติ ลูกค้าอาจจะเพิ่งสั่ง AI ตัดคลิป YouTube ยาว 2 ชม., หรือเพิ่งสั่ง summarize เอกสาร 50 หน้า ระหว่างนั้น CPU 95% ก็ปกติ

ผ่านไปครึ่งปี ระบบเตือนภัยที่ดูดีมาก = noise pile บน Telegram ที่ผม mute ไปแล้ว + spam ใน inbox ลูกค้า ที่ไม่มีใครเปิด

ผมตัดสินใจ — บอกทิมให้ลบทิ้งให้หมด

เมื่อวานผมไปทักทิมตรงๆ ว่า "ระบบ alert เนี่ย ลบทิ้งเลยดีกว่า ไม่มีใครได้อะไรจากมัน"

ผมคาดว่าทิมจะ push back หน่อย เพราะมันเป็นโค้ดที่มันเขียนเองครึ่งปีก่อน แต่ทิมตอบกลับมาทันทีว่า "เห็นด้วยครับ จะลบส่วน proactive monitoring ออกก่อนไหม? ส่วน activity tracker (chat / workspace activity) ผมต้องเก็บไว้ เพราะมันคืออาหารของ dashboard idle metric"

คำตอบนี้ทำให้ผมรู้ว่าทิมเข้าใจ codebase ตัวเองดีกว่าผมอีกครับ — เพราะผมลืมไปเลยว่าสคริปต์ alert ไฟล์เดียวกันยังถูกใช้สำหรับ tracking ว่าลูกค้าคนไหน "หลับไป 7 วันแล้ว" เพื่อให้ admin dashboard โชว์ funnel ได้

ทิมก็จัดการในชั่วโมงเดียว:

  • ลบ: โค้ดเช็ค CPU/RAM/Disk ทั้งหมด, ฟังก์ชัน send_email, ฟังก์ชัน plain_email, ตัวจัดการ cooldown (กันเมลซ้ำ), ค่า threshold ทุกตัว, ไฟล์ .alert_cooldown.json ที่ไม่มีใครใช้แล้ว
  • เก็บ: ส่วนที่อ่าน timestamp ว่าลูกค้าใช้แชทล่าสุดเมื่อไหร่ + workspace ของ AI Agent ขยับล่าสุดเมื่อไหร่ — เพราะอันนี้ admin dashboard ต้องใช้
  • เก็บอีกนิด: ฟังก์ชันตรวจ Hetzner server ที่ตอบ 404 (server โดนลบ) แล้ว auto-cleanup รายการในฐานข้อมูล — อันนี้เป็น admin task ของผม ไม่ใช่ noise สำหรับลูกค้า

419 → 170 บรรทัด, cron job */15 ยังต้องเหลือไว้เพราะ activity tracker ยังต้องวิ่ง รันสะอาดทั้ง TH (13 servers) และ EN (0 servers ตอนนี้) commit push ขึ้น git เสร็จในชั่วโมงเดียว

แต่ลูกค้ายังแจ้งว่าเครื่องช้าได้อยู่ — แล้วผมจะรู้ได้ยังไง?

นี่คือคำถามถัดไปที่ผมถามทิมทันที — ถ้าลบ alert ออกแล้ว วันที่ลูกค้าทักเข้ามาว่า "เครื่องช้า ตอบช้า เปิดไม่ขึ้น" ผมจะ diagnose ยังไง?

ทิมเสนอกลยุทธ์ใหม่ทันที — เปลี่ยนจาก proactive alerting (ส่งเตือนก่อนปัญหาจริงเกิด) เป็น reactive diagnosis (ตอนลูกค้าทักเข้ามาเองค่อยตรวจ)

วิธีคือเพิ่มข้อมูลใน "knowledge file" ที่ทิมใช้ตอนตอบ support — บอกว่าถ้าเจอคำว่า "ช้า, ค้าง, ตอบช้า, เครื่องหน่วง, เปิดไม่ขึ้น" ในข้อความลูกค้า ให้ทิม SSH เข้าไป run คำสั่งเดียว: uptime; free -h; df -h; ps aux --sort=-%cpu | head -5; ps aux --sort=-%mem | head -5

1 บรรทัดนี้บอกได้หมดเลยครับ — uptime + load average ตอนนี้, RAM ใช้เท่าไหร่, ดิสก์เหลือเท่าไหร่, process ไหนกิน CPU/RAM มากที่สุด 5 อันดับ

แล้วทิมก็ตีความได้ทันที เทียบกับ tier ของ server ลูกค้า (cpx11 มี 2 vCPU, cpx62 มี 16 vCPU — load 3 บน cpx11 = หนัก แต่บน cpx62 = ว่างมาก) แล้วตอบลูกค้าด้วยภาษาที่ไม่ใช่ jargon

ตัวอย่างที่ทิมตอบลูกค้าจริง (หลังจาก diagnose):

"ตอนนี้เครื่องของพี่ใช้ RAM ไป 14 GB จาก 16 GB และมี process ของ AI Agent ทำงานหนักครับ (ใช้ CPU 180%) เครื่องขนาดที่พี่ใช้อยู่ตอนนี้รับงานที่ AI Agent กำลังทำอยู่ลำบากนิดหน่อย ถ้าจะให้แก้ระยะยาว แนะนำ upgrade ขึ้นอีก tier นึง (เพิ่มประมาณ X บาท/เดือน) — แต่ถ้าอยากแก้เฉพาะหน้าก่อน ผมรีสตาร์ทเครื่องให้ได้ จะเร็วขึ้นทันที 30 นาที-1 ชม. แล้วค่อยตัดสินใจอีกที"

เทียบกับเมลเก่า — อันนี้บอกครบ: เกิดอะไรขึ้น, ทำไมจึงช้า, แก้ระยะสั้นยังไง, แก้ระยะยาวยังไง — ลูกค้าเลือกได้ทันที

บทเรียน 3 ข้อจากการลบโค้ดตัวเองทิ้ง 250 บรรทัด

1. Feature ที่ไม่ทำให้เกิด action = noise — ระบบ monitoring ที่ส่งเมลแล้วไม่มีใครอ่าน, dashboard ที่ไม่มีใครเปิด, รายงานที่ไม่มีใครเอาไปใช้ — ทั้งหมดนี้ = noise ที่ดูเหมือนระบบมีของ แต่จริงๆ เปลือง memory + เปลือง attention เปล่าๆ

2. ของที่เคยใช้ ไม่จำเป็นต้องเก็บไว้ตลอด — engineer หลายคนกลัวลบโค้ดเพราะ "อาจจะใช้อีกวันนึง" แต่ git keeps history ครับ ลบทิ้งได้เสมอ ของที่ไม่ได้ใช้ใน production ทุกวัน = สะสมหนี้เทคนิคที่จะระเบิดวันใดวันนึง

3. Reactive ดีกว่า Proactive ในเคสที่ user ตอบสนองช้า — Proactive alert ดีถ้าผู้รับสามารถ act ได้ทันที (เช่น oncall engineer) แต่ถ้าผู้รับเป็น end user ที่ไม่มี skill / time / interest ที่จะแก้ — รอให้เขาทักเข้ามาเอง ค่อย diagnose ดีกว่า ประหยัด attention ของทุกฝ่าย หลักการเดียวกันนี้ผมเอาไปใช้ตอนอัปเดต AI ให้ลูกค้าทุกเครื่องแบบเงียบๆ — งานหลังบ้านที่ดีคืองานที่ทำเสร็จโดยลูกค้าไม่ต้องรับรู้

นี่คือเหตุผลที่ผมชอบมี AI Agent ส่วนตัว — ลบของตัวเองได้ไม่หวงผลงาน

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

มันแค่อ่าน data จริง (ไม่มีใครตอบเมลเลย, Pond mute Telegram, ไม่มี action เกิดขึ้น) → ตัดสินใจตามข้อมูล → ลงมือ delete → restart service → commit push เสร็จในชั่วโมงเดียว

ถ้าผมจ้าง engineer คนนึงเขียน feature นี้แล้ววันนึงบอกให้ลบทิ้ง — มีโอกาสสูงที่จะได้ pushback "เสียดายอะ ลองปรับ threshold อีกหน่อยมั้ย? ลองเปลี่ยน format เมลก่อน?" ซึ่งทุกข้อเสนอเหล่านั้นจะกินเวลาอีก 2-3 วันโดยไม่แก้ปัญหาจริง

AI Agent ที่ดีไม่ผูกพันกับโค้ดที่มันเขียน — มันผูกพันกับเป้าหมายของผมแทน เป้าหมายผมคือ "Newton ทำงานให้ลูกค้าได้จริง โดยใช้ attention ของผมและลูกค้าน้อยที่สุด" — ระบบ alert ที่ไม่บรรลุเป้าหมายนั้น ก็ลบทิ้งได้ทันที

ก่อนหน้านี้ทิมก็เคยเสนอให้ ลบฟิลด์ password ออกจากหน้า signup แทนที่จะเสียเวลาแก้ — pattern เดียวกันครับ มองเป้าหมาย ไม่หวงโค้ดเดิม

(อัปเดตทีหลัง — ทิมก็เพิ่งลบ scheduler ทั้งก้อนของ Documentor ทิ้งเปลี่ยนเป็น "AI สร้าง Draft → Pond กดเอง" ด้วย pattern เดียวกัน — ฟังผมว่า workflow จริงคืออะไร แล้วลบของที่ไม่ตอบ workflow ทิ้งทันที)

อยากมี AI ส่วนตัวที่กล้าลบโค้ดตัวเองทิ้งแบบนี้ไหม?

ทิมไม่ใช่ของวิเศษอะไรครับ — เป็น Claude Code ที่รันอยู่บน server ส่วนตัวของผม ทักทายมา → SSH เข้าไปอ่าน source code ของระบบ Newton ได้ → ตัดสินใจตามข้อมูลจริง → แก้ + commit + push เองได้

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

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

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

ระบบ monitoring server ที่ดีควรเป็นแบบ proactive หรือ reactive?

ขึ้นอยู่กับว่า user รับการแจ้งเตือนแล้วทำอะไรได้ครับ ถ้า user เป็น engineer ที่รู้ว่าต้องทำอะไรต่อ proactive alert มีประโยชน์ แต่ถ้า user เป็นเจ้าของธุรกิจที่ไม่รู้ว่าจะแก้ CPU 92% ยังไง การส่งเตือนไปก็กลายเป็น noise แค่กด archive ทิ้ง ในกรณีนั้น reactive diagnosis ตอนลูกค้าทักเข้ามาเองมีประโยชน์กว่ามาก

ก่อนลบโค้ดที่ไม่ใช้แล้ว ต้องระวังอะไรบ้าง?

ต้องตรวจก่อนว่ามีส่วนไหนของโค้ดนั้นที่ระบบอื่นยังพึ่งพาอยู่ไหมครับ ในเคสนี้ AI สังเกตได้เองว่าสคริปต์ alert ไฟล์เดียวกันยังมีส่วน activity tracker ที่ dashboard ใช้อยู่ เลยลบเฉพาะส่วน proactive monitoring ออก ไม่ลบทั้งก้อน การลบโค้ดที่ git track ไว้แล้วทำได้ปลอดภัยเพราะ restore ได้เสมอ

feature ที่ไม่ทำให้ user ทำอะไรต่อได้ ยังมีประโยชน์ไหม?

ไม่ครับ ถ้า feature นั้นส่ง notification แล้ว user ไม่รู้จะทำอะไร หรือ dashboard แสดงตัวเลขแต่ไม่มีใครเปิดดู มันคือ noise ที่กิน attention ของทุกคนเปล่าๆ feature ที่ดีคือ feature ที่ผลักให้เกิด action ได้จริง ไม่ใช่แค่แสดงข้อมูล

เวลาแจ้งปัญหา server ให้ลูกค้า ควรบอกอะไรบ้าง?

ควรบอกครบ 4 อย่างครับ คือ เกิดอะไรขึ้น, ทำไมถึงเกิด, แก้ระยะสั้นได้ยังไง, และถ้าอยากแก้ระยะยาวต้องทำอะไร แบบนี้ลูกค้าตัดสินใจได้เลยว่าจะเลือกทางไหน แทนที่จะได้แค่ตัวเลข CPU 92% แล้วไม่รู้จะทำอะไร

— ปอนด์