- เหตุขัดข้องครั้งนี้ของ AWS ภูมิภาค US-EAST-1 ถูกวิเคราะห์ว่าไม่ใช่แค่ความขัดข้องทางเทคนิคธรรมดา แต่เป็นสัญญาณของความอ่อนแอเชิงองค์กรจากการ สูญเสียบุคลากรหลัก
- สาเหตุของเหตุขัดข้องยังคงเป็นปัญหาแบบคลาสสิกอย่าง DNS และจาก ข้อผิดพลาดของปลายทาง API ของ DynamoDB ทำให้บริการอื่นหยุดชะงักต่อเนื่องเป็นลูกโซ่
- เมื่อ วิศวกรอาวุโสที่จดจำรูปแบบความล้มเหลวของระบบในอดีตลาออกไป ก็มีสัญญาณชัดเจนว่าความเร็วในการระบุปัญหาและกู้คืนลดลงอย่างมาก
- ภายใน Amazon ทั้ง การปลดพนักงานครั้งใหญ่และ “อัตราการลาออกที่น่าเสียดาย” สูงถึง 69~81% ส่งผลร่วมกันจนความเสถียรในการปฏิบัติการของ AWS เริ่มสั่นคลอน
- นี่ไม่ใช่วิกฤตจาก เทคโนโลยีที่ล้าสมัย แต่เกิดจากการขาดคน และถูกมองว่าไม่ใช่ “อุบัติเหตุครั้งเดียว” ของ AWS แต่เป็น สัญญาณเตือนล่วงหน้าของการพังทลายของความเชื่อมั่นอย่างต่อเนื่อง
ความขัดข้องของ DNS และการหยุดให้บริการ
- ดังเช่นมุกที่ใช้กันมานานในหมู่ผู้ดูแลระบบว่า "It's always DNS" ศูนย์กลางของเหตุขัดข้องบริการจำนวนมากก็มักจะเป็น ปัญหา DNS เสมอ
- วันที่ 20 ตุลาคม 2025 เวลา 12:11AM(PDT) มีรายงานว่า อัตราความผิดพลาดของบริการ AWS ในภูมิภาค US-EAST-1 พุ่งสูงขึ้น
- เวลา 1:26AM คำขอไปยัง ปลายทาง DynamoDB เริ่มล้มเหลวอย่างจริงจัง
- เวลา 2:01AM ยืนยันได้ว่าสาเหตุคือ ข้อผิดพลาด DNS Resolution ของปลายทาง API ของ DynamoDB ทำให้บริการที่พึ่งพากันจำนวนมากเกิด เหตุขัดข้องเป็นลูกโซ่
- DynamoDB คือ บริการโครงสร้างพื้นฐานพื้นฐานของ AWS และเมื่อบริการในภูมิภาคนั้นล่ม ก็ส่งผลกระทบต่ออินเทอร์เน็ตในวงกว้าง
- เกิดอัมพาตเป็นวงกว้างกับธนาคาร เกม SNS บริการภาครัฐ และการช้อปปิ้งบน Amazon.com
- หลังรับรู้ปัญหาแล้ว ใช้เวลา 75 นาทีจึงระบุสาเหตุได้ ซึ่งถือว่าช้าผิดปกติเมื่อเทียบกับธรรมเนียม “กู้คืนได้อย่างเป็นแบบอย่าง” ของ AWS
- มีการวิเคราะห์ว่าสาเหตุที่ใช้เวลามากตั้งแต่รับรู้เหตุขัดข้องจนถึงระบุสาเหตุ ไม่ใช่เพราะ ขาดความโปร่งใสเท่านั้น แต่เป็นเพราะขาดประสบการณ์
- ในช่วงเวลาดังกล่าว หน้าแสดงสถานะยังคงแสดงข้อความว่า “ดำเนินงานตามปกติ” จนถูก ชุมชนวิจารณ์
คำเตือนที่กลายเป็นจริง: เสียงเตือนจากผู้ที่ลาออก
- เดิมที AWS มีชื่อเสียงด้าน ความสามารถในการปฏิบัติการโครงสร้างพื้นฐานระดับสูง ถึงขนาดที่แม้เพียงภูมิภาคเดียวเกิดปัญหาก็กลายเป็นประเด็นใหญ่ แต่ยิ่ง ความซับซ้อนสูงและปัญหาคล้ายอดีตเกิดซ้ำ ประสบการณ์ภาคสนามก็ยิ่งสำคัญ
- Justin Garrison อดีตวิศวกรของ AWS เตือนตอนลาออกในปี 2023 ว่า “เหตุการณ์ขนาดใหญ่ (LSE) กำลังเพิ่มขึ้น”
- เขาคาดว่า “จะเกิดเหตุขัดข้องร้ายแรงในปี 2024” และเหตุการณ์ครั้งนี้ก็เหมือนเป็นการยืนยันคำเตือนนั้น
- การ ลาออกต่อเนื่องของบุคลากรเทคนิคระดับสูง ภายใน AWS ดำเนินต่อเนื่องมาโดยตลอด และทำให้
Tribal Knowledge ที่สั่งสมมาหลายทศวรรษ (ความรู้ภายในที่อิงจากประสบการณ์) สูญหายไปพร้อมกัน
- สำหรับเหตุขัดข้องอย่าง DNS นั้น ไม่ใช่แค่ต้องมีคนที่รู้ สาเหตุทางเทคนิค เท่านั้น แต่ยังต้องมีคนที่จำได้ว่า
“ระบบนี้เคยก่อปัญหาคล้ายกันในอดีตหรือไม่”
- แต่คนที่มีความทรงจำเหล่านั้นได้ ลาออกจากบริษัทเพราะต่อต้านนโยบาย RTO(นโยบายกลับเข้าออฟฟิศ) และการปลดพนักงาน
หลักฐานของการไหลออกของบุคลากร
- ระหว่างปี 2022~2025 มี พนักงาน Amazon มากกว่า 27,000 คนถูกปลด และแม้สัดส่วนรายแผนกจะไม่เปิดเผย แต่คาดว่า AWS ก็ได้รับผลกระทบโดยตรงเช่นกัน
- ตามเอกสารภายใน “อัตราการลาออกที่น่าเสียดาย” อยู่ที่ 69~81%
- ซึ่งหมายความว่าเป็นการสูญเสีย บุคลากรที่บริษัทอยากรั้งตัวไว้
- เมื่อความไม่พอใจจาก คำสั่ง Return to Office ปะทุขึ้น ก็มีรายงานจำนวนมากว่า
วิศวกรอาวุโสมากประสบการณ์ลาออกกันเป็นจำนวนมาก
- ผลลัพธ์คือ AWS ถูกปรับโครงสร้างใหม่ให้เป็น ทีมต้นทุนต่ำที่ประสบการณ์น้อยกว่า
จนความสามารถในการดูแลโครงสร้างพื้นฐานที่ซับซ้อนค่อย ๆ อ่อนแอลง
ปัญหาเชิงโครงสร้าง: การบิดความหมายของ ‘Frugality’
- เดิมที Frugality(ความประหยัด) ซึ่งเป็นคุณค่าหลักของ Amazon
คือปรัชญาแบบ “ใช้ทรัพยากรให้น้อยแต่เพิ่มประสิทธิภาพสูงสุด”
- แต่ช่วงหลังกลับบิดไปเป็นความหมายว่า “จัดการทุกอย่างให้ได้แทบจะโดยไม่มีทรัพยากรเลย”
- การลดกำลังคนทำให้ถึงระดับที่แม้แต่การบำรุงรักษาพื้นฐานก็ทำได้ยาก
- นี่ไม่ใช่ปัญหาที่ “เทคโนโลยีเก่า” แต่เป็นปัญหาที่เกิดขึ้นเพราะ คนที่ดูแลเป็นคนใหม่
แนวโน้มในอนาคต
- ตลาดอาจมองเหตุขัดข้องครั้งนี้เป็นเรื่องครั้งเดียว แต่ โครงสร้างของปัญหายังคงอยู่
- คนที่มีประสบการณ์จากไป ระบบก็ซับซ้อนขึ้น และ
วงจรที่ทำให้โอกาสเกิด “เหตุครั้งถัดไป” สูงขึ้นเรื่อย ๆ ก็กำลังก่อตัว
- AWS มีแนวโน้มจะประกาศว่าเหตุการณ์นี้เป็น “เหตุขัดข้องเดี่ยวที่แยกขาด”
แต่หากช่องว่างภายในสะสมต่อไป ก็มี ความเสี่ยงสูงที่เหตุขัดข้องขนาดใหญ่ลักษณะคล้ายกันจะเกิดซ้ำ
- ดังสำนวน “chickens are coming home to roost”
การสูญเสียทุนมนุษย์มากกว่าเทคโนโลยี กำลังกลายเป็นความเสี่ยงใหญ่ที่สุดของ AWS
8 ความคิดเห็น
คนเราอยู่ที่ไหนก็ไม่ต่างกันเลย..
ดูเหมือนว่าจะเป็นเรื่องที่ใช้ได้กับทุกตลาดเลยนะครับ
ดูเหมือนว่าเราควรปฏิบัติต่อองค์ความรู้เชิงช่างของเทคโนโลยี IT ให้คล้ายกับทักษะเชิงช่างของช่างเชื่อมที่ชำนาญด้วยเหมือนกัน
จากบทความที่เพิ่งอ่านไปเมื่อไม่นานนี้
ทำให้นึกถึงเรื่องที่ว่าที่ Amazon การขยับจากระดับ Senior Engineer Level 2 ไปสู่ขั้นถัดไปนั้นยากมากอย่างแท้จริงนะครับ ไม่รู้ทำไมเหมือนกัน
เลยคิดว่าเหตุการณ์แบบให้ออกจากงานอย่างน่าเสียดายนั้น น่าจะเกิดขึ้นบ่อยเป็นพิเศษในช่วงระดับนั้น
ในทางกลับกัน ข้างบนอาจคิดว่า 'ปลดคนไปตั้งเยอะ แต่ยังประคองสถานการณ์ได้ขนาดนี้เลยสินะ...'
ที่เกาหลี พอวิศวกรไปถึงระดับหนึ่ง ทุกคนก็กลายเป็นผู้จัดการกันหมดแล้วสายงานก็ขาดตอน...
ที่อเมริกาก็มีปัญหา เพราะภายใต้ข้ออ้างเรื่องการเพิ่มประสิทธิภาพ กลับไล่ซีเนียร์ออกกันหมด...
ไม่ง่ายเลยจริง ๆ...
ทำ multi-az ไว้แล้วนี่สิ.. คงต้องเตรียมรับมือเหตุขัดข้องระดับรีเจียนด้วยหรือเปล่านะ..
ผมคิดว่าควรพิจารณาด้วยว่าต้นทุนนั้นสูงกว่าต้นทุนจากความเสียหายจริงหรือไม่
ความคิดเห็นใน Hacker News
ระหว่างพนักงานวิศวกรกับคนงานคลังสินค้า ตอนนี้ชวนให้คิดว่าถ้ายังไล่คนออกต่อไปเรื่อย ๆ อีกไม่นานก็คงถึงวันที่แม้แต่คนที่เคยทำงานที่บริษัทนี้มาก่อนก็หายไปหมด
ต่อให้จะมีผู้สมัครวิศวกร H1-B หลายแสนคนและคนงานคลังสินค้าผู้อพยพผิดกฎหมายอีกหลายสิบล้านคน แต่ถ้าบริษัทใหญ่ขนาดนี้ปลดคนจำนวนมากอย่างรวดเร็ว สุดท้ายทรัพยากรบุคคลก็ย่อมร่อยหรอลงจนหมดได้
สถานการณ์นี้ทำให้นึกถึงตอนล้อเลียน Star Wars ของ Robot Chicken ที่พวกนายทหารจักรวรรดิแกล้งทำเป็นว่า Darth Vader ใช้ Force choke แล้วแกล้งตายเพื่อหนีไม่ให้โดนไลท์เซเบอร์ฟัน จากนั้นก็กลับมาใหม่ด้วยชื่ออื่น แต่ Amazon หนักกว่านั้น เพราะไม่มีใครอยากกลับมาอีกแล้ว
https://www.youtube.com/watch?v=fFihTRIxCkg
พูดตามตรง ถ้าเป็นวิศวกรที่พอมีฝีมือ ก็แทบไม่เคยเห็นใครอยากกลับไปทำงานที่ Amazon เป็นครั้งที่สอง
ในคลังสินค้ามีผู้อพยพผิดกฎหมายเยอะขนาดนั้นจริงเหรอ? เท่าที่รู้ Amazon ตรวจสอบตัวตนและเอกสารค่อนข้างเข้มงวด อาจมีคนสวมรอยบ้างเป็นครั้งคราว แต่ไม่น่าจะเยอะขนาดนั้น
ปัญหาไม่ได้มีแค่การปลดคนออกอย่างเดียว ฉันยังจำได้ว่าทันทีที่ Amazon บังคับ RTO เต็มรูปแบบ ก็โดนอีเมลจากรีครูเตอร์ถล่มหนักมาก
ดูเหมือนจะมีบรรยากาศที่ตัดสินฝีมือวิศวกรล่วงหน้าเพียงเพราะเป็น H-1B
เมื่อก่อนฉันเองก็เคยทำงานด้วย H-1B และตอนนี้กลับมาอินเดียเพื่อทำธุรกิจของตัวเองแล้ว เคยอยู่ Amazon มาก่อน เป็นที่ทำงานที่หนัก แต่ช่วงกลางทศวรรษ 90 ตอนนั้นยังมี stock option เลยพอคุ้มจะทำ
ฉันมั่นใจว่าฉันเขียนโค้ดเก่งกว่าคนจำนวนมากในที่นี้พอสมควร และในกลุ่มคน H-1B รอบตัวฉันก็มีคนเก่งจริงอยู่เยอะ
อย่ามีอคติ ควรประเมินจากฝีมือโดยตรง ถ้าดูถูกคู่แข่ง สุดท้ายคนที่เสียประโยชน์ก็คือตัวเอง
ตอนนี้แหละคือเวลาที่ควรรักษาพนักงานไว้ และมอบเครื่องมือที่ดีที่สุดให้พวกเขาทำงานได้อย่างเต็มประสิทธิภาพ
เครื่องมือพัฒนากำลังก้าวหน้าขึ้นทุกวัน และแม้ระยะสั้นอาจลดจำนวนคนได้ แต่ผลลัพธ์คงไม่ออกมาทันที
มันเหมือนเอาการเติบโตในอนาคตและความยั่งยืนขององค์กรไปค้ำเพื่อประคองปัจจุบัน การหลอกตัวเองไม่ได้ทำให้การ downsizing ดีขึ้น
ในทางปฏิบัติดูเหมือนกลยุทธ์นี้จะใช้ได้ผล พวกเขาปลด principal engineer ระดับจูเนียร์ไปหนึ่งในสี่ แต่ราคาหุ้นกลับขึ้น และหลังเกิดเหตุขัดข้องครั้งใหญ่ ราคาหุ้นก็ยังขึ้นอีก ดังนั้นในระยะสั้นกลยุทธ์ของพวกเขาดูเหมือนจะยังเวิร์ก
ตอนนี้แม้แต่บริษัทบิ๊กเทคที่เคยดูเป็น “หน้าใหม่” ก็เริ่มเข้าสู่ยุคบริษัทใหญ่แก่ตัวแบบ IBM แล้ว
ไม่ใช่ว่าพวกเขาไม่รู้ว่าอัตราการลาออกสูงเป็นเรื่องแย่ แต่ดูเหมือนตั้งแต่ขั้นออกแบบระบบงานก็เลือกจะทำให้พนักงานโดยรวมถูกปรับให้เป็นค่าเฉลี่ย และกลายเป็นทรัพยากรมนุษย์ที่สลับแทนกันได้
ตอนนี้ถึงขั้นมองว่าแม้แต่ความสามารถที่โดดเด่นก็เป็นเพียง “วัฒนธรรมคาวบอย”
มันน่าสงสัยมากที่การแก้ปัญหาจริง ๆ เริ่มต้นตรงกับเวลาเริ่มงานฝั่งตะวันตกของสหรัฐ
ก่อนหน้านั้นอัปเดตมีแค่ “กำลังติดตามสถานการณ์ และกำลังดำเนินการบรรเทา” โดยไม่มีข้อมูลที่เป็นรูปธรรม
เท่าที่ฉันรู้ การกู้คืนดูเหมือนจะเกิดราวตี 4 ตามเวลา Seattle ปกติเริ่มงานกัน 9 โมง แต่ก็เป็นไปได้ว่าอาจเริ่มราว 6 โมงเช้าตามเวลา New York
ตอนนี้พอกลับมานึกถึงโพสต์ที่ฉันอ่านใน Reddit เมื่อเช้า ก็รู้สึกว่ามันมีความหมายขึ้นมาเลย
AWS ยังเป็นคลาวด์ที่ฉันชอบที่สุด และฉันก็ใช้งานมันได้อย่างมีประสิทธิภาพมาก
ฉันเองก็เคยคิดว่าอยากลองไปทำงานที่ AWS สักครั้ง แต่ถ้ายังไม่แน่ใจว่าความกังวลบางอย่างได้รับการแก้แล้วหรือยัง ก็อดคิดมากไม่ได้
ถ้าว่าที่ผู้จัดการยังปกป้องผู้สมัครไม่ได้แม้แต่ในกระบวนการแบบนี้ ก็ยิ่งน่ากังวลว่าจะปกป้องไม่ได้ในปัญหาวัฒนธรรมองค์กรที่หนักกว่านี้
ฉันมีแนวคิดที่น่าจะใช้ได้กับทั้ง FAANG ตอนนี้ คือพวกเขาต้องคอยตอกย้ำภาพลักษณ์ว่าที่นี่คือที่ที่คนเก่งจริงอยากมาทำงาน
Meta สร้างแบรนด์หลัก ๆ ด้วยค่าตอบแทนที่สูงกว่า และการปล่อยผลงาน open source กับ open hardware ส่วน Google ก็เน้นความได้เปรียบทางเทคนิคและวัฒนธรรมองค์กรที่อบอุ่น (หรือที่เรียกกันว่า วัฒนธรรมฝึกบ่มพนักงานใหม่ ซึ่งตอนนี้แม้จะออกแนวพิธีการไปแล้ว)
ฉันคิดว่า AWS เองก็มีบุคลากรเทคนิคที่น่าภูมิใจอยู่แล้ว และควรลงทุนทั้งในการดึงดูดและรักษาคนเหล่านี้ พร้อมสื่อสารภาพลักษณ์นี้ให้วงการรับรู้อย่างจริงจัง
ฉันเคยเห็นเรื่องแบบเดียวกันนี้ในสตาร์ตอัปเหมือนกัน
หลังการเข้าซื้อกิจการ มักจะเป็นช่วงที่คนสำคัญออกไป เพราะหุ้น vest แล้ว หรือไม่ก็บริษัทใหญ่ดันพวกเขาออกเพื่อเอาคนอื่นมานั่งแทน
คนที่เข้าใจเทคโนโลยีจริง ๆ ก็ออกไปหมด สุดท้ายเหลือแต่ codebase ยุ่งเหยิงที่ดูแลต่อไม่ได้ และไม่มีใครรู้วิธีแก้ปัญหา
ฉันชอบมากที่ El Reg จับแก่นของปัญหานี้ได้อย่างแม่นยำ
เพิ่งมารู้ตอนนี้เองว่าคนเขียนบทความคือ Corey Quinn ที่เขียนเรื่องเกี่ยวกับ AWS มาเยอะมาก
ฉันก็ชอบที่คนเขียนของที่นี่มีไหวพริบและเอกลักษณ์ในงานเขียน
คนพวกนี้ไม่ว่าเรื่องอะไร ก็ชี้เข้าแก่นได้ตรงจริง ๆ
“เกิดปัญหาขึ้นและใช้เวลา 75 นาทีจึงจำกัดสาเหตุให้เหลือเฉพาะ service endpoint ตัวหนึ่งได้”
มันนานขนาดนั้นเลยเหรอ? ฉันไม่ได้ทำเว็บ แต่รู้สึกว่าหาต้นตอเจอภายใน 75 นาทีก็ถือว่าเร็วมากแล้ว
เมื่อก่อนตอนเป็นวิศวกรเฟิร์มแวร์ บางครั้งใช้เวลาหลายสัปดาห์กว่าจะหาว่าพังตรงไหน
ถ้าเป็นปัญหาที่เกิดจริงแค่ 0.01% ไม่เกี่ยวโยงอะไรกับอย่างอื่น และพอลองใหม่ก็หาย แบบนั้นอาจใช้เวลาหลายสัปดาห์จริง
แต่โดยมากปัญหาแบบนั้นไม่ใช่เหตุการณ์ลำดับความสำคัญสูง ส่วนเหตุฉุกเฉินจริงมักเกิดซ้ำได้ และเป็นพวกที่เมื่อหนึ่งชั่วโมงก่อนยังปกติดีแล้วจู่ ๆ ก็พัง
โดยทั่วไป ถ้าเป็นระบบแกนหลักของธุรกิจที่ออกแบบมาดี การวินิจฉัยไม่น่ากินเวลาเกิน 75 นาที แน่นอนว่าการแก้อาจใช้เวลานานกว่านั้น
แม้จะพูดไม่ได้ว่าระบบในอุดมคติแบบนั้นมีอยู่ทั่วไปในโลกจริงก็ตาม
ถ้าเป็นบริษัททั่วไป 75 นาทีอาจไม่ถือว่านาน แต่ถ้าเป็นคลาวด์ที่ใหญ่ที่สุดในโลกและทำให้ส่วนใหญ่ของอินเทอร์เน็ตหยุดชะงัก เรื่องมันก็คนละแบบ
ที่จริงในประกาศทางการอาจเขียนว่า ‘ยังอยู่ระหว่างการสอบสวน’ แต่ภายในจริง ๆ ก็อาจเดาสาเหตุได้เร็วกว่านั้นแล้ว
การรีบอัปเดตเร็วเกินไปอาจทำให้ผู้ใช้เข้าใจผิดโดยไม่จำเป็น จึงควรระวังไว้
สำหรับฉัน 75 นาทีแทบจะเป็นความเร็วระดับสูงสุดแล้วสำหรับการวินิจฉัยปัญหาใหญ่แบบใดก็ตาม
Amazon เป็นที่รู้กันว่ามีโครงสร้างพื้นฐานระดับแนวหน้าของอุตสาหกรรม
เมื่อบริษัทอื่นจำนวนมากต่างก็ใช้อินฟราของ Amazon ก็ย่อมคาดหวังว่าคนระดับ SRE จะต้องหาต้นตอของเหตุการณ์แบบนี้ได้อย่างรวดเร็วจริง ๆ
ความรู้จากประสบการณ์และเคล็ดลับการทำงานที่กำลังหายไปจากองค์กรต่างหาก คือคุณค่าที่สำคัญจริง ๆ ซึ่งยากจะยัดลงไปในสเปรดชีต Excel ธรรมดาได้
องค์กรเริ่มให้ความสำคัญกับคนที่สร้างแบรนด์ให้ตัวเองหรือการจ้างงานเพื่อภาพลักษณ์ มากกว่าคนเก่งจริงและผู้เชี่ยวชาญที่อยู่ยาว จนกำลังหลักทางเทคนิคที่เข้าใจระบบจริง ๆ ถูกเบียดออกไป
เมื่อความไม่สมดุลนี้ขยายใหญ่ใน AWS คนดังบน LinkedIn และบุคลากร DEI แบบเช็กลิสต์ก็จะมีอิทธิพลเหนือกว่าคนที่สร้างของจริง ทำให้คุณภาพในการลงมือทำ ความรับผิดชอบ และความสมบูรณ์ทางเทคนิคค่อย ๆ อ่อนลง
ตอนนี้เริ่มชัดขึ้นเรื่อย ๆ ว่าภาวะผู้นำของ Andy Jassy ไม่ได้ผล และอีกไม่นาน Wall Street อาจเรียกร้องอย่างเป็นทางการให้เปลี่ยนตัว
พอมีคนบอกว่า The Register เป็นสำนักข่าวที่น่าเคารพ ก็อดรู้สึกไม่ได้ว่า จริง ๆ แล้วพวกเขาเองคงไม่อยากถูกเรียกแบบนั้นเท่าไร...