เกิดอะไรขึ้นกับ Microsoft 365 จากเหตุขัดข้อง MO1456424

ปัญหาไม่ได้หมายความว่าฟีเจอร์ทั้งหมดของ Outlook, SharePoint หรือ OneDrive ใช้งานไม่ได้ แต่ผู้ใช้ที่ได้รับผลกระทบอาจค้นหาอีเมล เอกสาร หรือไฟล์ที่จัดเก็บไว้ไม่พบ ซึ่งเพียงฟังก์ชันเดียวก็ทำให้งานประจำสะดุดได้หลายบริการพร้อมกัน

สาเหตุของ MO1456424 คืออะไร

Microsoft ระบุว่า การติดตั้งระบบครั้งล่าสุดทำให้เกิด “ปัญหาการใช้ทรัพยากรอย่างไม่มีประสิทธิภาพ” ในโครงสร้างพื้นฐานที่รองรับคำขอค้นหา ส่งผลให้ระบบประมวลผลคำค้นหาบางรายการได้แย่ลง

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

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

Microsoft แก้ปัญหาอย่างไร

Microsoft ระบุว่าได้พัฒนาและเริ่มปล่อยแพตช์เพื่อ ลดแรงกดดันต่อทรัพยากรและทำให้ฟังก์ชันค้นหากลับมาใช้งานได้ โดยบริษัทอยู่ระหว่างติดตามผลหลังการปล่อยแพตช์เพื่อประเมินการฟื้นตัวของบริการ

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

ทำไมจึงเรียกว่าเป็น “เหตุการณ์” ทั้งที่จัดประเภทเป็น Service Degradation

ในข้อมูลสถานะบริการ Microsoft 365 เหตุ MO1456424 ถูกจัดเป็น serviceDegradation ซึ่งหมายถึงบริการมีประสิทธิภาพลดลงหรือมีฟังก์ชันบางส่วนขัดข้อง ไม่ใช่การที่บริการทั้งชุดหยุดทำงาน

อย่างไรก็ตาม เหตุการณ์นี้ยังถูกติดตามในฐานะ incident เพราะฟังก์ชันค้นหาเป็นฟังก์ชันที่ผู้ใช้ต้องพึ่งพา และได้รับผลกระทบพร้อมกันในหลายผลิตภัณฑ์ Microsoft 365 สำหรับผู้ใช้บางส่วน

Microsoft ไม่ได้เผยแพร่คำอธิบายแยกต่างหากว่าทำไมจึงเลือกการจัดประเภทนี้ การตีความที่ปลอดภัยที่สุดจึงคือ นี่เป็น เหตุค้นหาในหลายผลิตภัณฑ์เสื่อมประสิทธิภาพ ไม่ใช่หลักฐานว่าบริการ Microsoft 365 ทุกตัวไม่พร้อมใช้งาน

แตกต่างจากเหตุ GitHub และ Azure อย่างไร

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

GitHub ล่มเกือบ 8 ชั่วโมงในวันเดียวกัน

GitHub ซึ่งเป็นแพลตฟอร์มพัฒนาซอฟต์แวร์ในเครือ Microsoft ประสบเหตุแยกต่างหากในวันที่ 17 สิงหาคม 2026 ตั้งแต่ 13:28 ถึง 21:15 UTC รวม 7 ชั่วโมง 47 นาที โดยพบข้อผิดพลาดและความหน่วงเพิ่มขึ้นใน Issues, Pull Requests, API, Actions และ Copilot อัตราข้อผิดพลาดของเว็บไซต์และ API แตะประมาณ 20% ในช่วงสูงสุด ขณะที่การดาวน์โหลดไฟล์เก็บถาวรและเนื้อหาดิบแตะประมาณ 50%

รายงานของ GitHub เชื่อมโยงเหตุการณ์ดังกล่าวกับโหลดบาลานเซอร์ที่มีโหลดหนาแน่น นโยบาย autoscaling ที่ทำงานผิดพลาด และบั๊กการ retry ที่มีอยู่เดิมใน Visual Studio Code กลไกเหล่านี้แตกต่างจากปัญหาการใช้ทรัพยากรอย่างไม่มีประสิทธิภาพในระบบค้นหาของ Microsoft 365

ปัญหาค้นหา Microsoft 365 ก่อนหน้านี้

