เส้นทาง 02บทเรียน 6 / 6

Debug ด้วยสมมติฐานที่ทดสอบได้

ใช้ agent เปรียบเทียบคำอธิบายและเก็บหลักฐาน หลีกเลี่ยงการแก้ซ้ำโดยยังไม่ได้ตรวจสอบสาเหตุ

ผู้ปฏิบัติงาน10 minตรวจทานแล้ว 5 ต.ค. 2569

ตรวจความเข้าใจคำขอล้มเหลวเฉพาะหลัง deploy แต่ทำงานได้ในเครื่อง Agent ควรทำอะไรเป็นอย่างแรกทำแบบฝึกหัด

แสดงคำตอบ

ความแตกต่างช่วยจำกัดขอบเขตการสืบค้น เปรียบเทียบคำขอ เวอร์ชัน configuration ตัวตน และข้อผิดพลาดที่เกี่ยวข้องโดยไม่เปิดเผย secret

สิ่งที่จะได้เรียนรู้

อธิบายพฤติกรรมที่คาดหวังและที่สังเกตได้อย่างแม่นยำ
เลือกสิ่งที่จะสังเกตซึ่งแยกคำอธิบายที่เป็นไปได้ออกจากกัน
ตรวจสอบการแก้ไขโดยไม่สับสนระหว่างการทำให้อาการหายกับการขจัดสาเหตุ

อธิบายความผิดพลาดก่อนเสนอวิธีแก้

คำขอ debug ที่มีประโยชน์ระบุพฤติกรรมที่คาดหวัง พฤติกรรมที่พบ และขอบเขตที่ได้รับผลกระทบ รวมเวอร์ชัน input ที่เกี่ยวข้อง และข้อผิดพลาด ลบข้อมูลรับรองและระเบียนส่วนตัวออกจาก log ก่อนส่งให้เครื่องมือ AI

“Export เสีย” ให้แนวทางน้อยเกินไป คำอธิบายที่ดีกว่าคือ “Export สำเร็จในเครื่อง แต่ใน staging คำขอเดียวกันของผู้จัดการได้ 403 หลัง deployment ล่าสุด Route อื่นยังทำงานได้”

คำอธิบายนี้ไม่ได้ยืนยันสาเหตุ แต่ระบุความแตกต่างที่ช่วยนำทางการสืบค้น

พิจารณาคำอธิบายหลายแบบไว้

ขอให้ agent เสนอสาเหตุที่เป็นไปได้ชุดเล็ก ๆ พร้อมหลักฐานของแต่ละข้อ อย่าขอให้ยึดคำอธิบายแรกที่ฟังน่าเชื่อถือ

สำหรับปัญหา export สมมติ สาเหตุที่เป็นไปได้คือสิทธิ์ของตัวตนบริการที่ขาดไป role mapping ที่เปลี่ยน หรือคำขอที่ส่งไปผิดสภาพแวดล้อม แต่ละคำอธิบายคาดว่าจะพบหลักฐานต่างกัน

สมมติฐาน	สิ่งที่สังเกตได้ซึ่งช่วยแยกสมมติฐาน
ตัวตนบริการอ่านข้อมูล export ไม่ได้	ตัวตนบริการถูกปฏิเสธการเข้าถึงทรัพยากรเป้าหมาย
Role mapping เปลี่ยน	คำขอถึงแอปพร้อม role ที่มีผลจริงต่างจากเดิม
คำขอใช้สภาพแวดล้อมผิด	Endpoint ที่ resolve ได้หรือตัวระบุทรัพยากรต่างจากเป้าหมายที่ตั้งใจ

ตารางนี้เป็นจุดเริ่มต้น คำตอบ 403 อาจมาจากหลายชั้น ระบุว่าคอมโพเนนต์ใดสร้างคำตอบก่อนสันนิษฐานว่าการตรวจสอบสิทธิ์ของแอปล้มเหลว

เลือกการสังเกตที่ปลอดภัย

