AI ตรวจสอบ Database Migration ได้ครับ ถ้าให้มันเทียบ schema, ลองกับข้อมูลสำเนา และรายงานความเสี่ยงก่อนแตะ production. มันเก่งมากกับการอ่าน diff ยาว ๆ และไล่ผลกระทบข้ามโค้ด แต่ไม่ควรได้สิทธิ์รันคำสั่งเปลี่ยนข้อมูลลูกค้าเองเด็ดขาดครับ
คำว่า migration ฟังเหมือนงาน dev หลังบ้าน เลยมีคนคิดว่าแค่รันผ่านก็จบ แต่จริง ๆ มันเหมือนย้ายชั้นวางเอกสารทั้งออฟฟิศครับ ถ้าเปลี่ยนป้ายช่องเก็บเอกสารโดยไม่เช็กว่าทีมเก่ายังหาช่องเดิมอยู่ไหม เอกสารไม่ได้หายทันที แต่งานทั้งทีมอาจไปต่อไม่ได้ 555
Database Migration คืออะไร และ AI ช่วยตรงไหน?
Database Migration คือชุดคำสั่งที่เปลี่ยนโครงสร้างข้อมูล เพื่อให้โค้ดเวอร์ชันใหม่ทำงานได้ครับ และ AI ช่วยได้ดีที่สุดก่อนรัน: มันอ่านว่าอะไรเพิ่ม อะไรเปลี่ยน และอะไรอาจพังตามมา. ตัวอย่างง่าย ๆ คือเพิ่มคอลัมน์อีเมล, เปลี่ยนสถานะออเดอร์, หรือสร้าง index ให้หน้ารายการเร็วขึ้น
สิ่งที่ผมให้ AI ไล่ไม่ใช่แค่ SQL หนึ่งไฟล์ แต่มี schema ก่อน-หลัง, จุดในโค้ดที่อ่านหรือเขียน field นั้น, งาน cron, API และหน้าที่ลูกค้าใช้ด้วย เพราะ migration ที่ syntax ถูก ยังอาจเปลี่ยนความหมายของข้อมูลผิดได้ เช่น status เดิมมีค่า null แต่โค้ดใหม่ตีความ null ว่า “ยกเลิก”
จุดสำคัญคือ AI ต้องรายงานสิ่งที่รู้กับสิ่งที่เดาแยกกัน ผมไม่รับคำตอบว่า “ปลอดภัยครับ” ถ้าไม่มีรายการ table ที่กระทบ จำนวนแถวที่คาดว่าจะเปลี่ยน และ test ที่ยืนยันผลได้ อ่านหลักคิดเรื่องให้ AI ใช้หลักฐานก่อนสรุปต่อได้ใน AI Agent ควรอ่าน Log ก่อนแก้บั๊กไหม ครับ
เคสจริง: ทำไมผมไม่ยอมให้แก้ schema แล้วขึ้น 86 เครื่องทันที?
ผมเคยเจอการเปลี่ยน schema ของ event ใน Newton ที่ทำให้ข้อมูลมีอยู่จริง แต่หน้าแชตหา text ไปแสดงไม่เจอครับ. มันไม่ใช่ database migration ตรงตัว แต่บทเรียนเหมือนกันเป๊ะ: โครงสร้างข้อมูลเปลี่ยนแล้ว consumer เก่าตามไม่ทัน
ตอน Codex เปลี่ยน event เป็นรูปแบบใหม่ adapter ของเรายังอ่าน schema เก่าอยู่ AI ช่วยเทียบ payload ทั้งสองฝั่ง แล้วเขียน test ที่ส่งข้อมูลแบบใหม่เข้าไป ผลบนโค้ดเดิมคือ 4 จาก 12 test ล้ม พอแก้ parser และทดสอบซ้ำจึงผ่าน 12 จาก 12 ก่อนผมอนุมัติ rollout ที่อาจกระทบลูกค้า Newton ถึง 86 เครื่อง
ตัวเลขนี้ไม่ได้แปลว่า AI รับประกันความปลอดภัยนะครับ แต่มันทำให้ผมตัดสินใจจากหลักฐานแทนความรู้สึก ถ้าเป็น migration ฐานข้อมูล ผมก็ใช้หลักเดียวกัน: ทำสำเนา, รันคำสั่ง, นับก่อน-หลัง, ลอง flow สำคัญ แล้วค่อยพิจารณาของจริง รายละเอียดเคส schema นี้ผมเล่าไว้ใน AI แก้ bug ได้ไหม ครับ
AI ควรตรวจอะไรบ้างก่อน Database Migration?
ก่อน migration ผมให้ AI ตรวจ 6 เรื่อง: schema diff, ข้อมูลเก่า, ความเข้ากันได้, เวลารัน, backup และ rollback ครับ. ถ้าขาดข้อใดข้อหนึ่ง คำว่า “ผ่าน” ยังไม่พอสำหรับ production
หนึ่ง ดูว่า add, rename หรือ drop อะไร และมี foreign key/index ที่เปลี่ยนไหม สอง นับข้อมูลจริงที่จะโดน เช่น column ที่กำลังบังคับ NOT NULL มีแถวว่างอยู่กี่แถว สาม โค้ดเวอร์ชันเก่ากับใหม่อยู่ร่วมกันระหว่าง deploy ได้ไหม สี่ query จะ lock ตารางนานจนลูกค้าใช้งานไม่ได้หรือเปล่า ห้า backup ล่าสุดอ่านคืนได้จริงไหม และหก ถ้าผลไม่ตรง เราจะย้อนเฉพาะส่วนไหนด้วยคำสั่งอะไร
AI ช่วยเปลี่ยน checklist นี้เป็นรายงานอ่านง่ายได้ครับ แต่หลักฐานต้องมาจาก staging หรือสำเนาที่ใกล้ของจริง ไม่ใช่ให้มันดู migration file เปล่า ๆ แล้วทายผล เรื่องตรวจข้อมูลข้ามระบบและไม่แก้ยอดเอง ผมเขียนต่อไว้ใน AI ตรวจข้อมูลผิดพลาดได้ไหม
ทำไมต้องทดสอบกับข้อมูลสำเนา ไม่ใช่แค่ดู SQL?
เพราะ SQL ที่รันได้ไม่เท่ากับข้อมูลหลังรันใช้ได้ครับ. ตัวอย่างเช่นคำสั่งแปลงวันที่อาจไม่มี error เลย แต่บาง row เก่ามีรูปแบบวันที่ไม่เหมือนที่คิด ผลคือข้อมูลถูกแปลงเป็นค่าว่าง หรือชื่อซ้ำเพิ่งมาเจอเมื่อสร้าง unique index
ผมจะให้ AI สร้าง test case จากข้อมูลจริงแบบปิดข้อมูลส่วนตัว: มี record ปกติ, record เก่า, record ว่าง, record ซ้ำ และค่าที่ขอบเขต แล้วรัน migration กับสำเนา หลังจากนั้นตรวจจำนวนแถว, ค่า field สำคัญ, query ที่หน้าเว็บใช้ และผลย้อนกลับ ขั้นนี้ไม่ได้ช้าเท่าการตามแก้ตอนลูกค้าเจอครับ
หลักเดียวกับการทดสอบระบบจ่ายเงินเลย: sandbox หรือ test เล็ก ๆ ผ่าน ไม่ได้แปลว่า production ผ่าน ถ้าปลายทางแตะสิทธิ์ลูกค้าหรือเงิน ผมให้ตรวจ flow จริงและมีคนยืนยันเสมอ ดูตัวอย่างได้ที่ AI ทดสอบระบบจ่ายเงินก่อนใช้จริงได้ไหม
ให้ AI รัน migration เองได้ไหม?
ให้ AI รันบน local หรือ staging ได้เมื่อขอบเขตชัดและย้อนกลับได้ แต่ production ควรหยุดรอคนอนุมัติครับ. สิทธิ์ที่เหมาะคืออ่าน schema, สร้างรายงาน, รัน test และเตรียมคำสั่ง—not มีสิทธิ์เปลี่ยนฐานข้อมูลลูกค้าด้วยประโยคเดียว
ผมแบ่งงานเป็นสามด่าน: ด่านแรก AI อ่านอย่างเดียวและทำ risk report; ด่านสอง AI รัน migration กับสำเนา พร้อมผลตรวจที่รันซ้ำได้; ด่านสามคนเลือกช่วงเวลา ดู backup และกดยืนยันบน production ถ้าคำสั่งล้ม ต้องมี owner ที่รู้ว่าต้องหยุดตรงไหน ไม่ใช่ปล่อย agent ลองคำสั่งถัดไปเอง
การคุมสิทธิ์แบบนี้ไม่ใช่ไม่เชื่อ AI ครับ มันคือออกแบบให้ความเร็วของ AI อยู่ในที่ที่มีประโยชน์ที่สุด ส่วนความเสี่ยงอยู่หลังประตูที่คนเปิดเท่านั้น วิธีแบ่งสิทธิ์ให้ agent อ่านต่อได้ใน AI Agent ควรมีสิทธิ์เข้าถึงอะไรบ้าง
เจ้าของธุรกิจที่ไม่ใช่ dev เริ่มใช้วิธีนี้อย่างไร?
เริ่มจากขอรายงานก่อนเปลี่ยนระบบทุกครั้ง ไม่ต้องเริ่มจากให้ AI จัดการ database เองครับ. ถามให้ครบว่าอะไรจะเปลี่ยน, ข้อมูลใครจะโดน, เราทดสอบกับอะไร, ถ้าพังย้อนยังไง และใครเป็นคนกดอนุมัติ
แม้คุณไม่อ่าน SQL คุณก็ตรวจคำตอบเชิงธุรกิจได้ เช่น “หลังเปลี่ยนลูกค้าเก่ายัง login ได้ไหม”, “ออเดอร์เดิมยังแสดงยอดถูกไหม”, “มี backup กี่โมงและ restore แล้วหรือยัง” คำถามพวกนี้บังคับให้ทั้งคนและ AI ผูกงานเทคนิคกับผลที่ลูกค้าเจอจริง ถ้าอยากฝึกแตกงานและสั่ง AI ให้ส่งหลักฐานแบบนี้ ผมสอนไว้ใน คอร์ส LearnAI ครับ
คำถามที่พบบ่อย
AI ตรวจสอบ Database Migration ได้ไหม?
ได้ครับ AI ช่วยอ่าน schema diff หา risk ตรวจสำเนาข้อมูล และสรุปสิ่งที่ต้องยืนยันได้ แต่ไม่ควรเป็นคนตัดสินใจรันบน production เอง
Database Migration คืออะไร?
คือการเปลี่ยนโครงสร้างฐานข้อมูล เช่น เพิ่มตาราง เพิ่มคอลัมน์ เปลี่ยนชนิดข้อมูล หรือสร้าง index เพื่อให้โค้ดเวอร์ชันใหม่ทำงานกับข้อมูลได้ถูกต้อง
ก่อนรัน migration ต้องตรวจอะไรบ้าง?
ตรวจ diff, ข้อมูลเดิมที่กระทบ, โค้ดเก่า-ใหม่อยู่ร่วมกันได้ไหม, เวลาที่ lock ตาราง, backup ที่ restore ได้ และ rollback ที่ทดลองแล้วครับ
ให้ AI รัน migration บน production เองได้ไหม?
ไม่ควรครับ ให้มันเตรียมรายงานและทดสอบ staging ได้เต็มที่ แต่คนควรอนุมัติช่วงเวลา คำสั่ง และการเปลี่ยนจริง
ถ้าคุณอยากมี AI ที่ไม่ได้แค่คุยเก่ง แต่ช่วยอ่านหลักฐาน ทำงานเป็นขั้น และหยุดรอคุณก่อนแตะจุดเสี่ยง ลองดู Newton ครับ ผมสร้างมันจากวิธีที่ผมใช้รันธุรกิจจริง: ให้ AI เร็วกับงานที่ตรวจได้ แต่ไม่ให้ความมั่นใจมาก่อน evidence
— Pond