AI Agent แก้ปัญหาระบบ Production ได้ไหม? ผมให้มันสืบก่อน แล้วค่อยให้คนตัดสินใจ
AI Agent แก้ปัญหาระบบ Production ได้ แต่ไม่ควรเริ่มจากปล่อยให้มันแก้เองทันที วิธีที่ผมใช้คือให้มันอ่าน log, เทียบสถานะ, สร้างสมมติฐาน และเสนอ patch ก่อน แล้วให้คนอนุมัติสิ่งที่กระทบลูกค้าจริง
ฟังดูระวังตัวเกินไปนิดนึง แต่ Production คือที่ที่ลูกค้าอยู่ครับ แก้เร็วแต่มั่วหนึ่งครั้ง อาจแพงกว่านั่งไล่สาเหตุดี ๆ สิบรอบ 555 ผมใช้ AI Agent ช่วย debug ระบบตัวเองแทบทุกวัน เพราะมันเปิดหลักฐานหลายจุดพร้อมกันได้เร็วกว่าผมมาก แต่ผมไม่เคยเอาคำว่า “AI มั่นใจ” มาแทนหลักฐาน
AI Agent ช่วยแก้ปัญหาระบบ Production ตรงไหนได้จริง?
มันเก่งที่สุดในงานสืบสวนที่ต้องข้ามหลายระบบ เช่น อ่าน error log, ดูสถานะ service, เทียบ code กับ configuration และสรุปลำดับเหตุการณ์ให้เราเห็นในภาพเดียว
เวลาเว็บมีปัญหา คนมักเริ่มจากหน้าที่พังแล้วเดาว่า “server ล่มมั้ง” แต่สาเหตุจริงอาจอยู่ที่ cache, database, cron, webhook หรือ deployment ก่อนหน้า Agent ไม่ได้มีพลังวิเศษหรอกครับ มันแค่ไม่เหนื่อยที่จะเปิดข้อมูลห้าจุดแล้วถามว่าอะไรเปลี่ยนไปพร้อมกัน
ผมจะกำหนดโจทย์ให้แคบมาก เช่น “หาว่าทำไม request ชุดนี้ error หลัง 14:00, สรุปหลักฐานเป็น link และห้าม restart หรือแก้ไฟล์” ผลลัพธ์ที่อยากได้ไม่ใช่บทความยาว ๆ แต่คือ timeline, จุดที่ผิดปกติ, สมมติฐานเรียงตามความน่าจะเป็น และคำสั่งตรวจต่อที่ปลอดภัย
เคสจริง: ทำไมลูกค้าเปิดแค่ 2 แท็บ แต่โดนบอกว่าเกินลิมิต?
เคสนี้ AI ช่วยให้ผมเจอว่าระบบนับ “การเชื่อมต่อ” ซ้ำแทนที่จะนับแท็บจริง ลูกค้าบอกว่าเปิดแค่ 2 แท็บ แต่หน้าแชตขึ้นว่าเกินโควตา 5 แท็บ ซึ่งถ้าดูแค่หน้าเว็บก็ไม่มีทางรู้ว่าผิดที่ไหน
ผมให้ Agent ไล่หลักฐานจาก API ที่บอกจำนวนแท็บ, log ของ WebSocket และโค้ดที่จอง slot ผลที่เจอคือ API มีแท็บจริงแค่ 2 แท็บ แต่ server ถือ connection ค้างอยู่ 6 เส้น เพราะทุกครั้งที่มือถือ reconnect ระบบใช้ id สุ่มใหม่และนับเป็น slot ใหม่ พอสะสมครบ 5 ก็ล็อกลูกค้าทั้งที่เขาไม่ได้เปิดเพิ่มเลย
รอบแรกมันช่วยชี้ root cause ได้เร็ว แต่เรื่องยังไม่จบครับ เราแก้ให้ browser ส่ง tab id ที่คงที่แล้ว ทดสอบผ่านหมด กลับมาเจอว่า iPhone ที่ค้าง JavaScript เก่ายัง reconnect วนอยู่ เพราะ protocol ping/pong ของ WebSocket ตอบเองได้แม้หน้าเว็บไม่ทำงานจริง สุดท้ายต้องเปลี่ยนเป็น app-level heartbeat แล้วตัด connection ที่เงียบเกิน 45 วินาที ถึงหายจริง
ตัวเลขนี้สำคัญกว่าคำว่า “แก้แล้วครับ” มาก: ระบบก่อนแก้เห็น 6 socket ทั้งที่มี 2 แท็บ หลังเปลี่ยน liveness check zombie ทั้ง 6 เส้นถูกคืน slot ภายในประมาณ 45 วินาที และแท็บที่ตอบ heartbeat อยู่ได้ตามปกติ Agent ทำให้การไล่หลักฐานเร็วขึ้น แต่คนยังเป็นคนตั้งคำถามว่า “เทสต์ผ่านแล้ว ทำไมลูกค้ายังเจอ?” นั่นแหละจุดที่ไม่ควรโยนพวงมาลัยให้ AI
ทำไมไม่สั่งให้ AI แก้แล้ว deploy ไปเลย?
เพราะการวิเคราะห์ผิดแก้ได้ แต่การเปลี่ยน Production ผิดอาจกระทบลูกค้าทุกคน ความสามารถรันคำสั่งได้ไม่ได้แปลว่าควรให้รันทุกคำสั่งโดยไม่มีด่านครับ
ในเคสนี้ ทางแก้แรกอาจทำให้ระบบนับแท็บของ client เก่าไม่ถูกเลยก็ได้ ถ้าผมให้ Agent push code แล้ว restart ทันทีโดยไม่มี canary หรือ test ลูกค้าที่ใช้งานอยู่จะกลายเป็นคนทดสอบแทนเรา ซึ่งไม่แฟร์เลย
ลำดับที่ผมใช้จึงเป็น: อ่านอย่างเดียว → สรุปหลักฐาน → เขียน patch → รัน test ที่ทำซ้ำได้ → deploy กล่องเดียว → ดู log จริง → ค่อยปล่อยต่อ วิธีนี้ช้ากว่า “สั่งทีเดียวจบ” นิดเดียว แต่ลดโอกาสที่เราจะกำลังแก้เหตุเล็กแล้วสร้าง incident ใหญ่กว่าเดิม
หลักเดียวกันนี้ผมใช้กับงานอื่นด้วย อย่าง เคส Stripe เก็บเงินได้ 2 รายรวม 1,980 บาท แต่ระบบไม่เปลี่ยนสถานะ Agent ไล่ event ที่หายและรายชื่อลูกค้าที่กระทบได้ แต่การ backfill ข้อมูลเงินยังต้องมีคนตรวจ เพราะผิดหนึ่ง record ก็กลายเป็นปัญหาบัญชีทันที
ต้องให้ AI Agent เข้าถึงอะไรบ้างถึงจะ debug ได้?
ให้สิทธิ์เท่าที่ตอบคำถามได้ ไม่ใช่เท่าที่ทำได้ เริ่มจาก read-only access ต่อ log, health endpoint, repository และข้อมูลที่ตัด secret ออกก่อน แล้วค่อยเพิ่มสิทธิ์เมื่อมีเหตุผลชัดเจน
ผมแยก credential สำหรับงานตรวจออกจาก credential ที่ deploy ได้ และไม่ปล่อย token ที่ใช้จริงลงใน prompt หรือ log ถ้า Agent ต้องเห็นข้อมูลลูกค้า ผมจะกำหนดว่าดูได้แค่ field ไหน และให้รายงานอ้างอิง id แทนการคัดข้อมูลส่วนตัวออกมาวางเต็ม ๆ
อีกกติกาหนึ่งที่ช่วยมากคือทุกข้อสรุปต้องชี้กลับไปที่ evidence ได้ เช่น timestamp ใน journal, commit ที่เปลี่ยน behaviour หรือ response จาก endpoint ถ้า Agent บอกว่า “น่าจะเป็น cache” แต่ไม่ชี้อะไรให้ตรวจต่อ ผมถือว่านั่นคือ hypothesis ไม่ใช่คำตอบ
เรื่องการกำหนดสิทธิ์นี่เป็นพื้นฐานเดียวกับบทความ AI Agent เชื่อมต่อระบบธุรกิจได้ยังไง เลยครับ ต่อเครื่องมือเยอะขึ้นไม่ได้ทำให้เก่งขึ้นอัตโนมัติ ถ้าเราไม่บอก source of truth, ขอบเขต และคนรับผิดชอบ มันก็แค่มีสิทธิ์ทำเรื่องผิดได้มากขึ้น
Workflow ให้ AI debug อย่างปลอดภัยควรมีอะไรบ้าง?
อย่างน้อยต้องมีโจทย์ชัด, หลักฐาน, วิธีทำซ้ำ, และจุดอนุมัติ สี่อย่างนี้ทำให้เราแยก “ดูเหมือนหาย” ออกจาก “รู้ว่าอะไรหายและกันไม่ให้กลับมา” ได้
เริ่มจากเขียน symptom เป็นภาษาที่ตรวจได้: ใครเจออะไร เวลาไหน ผลที่คาดหวังคืออะไร ต่อด้วยให้ Agent เก็บ facts ก่อนหา solution เสมอ ผมชอบกำชับว่าให้แยก facts, assumptions และ unknowns ออกจากกัน เพราะ AI มีนิสัยเอาช่องว่างไปเติมเป็นเรื่องเล่าได้เนียนมาก
จากนั้นให้มันเสนอ patch ที่เล็กที่สุดพร้อม test ที่จะ fail ก่อนแก้และ pass หลังแก้ ถ้าต้องแก้หลายชั้น ก็แก้ทีละชั้นและบันทึกผล ทุกครั้งที่มี restart, migration หรือข้อมูลลูกค้าเกี่ยวข้อง ให้หยุดรอ owner approve ไม่ใช่เพราะไม่ไว้ใจ AI แต่เพราะไม่มีใครควรมีอำนาจกดปุ่มเสี่ยงโดยไม่มีคนรับรู้
เวลาระบบโตขึ้น ผมใช้แนวคิดเดียวกับ การให้ AI Agent หลายตัวทำงานเป็นทีม คือแยกบทบาทให้ชัด ตัวหนึ่งสืบ, ตัวหนึ่งเขียนและรัน test, อีกตัวรีวิวผล ไม่ใช่ทุกตัวมีสิทธิ์ทุกอย่าง งานเร็วขึ้นเพราะแต่ละตัวรู้หน้าที่ ไม่ใช่เพราะเราปลดล็อกสิทธิ์หมด
ธุรกิจเล็กควรเริ่มใช้ AI แก้ปัญหาระบบจากงานไหน?
เริ่มให้มันเป็นผู้ช่วยหลังเหตุการณ์ก่อน อย่าเพิ่งให้เป็นคนกดปุ่มระหว่างเหตุการณ์ เอา incident เก่าหนึ่งเคสมาสั่งให้ทำ timeline, สรุป root cause และเสนอสิ่งที่ควร monitor เพิ่ม คุณจะเห็นทันทีว่ามันเข้าใจระบบตรงไหนและหลุดตรงไหน
ขั้นถัดไปคือให้มันทำ health check แบบ read-only ทุกวัน เช่น service ไหนตาย, disk ใกล้เต็มหรือไม่, งาน cron รอบล่าสุดสำเร็จไหม แล้วส่งแค่สิ่งผิดปกติมา ไม่ใช่ spam report ยาว ๆ เมื่อรายงานนิ่งค่อยให้มันเปิด ticket หรือสร้าง draft patch ใน staging
ถ้าอยากเรียนวิธีแตกงานให้ AI มีขอบเขต เขียน acceptance criteria และค่อย ๆ เพิ่ม autonomy แบบจับมือทำ ผมสอนไว้ใน คอร์สเรียน AI ครับ หัวใจไม่ได้อยู่ที่พิมพ์ prompt เก่งอย่างเดียว แต่อยู่ที่ออกแบบงานให้ตรวจคำตอบได้
คำถามที่พบบ่อย
AI Agent แก้ปัญหาระบบ Production ได้เองไหม?
ได้ในงานที่มีขอบเขตและย้อนกลับได้ เช่น อ่าน log ตรวจสถานะ หรือทำ patch เป็น draft แต่การ deploy ลบข้อมูล และงานที่กระทบลูกค้าควรมีคนอนุมัติเสมอครับ
ให้ AI Agent ดู log ระบบปลอดภัยไหม?
ปลอดภัยขึ้นเมื่อให้สิทธิ์อ่านเฉพาะที่จำเป็น ปิดบัง secret และบังคับให้มันอ้างอิงหลักฐานก่อนเสนอการแก้ ไม่ควรให้เข้าถึงทุกระบบตั้งแต่วันแรก
AI ช่วย debug ได้ดีกว่าคนหรือไม่?
AI เร็วมากในการไล่ข้อมูลหลายแหล่งและสร้างสมมติฐาน แต่ไม่รู้บริบทธุรกิจแทนเจ้าของ ผลที่ดีที่สุดคือให้ AI สืบและจัดหลักฐาน ส่วนคนตัดสินใจการเปลี่ยนแปลง
ควรเริ่มใช้ AI แก้ปัญหาระบบจากอะไร?
เริ่มจากสรุป incident เก่าหรือเช็ก health report แบบ read-only ก่อน เมื่อผลสม่ำเสมอค่อยเพิ่มให้สร้าง draft ของการแก้ไขและเทสต์ใน staging
ถ้าคุณอยากมี AI ที่ไม่ได้แค่ตอบแชต แต่มีพื้นที่ทำงานและ workflow ของตัวเองให้ช่วยตรวจงานหลังบ้าน ลองดู Newton ได้ครับ ผมสร้างมันจากโจทย์ที่เจอจริงนี่แหละ: อยากได้คนช่วยไล่ปัญหาได้ตลอดเวลา แต่ยังต้องให้เจ้าของธุรกิจคุมเรื่องสำคัญเอง
ปอนด์
