- หลังจากเกิด เหตุขัดข้องของบริการที่เกี่ยวข้องกับการใช้เครื่องมือเขียนโค้ดด้วย AI ต่อเนื่องเมื่อไม่นานมานี้ Amazon ได้เริ่มใช้ กระบวนการอนุมัติล่วงหน้าโดยวิศวกรอาวุโส สำหรับการเปลี่ยนแปลงโค้ดทั้งหมดที่มี AI ช่วย
- ตามบันทึกภายใน สาเหตุของเหตุขัดข้องถูกชี้ไปที่ "การนำ GenAI รูปแบบใหม่มาใช้ ซึ่งแนวปฏิบัติที่ดีที่สุดและมาตรการป้องกันยังไม่ได้ถูกวางไว้อย่างสมบูรณ์"
- ในเดือนนี้ เว็บไซต์และแอปช้อปปิ้งของ Amazon ล่มราว 6 ชั่วโมง ทำให้ลูกค้าไม่สามารถทำรายการให้เสร็จ ตรวจสอบข้อมูลบัญชี หรือดูราคาได้ โดยมีสาเหตุมาจากการปล่อยซอฟต์แวร์โค้ดที่ผิดพลาด
- ฝั่ง AWS ก็มีรายงานอุบัติเหตุที่เกี่ยวข้องกับ AI อย่างน้อยสองกรณี เช่น ผู้ช่วยเขียนโค้ด AI อย่าง Kiro ลบและสร้างสภาพแวดล้อมขึ้นใหม่จนทำให้เกิด เหตุขัดข้องนาน 13 ชั่วโมง
- เมื่อ ความเสี่ยงด้านการปฏิบัติการจากการนำเครื่องมือเขียนโค้ดด้วย AI ไปใช้ในโปรดักชัน เริ่มเกิดขึ้นจริง จึงมีการออกมาตรการทันทีให้ การเปลี่ยนแปลงที่มี AI ช่วยของวิศวกรระดับจูเนียร์และมิดเลเวลต้องมีลายเซ็นอนุมัติจากวิศวกรอาวุโส
การประชุมภายในและมาตรการตอบสนองของ Amazon
- ฝ่ายอีคอมเมิร์ซของ Amazon ได้เรียกประชุมวิศวกรวงใหญ่เพื่อวิเคราะห์ การหยุดชะงักของบริการที่เกิดขึ้นต่อเนื่อง เมื่อไม่นานมานี้
- วาระการประชุมรวมถึง อุบัติเหตุที่เกี่ยวข้องกับการใช้เครื่องมือเขียนโค้ดด้วย AI
- ในบันทึกสรุปภายในระบุว่าในช่วงไม่กี่เดือนที่ผ่านมา เหตุการณ์ "ความเสี่ยงสูง (high blast radius)" เพิ่มขึ้น และมีการกล่าวถึง "การเปลี่ยนแปลงที่ได้รับการสนับสนุนด้วย Gen-AI" ว่าเป็นปัจจัยสำคัญ
- เอกสารดังกล่าวระบุว่า "กรณีการใช้งาน GenAI รูปแบบใหม่ที่ยังไม่ได้ถูกทำให้เป็นมาตรฐานอย่างสมบูรณ์" เป็นหนึ่งในปัจจัยที่มีส่วนทำให้เกิดปัญหา
- รองประธานอาวุโส Dave Treadwell กล่าวในอีเมลว่า “ช่วงหลังมานี้ความพร้อมใช้งานของเว็บไซต์และโครงสร้างพื้นฐานไม่ดีนัก”
กรณีเหตุขัดข้องที่เกี่ยวข้องกับ AI
- เว็บไซต์และแอปช้อปปิ้งของ Amazon หยุดให้บริการราว 6 ชั่วโมง ในช่วงต้นเดือนนี้ โดยยืนยันสาเหตุว่าเป็น “การปล่อยซอฟต์แวร์โค้ดที่ผิดพลาด”
- ผลกระทบคือ ลูกค้าไม่สามารถ ทำรายการให้เสร็จ ตรวจสอบข้อมูลบัญชี และดูราคาสินค้า ได้
- ฝั่ง AWS ก็เกิดปัญหาระหว่างการใช้งาน ผู้ช่วยเขียนโค้ด AI อย่าง Kiro
- กลางเดือนธันวาคม Kiro ตัดสินใจ “ลบแล้วสร้างสภาพแวดล้อมขึ้นใหม่” ส่งผลให้ บริการเครื่องคำนวณค่าใช้จ่ายหยุดชะงักนาน 13 ชั่วโมง
- Amazon อธิบายเหตุการณ์นี้ว่าเป็น “เหตุการณ์ที่มีขอบเขตจำกัดมาก ซึ่งจำกัดอยู่ในบริการเดียวในบางพื้นที่ของจีนแผ่นดินใหญ่”
- Amazon ยังชี้แจงเพิ่มเติมว่าอุบัติเหตุครั้งที่สอง “ไม่ส่งผลกระทบต่อบริการ AWS ที่ให้บริการลูกค้า”
ขั้นตอนอนุมัติใหม่และการปรับปรุงการปฏิบัติการ
- Treadwell มีแผนจะหารือถึงสาเหตุของปัญหาและมาตรการปรับปรุงระยะสั้นผ่านการประชุมประจำสัปดาห์
This Week in Stores Tech (TWiST)
- จากเดิมที่เข้าร่วมแบบสมัครใจ ได้เปลี่ยนเป็น แนะนำให้พนักงานทุกคนเข้าร่วม
- ต่อจากนี้ การเปลี่ยนแปลงโค้ดที่มี AI ช่วยซึ่งดำเนินการโดยวิศวกรระดับจูเนียร์และมิดเลเวล จะต้องได้รับการลงนามอนุมัติจากวิศวกรอาวุโส
- Amazon ระบุว่าการทบทวนครั้งนี้เป็น “ส่วนหนึ่งของกระบวนการทางธุรกิจตามปกติ” และมีเป้าหมายเพื่อ การปรับปรุงอย่างต่อเนื่อง
ข้อถกเถียงเรื่องการลดพนักงานและเหตุขัดข้องที่เพิ่มขึ้น
- Financial Times รายงานว่า วิศวกรบางส่วนกล่าวถึงการเพิ่มขึ้นของ เหตุการณ์ระดับ 'Sev2' (เหตุขัดข้องระดับกลางที่ต้องตอบสนองอย่างรวดเร็ว) หลังการลดจำนวนพนักงาน
- ในช่วงไม่กี่ปีที่ผ่านมา Amazon ได้ดำเนิน การปรับโครงสร้างหลายครั้ง และ ลดตำแหน่งงานสายองค์กร 16,000 ตำแหน่งในเดือนมกราคม 2026 เพียงเดือนเดียว
- อย่างไรก็ตาม บริษัท ไม่เห็นด้วยกับข้ออ้างว่าการลดพนักงานเป็นสาเหตุของการเพิ่มขึ้นของเหตุขัดข้อง
ทิศทางในอนาคต
- Amazon กำลังทำให้ การทบทวนความพร้อมใช้งานของเว็บไซต์และการตรวจสอบผลการปฏิบัติการ เป็นกิจวัตรประจำ
- บริษัทกำลังผลักดันทั้ง การใช้งานเครื่องมือเขียนโค้ดด้วย AI อย่างปลอดภัย และ การเสริมความแข็งแกร่งให้ระบบป้องกันเหตุขัดข้อง ควบคู่กันไป
- มาตรการครั้งนี้ถูกมองว่าเป็นอีกกรณีตัวอย่างที่ตอกย้ำ ความสำคัญของกระบวนการตรวจสอบโดยมนุษย์ ท่ามกลางการขยายตัวของการนำ AI มาใช้
6 ความคิดเห็น
ต่อให้วิศวกรอาวุโสรีวิวโค้ด AI ก็ไม่ได้รับประกันว่าจะปลอดภัยนะ
กรณี crowdstrike ก็ไม่ได้เกิดเพราะ AI
ส่วน heartbleed ก็เป็นอุบัติเหตุในยุคที่ยังไม่มี AI
สรุปคือแก่นของเรื่องคือจะต้องให้ใครสักคนรับผิดชอบ
เพราะตามกฎหมายต้องมีมนุษย์ที่รับผิดชอบได้ เลยทำให้นึกถึงอารมณ์ขันเสียดสีของพวกนักบัญชีภาษีที่ชอบพูดกันว่า พวกเราคงไม่ถูกแทนที่หรอก
ใช่ครับ ดังนั้นถ้าไม่ใส่อะไรทำนองลายเซ็นทางกฎหมายให้กับ AI agent ก็น่าจะเป็นแบบนี้ต่อไป..
งั้นค่าใช้งาน Anthropic หรือ OpenAI ก็คงต้องแพงลิ่วเลยนะ
เพราะทุกครั้งที่เรียก API ก็คงต้องจ่ายค่าเบี้ยประกัน
อืม... แม้จะเป็นแค่การคาดเดา แต่ก็รู้สึกว่าอาจจะมีอะไรบางอย่างเกิดขึ้นแบบ IAM ก็ได้...
เขาว่าหน้าที่ของนักบัญชีภาษีคือการเข้าคุก แต่บริษัทประกันก็ไม่ได้ติดคุกแทนให้ สุดท้ายก็เลย...
ความคิดเห็นบน Hacker News
“mandatory meeting” ครั้งนี้จริง ๆ คือ การประชุมปฏิบัติการทั้งบริษัท ที่มีทุกสัปดาห์
แค่สัปดาห์นี้มีคนเข้าร่วมเยอะเพราะสัปดาห์ก่อนเกิดเหตุขัดข้องด้านปฏิบัติการครั้งใหญ่
รู้สึกว่าสื่อกำลังพูดเกินจริงไปมาก
แล้วก็มีการพูดถึงนโยบายว่า “การเปลี่ยนโค้ดที่ใช้ AI ของวิศวกรระดับจูเนียร์และมิดเลเวลต้องได้รับการอนุมัติจากวิศวกรซีเนียร์”
ต่อให้เป็นการประชุมประจำ ถ้ามี การประกาศนโยบายใหม่ ก็ถือว่ามีคุณค่าข่าวอยู่ดี
ราคาไม่แสดง และก็ใส่ของลงตะกร้าไม่ได้
ถ้าเป็นคู่แข่งอย่าง Walmart คงได้เป็นข่าวไปแล้ว เลยรู้สึกแปลก ๆ
นโยบายที่ว่า “วิศวกรจูเนียร์และมิดเลเวลห้าม push โค้ด AI โดยไม่มีการอนุมัติจากซีเนียร์”
ดูเหมือนจะตั้งอยู่บนความเข้าใจผิดว่า การรีวิวโดยซีเนียร์ เป็นยาวิเศษ
ในความเป็นจริง ถ้าซีเนียร์จะตรวจโค้ดได้ครบจริง ๆ เวลาที่ต้องใช้ก็แทบไม่ต่างจากการเขียนเอง
กล่าวคือการรีวิวมีคุณค่า แต่ไม่ได้เปลี่ยนโค้ดแย่ให้กลายเป็นโค้ดดี
สุดท้ายปัญหาคือเมื่อพยายามสร้างระบบแบบ “idiot proof” ก็จะเกิดความเข้าใจผิดว่า งั้นก็จ้าง ‘idiot’ ได้สิ
การเจอบั๊กเป็นแค่ผลพลอยได้ สิ่งที่สำคัญจริง ๆ คือทำให้ทดสอบได้ง่ายและลด ความซับซ้อนของโค้ด
แต่เรื่องพวกนี้กลับไม่ได้ช่วยให้เลื่อนตำแหน่ง
และจะมีประสิทธิภาพที่สุดถ้าคอยเฝ้าตั้งแต่ตอนที่โมเดลกำลังทำงาน
ไม่งั้น AI ก็จะปล่อย ระเบิดโค้ดคุณภาพต่ำ ออกมา
ถ้ามีผู้เชี่ยวชาญยอมเสียเวลาแก้ 5-15 เท่าก็พอไหว แต่ถ้าไม่ทำ codebase ก็พัง
โดยเฉพาะโค้ดแย่ ๆ ที่ต้องใช้เวลาทำความเข้าใจเพิ่มเป็นเท่าตัว
เพราะต้องถือทั้งโค้ดเดิมและทางแก้ใหม่ไว้ในหัวพร้อมกันเพื่อเปรียบเทียบ ทำให้ ภาระทางการรับรู้ สูง
สุดท้ายมันดูเหมือนวิวัฒนาการตามธรรมชาติที่บริษัทจะหันไปโฟกัสที่ การจัดการผลงานเฉลี่ย มากขึ้น
ภายใน Amazon คนส่วนใหญ่สนใจแค่ ไม่ให้โดนเลย์ออฟ กับ การเลื่อนตำแหน่ง
การประเมินนักพัฒนาถูกตัดสินจาก “ความเร็วในการปิด ticket”, “จำนวนคอมเมนต์ใน PR”, และ “การเขียนเอกสาร”
ถ้าไม่ใช้ AI ก็เสียเปรียบในการแข่งขัน
ในโครงสร้างแบบนี้ การขอให้ “ลดการใช้ AI” จึงแทบทำงานไม่ได้ในทางปฏิบัติ
ยิ่งทีมร่วมมือกันดีเท่าไร การถกใน PR ก็ยิ่งน้อย
คิดว่าสิ่งที่ต้องมีจริง ๆ คือ กระบวนการ self-review
การ push โค้ดที่ AI เขียนมาแบบตรง ๆ เป็นเรื่องอันตราย
แพลตฟอร์มอย่าง GitHub ควรเพิ่มตัวเลือก “บังคับ self-review” เพื่อให้ผู้เขียนยืนยันว่าได้ตรวจทานเองแล้ว
เพราะ local UI เร็วกว่า จึงมอง flow ของโปรเจกต์ได้ดีขึ้น
ถึงจะดูเหมือนเรื่องพื้นฐาน แต่ก็ช่วยได้จริง
ความน่าเชื่อถือของผู้นำ Amazon กำลังลดลง
ทั้งการลาออกของคนเก๋า ๆ, คุณภาพ AI ที่แย่ลง, และเหตุขัดข้องที่เกิดบ่อย ทำให้ดูเหมือนฝั่งวิศวกรรมกำลังพัง
ดูเหมือนคนที่ตัดสินใจจะไม่เข้าใจเรื่อง คอขวดของ pipeline
ต่อให้ AI สร้าง diff ได้เร็วขึ้น 10 เท่า แต่ถ้าการรีวิวยังคือคอขวด ความเร็วรวมก็เท่าเดิม
สุดท้ายมีแต่ ต้นทุนและความไม่แน่นอนที่เพิ่มขึ้น
ถ้ามาทำ AI code review กันตอนขั้น PR ข้อได้เปรียบด้าน productivity ก็หายไป
AI อาจสร้างฟีเจอร์ได้ใน 10 นาที แต่การรีวิวโดยคนใช้เวลามากกว่า 10-20 เท่า
เรื่องที่ยากจริง ๆ คือการรู้ว่า “กำลังสร้างอะไรและทำไม” กับ “มันถูกสร้างได้ถูกต้องหรือไม่”
AI ยังทำสองอย่างนี้ไม่ได้
จนกว่า LLM จะเก่งทั้งการสร้างและการรีวิว สิ่งที่เพิ่มขึ้นมีแต่ ความเสี่ยง
เป็นนโยบายที่เป็นไปไม่ได้ในโลกจริง
แล้วก็จะเข้าสู่ยุคที่ทดสอบเสร็จแล้ว deploy ได้ทันที
แก่นแท้ของ code review ไม่ใช่ การตรวจจับข้อผิดพลาด แต่คือ การทำให้ทีมซิงก์กันและการเรียนรู้
ผ่านการรีวิว ทีมได้แชร์การออกแบบและมาตรฐาน ฝึกจูเนียร์ และเปิดรับมุมมองที่หลากหลาย
กระบวนการเหล่านี้ต่างหากที่เป็นหัวใจในการลดข้อผิดพลาด
เพราะถ้าเดินไปในทิศทางการออกแบบที่ผิด ก็ย้อนกลับได้ยาก
กระแส AI กำลังกินทั้งเวลาและต้นทุนมากเกินไป
อดกังวลไม่ได้ว่าอนาคตของ ซอฟต์แวร์โครงสร้างพื้นฐานสำคัญ จะเป็นอย่างไร
ถ้าซอฟต์แวร์การบินโดนกระแสนี้พัดไปด้วย อาจเกิด ผลลัพธ์ร้ายแรงถึงชีวิต ได้
AI มีแนวโน้มจะถูกใช้เป็น เครื่องมือเสริม เพื่อช่วยยกระดับคุณภาพ