ปลายสัปดาห์ที่ผ่านมา Microsoft Azure ประสบปัญหาการล่มของระบบคลาวด์ ติดต่อกันสองวัน ซึ่งส่งผลกระทบต่อการให้บริการ Virtual Machines (VMs) และโครงสร้างพื้นฐานที่สำคัญทั่วโลก ทำให้หลายองค์กรต้องหยุดการทำงานชั่วคราวและตรวจสอบระบบกันอย่างเร่งด่วนโดยมี 2 เหตุการณ์ได้แก่
เหตุการณ์แรก: Azure VM ล่มจาก “การจัดการ VM”
วันที่ 2 กุมภาพันธ์ 2569 เวลา 19:46 UTC (ประมาณ 02:46 น. ตามเวลาไทยของวันที่ 3 ก.พ. 2569) ระบบเกิดข้อผิดพลาดที่เกี่ยวข้องกับฟังก์ชัน Service Management Operations ของ Azure Virtual Machines ซึ่งเป็นส่วนที่คอยจัดการการสร้าง, ปรับขนาด, หยุด/เริ่ม หรือการตั้งค่าต่างๆ ของ VM ผลลัพธ์คือ:
การจัดการ VMs ไม่สามารถทำงานได้ปกติ
ข้อผิดพลาดเกิดขึ้นกับ VM หลายภูมิภาคและบริการที่พึ่งพา VM
บริการอื่น ๆ อย่าง Azure Arc, AKS (Azure Kubernetes Service), Azure DevOps, Azure Container Apps, และ GitHub Actions ก็ได้รับผลกระทบจากเหตุการณ์นี้เช่นกัน
ปัญหานี้กินเวลาตั้งแต่ช่วงเย็นจนถึง ประมาณ 06:05 UTC ของวันที่ 3 ก.พ. ก่อนที่ทีมวิศวกรจะแก้ไขระบบและฟื้นฟูบริการให้กลับมาออนไลน์ได้ในหลายส่วน
เหตุการณ์ที่สอง: Managed Identity ล่มซ้ำซ้อน
ไม่กี่ชั่วโมงหลังเหตุการณ์ VM จบลง Azure ก็เจอปัญหาซ้ำอีกครั้งกับบริการ Managed Identity for Azure Resources ซึ่งเป็นระบบที่ช่วยให้แอปเข้าถึงโทเค็น (tokens) สำหรับใช้งานบริการต่าง ๆ บน Azure โดยไม่ต้องเก็บข้อมูลความลับเอง ครั้งนี้ปัญหาเกิดขึ้นใน ภูมิภาค East US และ West US ของสหรัฐฯ ตั้งแต่ 00:10 – 06:05 UTC ของวันที่ 3 ก.พ. 2569 ส่งผลให้:
ไม่สามารถสร้าง/อัปเดต/ลบทรัพยากร
รับโทเค็นสำหรับยืนยันตัวตนไม่ได้
บริการที่พึ่งพา Managed Identity หลายตัวเช่น Azure Synapse Analytics, Azure Databricks, Azure Stream Analytics, Azure Firewall และ Azure AI Video Indexer ประสบข้อผิดพลาดตามไปด้วย
ทีม Azure รายงานว่าเหตุล่มนี้มาจาก “ปริมาณคำร้องที่พุ่งสูงจนเกินขีดจำกัดบริการ” ทำให้ระบบ Retry คำร้องหลายครั้งจนเกิดคอขวด และเมื่อตรวจสอบก็ขยายขีดความสามารถของระบบจนฟื้นตัวกลับมาได้
ผลกระทบต่อผู้ใช้งานและองค์กร
เหตุการณ์ล่มสองครั้งนี้ทำให้หลายฝั่งได้รับผลกระทบอย่างเห็นได้ชัด:
บริการขึ้นระบบช้า หรือไม่สามารถ Provision VM ใหม่ได้
Deployment หรือ Scale-out งาน Compute ล้มเหลวกลางคัน
ระบบ CI/CD ที่พึ่งพา VM หรือบริการคลาวด์อื่นหยุดทำงาน
ทีมไอทีต้องตรวจสอบสถานะ VM และ Managed Identities อย่างเร่งด่วน
กระทบถึง Workload ที่ทำงานแบบ Auto-Scaling หรือ Distributed Environment โดยตรง
นอกจากนี้ ในบางกรณี VM Scale Sets (VMSS) ที่ได้รับผลกระทบจาก outage ยังไม่สามารถกลับสู่สถานะปกติได้ทันทีหลังเหตุการณ์คลี่คลาย ซึ่งแสดงให้เห็นว่า ผลกระทบอาจลากยาวเกินช่วงเวลาการล่ม
สาเหตุหลัก: “การตั้งค่าที่ผิดพลาด” ไม่ใช่แค่บริการล่ม
ทีม Azure ระบุว่าเหตุการณ์แรก เกิดจากการตั้งค่าการเข้าถึง Storage Accounts ที่ผิดพลาด ซึ่งเป็นส่วนที่ใช้งานเพื่อเก็บแพ็กเกจ Extensions สำหรับ VM และเมื่อการตั้งค่านั้นถูกปรับใช้ทั่วทั้งระบบ ก็ทำให้การจัดการ VM ล้มเหลวพร้อมกันเกือบทุกภูมิภาค และนี่เป็นคำเตือนสำคัญสำหรับองค์กรที่ใช้คลาวด์: อย่าประมาทการเปลี่ยนแปลงการตั้งค่าระบบบนระบบคลาวด์ขนาดใหญ่ — เพราะอาจส่งผลกระทบทวีคูณต่อบริการทั้งระบบได้โดยไม่ได้ตั้งใจ
ข้อคิดสำหรับผู้ใช้ Azure และผู้ดูแลระบบ
เพื่อให้บริการคลาวด์มีเสถียรภาพสูงสุดและลดผลกระทบจากเหตุการณ์แบบนี้ในอนาคต:
1. การกำหนดมาตรฐานการทดสอบก่อนปรับใช้
การตั้งค่าระบบควร:
ผ่านการตรวจสอบการเปลี่ยนแปลง
ทดสอบใน Dev/QA ก่อน
มีแผน Rollback เมื่อเกิดผลกระทบ
2. ใช้ระบบ Monitoring และ Alerts
เช่น Azure Monitor หรือระบบแจ้งเตือน Third-party ที่คอยบอกสถานะ VM และ Identity Services แบบเรียลไทม์
3. ติดตั้งระบบสำรองหรือ Multi-Region
วาง Architecture แบบ Multi-Region เพื่อกระจายความเสี่ยง หาก Region หลักล่มแล้วจึงย้ายงานไป Region สำรอง
4. ตรวจสอบ Dependencies
การพึ่งพา Managed Identity หรือ Extensions ต้องมีแผนรับมือ หากระบบเหล่านี้ขัดข้อง ก็อาจส่งผลให้บริการอื่นร่วมทั้งหมดล้มตามได้
สรุป
เหตุการณ์ Azure ล่ม 2 ครั้งซ้อน ในต้นปี 2026 ไม่ได้เป็นเพียงปัญหาทางเทคนิคทั่วไป แต่เป็นภาพสะท้อนว่าแม้แพลตฟอร์มคลาวด์ระดับโลกที่มีระบบซับซ้อนและทันสมัย ก็ยังสามารถล้มได้จาก “การตั้งค่าที่ผิดพลาดเพียงจุดเดียว” และเมื่อระบบเหล่านี้เป็นศูนย์กลางของธุรกิจจำนวนมาก ผลกระทบจึงขยายวงอย่างรวดเร็วในระดับโลก เหตุการณ์นี้ตอกย้ำว่าการพึ่งพาคลาวด์เพียงผู้ให้บริการเดียวโดยไม่มีแผนสำรอง คือความเสี่ยงที่องค์กรไม่ควรมองข้าม ไม่ว่าจะเป็นระบบสำรองข้าม Region, การออกแบบ Multi-Cloud, การตั้งระบบ Monitoring เชิงรุก หรือแผน Disaster Recovery ที่ทดสอบได้จริง สำหรับองค์กรที่ใช้ Azure หรือคลาวด์ใดก็ตาม เหตุการณ์นี้ไม่ใช่เรื่องของ “ใครผิด” แต่คือบทเรียนว่าความพร้อมรับมือกับความไม่แน่นอน คือหัวใจของความมั่นคงทางดิจิทัลในยุคคลาวด์
แหล่งที่มา : Azure ล่ม 2 ครั้งซ้อน! ตั้งค่าพลาดสะเทือนคลาวด์ทั่วโลก – ข่าวไอทีเทคโนโลยี
