การหยุดทำงานของ GitHub เกิดจากปริมาณการจราจรที่เพิ่มขึ้นจาก AI และข้อผิดพลาดในการตั้งค่า

เมื่อวันที่ 9 กุมภาพันธ์ปีนี้ เวลาดึกตามเวลาปักกิ่ง นักพัฒนาหลายล้านคนทั่วโลกเปิด GitHub และเห็นหน้าเว็บเดียวกัน

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

github.com ล่ม

API ล่ม

GitHub Actions หยุดทำงาน

การดำเนินการ Git ล้มเหลว—แม้แต่ Copilot ก็ไม่รอด

คืนนั้น บางคนมีสายการผลิต CI/CD หยุดนิ่งที่จุดสำคัญที่สุด บางคนการปรับใช้อัตโนมัติค้างอยู่กลางอากาศ และบางคนก็รอ PR ที่ยังไม่สามารถรวมเข้าด้วยกันได้—ทั้งหมดนี้เป็นฟีเจอร์ที่รอการเปิดใช้งาน และรอผู้ใช้จริง

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

สองวันก่อน ทีมวิศวกรรมได้เปลี่ยนเวลาอัปเดตแคชการตั้งค่าผู้ใช้จาก 12 ชั่วโมงเป็น 2 ชั่วโมง เพื่อเร่งการเผยแพร่โมเดลใหม่ให้ผู้ใช้ แค่การเปลี่ยนตัวเลขการตั้งค่านี้เท่านั้น

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

ตัวเลขหนึ่งตัว ถูกเปลี่ยนจาก 12 เป็น 2

GitHub ถูกกำหนดค่าที่แก้ไขเองทำให้เกิดปัญหา

แต่ถ้าคุณเห็นการเปลี่ยนแปลงการตั้งค่าเพียงข้อเดียว คุณอาจพลาดส่วนที่สำคัญที่สุดของเรื่องนี้

เหตุการณ์เมื่อวันที่ 9 กุมภาพันธ์ ไม่ใช่เหตุการณ์เดียวที่เกิดขึ้น

ในความเป็นจริง สามเดือนแรกของปี 2026 GitHub เผชิญกับเหตุขัดข้องร้ายแรงอย่างน้อย 8 ครั้ง ในเดือนกุมภาพันธ์เพียงเดือนเดียว มีบันทึกข้อผิดพลาดขนาดเล็กและใหญ่รวม 37 ครั้ง ต่อมา Vlad Fedorov หัวหน้าเจ้าหน้าที่เทคโนโลยีของ GitHub ได้ยอมรับในบล็อกว่า ในสองเดือนนี้ GitHub ไม่สามารถรักษาความพร้อมใช้งานระดับ “สามเก้า” ที่สัญญาไว้กับลูกค้าองค์กรไว้ได้ ซึ่งคือ 99.9%

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

วันที่ 2 กุมภาพันธ์: มีปัญหาเกี่ยวกับผู้ให้บริการการคำนวณของ Azure ทำให้ GitHub Actions หยุดทำงานนานเกือบ 4 ชั่วโมง ซึ่งส่งผลกระทบต่อ Copilot Code Agent, CodeQL และ Dependabot ทั้งหมด

February 9: Cache rewrite storm, authentication database overload.

วันที่ 5 มีนาคม: ข้อผิดพลาดของคลัสเตอร์ Redis ทำให้ 95% ของงาน流ใน GitHub Actions ไม่สามารถเริ่มต้นภายใน 5 นาที โดยมีความล่าช้าเฉลี่ย 30 นาที

วันที่ 18 มีนาคม: ความล่าช้าของ Webhook พุ่งสูงขึ้นถึง 32 เท่าของระดับปกติ

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

พูดในภาษาของวิศวกร รากฐานของ GitHub ได้เริ่มแสดงรอยร้าวภายใต้ภาระโหลดใหม่

และ "โหลดใหม่" นี้ มีชื่อเฉพาะ

ข้อมูลสำคัญ

ปริมาณการคอมมิตทั้งปี 2025: ประมาณ 1 พันล้านครั้ง

จำนวน commit ต่อสัปดาห์ในปี 2026: 275 ล้านครั้ง

ที่อัตรานี้ คาดการณ์ทั้งปีปี 2026: 14 พันล้านครั้ง (เพิ่มขึ้น 14 เท่าเมื่อเทียบกับปีก่อนหน้า)