เริ่มจากสิ่งที่สังเกตได้ด้วยต้นทุนต่ำและแยกคำอธิบายออกจากกันได้ เปรียบเทียบเวอร์ชันที่ deploy และ configuration ที่ไม่ใช่ความลับ ตรวจดูข้อผิดพลาดและตัวระบุคำขอที่เกี่ยวข้อง ทำให้ปัญหาเกิดซ้ำในสภาพแวดล้อมทดสอบที่ได้รับอนุญาตเมื่อทำได้

อย่าให้สิทธิ์กว้างเพียงเพื่อดูว่าข้อผิดพลาดหายหรือไม่ การทำเช่นนั้นเปลี่ยนขอบเขตความปลอดภัยและอาจซ่อนสิทธิ์ที่ขาดจริง อย่าส่ง log production ทั้งหมดให้โมเดล หากเพียงข้อความผิดพลาดที่ลบข้อมูลอ่อนไหวแล้วกับเส้นทางคำขอก็เพียงพอ

ระบุว่าอะไรจะลดน้ำหนักของแต่ละสมมติฐาน วิธีนี้ช่วยให้ agent ปรับคำอธิบาย แทนที่จะปกป้องคำตอบแรก

แก้ทีละสาเหตุ

หลังหลักฐานชี้สาเหตุที่น่าจะเป็น ให้แก้เฉพาะจุด หลีกเลี่ยงการรวมการเปลี่ยนสิทธิ์ การอัปเกรด library และการเขียน handler ใหม่ไว้ด้วยกัน หากอาการหาย คุณจะไม่รู้ว่าการเปลี่ยนแปลงใดมีผล

ตรวจสอบเงื่อนไขที่ทำให้ผิดพลาดเดิม ตรวจสอบขอบเขตใกล้เคียงด้วย หากแก้สิทธิ์เข้าถึงของผู้จัดการ ให้ยืนยันว่าผู้ใช้ที่ไม่มีสิทธิ์ยังถูกปฏิเสธ

สำหรับข้อบกพร่องที่เกิดซ้ำ ให้เพิ่ม regression check ในชั้นที่ตรวจจับได้ Unit test ตรวจพบข้อผิดพลาด deployment configuration ทุกแบบไม่ได้ บางกรณีต้องใช้ integration check หรือการตรวจสอบหลัง deploy ที่ควบคุมไว้

หยุดการลองซ้ำที่ไม่มีหลักฐานใหม่

Agent สร้างวิธีแก้ได้หลายแบบ แต่การลองมากขึ้นไม่ได้ทำให้วินิจฉัยดีขึ้นเสมอไป หากความผิดพลาดเดิมเกิดซ้ำ ให้ถามว่าการลองครั้งถัดไปจะให้ข้อมูลสังเกตใหม่อะไร

กำหนดขีดจำกัดเวลาหรือจำนวนครั้งสำหรับการสืบค้นที่ไม่แน่นอน เมื่อถึงขีดจำกัด ให้รายงานหลักฐานปัจจุบัน สมมติฐานที่ตัดออก และคำถามที่ยังไม่ตอบ บันทึกนี้ช่วยให้คนอื่นทำต่อโดยไม่ต้องทดลองแบบเดิมซ้ำ

หลังกู้คืน ให้บันทึกสาเหตุและเงื่อนไขที่ปล่อยให้ปัญหาไปถึงสภาพแวดล้อมที่ได้รับผลกระทบ การแก้ไขขจัดข้อบกพร่องเฉพาะหน้า งานติดตามที่มีประโยชน์ลดโอกาสที่ความผิดพลาดเดิมจะกลับมา

ทำแบบฝึกหัด

เขียนบันทึก debug สำหรับข้อบกพร่องล่าสุด รวมพฤติกรรมที่คาดหวัง พฤติกรรมที่พบ ขอบเขตที่ได้รับผลกระทบ และสาเหตุที่เป็นไปได้สามข้อ สำหรับแต่ละสาเหตุ ให้ระบุสิ่งที่สังเกตได้หนึ่งอย่างซึ่งจะลดน้ำหนักของสาเหตุนั้น เลือกสิ่งที่ตรวจได้อย่างปลอดภัยด้วยต้นทุนต่ำที่สุดก่อน

ดาวน์โหลดใบงาน (Markdown)

ตรวจความเข้าใจ ↑