OpenAI เพิ่งเผยแพร่รายงานโดยละเอียดเกี่ยวกับการหยุดให้บริการ ChatGPT และ Sora เป็นเวลา 4 ชั่วโมง 10 นาที เมื่อวันที่ 11 ธันวาคม เหตุการณ์นี้ส่งผลกระทบต่อผู้ใช้จำนวนมากและดึงดูดความสนใจอย่างกว้างขวาง รายงานจะอธิบายรายละเอียดถึงสาเหตุของความล้มเหลว ปัญหาที่วิศวกรพบ และกระบวนการขั้นสุดท้ายในการกู้คืนบริการ ซึ่งเป็นบทเรียนอันมีค่าสำหรับทีมเทคนิคอื่นๆ รายงานดังกล่าวอธิบายสาเหตุที่แท้จริงของความล้มเหลวอย่างชัดเจน รวมถึงชุดมาตรการฉุกเฉินที่วิศวกรใช้เมื่อเผชิญกับอุบัติเหตุเครื่องบินควบคุมตก ซึ่งสะท้อนถึงความสามารถของ OpenAI ในการตอบสนองต่อเหตุฉุกเฉิน
สัปดาห์ที่แล้ว (11 ธันวาคม) บริการ ChatGPT และ Sora ของ OpenAI หยุดทำงานเป็นเวลา 4 ชั่วโมง 10 นาที ส่งผลกระทบต่อผู้ใช้จำนวนมาก ตอนนี้ OpenAI เผยแพร่รายงานโดยละเอียดเกี่ยวกับการหยุดทำงานของ ChatGPT อย่างเป็นทางการ
พูดง่ายๆ ก็คือ สาเหตุที่แท้จริงของความล้มเหลวนี้คือการเปลี่ยนแปลงเล็กๆ น้อยๆ แต่นำไปสู่ผลลัพธ์ที่ร้ายแรง วิศวกรถูกล็อกออกจากพื้นผิวการควบคุมในช่วงเวลาวิกฤติ และไม่สามารถจัดการกับปัญหาได้ทันเวลา เกี่ยวกับความล้มเหลวนี้ วิศวกร OpenAI ดำเนินการซ่อมแซมหลายอย่างอย่างรวดเร็วหลังจากค้นพบปัญหา รวมถึงการลดขนาดของคลัสเตอร์ การบล็อกการเข้าถึงเครือข่ายไปยัง API การจัดการ Kubernetes และการเพิ่มทรัพยากรของเซิร์ฟเวอร์ Kubernetes API หลังจากความพยายามหลายรอบ ในที่สุดวิศวกรก็กู้คืนการเข้าถึงส่วนหนึ่งของ Control Plane Kubernetes ได้ในที่สุด และดำเนินการเพื่อเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังคลัสเตอร์ที่ดี และในที่สุดก็สามารถกู้คืนระบบได้อย่างสมบูรณ์
เหตุการณ์ดังกล่าวเกิดขึ้นเมื่อเวลา 15:12 น. PST ขณะที่วิศวกรใช้บริการการวัดและส่งข้อมูลทางไกลแบบใหม่เพื่อรวบรวมตัววัดระนาบควบคุม Kubernetes (K8S) อย่างไรก็ตาม การกำหนดค่าบริการกว้างเกินไปโดยไม่ได้ตั้งใจ ทำให้ทุกโหนดในทุกคลัสเตอร์ดำเนินการ K8S API ที่ใช้ทรัพยากรจำนวนมากพร้อมกัน สถานการณ์นี้ทำให้เซิร์ฟเวอร์ API หยุดทำงานอย่างรวดเร็ว ส่งผลให้ระนาบข้อมูล K8S ของคลัสเตอร์ส่วนใหญ่สูญเสียความสามารถในการให้บริการ
เป็นที่น่าสังเกตว่าแม้ว่าในทางทฤษฎีแล้ว Data Plane K8S สามารถทำงานได้โดยอิสระจาก Control Plane แต่การทำงานของ DNS จะขึ้นอยู่กับ Control Plane ซึ่งทำให้บริการต่างๆ ไม่สามารถสื่อสารระหว่างกันได้ เมื่อการทำงานของ API โอเวอร์โหลด กลไกการค้นหาบริการจะเสียหาย ส่งผลให้บริการทั้งหมดเป็นอัมพาต แม้ว่าปัญหาจะได้รับการแก้ไขภายใน 3 นาที แต่วิศวกรก็ไม่สามารถเข้าถึงระนาบควบคุมเพื่อย้อนกลับบริการได้ ส่งผลให้เกิดสถานการณ์ "วนซ้ำไม่สิ้นสุด" อุบัติเหตุเครื่องบินควบคุมขัดข้องทำให้พวกเขาไม่สามารถลบบริการที่มีปัญหาออกได้ และทำให้ไม่สามารถกู้คืนได้
วิศวกรของ OpenAI เริ่มสำรวจวิธีต่างๆ ในการกู้คืนคลัสเตอร์ทันที พวกเขาพยายามลดขนาดคลัสเตอร์เพื่อลดโหลด API บน K8S และบล็อกการเข้าถึงการจัดการ K8S API เพื่อให้เซิร์ฟเวอร์สามารถกลับมาดำเนินการตามปกติได้ นอกจากนี้ พวกเขายังขยายการกำหนดค่าทรัพยากรของเซิร์ฟเวอร์ K8S API เพื่อจัดการคำขอได้ดียิ่งขึ้น หลังจากความพยายามหลายครั้ง ในที่สุดวิศวกรก็สามารถควบคุมระนาบควบคุม K8S ได้อีกครั้ง สามารถลบบริการที่ผิดพลาด และค่อยๆ กู้คืนคลัสเตอร์ได้
ในช่วงเวลานี้ วิศวกรยังได้ย้ายการรับส่งข้อมูลไปยังคลัสเตอร์ที่ได้รับการกู้คืนหรือเพิ่มใหม่ที่มีประสิทธิภาพเพื่อลดภาระในคลัสเตอร์อื่นๆ อย่างไรก็ตาม เนื่องจากบริการจำนวนมากพยายามกู้คืนในเวลาเดียวกัน ส่งผลให้ทรัพยากรมีขีดจำกัด กระบวนการกู้คืนจึงจำเป็นต้องมีการแทรกแซงด้วยตนเองเพิ่มเติม และการกู้คืนบางคลัสเตอร์ใช้เวลานาน ผ่านเหตุการณ์นี้ OpenAI คาดว่าจะเรียนรู้จากประสบการณ์และหลีกเลี่ยงการถูก "ล็อคเอาท์" อีกครั้งเมื่อเผชิญกับสถานการณ์ที่คล้ายกันในอนาคต
รายละเอียดการรายงาน: https://status.openai.com/incidents/ctrsv3lwd797
ไฮไลท์:
สาเหตุของความล้มเหลว: การเปลี่ยนแปลงบริการการวัดและส่งข้อมูลทางไกลเล็กน้อยทำให้การทำงานของ K8S API โอเวอร์โหลด ส่งผลให้เกิดอัมพาตของบริการ
ภาวะที่กลืนไม่เข้าคายไม่ออกของวิศวกร: ความผิดพลาดในระนาบควบคุมทำให้วิศวกรไม่สามารถเข้าถึงได้ ทำให้ไม่สามารถจัดการกับปัญหาได้
⏳ กระบวนการกู้คืน: ด้วยการลดขนาดของคลัสเตอร์และเพิ่มทรัพยากร บริการจึงได้รับการกู้คืนในที่สุด
แม้ว่าเหตุการณ์นี้จะทำให้บริการหยุดชะงัก แต่ก็ยังมอบประสบการณ์อันมีค่าให้กับ OpenAI กระตุ้นให้พวกเขาปรับปรุงสถาปัตยกรรมระบบและแผนฉุกเฉิน ปรับปรุงเสถียรภาพของบริการให้ดียิ่งขึ้น และมอบการรับประกันบริการที่เชื่อถือได้มากขึ้นแก่ผู้ใช้ ฉันเชื่อว่า OpenAI จะเรียนรู้จากเหตุการณ์นี้ ปรับปรุงเทคโนโลยีต่อไป และนำประสบการณ์ที่ดีขึ้นมาสู่ผู้ใช้