ไมโครซอฟต์ล่มสองครั้งในสิบห้าวัน และครั้งที่สองทำให้ต้องเลื่อนกำหนดวันประกาศผลประกอบการ

ระบบ Microsoft 365, Outlook, Teams, Copilot และ Store ใช้งานไม่ได้ตั้งแต่ประมาณ 01:00 น. ตามเวลาฮานอยของวันที่ 13 พฤศจิกายน โดยมีรายงานปัญหา Outlook ถึง 130,000 รายการในสหรัฐฯ เพียงประเทศเดียว Microsoft ออกมาโทษภาระโหลดก่อน จากนั้นกล่าวว่าเซิร์ฟเวอร์ทำงานผิดปกติ ทั้ง OpenAI และ Anthropic รายงานว่าตัวเชื่อมต่อล้มเหลว และผู้ผลิตรถบรรทุกไฟฟ้ารายหนึ่งเลื่อนผลประกอบการรายไตรมาสออกไปเพราะเหตุนี้

ตั้งแต่ประมาณ 01:00 น. ตามเวลาฮานอยของวันที่ 13 พฤศจิกายน ผู้ใช้ในเวียดนามและที่อื่น ๆ ไม่สามารถเข้าถึง Microsoft 365, Outlook, Teams, Copilot และ Microsoft Store ได้ Downdetector บันทึกรายงานมากกว่า 130,000 รายการสำหรับ Outlook ในสหรัฐอเมริกาเพียงประเทศเดียว 45,000 รายการสำหรับ Microsoft 365 และ 10,000 รายการสำหรับ Store โดยส่วนใหญ่เกี่ยวกับการเชื่อมต่อและการส่งหรือรับอีเมล

ส่วนที่น่าสนใจไม่ใช่การล่มครั้งนี้ แต่เป็นความเสียหายลำดับที่สอง

สิ่งที่ Microsoft กล่าว และสิ่งที่มันเปลี่ยนไป

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

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

กล่าวอีกนัยหนึ่ง ระบบปกป้องตัวเองโดยระบายโหลดไปยังส่วนที่เหลือ ซึ่งเป็นพฤติกรรมที่เปลี่ยนโหนดที่มีปัญหาเพียงหนึ่งโหนดให้กลายเป็นเหตุการณ์ระดับโลกพอดี

การลุกลามคือเนื้อเรื่อง

สองห้องแล็บ AI ของสหรัฐฯ กล่าวต่อสาธารณะว่าความล้มเหลวของ Microsoft ได้ส่งผลมาถึงพวกเขาแล้ว

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

สองเหตุขัดข้อง สิบห้าวัน

นี่ไม่ใช่เช้าวันเดียวที่โดดเดี่ยว

1. ทำแผนที่ตัวเชื่อมต่อ ไม่ใช่แค่บริการ ทีมที่ได้รับผลกระทบหนักที่สุดในกรณีนี้ไม่ได้รัน Exchange — พวกเขารันผลิตภัณฑ์ที่ยืนยันตัวตนผ่าน Microsoft หากสแต็กของคุณระบุ Microsoft ไว้ในหมวด "อีเมล" เท่านั้น แผนที่นั้นผิด
2. จดบันทึกว่าอะไรเสื่อมลง ไม่ใช่ว่าอะไรพัง "Outlook ล่ม" ยังรับมือได้ "ไม่สามารถสร้างการเชื่อมต่อใหม่ได้ และการยื่นรายงานประจำไตรมาสล่าช้า" รับมือไม่ได้ ประโยคที่สองคือประโยคที่ต้องซ้อม
3. ซ้อมข้ออ้างของผู้ขาย Workhorse ทำถูกแล้ว — เปิดเผย เลื่อนวันที่ และบอกเหตุผล

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

สิ่งนี้เปลี่ยนอะไรสำหรับใครก็ตามที่สร้างระบบบนแพลตฟอร์มนี้

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

สามสิ่งที่ควรทำก่อนเหตุการณ์ครั้งถัดไป:

บริษัทส่วนใหญ่ค้นพบในเหตุการณ์ว่าไม่มีใครรับผิดชอบการตัดสินใจนั้น

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

แหล่งข่าว: VnExpress, 13 พฤศจิกายน 2026 รายงานตัวเลขของ Downdetector คำแถลงของ Microsoft ต่อ Reuters และแถลงการณ์สาธารณะจาก OpenAI, Anthropic และ Workhorse Group รายละเอียดเหตุการณ์ Azure ขัดข้องเมื่อวันที่ 29 ตุลาคม เป็นไปตามที่ VnExpress รายงาน จำนวนรายงานวัดจากจำนวนผู้ใช้ที่ร้องเรียน ไม่ใช่ความรุนแรงหรือสาเหตุของเหตุการณ์

ติดต่อ: [email protected]

โปรดทราบว่าเวอร์ชันภาษาไทยได้รับการช่วยเหลือจาก AI ดังนั้นอาจมีข้อผิดพลาดเล็กน้อย

ผู้เขียน

Ai-Banking-NetworkSecurity (ABN), ABN ASIA ถูกก่อตั้งขึ้นโดยคนที่มีรากฐานลึกในวงการวิชาการ มีประสบการณ์การทำงานในสหรัฐอเมริกา ดัตช์ ฮังการี ญี่ปุ่น เกาหลีใต้ สิงคโปร์ และเวียดนาม ABN Asia เป็นที่เราพบกันของวิทยาลัยและเทคโนโลยี ด้วยโซลูชันขั้นสูงและบริการพัฒนาซอฟต์แวร์ที่มีความสามารถ เราช่วยธุรกิจเติบโตและเข้าสู่ฉากโลก ความมุ่งมั่นของเรา: ด่วนขึ้น ดีขึ้น น่าเชื่อถือมากขึ้น ในกรณีส่วนมาก: ราคาถูกด้วย

หากคุณต้องการบริการ IT การให้คำปรึกษาดิจิทัล โซลูชันซอฟต์แวร์ใช้ได้หรือหากคุณต้องการส่งคำขอข้อเสนอ (RFPs) อย่าลังเลที่จะติดต่อเรา คุณสามารถติดต่อเราได้ที่ [email protected] เราพร้อมช่วยเหลือคุณด้านทุกความต้องกรทางเทคโนโลยีของคุณทุกเมื่อ

© ABN ASIA