ระบบอัตโนมัติทั้ง server ของผมยิงเร็วไป 7 ชั่วโมงพร้อมกัน — เพราะแก้ฟิลด์เดียวในหน้า Newton

เช้าวันหนึ่งผมเปิดมือถือมาดูบล็อกที่ตั้งให้โพสต์อัตโนมัติทุกวัน — ปกติมันจะขึ้นตอนสายๆ แต่วันนั้นผมเห็น timestamp ว่า "เผยแพร่ตอน 04:06 น." 555 ตี 4 ใครอ่าน

ไม่ใช่แค่บล็อก — สรุปข่าวเช้าที่ทิม (AI Agent ของผม) ส่งเข้า Telegram ทุกเช้า ดันเด้งมาตั้งแต่กลางดึก โพสต์ FB ที่ตั้งเวลาไว้ก็ออกเร็วผิดเวลา ทุกอย่างที่เป็น cron job ในเครื่องผม ยิงเร็วไปพร้อมกันหมดเป๊ะ 7 ชั่วโมง

ไม่มี error สักตัว ไม่มีอะไรพัง — แค่ทุกอย่างมาผิดเวลา ซึ่งเป็นบั๊กที่หาเจอยากที่สุดประเภทหนึ่งเลยครับ

เครื่องผมเคยรันด้วย UTC มาตลอด

เล่าพื้นก่อน — server หลักของผม (เครื่องที่รัน Loom, Documentor, Tim Chat, เว็บนี้ ทุกอย่าง) ตั้งเวลาระบบเป็น UTC มาตั้งแต่วันแรก ซึ่งเป็นค่า default ของ VPS ส่วนใหญ่

เวลาผมหรือทิมจะตั้ง cron ให้ทำงาน "ตอน 9 โมงเช้าเวลาไทย" เราก็ต้องเขียนเป็น 0 2 (ตี 2 UTC) เพราะ UTC + 7 = เวลาไทย วิธีนี้น่ารำคาญนิดหน่อยแต่อยู่กันมาเป็นปี ทุก cron ในเครื่องเลยถูกเขียนด้วย "ความคิดแบบ UTC" หมด

กฎเหล็กของเครื่องนี้คือ — เวลาที่เขียนใน cron = เอาเวลาไทยที่อยากให้รัน ลบออก 7 ทุกคนที่แตะ cron เครื่องนี้รู้กฎข้อนี้

อยู่ดีๆ timedatectl ก็บอกว่าเครื่องเป็นเวลาไทย

ผมทักทิมว่า "ทำไม cron ยิงเร็วไป 7 ชั่วโมงหมดเลย" ทิมเข้าไปรันคำสั่งแรกที่ควรเช็คทันที:

timedatectl

ผลออกมาว่า Time zone: Asia/Bangkok (+07) — เครื่องไม่ใช่ UTC อีกต่อไปแล้ว!

พอ timezone ของเครื่องเปลี่ยนจาก UTC เป็น Asia/Bangkok ปุ๊บ cron ทุกตัวที่เขียนด้วย "ความคิดแบบ UTC" ก็ตีความใหม่ทันที — 0 2 ที่เคยหมายถึง "ตี 2 UTC = 9 โมงเช้าไทย" ตอนนี้กลายเป็น "ตี 2 เวลาไทย" ตรงๆ เลยเร็วไป 7 ชั่วโมงเป๊ะทุกตัว นั่นแหละสาเหตุที่บล็อกผมโผล่ตอนตี 4

คำถามต่อไปคือ — แล้วใครไปเปลี่ยน timezone ของเครื่อง? ผมไม่ได้ไป SSH สั่ง set-timezone เลยสักครั้ง

ต้นเหตุ: ฟิลด์เล็กๆ ในหน้าโปรไฟล์ Newton ที่ผมกดเองเมื่อ 4 วันก่อน

ทิมไล่ดู log ย้อนหลังแล้วชี้มาที่วันที่ 25 พ.ค. — วันนั้นผมเข้าไปในแดชบอร์ดของ Newton (บริการที่ผมจัด server + AI Agent ส่วนตัวให้ลูกค้าใช้) แล้วลองแก้ฟิลด์ "timezone" ในหน้าโปรไฟล์ของเครื่องตัวเอง เปลี่ยนจาก UTC เป็น Asia/Bangkok

ในหัวผมตอนนั้นคิดว่า — ฟิลด์ timezone ก็แค่ "ค่าแสดงผล" ใช่ไหม? แบบตั้งให้ dashboard โชว์เวลาเป็นเวลาไทย ไม่น่าจะมีอะไร

แต่ที่จริง — โค้ดเบื้องหลังฟิลด์นั้น พอกดเซฟ มัน SSH เข้าไปรัน timedatectl set-timezone Asia/Bangkok บนเครื่องจริง เลยครับ มันไม่ใช่ค่าแสดงผล มันคือคำสั่งที่ไปแก้ system clock ของ OS ตรงๆ

และเพราะเครื่องหลักของผมเองก็ถูกจัดการอยู่ภายใต้ control plane เดียวกับลูกค้า Newton (ผมกินอาหารหมาตัวเอง — รัน Newton บนเครื่องตัวเองด้วย) การกดฟิลด์เดียวในหน้าโปรไฟล์เลยไปสั่งเปลี่ยน timezone ของ production server ผมแบบเงียบๆ ไม่มี popup เตือน ไม่มี "คุณแน่ใจไหม" ไม่มี log เด้งเข้า Telegram

แล้วผลของมันก็ไม่ออกทันที — มันออกตอน cron ตัวถัดไปทำงาน ซึ่งคือกลางดึกของอีกหลายวันถัดมา กว่าผมจะสังเกตเห็นว่า "เอ๊ะ ทำไมของมาผิดเวลา" ก็ผ่านไป 4 วันแล้ว

บั๊กเรื่องเวลา = บั๊กที่เงียบที่สุด

ผมเจอบั๊กเงียบๆ ที่ไม่มี error เด้งมาหลายรอบแล้วครับ — ทั้งตอน ความจำของทิมเขียนไม่ลงไฟล์ 3 วันเต็มแบบไม่มี error ทั้งตอน ระบบหาหัวข้อคอนเทนต์พังเงียบ 3 วันเพราะ JSON แต่เคสนี้พิเศษกว่าตรงที่ — ไม่มีอะไรพังเลยด้วยซ้ำ

cron ทุกตัวยังทำงานครบ สคริปต์รันถูกต้องทุกบรรทัด ไฟล์ถูกสร้าง โพสต์ถูกเผยแพร่ เมลถูกส่ง — ทุกอย่าง "สำเร็จ" หมด แค่มันเกิดขึ้นผิดเวลา 7 ชั่วโมง

ถ้าเป็นบั๊กที่ทำให้โปรแกรม crash เราจะเห็น stack trace ทันที แต่บั๊กที่ทำให้ของถูกต้องมาผิดเวลา — ไม่มีระบบไหนจับได้นอกจากตาคนที่บังเอิญเห็น timestamp แปลกๆ มันเลยซ่อนอยู่ได้เป็นวันๆ

ทิมแก้ยังไง — และทำไมไม่ flip กลับเป็น UTC

ทางเลือกที่ง่ายที่สุดคือสั่ง timedatectl set-timezone UTC flip กลับ แล้วจบ — cron ทุกตัวก็กลับมาถูกเหมือนเดิม

แต่ผมกับทิมคุยกันแล้วตัดสินใจทำตรงข้าม — เก็บเครื่องไว้เป็น Asia/Bangkok แล้วแก้ cron ให้เข้ากับเวลาไทยแทน

เหตุผลคือ การเขียน cron ด้วยเวลาท้องถิ่นมันอ่านง่ายกว่าเยอะ — "อยากให้รัน 9 โมงเช้า" ก็เขียน 0 9 ตรงๆ ไม่ต้องมานั่งลบ 7 ในหัวทุกครั้งแล้วเสี่ยงคิดเลขผิด การที่เครื่องเคยเป็น UTC คือต้นตอความสับสนตั้งแต่แรกอยู่แล้ว ในเมื่อมันถูก flip ไปแล้วก็ถือโอกาสแก้ให้ถูกระยะยาวเลย

ขั้นตอนที่ทิมทำ:

