Red Squares แสดงเหตุขัดข้องของ GitHub เป็นการมีส่วนร่วม
(red-squares.cian.lol)- Red Squares ล้อเลียนกราฟการมีส่วนร่วมจากคอมมิตของ GitHub โดยแสดงเหตุขัดข้องของแพลตฟอร์ม GitHub.com เป็นช่องสีแดงแทนช่องสีเขียว
- ช่องสีแดง แต่ละช่องหมายถึงหนึ่งวันที่ GitHub ประสบเหตุขัดข้อง และยิ่งสีเข้มก็ยิ่งหมายถึงวันที่เหตุขัดข้องกินเวลานานกว่า
- ตลอด 1 ปีที่ผ่านมา มีการนับรวมดาวน์ไทม์ของ GitHub ได้ทั้งหมด 32.5 วัน
- จำนวนวันที่มีอินซิเดนต์อย่างน้อย 1 ครั้ง คือ 167 วัน
- วันที่เลวร้ายที่สุดคือ วันพฤหัสบดีที่ 30 เมษายน 2026 โดยมีดาวน์ไทม์ยาวนานถึง 1.0 วัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ทุกครั้งที่มี เว็บมีม vibe coding แบบนี้โผล่ขึ้นมา ก็จะมีคอมเมนต์ตามมาไม่รู้จบว่าต้นเหตุจริงไม่ใช่โหลด แต่เป็นเพราะทีม GitHub, เทคสแตก, Microsoft และ Azure แย่กันเอง
ถ้าเทียบหน้าแสดงสถานะสาธารณะของ GitHub กับหน้า Enterprise Cloud จะเห็นว่าฝั่ง Enterprise ตัวเลขดีกว่ามาก และส่วนตัวก็นึกไม่ออกว่าครั้งสุดท้ายที่ระบบล่มจนทำงานต่อไม่ได้จริง ๆ คือเมื่อไร
ถ้าปัญหาไม่ได้เกี่ยวกับโหลด ก็น่าจะเห็นปัญหา uptime แบบเดียวกันในผลิตภัณฑ์ Enterprise ด้วย
โดยเฉพาะเมื่อเป็นบริษัทที่มีทรัพยากรมากกว่าหลายประเทศและมีบุคลากรเทคนิคระดับโลก การวิจารณ์ระบบก็ยิ่งสมเหตุสมผล
เทคสแตกของ GitHub เองก็ไม่ได้ดีจริง และยังปกป้องมันแบบค่อนข้างหยิ่งมานาน
Azure เป็นแพลตฟอร์มที่แย่มาก แต่กลับถูกยัดเยียดให้ทีมใช้งาน และก็เคยเห็นท่าทีตั้งการ์ดทั้งเรื่องการเลือก relational database และการเขียน frontend ใหม่
เปิดเว็บให้เสถียรยังทำไม่ได้ แต่กลับไปเขียน UI ใหม่และดันเครื่องมือ AI ถือเป็นการเสียเวลา
นี่ไม่ใช่การโจมตีวิศวกรรายบุคคล แต่เป็นการวิจารณ์ การตัดสินใจของผู้บริหาร ที่ให้ความสำคัญกับฟีเจอร์ใหม่หรือการเอาใจเจ้าของ มากกว่าผลิตภัณฑ์หลักของระบบที่กลายเป็นกึ่งผูกขาดจาก network effect
หน้าสถานะสามารถถูกใช้เป็นหลักฐานที่เสียเปรียบต่อบริษัทได้ ดังนั้นการเอามาเทียบกันเองจึงไม่ค่อยมีความหมาย
หลายครั้งที่ในความเป็นจริงคือระบบล่ม แต่ในภาษาการตลาดจะเรียกว่า “ประสิทธิภาพลดลง” และหน้าสถานะที่ดำเนินการอย่างอิสระมีประโยชน์กว่ามาก
ไม่ได้เกิดทุกวัน แต่แทบจำไม่ได้เลยว่าที่บริษัทจะผ่านไปได้หนึ่งสัปดาห์โดยไม่ต้องหาทางอ้อมปัญหาระบบล่ม
ส่วนใหญ่ยังพอ “ทำงาน” ต่อได้ แต่ถ้าไม่มีปัญหา งานที่ควร build หรือ deploy เสร็จในเวลาเดิมก็จะล่าช้า ดังนั้นส่วนตัวมองว่าโดน ผลกระทบ อย่างน้อยสัปดาห์ละครั้ง
ไม่อย่างนั้นอย่างน้อยก็ควรติดคำเตือนตัวใหญ่ด้านบนว่า “ใช้ได้แค่งานอดิเรก”
ตอบในเธรดเดิมได้ แต่สร้างเธรดใหม่ไม่ได้ และมันก็ขึ้นอยู่ในหน้าสถานะแล้ว
ไม่รู้เลยว่าเรื่องแบบนี้ผ่านออกมาได้ยังไง และก็ยากจะเข้าใจว่าทำไมมันยังยืดมาชั่วโมงกว่าแล้ว
แถมยังบอกอีกว่าต้องใช้เวลาอีก 3–4 ชั่วโมงกว่าจะแก้เสร็จ ช่างใจดีจริง ๆ
การโทษ GitHub แม้แต่เรื่อง ประสิทธิภาพของโมเดลภายนอกลดลง อย่าง Gemini 2.5 Pro, Grok Code Fast 1 in Copilot, Claude Opus 4 ก็ดูไม่ค่อยยุติธรรม
รู้สึกว่านี่เป็นปัญหาที่ GitHub ทำอะไรไม่ได้อยู่แล้วหรือเปล่า
พอลบระดับความรุนแรงทิ้งไป ก็ย่อทุกอย่างให้เหลือแค่ “GitHub ล่ม” หรือกราฟ uptime
ฉันเองก็ไม่พอใจกับเหตุขัดข้องใหญ่ของ GitHub ช่วงหลัง แต่การทำให้เส้นแบ่งระหว่างบริการย่อยสะดุดกับเว็บทั้งเว็บล่มพร่ามัว เพื่อให้ดูดราม่าขึ้น และใช้เป็น เว็บเรียกความสนใจ หรือโพสต์โซเชียลเพื่อปั่นคำแนะนำ ไลก์ คาร์มา และความสนใจ มันไม่น่าดูเลย
เหมือนแค่อยากทำให้กราฟแดงที่สุดเท่าที่จะทำได้
เรารันบริการที่เล็กกว่า GitHub มาก แต่ยังเตรียม เส้นทางสำรอง ไว้กับหลายผู้ให้บริการและหลายโมเดล
วันหยุดสุดสัปดาห์ยังเป็น frontier ที่ยังไม่ถูกบุกเบิก
ยังมีพื้นที่ให้ขยายได้อีก
เหตุขัดข้องกินพื้นที่ 62% ของวันธรรมดา และ 11% ของวันหยุด ส่วน Claude ก็คล้ายกันคือวันธรรมดา 92.5% วันหยุด 97.8%
ช่วงอันตรายคือวันอังคารถึงพฤหัสบดี และวันอาทิตย์ดูแทบเหมือนเป็นคนละบริการ
https://www.aakash.io/tech-chase/github-and-claude-are-down-...
ผมยังสงสัยก่อนเลยว่ากราฟนี้แม่นแค่ไหน
มันขึ้นว่า “170 วันที่มีเหตุขัดข้องอย่างน้อยหนึ่งครั้ง · วันที่แย่ที่สุดคือวันพฤหัสบดี 20 พฤศจิกายน 2025, 1.1 วัน” ซึ่งผมไม่เข้าใจว่าในหนึ่งวันจะรวมกันเป็น 1.1 วัน ได้ยังไง
พอเอาเมาส์ไปชี้วันที่นั้นก็ไม่เห็นวิธีคำนวณภายใน และรายการเดี่ยวกลับแสดงเป็น 1.3 ชั่วโมง
ส่วนวันที่ 19 พฤศจิกายนมีรายการเหตุขัดข้อง 1.3 วัน แต่ยอดรวมกลับแสดงเป็น 8.1 ชั่วโมง
ในวันนั้นมันถูกแสดงเป็นเหตุขัดข้องเล็กน้อยยาว 24 ชั่วโมง
ส่วนเว็บนี้ดูเหมือนจะเอา downtime ของทุกบริการในหนึ่งวันมาบวกกัน ซึ่งถ้าเป็นแบบนั้น วันแย่ที่สุดก็อาจรวม downtime ได้ถึง 10 วัน เมื่อบวกตามหมวดหลักต่าง ๆ
1: https://mrshu.github.io/github-statuses/
ฉันไม่ได้เช็กว่ามี downtime จริงในวันนั้นหรือเปล่า แต่ถ้าสมมติว่าตัวเลขถูกต้อง 7.8 ชั่วโมงบวก 1 วันก็ประมาณ 1.3 วัน พอดี
ความต่างระหว่างหน้าสถานะทางการ [0] กับหน้าสถานะของบุคคลที่สาม [1] ใหญ่มาก
ถ้าต่างจากสภาพการใช้งานจริงของผลิตภัณฑ์ขนาดนี้ ก็อดสงสัยไม่ได้ว่าเงื่อนไข SLA ยังถือว่าถูกกฎหมายได้อย่างไร
ฉันชอบทั้ง GitHub และบริการของมัน แต่ทุกครั้งที่ของจริงพังอยู่แต่หน้าสถานะยังเขียวล้วน มันทำให้รู้สึกเดือดข้างใน
[0] https://www.githubstatus.com/
[1] https://mrshu.github.io/github-statuses/
ที่ทำงานล่าสุดของฉันเจอเหตุ GitHub ล่มหลายครั้งที่ไม่ได้ถูกบันทึกไว้ในหน้าสถานะ และเราก็เก็บ log ไว้ผ่านการค้นหาใน Slack
หลังจากนั้นฝั่งธุรกิจก็ไปเถียงกับ account manager ของ GitHub จนได้เครดิตคืนมาหลายร้อยดอลลาร์
แต่พวกเขาก็บ่นว่าเครดิตไม่กี่ร้อยดอลลาร์นั้นไม่คุ้มกับเวลาที่เสียไป ดังนั้น uptime ที่ต่ำของ GitHub ก็ยังคงอยู่ต่อไปโดยไม่มีอะไรเกิดขึ้น
ขณะที่หน้าของบุคคลที่สามอาจนับแม้แต่เหตุขัดข้องหรือปัญหาของโมเดลเดียวว่าเป็นปัญหาของ GitHub จึงอาจต่างจากประสบการณ์ใช้งานจริงได้
วันหยุดสุดสัปดาห์มีเหตุขัดข้องน้อยกว่ามาก
ก็ดีอยู่แล้ว เพราะยังไงตอนนั้นก็ไม่ได้คิดจะทำงาน
ไอเดียนี้มีมานานแล้ว
ตอนเดือนมกราคมฉันทำสิ่งนี้ขึ้นมาเพื่อแยกดู uptime ตามหมวดของเหตุขัดข้อง
https://isgithubcooked.com
การที่แทบไม่มี downtime ในวันหยุดสุดสัปดาห์ ทำให้มันดูคล้าย กราฟ contribution มากจนขำ