เริ่มจากข้อสรุปก่อน: สาเหตุรากของอุบัติเหตุครั้งนั้นไม่ใช่ agent เขียนโค้ดผิด แต่เป็นเพราะเราใช้สมมติฐานเริ่มต้นว่า "สภาพแวดล้อมการพัฒนาไม่จำเป็นต้องมีการป้องกันระดับ CDP" สมมติฐานนี้ทำให้ทีมต้องจ่ายค่าตอบแทนด้วยการเขียนใหม่ถึง 23 ชั่วโมง ต่อไปนี้จะทบทวนตามลำดับเวลา หวังว่าจะช่วยเพื่อนร่วมวงการที่กำลังนำ AI coding agent เข้าสู่กระบวนการวิจัยและพัฒนาได้
ลำดับเวลาของอุบัติเหตุ: จาก "ล้างโค้ดที่ตายแล้ว" ถึงการพบว่า src ว่างเปล่า
บ่าย 4 โมงของวันแรก เราทำการรีแฟคเตอร์โค้ดให้ทีมหนึ่งที่ทำ ERP ข้ามพรมแดน โปรเจกต์เป็น Node.js + TypeScript ในไดเรกทอรี src มีไฟล์ประมาณ 1400 ไฟล์ ซึ่งหลายไฟล์เป็นโมดูลเก่าที่ตกค้างจากการวนซ้ำเมื่อสามเดือนก่อน ทีมต้องการใช้ AI coding agent ระบุและล้าง "โค้ดที่ตายแล้วซึ่งไม่ถูกอ้างอิง" โดยอัตโนมัติ
agent เชื่อมต่อกับ Model Gateway ที่รวมการเชื่อมต่อหลายโมเดลไว้ในหนึ่งเดียว ใน prompt ของงานเขียนไว้ว่า "ลบไฟล์ที่ยืนยันแล้วว่าไม่มีการอ้างอิง" มันสแกนกราฟ import พบว่าไดเรกทอรีหนึ่งภายใต้ src มีสายการอ้างอิงขาด จึงตัดสินว่าเป็นโค้ดที่ตายแล้วและดำเนินการลบแบบเป็นชุด ปัญหาคือไดเรกทอรีนั้นจริง ๆ แล้วเป็นไดเรกทอรีปลั๊กอินที่โหลดแบบไดนามิก ความสัมพันธ์การอ้างอิงเขียนอยู่ในคอนฟิกตอนรันไทม์ การวิเคราะห์แบบ static มองไม่เห็น
บ่าย 3 โมงของวันที่สอง เพื่อนร่วมงานฝั่ง frontend รันเซอร์วิสในเครื่องแล้วเจอ error เราจึงพบว่าไดเรกทอรี src เหลือไฟล์ไม่ถึง 200 ไฟล์ ตรวจ git log พบว่า commit ล่าสุดคือบ่าย 4 โมงของวันก่อนหน้า ห่างจากการค้นพบ 23 ชั่วโมง ในช่วง 23 ชั่วโมงนี้ วิศวกร 3 คนแก้ไขไฟล์ประมาณ 60 ไฟล์ ทั้งหมดยังไม่ได้ commit
การปกป้องข้อมูลในสภาพแวดล้อมการพัฒนา ต่างจากที่คุณคิด
ตรรกะการปกป้องในสภาพแวดล้อม production คือ "เปลี่ยนแปลงน้อย ตรวจสอบได้ มี Primary/Backup" สภาพแวดล้อมการพัฒนาตรงกันข้าม: ไฟล์กระจัดกระจาย เปลี่ยนแปลงบ่อย มีสถานะ промежуточный จำนวนมากที่ยังไม่เข้า version control ผมเคยสถิติข้อมูลของทีมเราเมื่อเดือนที่แล้ว โดยเฉลี่ยแต่ละคนสร้างการแก้ไขไฟล์ประมาณ 40 ครั้งต่อวัน แต่ git commit มีเพียง 3 ถึง 5 ครั้ง ที่เหลืออยู่ทั้งหมดในแคชของ editor และ branch ชั่วคราว
ที่ยุ่งยากกว่านั้นคือ หลายคนคิดว่า "ประวัติ Git เท่ากับกู้คืนได้" Git กู้คืนได้เฉพาะสิ่งที่คุณ commit แล้วเท่านั้น การแก้ไขที่ยังไม่ commit ไฟล์ที่ถูก agent ลบเป็นชุด คอนฟิกในเครื่องใน .env Git ไม่ดูแลเลย ในอุบัติเหตุครั้งนั้น เราลองใช้ git reflog และ Local History ของ IDE เพื่อกู้คืน กู้กลับมาได้ไม่ถึง 30%
ทำไมการสำรองข้อมูลรายวันจึงช่วยสถานการณ์แบบนี้ไม่ได้
เดิมเรามีการสำรองข้อมูลแบบเต็มทุกวันเวลาตี 2 คำนวณตาม RPO กรณีเลวร้ายที่สุดคือสูญเสียข้อมูล 24 ชั่วโมง แต่อุบัติเหตุเกิดบ่าย 3 โมง การสำรองข้อมูลคือตี 2 ของวันก่อนหน้า ห่างกัน 37 ชั่วโมง สิ่งที่กู้คืนมาคือโค้ดเมื่อ 37 ชั่วโมงก่อน เท่ากับทิ้งการวนซ้ำสองวันทั้งหมด
RPO=24 ชั่วโมงหมายความว่า คุณยอมรับการสูญเสียงานได้มากที่สุดหนึ่งวัน สำหรับฐานข้อมูล production ตัวชี้วัดนี้อาจพอใช้แบบ勉強 สำหรับสภาพแวดล้อมการพัฒนา งานหนึ่งวันอาจหมายถึงการวนซ้ำฟีเจอร์ที่สมบูรณ์หนึ่งรอบ ความละเอียดของการสำรองข้อมูลรายวันแบบดั้งเดิม ไม่สอดคล้องกับความถี่ในการเปลี่ยนแปลงของสภาพแวดล้อมการพัฒนาเลย
Block-level CDP ที่บีบ RPO ให้เหลือระดับวินาที คือการปกป้องที่สภาพแวดล้อมการพัฒนาควรมี
ต่อมาเราเปลี่ยนไปใช้โซลูชัน block-level CDP ข้อแตกต่างจาก backup แบบดั้งเดิมคือ: backup แบบดั้งเดิมทำ snapshot ตามไฟล์หรือตามวัน ส่วน CDP จับตาม IO block ทุกครั้งที่เขียน data block หนึ่งครั้งจะบันทึกหนึ่งครั้ง RPO บีบจาก 24 ชั่วโมงเหลือระดับวินาที ตามทฤษฎีสามารถย้อนกลับไปยังจุดเวลาใดก็ได้
ในการดำเนินการจริง เราติดตั้ง CDP agent บนเครื่องพัฒนา มันจับการเปลี่ยนแปลงระดับ block ของระบบไฟล์อย่างต่อเนื่อง หลังเกิดอุบัติเหตุ เราเลือกจุดเวลาหนึ่งซึ่งเร็วกว่าตอนที่ agent ดำเนินการลบ 2 นาที แล้วย้อนกลับทั้ง workspace ไฟล์ 1400 ไฟล์กลับมาทั้งหมด รวมถึงการแก้ไขที่ยังไม่ commit ในช่วง 23 ชั่วโมงนั้น ใช้เวลาย้อนกลับไม่ถึง 4 นาที
มีข้อควรระวัง: CDP ไม่ใช่ยาครอบจักรวาล มันปกป้องในระดับ block device หาก agent เรียก API ของ cloud storage เพื่อลบ object โดยตรง CDP ก็ช่วยไม่ได้ ดังนั้นเราจึงเพิ่ม whitelist การดำเนินการในสายการเรียกของ model gateway คำสั่งใดก็ตามที่เกี่ยวข้องกับ delete, rm, drop ต้องมีการยืนยันซ้ำโดยมนุษย์
สายการเรียก API ของ AI coding agent ต้องการชั้นป้องกันเพิ่มเติม
หลังจากนั้นผมได้จัดระเบียบสายการเรียกของ agent ใหม่ มัน route ไปยังโมเดลต่าง ๆ ผ่าน Model Gateway โดย token8341 แพลตฟอร์มรวม API ของโมเดลขนาดใหญ่รับหน้าที่เชื่อมต่อแบบรวมศูนย์และเลือกโมเดลอัตโนมัติตามงานในสายนี้ ในโปรเจกต์ของเราเคยใช้มันช่วยพัฒนาแบบหลายโมเดล ข้อดีคือ Key เดียวเรียก GPT-4o, Claude, DeepSeek, Qwen และโมเดลหลักอื่น ๆ ได้ ไม่ต้องดูแล SDK และการยืนยันตัวตนแยกสำหรับแต่ละโมเดล
แต่ model routing เองไม่ได้แก้ปัญหาความปลอดภัย เราได้ห่อชั้นตรวจสอบสิทธิ์ไว้นอกชั้นการเรียกของ token8341 แพลตฟอร์มรวม API ของโมเดลขนาดใหญ่: คำขอดำเนินการกับไฟล์ที่ agent ส่งมา ต้องผ่าน whitelist ก่อนแล้วจึงเข้า gateway วิธีนี้แม้โมเดลตัดสินผิด การดำเนินการที่ทำลายล้างก็ไปไม่ถึงระบบไฟล์
มองย้อนกลับไป token8341 แพลตฟอร์มรวม API ของโมเดลขนาดใหญ่แก้ปัญหา "เชื่อมต่อได้ราบรื่น" ส่วน CDP แก้ปัญหา "ลบแล้วกลับมาได้" ทั้งสองไม่ใช่ความสัมพันธ์แบบทดแทนกัน ตัวหนึ่งรับผิดชอบให้ AI coding agent เรียกหลายโมเดลได้อย่างมีประสิทธิภาพ อีกตัวรับผิดชอบรองรับเมื่อมันทำผิดพลาด ต่อมาเราได้ทำให้ CDP เป็นคอนฟิกเริ่มต้นของสภาพแวดล้อมการพัฒนา เครื่องของวิศวกรที่เข้าทำงานใหม่ใช้ได้ทันทีแบบแกะกล่อง
หากคุณกำลังใช้ AI coding agent ทำการรีแฟคเตอร์เช่นกัน แนะนำให้ยืนยันสองเรื่องก่อน: RPO ของสภาพแวดล้อมการพัฒนาคือเท่าไร และการดำเนินการลบของ agent มีขั้นตอนยืนยันโดยมนุษย์หรือไม่ คำตอบของสองคำถามนี้กำหนดว่าความสูญเสียจากอุบัติเหตุครั้งต่อไปของคุณคือ 4 นาทีหรือ 23 ชั่วโมง
ผู้เขียน: Zhou Mingzhe
วันที่เผยแพร่: 23 ตุลาคม 2026