ปริมาณการคำนวณของ GitHub Actions: 5 พันล้านนาทีต่อสัปดาห์ในปี 2023 → 10 พันล้านนาทีในปี 2025 → 21 พันล้านนาทีในสัปดาห์ใดสัปดาห์หนึ่งต้นปี 2026

หากคุณเป็นวิศวกรโครงสร้างพื้นฐานของ GitHub การเปรียบเทียบแดชบอร์ดการตรวจสอบระหว่างปี 2025 และ 2026 น่าจะทำให้คุณอึ้งไปเลย

ในปี 2025 GitHub ได้จัดการคำสั่งส่งโค้ดประมาณ 1 พันล้านครั้ง ตัวเลขนี้เองก็ใหญ่โตอยู่แล้ว และเป็นผลลัพธ์จากการสะสมมานานหลายปีของแพลตฟอร์ม GitHub แต่ในปี 2026 ปริมาณการส่งโค้ดต่อสัปดาห์ได้เพิ่มขึ้นถึง 275 ล้านครั้ง คำนวณออกมา—หากยังคงอัตราเช่นนี้ตลอดทั้งปี ปริมาณการส่งโค้ดทั้งหมดในปี 2026 จะใกล้เคียงกับ 14 พันล้านครั้ง ซึ่งมากกว่าปริมาณทั้งปีของปี 2025 ถึง 14 เท่า

นี่ไม่ใช่เส้นโค้งที่เติบโตอย่างราบเรียบ แต่เป็นความชันที่陡峭มาก: ปริมาณการคำนวณของ GitHub Actions แสดงให้เห็นชัดเจนยิ่งขึ้น: ในปี 2023 ใช้เวลาคำนวณ 5 พันล้านนาทีต่อสัปดาห์ ปี 2025 เพิ่มเป็นสองเท่าเป็น 10 พันล้านนาที จากนั้นในสัปดาห์ใดสัปดาห์หนึ่งต้นปี 2026 ปริมาณดังกล่าวพุ่งขึ้นไปถึง 21 พันล้านนาทีทันที

อะไรกำลังส่งโค้ดอย่างบ้าคลั่ง?

ไม่ใช่นักพัฒนาที่เป็นมนุษย์

ข้อมูลจาก GitHub แสดงให้เห็นว่า AI Agent กำลังกลายเป็น “ผู้ใช้งาน” ที่มีกิจกรรมมากที่สุดบนแพลตฟอร์มนี้ เครื่องมือเดียวอย่าง Claude Code ตอนนี้มีส่วนร่วมในการส่งข้อมูลไปยังคลังสาธารณะทั้งหมดของ GitHub ถึง 4.5% หรือ 2.6 ล้านครั้งต่อสัปดาห์ ขณะที่ปลายเดือนกันยายน 2025 ตัวเลขนี้ยังอยู่ที่เพียง 100,000 ครั้ง — เพิ่มขึ้น 25 เท่าภายในสามเดือน

จำนวน PR ที่เปิดโดย AI Agent ก็กำลังพุ่งสูงขึ้นอย่างระเบิด ในเดือนกันยายน 2025 จำนวน PR ที่สร้างโดย AI อยู่ที่ประมาณ 4 ล้านรายต่อเดือน แต่จนถึงเดือนมีนาคม 2026 ตัวเลขนี้พุ่งขึ้นเป็น 17 ล้าน—เพิ่มขึ้นมากกว่าสี่เท่าภายในหกเดือน

มีภาพหนึ่งที่สามารถช่วยให้คุณเข้าใจว่าหมายความว่าอะไร

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

ในปัจจุบัน ผู้ใช้จำนวนมากขึ้นเรื่อยๆ คือ AI Agent พวกเขาไม่หลับ ไม่พัก และไม่ลังเล สามารถเปิด Agent หลายตัวพร้อมกันเพื่อทำภารกิจเดียวกัน แต่ละ Agent สามารถส่งงานได้มากกว่าปริมาณงานของวิศวกรจริงหนึ่งคนในหนึ่งสัปดาห์ ยิ่งไปกว่านั้น พวกเขาไม่ได้แค่ส่งโค้ดเท่านั้น แต่ยังสร้าง repository ใหม่อย่างต่อเนื่อง—โดยใช้ repository เป็นผลลัพธ์ของกระบวนการทำงาน ไม่ใช่พื้นที่ทำงานของมนุษย์

วิศวกรโครงสร้างพื้นฐานของ GitHub กำลังเผชิญกับปัญหาที่ไม่ใช่แค่ปริมาณการรับส่งข้อมูลที่มากขึ้น แต่เป็นปัญหาที่มีลักษณะต่างออกไปอย่างสิ้นเชิง