• backup ก่อน: ดัมพ์ crontab ทั้งหมดเก็บไว้ที่ /root/crontab-backup-2026-05-29.txt เผื่อแก้พลาดจะได้ย้อนได้
• เลื่อน cron แบบ fixed-hour ทุกตัว +7 ชั่วโมง: ตัวที่เคยเขียน 0 2 (ตั้งใจให้รัน 9 โมงไทย) เปลี่ยนเป็น 0 9 — ให้มันกลับไปยิงตรงเวลาจริงที่เคยตั้งใจไว้
• ไม่แตะ cron แบบ hourly / ทุกกี่นาที: ตัวที่เขียน * หรือ */15 (เช่น activity tracker ที่วิ่งทุก 15 นาที) ไม่ต้องขยับ เพราะมันไม่ผูกกับชั่วโมงที่แน่นอนอยู่แล้ว
• เช็คตัว one-shot เป็นพิเศษ: มี cron ตัวนึงที่ตั้งให้หมดอายุโปรโมชัน Stripe วันที่ 1 มิ.ย. (0 0 1 6) — ตัวนี้ผมเขียนด้วยเวลาไทยอยู่แล้ว เลยถูกต้องพอดีภายใต้ timezone ใหม่ ไม่ต้องแตะ

คล้ายกับตอนที่ทิม เกือบลบ cron ส่วนตัวลูกค้า 144 ตัวทิ้งตอนตั้ง auto-update — บทเรียนคือ การแตะ crontab ต้อง backup ก่อนเสมอ แล้วแก้แบบรู้ว่าแต่ละบรรทัดทำอะไร ไม่ใช่ sed ทับทั้งไฟล์ (เรื่อง cron เขียนเป็น/แก้เป็น มันสำคัญแบบนี้แหละ — อย่างตอนที่ทิม ตั้ง cron เตือนตัวเองล่วงหน้าแล้วลบทิ้งหลังเตือนเสร็จ ก็ใช้ความเข้าใจ crontab ชุดเดียวกันนี้)

แล้วก็ฝังกฎใหม่ลง "ความจำ" ของทิมทันที

สิ่งที่ผมชอบที่สุดของการมี AI Agent ที่มีระบบความจำข้ามวัน คือ — พอแก้บั๊กเสร็จ ทิมจะเขียนบันทึกลงไฟล์ memory ของตัวเองว่า "ตั้งแต่นี้ไป เครื่องเป็น Asia/Bangkok แล้ว เขียน cron ใหม่ด้วยเวลาไทยเสมอ ห้ามเขียนแบบ UTC อีก"

หมายความว่ารอบหน้าไม่ว่าผมหรือทิมเองจะมาตั้ง cron ใหม่ มันจะไม่เผลอเขียนแบบ UTC แล้วทำให้ของยิงผิดเวลาอีก — บทเรียนถูกเก็บถาวร ไม่ใช่แก้แล้วลืม

ทิมยังตั้งข้อสังเกตกลับมาด้วยว่า "จริงๆ ควรทบทวนไหมครับ ว่าฟิลด์ timezone ในโปรไฟล์ Newton ควรไปแตะ system clock ของเครื่องเลยหรือเปล่า" — ซึ่งเป็นคำถามที่ถูกต้องมาก เพราะ root cause จริงๆ ไม่ใช่ cron แต่เป็นฟิลด์ที่ดูเหมือนการตั้งค่าแสดงผล แต่ดันมี side-effect ไปแก้ระบบจริง

บทเรียน 3 ข้อ

1. ระวังฟิลด์ตั้งค่าที่มี side-effect ซ่อนอยู่ — ฟิลด์ "timezone" ดูเป็นแค่ค่าแสดงผล แต่จริงๆ ไปรัน timedatectl บน OS ตรงๆ ทุกครั้งที่ปุ่มเซฟทำมากกว่าที่ชื่อมันบอก = กับดัก ของพวกนี้ควรมี confirmation หรือ log ให้เห็นชัดว่า "กดแล้วจะเกิดอะไรขึ้นกับเครื่องจริง"

2. บั๊กเรื่องเวลาเงียบที่สุดในบรรดาบั๊กทั้งหมด — ไม่มี crash ไม่มี error ไม่มี alert ทุกอย่าง "สำเร็จ" หมด แค่มาผิดเวลา ระบบ monitoring แบบเดิมจับไม่ได้เลย ต้องอาศัยคนสังเกต timestamp แปลกๆ เอง

