มีงานประเภทหนึ่งที่น่าเบื่อมาก แต่ถ้าไม่ทำ ของจะค่อยๆ พังเงียบๆ — นั่นคือการ "อัปเดต" ครับ Newton ขายเป็น managed server คือลูกค้าจ่ายรายเดือนได้ server ส่วนตัวเต็มลูก + AI agent (Tim Chat) พร้อมใช้ ทุกอย่างผมดูแลให้หมด ลูกค้าแค่สั่งงาน AI ไม่ต้องแตะ terminal เลย — แต่พอผมไปเช็ค server ลูกค้าวันก่อน ถึงเจอว่ามีของชิ้นนึงที่ผมลืมดูแลมาตลอด
Claude Code — ตัว AI ที่รันอยู่บน server ลูกค้าทุกคน — มันค้างอยู่เวอร์ชันเก่า
ปัญหา — AI ของลูกค้าค้างเวอร์ชันเดิมตั้งแต่วันสมัคร
Anthropic (เจ้าของ Claude) ออกเวอร์ชันใหม่ของ Claude Code ถี่มากครับ — บางสัปดาห์ออก 2-3 รอบ แต่ละรอบมีของใหม่ บั๊กที่แก้ ความเร็วที่ดีขึ้น หรือบางทีก็ model ใหม่เลย
ปัญหาคือ — ตอนผม provision server ให้ลูกค้าใหม่ ผมติดตั้ง Claude เวอร์ชันที่มีอยู่ ณ วันนั้น แล้วก็... จบ มันค้างอยู่เวอร์ชันนั้นตลอดไป ลูกค้าที่สมัครเมื่อเดือนก่อนก็ยังใช้ของเก่ากว่าลูกค้าที่เพิ่งสมัครเมื่อวาน
ผมไปไล่เช็คทั้ง 20 เครื่องที่ active อยู่ — เจอว่าหลายเครื่องค้างอยู่เวอร์ชัน 2.1.92 ในขณะที่ของล่าสุดตอนนั้นคือ 2.1.154 ห่างกันหลายสิบรุ่น 555
นี่มันขัดกับสัญญาของ Newton ตรงๆ ครับ — ผมบอกลูกค้าว่า "ไม่ต้องดูแล infra เอง" แต่ดันปล่อยให้ AI หัวใจของระบบค้างเวอร์ชันเก่า มันไม่ควรเป็นภาระของลูกค้าที่จะมานั่งพิมพ์คำสั่งอัปเดตเองทุกสัปดาห์
โจทย์ที่ผมให้ทิม
ผมสั่งทิม (AI agent ของผมเอง ตัวที่ช่วยรันธุรกิจ) สั้นๆ ว่า "ทำให้ Claude บน server ลูกค้าทุกเครื่องอัปเดตเองอัตโนมัติ และเครื่องใหม่ที่สมัครเข้ามาต้องอัปเดตเองตั้งแต่วันแรก"
ฟังดูง่ายนะครับ — ก็แค่ตั้ง cron job ให้รันคำสั่งอัปเดตทุกวัน เครื่องละบรรทัดเดียว
คำสั่งจริงๆ มันสั้นแค่นี้เอง:
npm install -g @anthropic-ai/claude-code@latest
แล้วเอาไปใส่ cron ให้รันตอนตี 4 ทุกวัน (เวลาที่ลูกค้าไม่ได้ใช้งาน) จบ — แต่พอทิมลงมือทำจริง มันเจอกับดักที่เกือบทำลูกค้าพังหมดทั้งระบบ
กับดัก — วิธีเติม cron ที่นิยมใช้กัน ดันลบ cron เดิมทิ้งทั้งหมด
เรื่องนี้สำคัญ เพราะมันคือความต่างระหว่าง "AI ที่ทำตามคำสั่งดิบๆ" กับ "AI ที่คิดเผื่อก่อนทำ"
server ลูกค้า Newton ไม่ใช่เครื่องเปล่าๆ ครับ — ลูกค้าหลายคนสั่ง AI ของตัวเองตั้ง cron job ไว้เพียบ มีเครื่องนึงที่ทิมไปเจอ ลูกค้าตั้ง cron ไว้ 144 ตัว สำหรับระบบโพสต์ Facebook อัตโนมัติของเขา
วิธีเติม cron ที่คนส่วนใหญ่ (รวมถึง AI หลายตัว) เขียนกันคือแบบนี้:
(crontab -l; echo "บรรทัดใหม่") | crontab -
ดูเผินๆ เหมือนถูก — มันคือ "เอา cron เดิมทั้งหมด บวกบรรทัดใหม่ แล้วเขียนกลับ" แต่ทิมไม่เชื่อใจ มันทดสอบก่อนบนเครื่องเปล่าๆ — แล้วพบว่าวิธี subshell-pipe แบบนี้ในบาง environment มัน เขียน crontab ว่างเปล่ากลับไป เฉยเลย
ลองคิดดูครับ — ถ้าทิมเอาคำสั่งนี้ไปยิงใส่เครื่องลูกค้าที่มี cron 144 ตัว ระบบโพสต์ Facebook ของเขาจะหายเกลี้ยงในคืนเดียว แล้วลูกค้าจะไม่รู้ตัวด้วยซ้ำว่าทำไมเพจตัวเองเงียบไป จนกว่าจะมาเช็คเอง
นี่แหละครับเหตุผลที่ผมย้ำกับทิมเสมอว่า — บน server ลูกค้าต้อง careful เป็นพิเศษ เพราะมันไม่ใช่ sandbox ของเรา มันคือธุรกิจของคนอื่นที่รันอยู่จริง
วิธีที่ปลอดภัย — temp file + dedup
ทิมเปลี่ยนมาใช้วิธีที่ปลอดภัยกว่า แทนที่จะ pipe ตรงๆ มันทำเป็นขั้นตอน:
หนึ่ง — ดึง cron เดิมทั้งหมดออกมา กรองบรรทัดของเราออก (เผื่อเคยใส่ไว้แล้ว) เขียนลงไฟล์ชั่วคราว สอง — เติมบรรทัดอัปเดตของเราต่อท้ายไฟล์ สาม — โหลด crontab จากไฟล์นั้น
ผลคือ — cron เดิมของลูกค้าทุกตัวอยู่ครบ บรรทัดของเราถูกเติมเข้าไปแค่บรรทัดเดียว และถ้ารันซ้ำกี่รอบก็ไม่ซ้อน (เพราะกรองของเก่าออกก่อนเสมอ) ภาษาเทคนิคเรียกว่า idempotent — รันกี่ครั้งผลก็เหมือนเดิม ปลอดภัยที่จะรันซ้ำ
ทิมยิงคำสั่งนี้ผ่าน SSH เข้าทุกเครื่องที่ active แล้วบังคับอัปเดตทุกตัวจาก 2.1.92 → 2.1.154 ในรอบเดียว พร้อมฝัง cron ตี 4 ไว้ให้ทุกเครื่องดูแลตัวเองต่อไปเอง
ทำไมต้อง "เงียบ" — ไม่แจ้งลูกค้าเลย
จุดที่ผมตั้งใจออกแบบคือ — การอัปเดตนี้ต้อง เงียบสนิท ลูกค้าไม่ต้องรู้ว่ามันเกิดขึ้น ไม่มีอีเมล ไม่มี notification ไม่มีอะไรเด้งขึ้นมา
เหตุผลคือ — ลูกค้า Newton ส่วนใหญ่ไม่ใช่ dev ครับ เขาจ่ายเงินเพื่อให้ "มันทำงานได้" ไม่ใช่เพื่อมานั่งติดตามว่าวันนี้ AI อัปเดตเป็นเวอร์ชันอะไร ถ้าผมส่งอีเมลแจ้งทุกครั้งที่อัปเดต = สัปดาห์ละ 2-3 ฉบับ มันกลายเป็น noise ที่ทำให้ลูกค้ารำคาญเปล่าๆ
นี่เป็นปรัชญาเดียวกับที่ผมลบระบบแจ้งเตือนที่เยอะเกินไปทิ้งก่อนหน้านี้ครับ — งานบ้านหลังบ้านที่ดีคืองานที่ทำเสร็จโดยที่ลูกค้าไม่ต้องรับรู้ มันควรจะ "หายไป" ในความรู้สึกของลูกค้า เหมือนน้ำประปาที่ไหลตลอดโดยไม่ต้องมีใครมาบอกว่า "วันนี้สูบน้ำให้แล้วนะ"
ถ้าวันไหน Anthropic ออกเวอร์ชันที่ดันมีบั๊ก — อันนั้นเป็นเรื่องที่ผมจัดการได้ ผม rollback เครื่องนั้นกลับเวอร์ชันเดิมได้ในคำสั่งเดียว ความเสี่ยงของการ "อัปเดตอัตโนมัติ" มันเล็กกว่าความเสี่ยงของการ "ปล่อยให้ค้างเวอร์ชันเก่าไปเรื่อยๆ" เยอะครับ
เครื่องใหม่ต้องอัปเดตเองตั้งแต่วันแรก
การไล่อัปเดต 20 เครื่องที่มีอยู่ มันแก้ปัญหาแค่ "ตอนนี้" ครับ — แต่ลูกค้าใหม่ที่สมัครพรุ่งนี้ล่ะ?
ทิมเลยไปแก้ที่ ระบบ provision อัตโนมัติ ด้วย — ตอนนี้ทุกครั้งที่มีคนสมัคร Newton ใหม่ ระบบสร้าง server จะ (1) ติดตั้ง Claude เวอร์ชันล่าสุดทันที ไม่ใช่เวอร์ชันที่ติดมากับ image และ (2) ฝัง cron ตี 4 ตัวเดิมเข้าไปด้วยวิธี temp file ที่ปลอดภัยเดียวกัน
แปลว่าตั้งแต่นาทีแรกที่ลูกค้าได้ server — AI ของเขาเป็นเวอร์ชันล่าสุด และมันจะดูแลอัปเดตตัวเองต่อไปทุกวันโดยอัตโนมัติ ผมไม่ต้องมาไล่ทำเองอีก ระบบดูแลตัวเองครบวงจร
ของแถมที่ไม่ได้ตั้งใจ — model ใหม่มาเองโดยไม่ต้องแก้โค้ด
มีเรื่องนึงที่ผมเพิ่งรู้ตอนทำเรื่องนี้ครับ — เวลาลูกค้าเลือก model ใน Tim Chat (เช่นเลือก "Opus" ตัวที่ฉลาดที่สุด) ระบบผมไม่ได้ระบุเวอร์ชันตายตัว แต่ส่งเป็นชื่อเล่นว่า "opus" เฉยๆ
ผลพลอยได้คือ — พอ Claude Code อัปเดต ชื่อ "opus" มันก็ไปชี้ไปที่ Opus เวอร์ชันใหม่ล่าสุดให้เองอัตโนมัติ ลูกค้าไม่ต้องทำอะไรเลย วันดีคืนดี AI ของเขาก็ฉลาดขึ้นเองเพราะ model รุ่นใหม่มาแทนที่ — ทั้งหมดนี้เกิดจาก cron ตี 4 ที่อัปเดตตัว CLI
นี่คือสิ่งที่ผมชอบเรื่อง managed server ครับ — งานหลังบ้านชิ้นเดียวที่ทำถูก มันส่งผลดีต่อลูกค้าเป็นทอดๆ โดยที่ลูกค้าไม่ต้องรู้ด้วยซ้ำ (แต่ระบบอัปเดตตี 4 ตัวนี้เองก็เคยมีวันที่มันย้อนมาทำร้ายเครื่องลูกค้าเหมือนกันนะครับ — วันนึงAI 3 ตัวอัปเดตพร้อมกันจนแรมหมดแล้วเครื่องตายทั้งวัน นั่นอีกบทเรียนนึงเลย)
สิ่งที่ผมเรียนรู้
เรื่องนี้สอนผม 2 อย่างครับ
อย่างแรก — "managed" แปลว่าต้องดูแลถึงรายละเอียดที่ลูกค้ามองไม่เห็น ลูกค้าไม่มีทางรู้หรอกว่า AI ตัวเองค้างเวอร์ชันเก่า เขาก็ใช้ไปเรื่อยๆ ได้ แต่หน้าที่ของคนขาย managed server คือต้องเห็นปัญหานี้ก่อนลูกค้า แล้วแก้ให้จบโดยที่ลูกค้าไม่ต้องร้องขอ นี่แหละคือสิ่งที่ลูกค้าจ่ายเงินซื้อจริงๆ — ไม่ใช่ตัว server แต่คือความไม่ต้องคิดเรื่องพวกนี้
อย่างที่สอง — คำสั่งที่ดู "ง่าย" ที่สุดบางทีคือที่อันตรายที่สุด การเติม cron บรรทัดเดียวดูเหมือนงาน 5 นาที แต่ถ้าทิมทำตามวิธีที่นิยมกันโดยไม่ทดสอบก่อน มันอาจลบ cron 144 ตัวของลูกค้าทิ้งหมด — การที่ AI หยุดคิด "เดี๋ยวนะ บนเครื่องลูกค้าต้องไม่ทำลายของเดิม" แล้วทดสอบก่อนยิงจริง คือความต่างระหว่างเครื่องมือที่ไว้ใจได้กับระเบิดเวลา (เรื่อง cron นี่มีกับดักอีกแบบที่ผมเจอเองด้วย — วันนึงทุก cron ในเครื่องผมยิงเร็วไป 7 ชั่วโมงพร้อมกันเพราะ timezone โดน flip เงียบๆ)
คำถามที่พบบ่อย
ทำไม managed server ถึงต้อง auto-update AI ให้ลูกค้าด้วย?
เพราะลูกค้าที่จ่าย managed server จ่ายเงินเพื่อไม่ต้องมากังวลเรื่อง infrastructure ครับ ถ้าให้ลูกค้ามานั่งพิมพ์คำสั่งอัปเดต AI เองทุกสัปดาห์ มันขัดกับสัญญาที่ให้ไว้ การ auto-update ตอนตี 4 เงียบๆ คือสิ่งที่ลูกค้าซื้อจริงๆ
การเติม cron job บน server ลูกค้าทำยังไงให้ไม่ลบ cron เดิมทิ้ง?
ต้องทำเป็น idempotent ครับ คือ (1) ดึง cron เดิมทั้งหมดออกมา (2) กรองบรรทัดของเราออกถ้ามีอยู่แล้ว (3) เติมบรรทัดใหม่ต่อท้าย (4) โหลด crontab จากไฟล์ชั่วคราว วิธีนี้ cron เดิมของลูกค้าทุกตัวอยู่ครบ และรัน script ซ้ำกี่รอบก็ไม่ซ้อน
cron job ตี 4 อัปเดต AI มีความเสี่ยงอะไรไหม?
มีครับ แต่ความเสี่ยงจากการอัปเดตน้อยกว่าปล่อยให้ค้างเวอร์ชันเก่าไปเรื่อยๆ มาก ถ้าเวอร์ชันใหม่มีบั๊ก ก็ rollback ได้ในคำสั่งเดียว แต่ถ้าค้างเวอร์ชันเก่า ลูกค้าไม่ได้ feature ใหม่และ bug fix ที่ควรได้มาตลอด
ลูกค้าจะรู้ตัวไหมว่า AI ของตัวเองอัปเดตเองทุกคืน?
ไม่รู้ตัวครับ ระบบออกแบบมาให้เงียบสนิท ไม่มีอีเมล ไม่มี notification ลูกค้า managed server ส่วนใหญ่ไม่ใช่ dev และไม่ต้องการมาติดตามว่า AI อัปเดตเป็นเวอร์ชันอะไร เขาแค่อยากให้ AI ของตัวเองทำงานได้ดีที่สุดตลอดเวลา
ถ้าคุณกำลังคิดจะใช้ AI agent รันงานจริงบน server ของตัวเอง — ลองดู Newton ครับ ลูกค้าได้ server ส่วนตัวเต็มลูก + AI agent พร้อมใช้ และเรื่องน่าเบื่อหลังบ้านแบบการอัปเดต AI ให้ทันสมัยตลอด ผมดูแลให้หมด คุณแค่สั่งงาน ที่เหลือปล่อยให้ระบบมันดูแลตัวเอง — รวมถึงอัปเดตตัวเองตอนตี 4 ที่คุณกำลังหลับอยู่ 555