ความถี่ของการเกิดข้อผิดพลาดเป็นเพียงด้านหนึ่งของปัญหา GitHub ยังมีปัญหาที่น่ากังวลมากกว่านั้นอีก—เมื่อคำนวณบัญชีแล้วพบว่าขาดทุน

ตรรกะการตั้งราคาเริ่มต้นของ Copilot ถูกสร้างขึ้นจากสมมติฐานที่สมเหตุสมผล: ผู้ใช้ส่วนใหญ่ใช้งานในรูปแบบ “ช่วยเติมเต็ม” โดยแต่ละครั้งที่มีการโต้ตอบจะสั้นและมีปริมาณการคำนวณที่สามารถคาดการณ์ได้ รุ่นส่วนบุคคลราคา 10 ดอลลาร์สหรัฐต่อเดือน รุ่นธุรกิจราคา 19 ดอลลาร์สหรัฐต่อเดือน โดยคิดค่าบริการตามจำนวนผู้ใช้ โมเดลนี้ทำงานได้ดีมาหลายปีที่ผ่านมา

จากนั้น Agentic AI ก็ปรากฏขึ้น

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

GitHub กำลังเผชิญกับสถานการณ์ที่ผู้ใช้ที่ใช้งาน Agentic อย่างหนักเพียงไม่กี่คน กำลังใช้ทรัพยากรการคำนวณมูลค่าหลายร้อยดอลลาร์ด้วยค่าใช้จ่ายรายเดือนเพียงไม่กี่ดอลลาร์

ในสถานการณ์นี้ GitHub ตอบสนองอย่างตรงไปตรงมา—ควบคุมการไหลก่อน แล้วจึงปรับราคา

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

วันที่ 1 มิถุนายน GitHub ได้ดำเนินการปรับเปลี่ยนราคาอย่างลึกซึ้ง: Copilot ย้ายไปใช้ระบบคิดค่าบริการตามการใช้งานอย่างสมบูรณ์ โดยแทนที่ค่าแพ็กเกจเดิมด้วย "AI Credits" 1 AI Credit เท่ากับ 1 เซนต์สหรัฐ และการใช้งานจะถูกคำนวณแบบเรียลไทม์ตามการบริโภค token

ยุคที่คิดค่าบริการตามที่นั่งได้สิ้นสุดลงแล้วต่อหน้า Agentic AI

การเปลี่ยนแปลงนี้ไม่ใช่แค่ปัญหาของ GitHub เท่านั้น แต่เป็นวิกฤตการกำหนดราคาแบบร่วมกันที่อุตสาหกรรมเครื่องมือ AI ทั้งหมดกำลังเผชิญในปี 2026 — เมื่อ AI เริ่มแทนที่มนุษย์ในการดำเนินงานทั้งกระบวนการ ไม่ใช่แค่ “ช่วยเหลือ” งานของมนุษย์ อีกต่อไป ตรรกะการสมัครสมาชิกแบบ “ต่อคนต่อเดือน” ทั้งหมดจะล้มเหลว

กลับมาที่ปัญหาโครงสร้างพื้นฐาน GitHub จะรับมือกับการเติบโต 14 เท่านี้อย่างไร

มีรายละเอียดหนึ่งที่แสดงให้เห็นถึงความรุนแรงของปัญหา:

ปลายเดือนธันวาคม 2025 กระบวนการ Agentic เริ่มเร่งความเร็วอย่างฉับพลัน วิศวกรของ GitHub ตระหนักว่าการขยายขนาด 10 เท่านั้นไม่เพียงพอ จนถึงเดือนกุมภาพันธ์ 2026 หลังจากเกิดการหยุดให้บริการอย่างรุนแรง GitHub ประกาศว่าจำเป็นต้องออกแบบสถาปัตยกรรมใหม่ให้รองรับขนาดใหญ่ขึ้น 30 เท่าจากปัจจุบัน

ไม่ใช่การขยายความสามารถ แต่เป็นการออกแบบใหม่

