บริการ GitHub.com หยุดชะงัก (github.com/status) 1 คะแนน โดย GN⁺ 2023-06-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp บทความที่เกี่ยวข้อง เหตุขัดข้องของบริการ GitHub หลายรายการ 2 คะแนน · 1 ความคิดเห็น · 2026-04-25 GitHub เกิดเหตุขัดข้องอีกครั้ง 1 คะแนน · 2 ความคิดเห็น · 2026-02-10 อัปเดตเกี่ยวกับความพร้อมใช้งานของ GitHub 2 คะแนน · 2 ความคิดเห็น · 2026-04-29 GitHub ยกเลิกฟีเจอร์โฆษณาใน Pull Request ของ Copilot หลังถูกต่อต้าน 1 คะแนน · 2 ความคิดเห็น · 2026-04-01 Azure ขัดข้อง 1 คะแนน · 1 ความคิดเห็น · 2025-10-30 1 ความคิดเห็น GN⁺ 2023-06-30 ความคิดเห็นบน Hacker News การแยก หน้าสถานะ ไปไว้อีกโดเมนหนึ่งเพื่อเรื่องความพร้อมใช้งานนั้นเป็นเรื่องดี แต่ถ้าโดเมนหลักล่มแล้วไม่อัปเดตหน้าสถานะนั้นด้วยก็ไม่ค่อยดีเท่าไร ชอบฝั่ง https://downdetector.com มากกว่า เพราะผู้ใช้โหวตกันเองได้ และอย่างน้อยเท่าที่เห็นก็ไม่มีการกรองจากฝั่งบริษัท https://downdetector.com/status/github/ https://www.githubstatus.com/ หน้าแบบนั้นถูก อัปเดตด้วยมือ บ่อยกว่าที่คิด แถมมักเป็นหน้าที่ของคนออนคอลที่มีงานเร่งด่วนอื่นต้องทำก่อน คิดถึงหน้าสถานะแบบเก่า: https://web.archive.org/web/20170110044141/https://status.gi... เป็นไปได้ว่าระบบที่ใช้สำหรับอัปเดตหน้าสถานะก็ล่มไปด้วย เหมือนปัญหาแบบนี้จะเกิดแทบทุก 2 สัปดาห์ เลย เดี๋ยวนี้ GitHub เป็นอะไรไป? ดูเหมือนจะเพิ่มฟีเจอร์ใหม่อย่าง Copilot แต่ไม่ได้ลงทุนกับ ความเชื่อถือได้ของเว็บไซต์ มากพอ ถ้าไม่มีการเปลี่ยนแปลง แค่แก้บั๊กให้ดีก็รักษาเสถียรภาพได้ค่อนข้างง่าย การเปลี่ยนแปลงหรือฟีเจอร์ใหม่ย่อมนำบั๊กใหม่และโหลดใหม่มาด้วย คงมีใครลืมใส่ node_modules ไว้ใน .gitignore หรือคนที่เข้ากับสไตล์การบริหารแบบ Microsoft ไม่ได้คงไปหางานใหม่กันแล้ว? กำลังทดสอบ gpt4-ops อยู่หรือเปล่า? ความไร้ความสามารถของ Microsoft + DDoS? การเอาโอเพนซอร์สทั้งหมดของเราไปกองไว้ที่เดียวอาจไม่ใช่ความคิดที่ดี >_< เอาเข้าจริงสิ่งที่เปลี่ยนไปอาจมีแค่ว่า วันหนึ่งเราจะคิดว่า “น่าจะอยู่อีกฝั่งมากกว่า” ถ้า 1% ของทั้งหมดล่มตลอดเวลา เทียบกับ 100% ของทั้งหมดล่ม 1% ของเวลา ในเชิงความรู้สึกมีแบบที่ดูดีกว่าอยู่ แต่ในทางปฏิบัติอันไหนดีกว่ากันก็ไม่แน่ใจ แน่นอนว่าถ้าอยากก็ทำมิเรอร์ได้ แต่ตอนนี้ก็ทำได้อยู่แล้ว เลยไม่ใช่ประเด็นหลักของเรื่องนี้ ประเด็นของ ระบบควบคุมเวอร์ชันแบบกระจาย คือทุกคนที่ git clone จะมีสำเนาที่สมบูรณ์ของทั้งรีโพซิทอรี และทำงานส่วนใหญ่ได้โดยไม่ต้องคุยกับเซิร์ฟเวอร์กลาง ดาวน์ไทม์สั้น ๆ จึงมักกระทบโครงสร้างพื้นฐานรอบ ๆ โค้ดจริงมากกว่า เช่น เวิร์กโฟลว์, อีชู ฯลฯ พูดตามตรง การรวมอยู่ที่เดียวน่าจะดีกว่า อย่างน้อยทั้งวงการหยุดพร้อมกันก็ดีกว่าต่างคนต่างหยุดกันคนละเวลา คล้ายตอน us-east-1 ล่ม ทุกคนลงเรือลำเดียวกัน ก็พักพร้อมกันได้ และมีข้ออ้างดี ๆ ให้ชิลได้สักพัก เอาโค้ดบริษัททั้งหมดไปไว้ที่นั่นถือว่าเป็นความคิดที่ดี ได้พักฟรี จุดขายหลักของ GitHub ไม่เคยเป็นเรื่อง ความกระจายศูนย์ ตอนสมัครใช้ในปี 2008 มันใกล้เคียงกับ โซเชียลเน็ตเวิร์ก ที่นักพัฒนามาเจอกันมากกว่า เหมือนจะกลับมาแล้ว อยากเห็น การวิเคราะห์เชิงลึก ของเหตุขัดข้องช่วงหลัง ๆ และอยากได้ความมั่นใจว่าจะให้ความสำคัญกับเสถียรภาพก่อนฟีเจอร์ใหม่ ไม่กี่เดือนก่อนเคยคุยกับคนฝั่งซัพพอร์ตลูกค้า ซึ่งเขาแทบโทษว่าความเสถียรที่ตกลงมาจากงานคัสตอมสารพัดที่ทำให้ลูกค้ารายใหญ่ สรุปแล้วดูเหมือนหนี้เทคนิคจะกองมหาศาล ถ้าจะรันอินสแตนซ์ GitHub Enterprise ต้องใช้ RAM ราว 64GB เป็นสัตว์ประหลาดตัวหนึ่งเลย https://github.blog/2023-05-16-addressing-githubs-recent-ava... งานคัสตอมพวกนั้นอาจทำให้เกิดข้อผิดพลาดหรือบางฟีเจอร์ใช้การไม่ได้ แต่การที่ทั้งเว็บไซต์ล่ม โดยเฉพาะแม้แต่คอนเทนต์แบบสแตติกอย่าง GH Pages ยังล่มด้วย นั่นเป็นปัญหา SRE ล้วน ๆ มีแนวโน้มว่าจะเป็นเรื่อง network routing หรือความผิดพลาดอื่นที่ชั้น 4 หรือต่ำกว่า มากกว่าการเปลี่ยนแปลงระดับแอปพลิเคชัน การเปลี่ยนแปลงของแอปส่วนใหญ่มักปล่อยแบบทยอยและแบบ canary และถ้ามีปัญหาก็มัก rollback ได้ค่อนข้างเร็ว ดูเหมือนเหตุขัดข้องนี้จะกระทบ GitHub Pages ด้วย หน้า .github.io แสดงหน้า unicorn 503 We're having a really bad day. The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running. โอ้โห ตอนนี้แม้แต่หน้าสถานะก็ยังเปิดไม่ได้ เหมือนทั้งเว็บล่มหมด และจำไม่ได้แล้วว่าครั้งสุดท้ายที่ล่มทั้งยวงแบบนี้คือเมื่อไร ฝั่งผมหน้าสถานะยังเปิดได้ แต่ดันแสดงว่าทุกอย่างปกติ: https://www.githubstatus.com/ คนอื่นใช้อะไรเพื่อแยกตัวเองออกจากปัญหาแบบนี้บ้าง? การเพิ่ม แคช สำหรับงานอ่านก็ดูเป็นความคิดที่ฉลาดและยังช่วยเรื่องประสิทธิภาพด้วย ถ้าใครมีกรณีที่หลบผลกระทบได้สำเร็จก็อยากให้แชร์ ที่ทำงานเก่า การตั้งค่า “GitOps” ขององค์กรหนึ่งทำมิเรอร์ GitLab ไปที่ AWS CodeCommit แล้วใช้ที่นั่นเป็นแหล่งความจริงเดียวของระบบอัตโนมัติ การตัดสินใจนั้นพิสูจน์แล้วว่าฉลาดหลายครั้ง และจำไม่ได้ว่าเคยเจอปัญหาชัดเจนกับ CodeCommit แต่ถ้าในกระบวนการพัฒนาจริงยังใช้ GitHub เป็น forge ใช้ issue tracker หรือ PR สำหรับรีวิว ก็นึกไม่ออกเหมือนกันว่าจะกันตัวเองออกจากมันได้ดีอย่างไร ที่ทำงานก่อนหน้านี้มี GitHub Enterprise แบบโฮสต์ในเครื่องเอง และทุกครั้งที่คนใน Twitter บ่นว่า “github ล่ม! วันนี้เลิกงานเร็ว!” ก็รู้สึกน้อยใจตลอด :( แน่นอนว่าถ้ามีเครื่องมือบางตัวบังคับให้อัปเดต dependency ที่อยู่บน GitHub ปกติก็ยังน่าหงุดหงิดอยู่ดี แต่อย่างน้อยงานพวกดีพลอยก็ยังทำต่อได้ พักไปกินกาแฟ git ถูกออกแบบมาให้ใช้แบบออฟไลน์ได้ตั้งแต่แรกอยู่แล้ว ก็ใช้ local clone ที่มีอยู่ https://www.githubstatus.com/ ยังเป็นสีเขียวทั้งหมดอยู่ หน้าสถานะเพิ่งเปลี่ยน: Investigating - We are currently experiencing an outage of GitHub products and are investigating. Jun 29, 2023 - 17:52 UTC แม้แต่อ่านอย่างเดียวก็แดงหมด น่าจะเป็นครั้งแรกที่เห็น ทุกรายการเป็นสีแดงทั้งหมด บนหน้าสถานะ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
https://downdetector.com/status/github/
ถ้าไม่มีการเปลี่ยนแปลง แค่แก้บั๊กให้ดีก็รักษาเสถียรภาพได้ค่อนข้างง่าย การเปลี่ยนแปลงหรือฟีเจอร์ใหม่ย่อมนำบั๊กใหม่และโหลดใหม่มาด้วย
node_modulesไว้ใน.gitignoreถ้า 1% ของทั้งหมดล่มตลอดเวลา เทียบกับ 100% ของทั้งหมดล่ม 1% ของเวลา ในเชิงความรู้สึกมีแบบที่ดูดีกว่าอยู่ แต่ในทางปฏิบัติอันไหนดีกว่ากันก็ไม่แน่ใจ แน่นอนว่าถ้าอยากก็ทำมิเรอร์ได้ แต่ตอนนี้ก็ทำได้อยู่แล้ว เลยไม่ใช่ประเด็นหลักของเรื่องนี้
git cloneจะมีสำเนาที่สมบูรณ์ของทั้งรีโพซิทอรี และทำงานส่วนใหญ่ได้โดยไม่ต้องคุยกับเซิร์ฟเวอร์กลางดาวน์ไทม์สั้น ๆ จึงมักกระทบโครงสร้างพื้นฐานรอบ ๆ โค้ดจริงมากกว่า เช่น เวิร์กโฟลว์, อีชู ฯลฯ
คล้ายตอน us-east-1 ล่ม ทุกคนลงเรือลำเดียวกัน ก็พักพร้อมกันได้ และมีข้ออ้างดี ๆ ให้ชิลได้สักพัก
ไม่กี่เดือนก่อนเคยคุยกับคนฝั่งซัพพอร์ตลูกค้า ซึ่งเขาแทบโทษว่าความเสถียรที่ตกลงมาจากงานคัสตอมสารพัดที่ทำให้ลูกค้ารายใหญ่ สรุปแล้วดูเหมือนหนี้เทคนิคจะกองมหาศาล
มีแนวโน้มว่าจะเป็นเรื่อง network routing หรือความผิดพลาดอื่นที่ชั้น 4 หรือต่ำกว่า มากกว่าการเปลี่ยนแปลงระดับแอปพลิเคชัน การเปลี่ยนแปลงของแอปส่วนใหญ่มักปล่อยแบบทยอยและแบบ canary และถ้ามีปัญหาก็มัก rollback ได้ค่อนข้างเร็ว
.github.ioแสดงหน้า unicorn 503การตัดสินใจนั้นพิสูจน์แล้วว่าฉลาดหลายครั้ง และจำไม่ได้ว่าเคยเจอปัญหาชัดเจนกับ CodeCommit แต่ถ้าในกระบวนการพัฒนาจริงยังใช้ GitHub เป็น forge ใช้ issue tracker หรือ PR สำหรับรีวิว ก็นึกไม่ออกเหมือนกันว่าจะกันตัวเองออกจากมันได้ดีอย่างไร
แน่นอนว่าถ้ามีเครื่องมือบางตัวบังคับให้อัปเดต dependency ที่อยู่บน GitHub ปกติก็ยังน่าหงุดหงิดอยู่ดี แต่อย่างน้อยงานพวกดีพลอยก็ยังทำต่อได้
gitถูกออกแบบมาให้ใช้แบบออฟไลน์ได้ตั้งแต่แรกอยู่แล้ว ก็ใช้ local clone ที่มีอยู่Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC