การตรวจสอบหลังเกิดเหตุ: เกิดข้อผิดพลาด 500 อย่างไม่คาดคิดในระหว่างการลงชื่อเข้าใช้ของผู้ใช้

สรุป#

เมื่อวันที่ 18 กรกฎาคม 2024 Logto Cloud เกิดการหยุดให้บริการโดยแสดงข้อผิดพลาด 500 Internal server error จากบริการยืนยันตัวตน

• ผู้ใช้ที่ได้รับผลกระทบ: ผู้ใช้ Cloud ทั้งหมดที่พยายามยืนยันตัวตน
• ภูมิภาคที่ได้รับผลกระทบ: ยุโรปและสหรัฐอเมริกา
• ความรุนแรง: วิกฤติ, ส่งผลกระทบต่อประสบการณ์การลงชื่อเข้าใช้ของผู้ใช้

สาเหตุที่แท้จริง#

ระหว่างการปรับใช้ Cloud ล่าสุด การเปลี่ยนแปลงที่มีผลกระทบในโครงสร้างฐานข้อมูลทำให้ API ประสบการณ์การลงชื่อเข้าใช้ล้มเหลวระหว่างการเปลี่ยนผ่านระหว่างสภาพแวดล้อม staging และ production

เส้นเวลา#

• 2024-07-18 08:57 (UTC): มีการปรับปรุงให้กับ Logto Cloud
• 2024-07-18 09:28 (UTC): ผู้ใช้รายแรกที่รายงานข้อผิดพลาด 500
• 2024-07-18 09:31 (UTC): ทีมพัฒนารับทราบปัญหาและเริ่มการตรวจสอบ
• 2024-07-18 09:32 (UTC): ปัญหาได้รับการแก้ไขโดยอัตโนมัติ
• 2024-07-18 09:40 (UTC): ระบุสาเหตุได้

การวิเคราะห์เหตุการณ์#

การเปลี่ยนแปลงที่มีผลกระทบในฐานข้อมูลคืออะไร และทำไม?#

ขณะนี้เรากำลังพัฒนาฟีเจอร์ใหม่ชื่อว่า "Bring your UI" ซึ่งจะอนุญาตให้ผู้ใช้ปรับแต่งประสบการณ์การลงชื่อเข้าใช้ของ Logto ด้วยเว็บเพจของตนเอง ฟีเจอร์นี้ต้องการคอลัมน์ใหม่ในตาราง sign-in-exp เพื่อเก็บการกำหนดค่า UI แบบกำหนดเอง

เนื่องจากมีการเปลี่ยนแปลงข้อกำหนดระหว่างการพัฒนา การปล่อยฟีเจอร์นี้จึงล่าช้า แต่ส่วนแรกของการเปลี่ยนแปลงโครงสร้างได้ถูกปรับใช้ไปยัง production เมื่อหลายสัปดาห์ก่อนแล้ว แม้ว่าจะยังไม่มีการใช้งานก็ตาม การอัปเดตคอลัมน์ในฐานข้อมูลถูกแนะนำใน PR นี้

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

เราปรับใช้เวอร์ชันใหม่ของ Logto Cloud อย่างไร?#

เมื่อปรับใช้เวอร์ชันใหม่ของ Logto Cloud เราจะปรับใช้ไปยังสภาพแวดล้อม staging ก่อนแล้วจึงสลับสภาพแวดล้อม staging และ production ขั้นตอนเป็นดังนี้:

1. รันสคริปต์การเปลี่ยนแปลงฐานข้อมูลและอัปเดตฐานข้อมูล
2. ปรับใช้ซอร์สโค้ดใหม่ไปยังเซิร์ฟเวอร์ staging
3. รันเซิร์ฟเวอร์ staging และทำการทดสอบ
4. สลับเซิร์ฟเวอร์ staging และ production เพื่อให้ "staging" กลายเป็น "production" อนุญาตให้ผู้ใช้เข้าถึงเวอร์ชันใหม่โดยไม่หยุดทำงาน

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

นี่เป็นสาเหตุหลักของเหตุการณ์และเหตุผลที่มันได้รับการแก้ไขโดยอัตโนมัติใน 35 นาที

ทำไมสิ่งนี้ไม่ถูกแก้ไขในกระบวนการตรวจสอบโค้ด?#

เรามีงาน CI เพื่อตรวจสอบความเข้ากันได้ย้อนหลังของการเปลี่ยนแปลงฐานข้อมูล แต่อดีตไม่จำเป็นต้องผ่านการตรวจสอบ CI ก่อนที่จะรวม PR นี้ เนื่องจากเวลาส่วนใหญ่ในระยะการพัฒนามักจะสั้นในไม่กี่ช่วงและส่วนแรกและส่วนที่สองของการเปลี่ยนแปลงโครงสร้างมักจะรวมอยู่ในระยะการปล่อยเดียวกัน

ครั้งนี้ การปล่อยฟีเจอร์ล่าช้า การเปลี่ยนแปลงโครงสร้างกระจายไปอยู่ในสองการปล่อย ดีเวลลอปเปอร์ถือว่าความล้มเหลวใน CI เป็นสิ่งที่ควรคาดหวังและแจ้งผู้ตรวจสอบว่าไม่ควรบล็อค PR นี้

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

บทเรียนที่ได้รับ#

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

มาตรการแก้ไขและป้องกัน#

• ✅ การตรวจสอบความเข้ากันได้ย้อนหลังกับฐานข้อมูลใน CI ตอนนี้จำเป็นต้องผ่านก่อนที่จะรวม PR ที่มีการเปลี่ยนแปลงโครงสร้าง
• ✅ เน้นความสำคัญของความเข้ากันได้ย้อนหลังภายในทีม