3. ถ้าจะแก้ ก็แก้ให้ถูกระยะยาวไปเลย — ผมเลือกไม่ flip กลับ UTC (ทางที่เร็วสุด) แต่เก็บเครื่องไว้เป็นเวลาไทยแล้วแก้ cron ทั้งหมดแทน เพราะการเขียน cron ด้วยเวลาท้องถิ่นมันถูกต้องและอ่านง่ายกว่าตั้งแต่แรก บางทีบั๊กก็เป็นโอกาสได้แก้สิ่งที่ควรแก้มานานแล้ว

นี่แหละเหตุผลที่ผมอยากให้ทุกคนมี AI Agent ที่ "อยู่บนเครื่อง" จริงๆ

ลองคิดดูครับ — ถ้าผมไม่มีทิม ผมจะไล่บั๊กนี้ยังไง? ผมต้อง SSH เข้าเครื่องเอง รู้ว่าต้องรัน timedatectl ก่อน รู้ว่าต้องไล่ log ย้อนหาว่าใครเปลี่ยน tz รู้ว่า cron ตัวไหนเขียนแบบ UTC ตัวไหนไม่ใช่ แล้วแก้ทีละบรรทัดโดยไม่พังของเดิม — สำหรับคนที่ไม่ใช่ engineer แทบจะเป็นไปไม่ได้เลย

แต่ทิมทำได้หมดในไม่กี่นาที เพราะมันคือ Claude Code ที่รันอยู่บน server ของผมจริงๆ — ทักทายมา → SSH เข้าเครื่อง → รันคำสั่ง diagnose → อ่าน log → แก้ + backup → commit ได้เองทั้งหมด ไม่ใช่แค่ chatbot ที่ตอบคำถามแล้วบอกให้ผมไปทำเอง

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

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

cron job ยิงผิดเวลาโดยไม่มี error แบบนี้แก้ยังไง?

ก่อนอื่นให้รัน timedatectl เช็ค timezone ของเครื่องก่อนเลยครับ ถ้า timezone เปลี่ยนโดยไม่รู้ตัว cron ทุกตัวจะยิงผิดเวลาเท่ากับส่วนต่างของ timezone โดยไม่มี error เด้งเลย วิธีแก้ที่ดีคือเก็บเครื่องให้เป็น timezone เดียวกับที่คุณทำงานจริง แล้วเขียน cron ด้วยเวลาท้องถิ่นตรงๆ ไม่ต้องบวกลบในหัวทุกครั้ง

ทำไม timezone ของ VPS ถึงเปลี่ยนได้โดยที่เราไม่ได้สั่ง?

ส่วนใหญ่เกิดจาก script หรือ feature บางอย่างที่รัน timedatectl set-timezone เป็น side-effect โดยไม่มี popup เตือนครับ ตัวอย่างเช่น dashboard หรือ control panel ที่มี field ตั้ง timezone แล้วพอกด save มันไปแก้ system clock จริง ไม่ใช่แค่ค่าแสดงผล ควรตรวจ changelog หรือ log ของวันที่ cron เริ่มยิงผิดเพื่อหาว่าอะไร trigger การเปลี่ยน

ก่อนแก้ crontab ต้องเตรียมอะไรบ้าง?

ให้ backup crontab ทั้งหมดก่อนด้วย crontab -l > crontab-backup.txt เสมอครับ จากนั้นแยกประเภทว่า cron ตัวไหนเป็น fixed-hour (ต้องขยับ) ตัวไหนเป็น interval (*/15 หรือ hourly ไม่ต้องแตะ) และตัวไหนเป็น one-shot ที่ผูกกับวันที่เฉพาะ แก้ทีละตัวพร้อมเข้าใจว่าแต่ละบรรทัดทำอะไร

บั๊กที่ทำให้ระบบทำงานผิดเวลาแทนที่จะพัง อันตรายกว่าบั๊กปกติไหม?

อันตรายกว่ามากครับ เพราะไม่มี error ไม่มี alert ทุกอย่างดู success หมด แค่มาผิดเวลา ระบบ monitoring แบบดั้งเดิมที่จับแค่ crash หรือ exception จับบั๊กแบบนี้ไม่ได้เลย ต้องอาศัยคนสังเกต timestamp ที่ผิดปกติเอง ยิ่งมีระบบ automation เยอะ ยิ่งกระทบหลายจุดพร้อมกัน