คำถามเดียวในดีไซน์รีวิวที่ช่วยป้องกันปัญหา APIM Naming Collision
บทเรียนจากการตั้งชื่อซ้ำใน Azure API Management ที่สะท้อนปัญหาการออกแบบทรัพยากรระบบซึ่งพบบ่อยในทุกสแต็กเทคโนโลยี
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ข้อผิดพลาดระบุเพียงว่ามีพร็อพเพอร์ตี้ชื่อซ้ำกันอยู่แล้ว
- Azure API Management บังคับให้ชื่อแสดงผล (name) ต้องไม่ซ้ำกันทั่วทั้งบริการ
- การเพิ่มคำถามเรื่องตัวระบุตัวตนในดีไซน์รีวิวช่วยแก้ปัญหาที่ต้นเหตุ
- การแก้ไขทำได้โดยเพิ่มการตรวจสอบความซ้ำซ้อนก่อนดำเนินการ PUT
ข้อความแสดงข้อผิดพลาดสั้น ๆ ว่า "Property with the same name already exist" ปรากฏขึ้นพร้อมกับไปป์ไลน์ที่หยุดชะงักในเวลา 14.00 น. โดยไม่มีสแต็กเทรซหรือหมายเลขบรรทัดให้อ่าน ปฏิกิริยาแรกคือการพุ่งเป้าไปที่สคริปต์การเผยแพร่ แต่แท้จริงแล้วปัญหาเกิดจากตัว Azure API Management (APIM) เอง ที่ตัวแปรแบบ Named Values มีตัวระบุแยกกันสองส่วน ได้แก่ id ที่ได้จากชื่อโฟลเดอร์ และ name ซึ่งเป็นคุณสมบัติการแสดงผลที่ระบบบังคับให้ต้องไม่ซ้ำกันทั่วทั้งบริการ
ในกรณีนี้ มีการสร้างค่าผ่านพอร์ทัลด้วยมือไว้ล่วงหน้าแล้วหลายเดือนภายใต้ id อื่น แต่ดันไปตรงกับเงื่อนไขชื่อ name ที่ระบบกำลังจะเขียนทับ ส่งผลให้ APIM ปฏิเสธการเขียนข้อมูล ซึ่งดูเหมือนระบบพังแต่จริง ๆ เกิดจากการกระทำของคนสองคนที่ต่างก็ทำหน้าที่ของตนเองแต่ขาดการเชื่อมโยงข้อมูลระหว่างกัน ปัญหารูปแบบนี้เกิดขึ้นในสามระบบที่แตกต่างกันในปีนี้ และล้วนมีจุดเริ่มต้นจากช่องโหว่ในกระบวนการดีไซน์รีวิว
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อเอกสารออกแบบแนะนำทรัพยากรใหม่ ผู้ตรวจสอบมักจะตั้งคำถามเดิม ๆ เช่น มันรองรับการขยายตัวหรือไม่ จุดล่มคืออะไร หรือใครเป็นผู้ดูแลในระบบโปรดักชัน ซึ่งคำถามเหล่านี้ไม่สามารถตรวจจับปัญหานี้ได้ คำถามที่ควรถูกหยิบยกมาถามคือ ทรัพยากรนี้มีตัวระบุมากกว่าหนึ่งตัวหรือไม่ และตัวใดกันแน่ที่ไม่ซ้ำกันในระดับขอบเขตใด วิศวกรส่วนใหญ่มักคิดว่าไอดีมีความไม่ซ้ำกันแล้วจบ แต่หลายแพลตฟอร์มแยกตัวระบุออกเป็นคีย์ที่ระบบสร้างขึ้นกับชื่อที่มนุษย์อ่านได้ และบังคับความไม่ซ้ำในจุดที่ไม่มีใครสังเกต
ช่องโหว่เรื่อง Compound Identity หรือตัวระบุที่มีหลายมิติ มักสร้างความปวดหัวให้กับทีมพัฒนาซอฟต์แวร์อยู่เสมอ เนื่องจากเครื่องมือหรือพอร์ทัลบริหารจัดการมักเปิดช่องให้ผู้ใช้งานสร้างข้อมูลผ่าน UI ได้โดยตรงนอกเหนือจากกระบวนการ CI/CD การทำความเข้าใจขอบเขตของตัวระบุ (Scope) จึงเป็นหัวใจสำคัญของการออกแบบคลาวด์เนทีฟทรัพยากรทุกประเภท เพื่อป้องกันความขัดแย้งที่คาดไม่ถึงในสภาพแวดล้อมจริง
การแก้ปัญหาที่ยั่งยืนไม่ใช่การปิดกั้นไม่ให้ใครสร้างข้อมูลผ่านพอร์ทัลด้วยมือ เพราะการทำเช่นนั้นเป็นเพียงการแก้ปัญหาปลายเหตุ แต่ควรเพิ่มข้อกำหนดลงในเทมเพลตเอกสารการออกแบบว่า สำหรับทรัพยากรที่มีตัวระบุซับซ้อน จะต้องระบุให้ชัดเจนว่าฟิลด์ใดไม่ซ้ำกัน และเกิดอะไรขึ้นหากเกิดการชนกัน ทีมงานได้แก้ไขด้วยการเพิ่มการตรวจสอบความซ้ำซ้อนในขั้นตอนการเผยแพร่โดยค้นหาตามชื่อก่อนทำคำสั่ง PUT ซึ่งช่วยเปลี่ยนเวลาในการแก้ปัญหา 45 นาทีให้กลายเป็นความผิดพลาดที่ตรวจพบได้ทันทีในไม่กี่วินาที
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น