Outlook ล่ม: บทเรียนจากระบบที่คนใช้ทั้งโลก
ว่าด้วยเหตุการณ์ Microsoft 365 ล่มเมื่อ 12–13 พฤศจิกายน 2026 และสิ่งที่ทีม Performance Test ควรเก็บไปคิดต่อ
บทเรียนที่ทีมทดสอบระบบควรรู้ โดยเฉพาะเรื่อง Availability Test ที่หลายทีมยังไม่ได้ใส่ไว้ในแผนทดสอบ
Outlook, Teams และบริการอื่นใน Microsoft 365 ใช้งานไม่ได้หรือใช้งานได้ไม่เต็มที่ในหลายภูมิภาคทั่วโลก นานกว่า 12 ชั่วโมง ระหว่างที่ทีมวิศวกรของ Microsoft พยายามกู้ระบบ ข้อมูลที่ค่อย ๆ ทยอยออกมาก็ให้บทเรียนที่ทีมทดสอบระบบควรรู้ โดยเฉพาะเรื่อง Availability Test ที่หลายทีมยังไม่ได้ใส่ไว้ในแผนทดสอบ
สรุปสั้น ๆ: เกิดอะไรขึ้น
ปัญหาเริ่มราวบ่ายโมงวันพฤหัสบดีที่ 12 พฤศจิกายน ตามเวลาฝั่งตะวันออกของสหรัฐฯ หรือราวตีหนึ่งของวันศุกร์ตามเวลาไทย Microsoft แจ้งครั้งแรกว่าผู้ใช้ในทวีปอเมริกาเข้า Mailbox ของ Exchange Online ไม่ได้ ก่อนจะขยายขอบเขตว่าอาจกระทบผู้ใช้ทุกภูมิภาค
- ขนาดของผลกระทบ — ช่วงพีค Downdetector มีรายงานปัญหา Outlook ราว 130,000 รายการ จากผู้ใช้ใน 74 ประเทศ
- บริการที่โดน — Outlook และ Exchange Online, SharePoint Online, Microsoft 365 Copilot, Planner, To Do, Intune และ Defender XDR ส่วน Teams มีปัญหาเรื่องปฏิทินและการนัดประชุม แต่การแชตยังพอใช้ได้
- ไม่ใช่การโจมตี — Charles Lamanna ผู้บริหารระดับ Executive Vice President ของ Microsoft ยืนยันว่าไม่ได้เกิดจาก Cyberattack
- สถานะล่าสุด — ณ เช้าวันศุกร์ที่ 13 พฤศจิกายน ตามเวลาไทย ระบบยังกู้คืนได้เพียงบางส่วนในหลายภูมิภาค และ Microsoft ยังไม่ยืนยันต้นเหตุสุดท้าย
ระหว่างที่ระบบล่ม แม้แต่หน้า Status ของ Microsoft 365 เองก็โหลดไม่ขึ้นอยู่ช่วงหนึ่ง และ Microsoft ยังเตือนว่าผู้ดูแลระบบอาจเข้า Admin Center เพื่อดูสถานะไม่ได้ เครื่องมือที่ใช้บอกว่า “ระบบล่ม” ก็ล่มไปด้วยเหมือนกัน
01เมื่อ Server ที่เหลือต้องแบกงานแทนเพื่อน
สิ่งที่น่าสนใจคือ Microsoft บอกว่าปัญหานี้ ไม่ได้เกิดจากทราฟฟิกที่พุ่งขึ้น แต่เกิดจาก Server จำนวนหนึ่งหายไปจากระบบแบบไม่คาดคิด งานทั้งหมดจึงไปกองอยู่ที่ Server ที่เหลือ คำอธิบายของ Microsoft ค่อย ๆ ชัดขึ้นตลอดคืน
- ช่วงแรก — Server ที่มีปัญหาไม่ผ่าน Health Check อัตโนมัติ จึงถูกถอดออกจาก Pool ตอนนั้น Microsoft สงสัยว่าตัวที่ผิดอาจเป็นส่วนที่ประมวลผล Health Check เอง และทดลองใช้วิธีตรวจแบบอื่นกับ Server บางกลุ่ม ซึ่งทำให้ Server กลุ่มนั้นกลับมาให้บริการได้
- กลางดึก — Microsoft ระบุชัดขึ้นว่า Process บน Server ที่ทำหน้าที่สร้าง Secure Connection ทำงานจนล้น แล้ว Server ก็หยุดรับ Request ไปเลย แปลว่า Health Check ไม่ได้ตรวจผิด Server พวกนั้นหยุดทำงานจริง ๆ
- ระหว่างแก้ — Microsoft หยุด Deploy ทั้งหมด ย้ายทราฟฟิกออกจากส่วนที่มีปัญหา และรีสตาร์ท Server ทีละชุด แต่หลายเครื่องกลับมาได้ไม่นานก็ล่มซ้ำ จึงเปลี่ยนมาจำกัดทราฟฟิกบางประเภท แล้วค่อย ๆ เปิดรับเพิ่มทีละน้อย
- ข้อสงสัยที่ยังไม่ยืนยัน — มีรายงานว่า Microsoft กำลังย้อนการเปลี่ยน Network Configuration ที่เกิดขึ้นช่วงเดียวกับที่ปัญหาเริ่ม เพื่อดูว่าเกี่ยวข้องหรือไม่
เมื่อเอาข้อมูลเหล่านี้มาเรียงกัน จะเห็นภาพเป็นวงจรแบบนี้
02Availability Test: การทดสอบที่ตอบคำถามของวันนี้
Load Test ตอบคำถามว่า “ระบบรับคนได้เท่าไร” ส่วน Availability Test ตอบอีกคำถามหนึ่ง คือ “เมื่อบางส่วนของระบบหยุดทำงาน ระบบโดยรวมยังให้บริการต่อได้ไหม และใช้เวลานานแค่ไหนกว่าจะกลับมาปกติ”
วิธีทดสอบคือจงใจทำให้ชิ้นส่วนหนึ่งเสียขณะที่ยังมีโหลดวิ่งอยู่ เช่น ปิด Server ไปบางเครื่อง ทำให้ Service ปลายทางช้าลง หรือตัด Network บางเส้น แล้ววัดสามเรื่อง
- ผลกระทบ — ผู้ใช้เห็น Error หรือความช้าเพิ่มขึ้นแค่ไหน
- การลุกลาม — ความเสียหายหยุดอยู่ที่จุดเดิม หรือลามไปส่วนอื่น
- การฟื้นตัว — ระบบกลับมาปกติเองได้ไหม และใช้เวลานานเท่าไร
เหตุการณ์ครั้งนี้คือตัวอย่างของทั้งสามเรื่องในวันเดียว Server ส่วนหนึ่งหายไป ความเสียหายลามไปหลายบริการ และการฟื้นตัวใช้เวลานานกว่าครึ่งวัน
Microsoft รับประกัน Uptime ของบริการหลักใน Microsoft 365 ไว้ที่ 99.9% ต่อเดือน ฟังดูสูงมาก แต่ 0.1% ที่เหลือคิดเป็นเวลาราว 43 นาทีต่อเดือนเท่านั้น ระบบที่ล่มนานหลายชั่วโมงในครั้งเดียวจึงกินโควตาของทั้งเดือนไปหลายเท่า ตัวเลข “เก้า” ที่เพิ่มขึ้นทุกตัวจึงหมายถึงงานทดสอบ Availability ที่หนักขึ้นตามไปด้วย
034 Scenario ของ Availability Test ที่ได้จากเหตุการณ์นี้
เราไม่รู้ว่าระบบภายในของ Microsoft หน้าตาเป็นอย่างไร และต้นเหตุจริงยังไม่ได้ข้อสรุป แต่รูปแบบของปัญหานี้เกิดได้กับระบบแทบทุกระบบที่มี Server หลายเครื่องอยู่หลัง Load Balancer ซึ่งก็คือระบบส่วนใหญ่ที่เราทดสอบกันทุกวัน ทั้ง 4 ข้อด้านล่างจึงเป็น Scenario ของ Availability Test ที่นำไปใส่ในแผนทดสอบได้ทันที
1. ทดสอบตอนที่ Server ไม่ครบ ไม่ใช่แค่ตอนที่ครบ
Load Test ส่วนใหญ่รันบน Environment ที่ทุกเครื่องพร้อมใช้งาน แต่วันจริงมักไม่เป็นแบบนั้น คำถามที่ควรตอบให้ได้คือ ถ้า Server หายไป 1 เครื่อง หรือหายไป 30% ระหว่างที่โหลดยังวิ่งอยู่ เครื่องที่เหลือรับงานไหวไหม
2. Health Check ช่วยได้ แต่ก็เร่งให้พังได้
Health Check มีไว้ถอดเครื่องที่เสียออก ซึ่งถูกต้อง แต่ถ้าเครื่องเสียเพราะ “งานล้น” ทุกครั้งที่ถอดหนึ่งเครื่อง งานก็จะไปล้นเครื่องถัดไปเร็วขึ้น
Load Balancer บางตัวมีกลไกกันเรื่องนี้ไว้ตั้งแต่แรก เช่น Envoy มี “Panic Threshold” ที่ตั้งต้นไว้ 50% ถ้าเครื่องที่ผ่าน Health Check เหลือไม่ถึงครึ่ง มันจะเลิกเชื่อ Health Check แล้วกระจายงานให้ทุกเครื่องแทน เพราะการให้เครื่องที่เหลือไม่กี่เครื่องแบกทั้งหมดมักแย่กว่า
3. การเปิด Connection ใหม่มีราคาแพงกว่าที่คิด
การสร้าง Secure Connection (TLS Handshake) ใช้ CPU มากกว่าการส่ง Request ผ่าน Connection เดิมหลายเท่า ทว่า Script ส่วนใหญ่ใช้ Connection เดิมซ้ำ (Keep-Alive) ตลอดการทดสอบ ตัวเลขที่ได้จึงแทบไม่สะท้อนต้นทุนส่วนนี้ ทั้งที่ในวันที่ Server ล่มหรือรีสตาร์ท Client จำนวนมากจะต้องเชื่อมต่อใหม่พร้อมกัน
noConnectionReuse ใน k6 หรือปิด Use KeepAlive ใน JMeter แล้วเทียบ CPU ของ Server กับการรันแบบปกติ
4. ทดสอบการ “ฟื้น” ด้วย ไม่ใช่แค่การ “ล่ม”
ส่วนที่ยืดเวลาเหตุการณ์ครั้งนี้คือ Server ที่รีสตาร์ทแล้วกลับมาล่มซ้ำ สุดท้าย Microsoft ต้องจำกัดทราฟฟิก แล้วค่อย ๆ ปล่อยเพิ่ม เครื่องที่เพิ่งกลับมามักยังไม่พร้อมรับงานเต็มที่ ทั้ง Cache ยังว่างและ Connection ยังไม่ถูกสร้าง ถ้าโยนโหลดเต็มใส่ทันทีก็เสี่ยงล่มอีกรอบ
04ทิ้งท้าย
ถ้าบริษัทที่มีวิศวกรและงบประมาณมากที่สุดในโลกยังเจอเรื่องแบบนี้ได้ ระบบของเราก็เจอได้เหมือนกัน ความต่างอยู่ที่ว่าเราจะเจอมันครั้งแรกในห้อง Test หรือเจอตอนที่ลูกค้าทั้งประเทศกำลังใช้งาน
บทเรียนจากเหตุการณ์ครั้งนี้ไม่ได้อยู่ที่ว่า Server ล่ม เพราะ Server ล่มเป็นเรื่องปกติของทุกระบบ แต่อยู่ที่ว่า เมื่อมีเครื่องหนึ่งล่ม เครื่องที่เหลือจะล่มตามหรือเปล่า
“ระบบที่แข็งแรงไม่ใช่ระบบที่ไม่เคยมี Server ล่ม แต่คือระบบที่ Server ล่มไปหนึ่งเครื่อง แล้วไม่มีใครรู้ตัว“
ลองหยิบ Load Test รอบล่าสุดของทีมขึ้นมาดู แล้วถามกันว่าเคยปิด Server สักเครื่องระหว่างที่โหลดยังวิ่งอยู่หรือยัง ถ้ายัง นั่นคือ Availability Test Scenario แรกที่ควรเพิ่ม