ความแตกต่างระหว่างสองคำนี้มากมาก การขยายขนาดหมายถึงการเพิ่มจำนวนเครื่องจักรที่มีอยู่หรือเพิ่มหน่วยความจำให้กับฐานข้อมูลที่มีอยู่—ทิศทางยังเหมือนเดิม แค่ขนาดใหญ่ขึ้น การออกแบบใหม่หมายถึง สมมติฐานของสถาปัตยกรรมปัจจุบันจะล้มเหลวอย่างเป็นระบบเมื่ออยู่ในขนาด 30 เท่า จึงต้องพิจารณาใหม่ตั้งแต่พื้นฐานเกี่ยวกับการแบ่งบริการ การไหลของข้อมูล และการแยกความล้มเหลว

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

ควรสังเกตว่า GitHub ไม่ได้อยู่คนเดียว

Stripe ได้เผชิญกับปัญหาการสร้างบัญชีจำนวนมากโดย AI Agent ขณะที่ AWS กำลังพัฒนาระบบระบุตัวตน ระบบบันทึก และกลไกการควบคุมการผลิตเฉพาะสำหรับ Agent การกระทำเหล่านี้ไม่ใช่การป้องกันล่วงหน้า แต่เป็นการตอบสนองต่อสัญญาณที่ปรากฏบนแดชบอร์ดการติดตามผลซึ่งพวกเขาต้องแก้ไข

GitHub เป็นเพียงจุดแรกที่ถูกเจาะ — เพราะมันอยู่ที่ใจกลางของโซ่เครื่องมือ AI

หยุดคิดสักครู่เกี่ยวกับลักษณะของเรื่องทั้งหมดนี้

GitHub คืออะไร? คำตอบที่ตรงที่สุดคือ มันคือที่เก็บโค้ดของนักพัฒนา แต่ในระดับที่ลึกกว่านั้น มันคือโครงสร้างพื้นฐานของการร่วมมือกันด้านซอฟต์แวร์ของมนุษย์—บันทึกการส่งโค้ดเป็นเส้นทางของการร่วมมือ PR เป็นภาชนะสำหรับการอภิปราย Issues เป็นการบันทึกเจตนา และ Action เป็นท่อสำหรับการดำเนินการ ระบบทั้งหมดนี้ถูกออกแบบมาเพื่อรองรับจังหวะการทำงาน วิธีคิด และรูปแบบการร่วมมือของมนุษย์

AI Agent เปลี่ยนทุกอย่างไปแล้ว

เมื่อ AI Agent สามารถส่งโค้ดได้หลายร้อยครั้งต่อวัน และแต่ละครั้งที่ “ส่ง” ไม่มีการคิดหรือการตัดสินใจจากมนุษย์ แต่เป็นเพียงขั้นตอนความคืบหน้าของวงจรงาน — คลังโค้ดยังคงเป็น “ภาชนะสำหรับร่วมมือ” อยู่หรือไม่?

เมื่อเครื่องมือ AI สร้างรีโพสิทอรีอัตโนมัติ เปิด PR อัตโนมัติ รัน CI อัตโนมัติ และรวมเข้าด้วยกันอัตโนมัติ — นักพัฒนายังคงเป็นผู้หลักในกระบวนการนี้ หรือพวกเขาได้ลดบทบาทลงเหลือเพียง “ผู้ตรวจสอบ” หรือแม้แต่ “ผู้สังเกตการณ์”?

CTO ของ GitHub ใช้คำว่า “การเติบโตอย่างรวดเร็วของภาระงาน” เพื่ออธิบายวิกฤตครั้งนี้ แต่คำนี้อาจลดทอนแก่นแท้ของปัญหา—มันไม่ใช่แค่การเพิ่มขึ้นในปริมาณ แต่เป็นการเปลี่ยนแปลงเชิงคุณภาพในวิธีการใช้งาน ในโมเดลเดิม GitHub เป็น “เครื่องมือของนักพัฒนา” ในโมเดลใหม่ GitHub กำลังกลายเป็น “ท่อระบายของ AI” หรือท่อส่งออกของกระบวนการอัตโนมัติ

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

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

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

คืนวันที่ 9 กุมภาพันธ์ วิศวกรที่รอการรวม PR น่าจะได้รับสัญญาณสีเขียวในที่สุด แต่เขาอาจไม่รู้ตัวว่า การหยุดทำงานครั้งนั้นที่ทำให้เขาต้องรอ ไม่ใช่เหตุการณ์ผิดปกติของ GitHub แต่เป็นเสียงคำรามที่ประกาศการเข้าสู่ยุคใหม่ของอุตสาหกรรมการพัฒนาซอฟต์แวร์ทั้งหมด

บทความนี้มาจาก微信号 “极客公园” (ID: geekpark) โดยผู้เขียน: ยูฮังยวน