Microsoft 365 เคยมีเหตุขัดข้องด้านการค้นหามาก่อน ในเดือนเมษายน 2025 ผู้ใช้ Outlook บนเว็บและ SharePoint Online พบการค้นหาล่าช้าหรือไม่ทำงาน โดยเกี่ยวข้องกับองค์ประกอบโครงสร้างพื้นฐานที่ประมวลผลคำขอค้นหาและทำงานได้ต่ำกว่าเกณฑ์ประสิทธิภาพที่กำหนด

นอกจากนี้ ยังมีรายงานปัญหาการค้นหาไฟล์ใน OneDrive ที่ผลการค้นหาแสดงเป็นหน้าว่างหรือไม่แสดงผลลัพธ์ แม้ผู้ใช้จะทราบว่าเคยอัปโหลดไฟล์ดังกล่าวแล้ว แต่ข้อมูลที่มีอยู่ไม่ได้ยืนยันว่าปัญหาในอดีตเหล่านี้มีสาเหตุเดียวกับ MO1456424

เหตุ Azure และ Microsoft 365 วันที่ 23 กรกฎาคม

เหตุการณ์วันที่ 23 กรกฎาคม 2026 มีขอบเขตกว้างกว่าและเกิดจากปัญหาคนละประเภท โดยประวัติสถานะ Azure ระบุว่าผู้ใช้บางส่วนประสบปัญหาการเชื่อมต่อ ความหน่วงสูง หรือเข้าถึงบริการที่โฮสต์ในภูมิภาค West US ได้ยาก ระหว่าง 14:44 ถึง 19:41 UTC ผลกระทบจำกัดอยู่ที่ทราฟฟิกที่วิ่งเข้าออกภูมิภาคดังกล่าว ส่วนทราฟฟิกที่อยู่ภายในภูมิภาคทั้งหมดไม่ได้รับผลกระทบ

Microsoft ระบุว่าสาเหตุคือระบบอัตโนมัติสำหรับบำรุงรักษาเครือข่ายมีบั๊ก ทำให้ลบเส้นทาง IP จากอุปกรณ์มากกว่าที่ตั้งใจไว้ จนเกิดความล้มเหลวในชั้นควบคุมเครือข่าย นี่แตกต่างจาก MO1456424 ซึ่งเป็นการเสื่อมประสิทธิภาพของบริการค้นหาหลังการติดตั้งระบบ

สิ่งที่เหตุการณ์เหล่านี้บอกเราได้

เมื่อพิจารณาร่วมกัน เหตุการณ์เหล่านี้สะท้อนความเสี่ยงคนละชั้นของระบบ

• MO1456424: การติดตั้งระบบล่าสุดทำให้เกิดการใช้ทรัพยากรอย่างไม่มีประสิทธิภาพในโครงสร้างพื้นฐานค้นหา
• เหตุ GitHub วันที่ 17 สิงหาคม: โหลดบาลานเซอร์หนาแน่น ความล้มเหลวของ autoscaling และปัญหา retry ที่ขยายผลกระทบ
• เหตุ Azure วันที่ 23 กรกฎาคม: ระบบบำรุงรักษาเครือข่ายอัตโนมัติลบเส้นทาง IP มากเกินไป

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

ข้อมูลที่มีอยู่ยังไม่ยืนยันว่าความต้องการใช้งานจาก AI เป็นสาเหตุของ MO1456424 เหตุ GitHub หรือเหตุ Azure เดือนกรกฎาคม นอกจากนี้ GitHub เคยพูดถึงการย้ายออกจากศูนย์ข้อมูลแบบเดิมไปยัง public cloud และแนวทางสู่ multicloud แต่ทิศทางเชิงกลยุทธ์ดังกล่าวไม่ได้พิสูจน์ว่าเป็นสาเหตุของเหตุขัดข้องใดเหตุขัดข้องหนึ่ง

บทเรียนที่สรุปได้อย่างระมัดระวังคือ เมื่อบริการคลาวด์และเวิร์กโหลดที่เชื่อมโยงกับ AI มีความสำคัญต่อการทำงานมากขึ้น การวางแผนความจุ การควบคุมการปล่อยซอฟต์แวร์ การป้องกัน retry storm การแยกขอบเขตความเสียหาย และการทดสอบระบบอัตโนมัติด้านเครือข่ายจะยิ่งสำคัญขึ้นตามไปด้วย ส่วนการใช้ multicloud อาจช่วยกระจายความเสี่ยงของโครงสร้างพื้นฐานบางส่วนได้ แต่ไม่ได้ป้องกันความล้มเหลวที่เกิดขึ้นภายใน control plane ของบริการนั้นเอง