อัปเดตเกี่ยวกับความพร้อมใช้งานของ GitHub

• หลังจาก เหตุขัดข้องสองครั้งล่าสุด GitHub กำลังให้ความพร้อมใช้งานเป็นสิ่งสำคัญสูงสุด และกำลังปรับโครงสร้างพื้นฐานกับสถาปัตยกรรมใหม่ให้สอดรับกับภาระงานพัฒนาที่พุ่งสูงขึ้นและ agentic development workflows
• pull request เพียงหนึ่งรายการเชื่อมโยงกว้างไปถึง Git repository, Actions, การค้นหา, การแจ้งเตือน, สิทธิ์, webhooks, APIs, งานเบื้องหลัง, แคช และฐานข้อมูล ดังนั้นเมื่อความไม่มีประสิทธิภาพเล็กน้อยสะสมมากขึ้น ก็อาจนำไปสู่ คิวค้างสะสม และ การลามของการพึ่งพา ได้
• ในระยะสั้น บริษัทกำลังมุ่งลดคอขวดและภาระฐานข้อมูลผ่าน การย้ายแบ็กเอนด์ ของ webhooks, การออกแบบแคชเซสชันผู้ใช้ใหม่, การปรับ flow การยืนยันตัวตนและการให้สิทธิ์ รวมถึงการขยายคอมพิวต์บน Azure
• ในระยะยาว บริษัทกำลังเพิ่มความทนทานและความยืดหยุ่นผ่าน การแยกบริการหลัก, การลด single point of failure, การย้ายบางส่วนของ Ruby monolith ไปยัง Go และการย้ายสู่ public cloud พร้อมเปิดทางสู่ multi cloud
• ทั้งกรณี merge queue regression เมื่อ 23 เมษายน และ Elasticsearch overload เมื่อ 27 เมษายน ไม่มีการสูญหายของข้อมูล และ GitHub ก็กำลังเสริมความโปร่งใสไปพร้อมกันด้วยการใส่ตัวเลข availability ลงใน status page และขยายการเปิดเผยให้ครอบคลุมเหตุขัดข้องขนาดเล็กด้วย

---

เบื้องหลังการรับมือด้านความพร้อมใช้งาน

• หลังจาก เหตุขัดข้องสองครั้งล่าสุด GitHub ได้สรุปความคืบหน้าของงานปรับปรุงด้านความพร้อมใช้งานและความน่าเชื่อถือ
• ตั้งแต่เดือนตุลาคม 2025 บริษัทได้ดำเนิน แผนขยายความจุ 10 เท่า และในเดือนกุมภาพันธ์ 2026 ก็ชัดเจนว่าจำเป็นต้องออกแบบโดยสมมติขนาดระดับ 30 เท่าของปัจจุบัน
• ปัจจัยสำคัญคือการเปลี่ยนแปลงของวิธีพัฒนาซอฟต์แวร์ โดยหลังครึ่งหลังของปี 2025 agentic development workflows ได้เร่งตัวขึ้นอย่างมาก
• การสร้าง repository, กิจกรรม pull request, ปริมาณการใช้ API, งานอัตโนมัติ และภาระงานของ repository ขนาดใหญ่ ต่างเพิ่มขึ้นอย่างรวดเร็ว

ภาระเชิงโครงสร้างที่ปรากฏระหว่างการขยายระบบ

• pull request หนึ่งรายการอาจไปแตะทั้ง Git repository, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches และ databases พร้อมกัน
• เมื่ออยู่ในระดับขนาดใหญ่ ความไม่มีประสิทธิภาพเล็กน้อยสามารถสะสมจนกลายเป็น คิวค้างสะสม, การเปลี่ยนภาระจาก cache miss ไปลงฐานข้อมูล, ความล่าช้าในการทำดัชนี, การขยายตัวของทราฟฟิกจากการ retry และผลกระทบข้ามหลายผลิตภัณฑ์จาก dependency ที่ช้า
• ลำดับความสำคัญถูกจัดเป็น ความพร้อมใช้งานก่อน จากนั้นจึงเป็นความจุ และค่อยเป็นฟีเจอร์ใหม่
• บริษัทกำลังทำควบคู่กันทั้งการลดงานที่ไม่จำเป็น, ปรับปรุงแคช, แยกบริการหลัก, กำจัด single point of failure และย้ายเส้นทางที่ไวต่อประสิทธิภาพไปยังระบบเฉพาะทาง
• โจทย์สำคัญคือการลด การเชื่อมโยงแฝง จำกัด blast radius และทำให้เกิด graceful degradation เพื่อไม่ให้ทั้งระบบล้มตามกันเมื่อมีแรงกดดันที่ subsystem ใด subsystem หนึ่ง

งานปรับปรุงที่กำลังดำเนินอยู่

• ในระยะสั้น บริษัทกำลังมุ่งแก้คอขวดที่ปรากฏเร็วเกินคาด
• บริษัทได้ ย้าย webhooks ออกจาก MySQL ไปยังแบ็กเอนด์อื่น, ออกแบบแคชเซสชันผู้ใช้ใหม่ และปรับ flow การยืนยันตัวตนและการให้สิทธิ์อีกครั้ง เพื่อลดภาระฐานข้อมูลลงอย่างมาก
• บริษัทยังใช้การย้ายสู่ Azure เพื่อจัดหา ทรัพยากรคอมพิวต์เพิ่มเติม
• จากนั้นจะเน้นที่ การแยกบริการหลัก เช่น git และ GitHub Actions รวมถึงการลด single point of failure
• บริษัทได้วิเคราะห์ dependency และชั้นของทราฟฟิกอย่างละเอียดเพื่อดูว่าควรแยกอะไรออก และดำเนินการตามลำดับความเสี่ยงเพื่อลดผลกระทบของการโจมตีประเภทต่าง ๆ ต่อทราฟฟิกปกติให้เหลือน้อยที่สุด
• งานย้ายบางส่วนของโค้ดที่ไวต่อประสิทธิภาพหรือสเกล จาก Ruby monolith ไปยัง Go ก็เร่งดำเนินมากขึ้นเช่นกัน
• ระหว่างที่กำลังย้ายจาก data center ภายในขนาดเล็กเดิมไปยัง public cloud บริษัทก็เริ่มผลักดัน เส้นทาง multi cloud ไปพร้อมกันในระยะยาว
• มาตรการระยะยาวนี้จำเป็นต่อการสร้างความทนทาน, latency ต่ำ และความยืดหยุ่นที่ต้องใช้ในอนาคต

การรับมือ repository ขนาดใหญ่และ merge queue

• บริษัทมองว่า การเพิ่มขึ้นของ monorepo ขนาดใหญ่ เป็นโจทย์การขยายที่ยากกว่าการเพิ่มขึ้นของจำนวน repository
• ในช่วง 3 เดือนที่ผ่านมา บริษัทได้เพิ่มการลงทุนอย่างมากเพื่อรับมือแนวโน้มนี้ทั้งในระบบ git และประสบการณ์ pull request
• ยังมีงานเกี่ยวกับ การออกแบบ API ใหม่ เพื่อเพิ่มประสิทธิภาพและความสามารถในการขยาย ซึ่งจะเผยแพร่ในบล็อกโพสต์แยกต่างหาก
• บริษัทยังลงทุนกับ การปรับงานของ merge queue ให้เหมาะสม เพราะมีความสำคัญต่อ repository ที่มี pull request หลายพันรายการต่อวัน

เหตุขัดข้องล่าสุด 1: ปัญหา merge queue วันที่ 23 เมษายน

• วันที่ 23 เมษายน เกิด regression ของการทำงาน merge queue ใน pull request
• ใน merge queue ที่ใช้วิธี squash merge หากมี pull request มากกว่าหนึ่งรายการอยู่ใน merge group จะเกิด merge commit ที่ไม่ถูกต้อง
• ในกรณีที่ได้รับผลกระทบ การ merge หลังจากนั้นจะทำให้เกิดสภาพที่เผลอย้อนการเปลี่ยนแปลงของ pull request ที่ merge ไปก่อนหน้าและ commit เดิมโดยไม่ตั้งใจ
• ในช่วงที่ได้รับผลกระทบ มี 658 repository และ 2,092 pull request ได้รับผลกระทบ
• ตัวเลขเริ่มต้นถูกประเมินแบบเผื่อไว้ จึงทำให้ตัวเลขที่แชร์ในตอนแรกสูงกว่านี้เล็กน้อย
• pull request ที่ merge นอก merge queue ไม่ได้รับผลกระทบ และกลุ่ม merge queue ที่ใช้วิธี merge หรือ rebase ก็ไม่ได้รับผลกระทบเช่นกัน
• ไม่มีการสูญหายของข้อมูล ทุก commit ยังคงถูกเก็บอยู่ใน Git
• อย่างไรก็ตาม สถานะของ default branch ใน repository ที่ได้รับผลกระทบไม่ถูกต้อง และไม่สามารถกู้คืนทุก repository แบบอัตโนมัติและปลอดภัยได้
• incident root cause analysis: สามารถดูรายละเอียดเพิ่มเติมได้
• เหตุขัดข้องครั้งนี้เผยให้เห็น ความล้มเหลวของกระบวนการ หลายจุด และบริษัทกำลังปรับเปลี่ยนกระบวนการเหล่านั้นเพื่อไม่ให้ปัญหาประเภทเดียวกันเกิดซ้ำ

เหตุขัดข้องล่าสุด 2: ปัญหาที่เกี่ยวข้องกับการค้นหาในวันที่ 27 เมษายน

• วันที่ 27 เมษายน เกิดเหตุขัดข้องใน subsystem ของ Elasticsearch ที่รับผิดชอบประสบการณ์หลายส่วนที่อิงกับการค้นหา
• ขอบเขตผลกระทบรวมถึง UI ที่อิงการค้นหาบางส่วนของ pull requests, issues และ projects
• การวิเคราะห์สาเหตุรากยังอยู่ระหว่างการสรุปและจะเผยแพร่ในเร็ว ๆ นี้
• จากที่ทราบจนถึงขณะนี้ cluster อยู่ในสถานะ overload และทำให้ไม่สามารถส่งคืนผลการค้นหาได้
• สำหรับสาเหตุของ overload ยังเปิดความเป็นไปได้ว่าอาจเป็น botnet attack แต่การวิเคราะห์สาเหตุรากยังไม่เสร็จสมบูรณ์
• ไม่มีการสูญหายของข้อมูล และ งาน Git กับ APIs ไม่ได้รับผลกระทบ
• อย่างไรก็ตาม UI บางส่วนที่พึ่งพาการค้นหาไม่สามารถแสดงผลลัพธ์ได้เลย จนทำให้เกิดความสับสนอย่างมาก
• ระบบนี้เป็นพื้นที่ที่การแยกอย่างสมบูรณ์เพื่อกำจัด single point of failure ยังไม่เสร็จสิ้น และก่อนหน้านั้นพื้นที่อื่นมีลำดับความเสี่ยงสูงกว่า
• บริษัทกำลังนำการวิเคราะห์ dependency และการลด blast radius แบบเดียวกันมาใช้ เพื่อลดทั้งโอกาสและผลกระทบของความล้มเหลวลักษณะนี้

การเพิ่มความโปร่งใสเรื่องเหตุขัดข้อง

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

คำมั่นสัญญาต่อจากนี้

• GitHub ให้คำมั่นเรื่อง การปรับปรุงความพร้อมใช้งาน, การเพิ่มความทนทาน, การขยายระบบให้รองรับขนาดของการพัฒนาซอฟต์แวร์ในอนาคต และการสื่อสารที่โปร่งใสมากขึ้น
• จำนวน repository ที่ได้รับผลกระทบจากเหตุขัดข้องวันที่ 23 เมษายน ได้รับการอัปเดต ณ วันที่ 28 เมษายน 2026

[xguru]

เพราะมีเออร์เรอร์เยอะเกินไป เลยรีบออกประกาศกันแบบนี้สินะ
แต่ก็อดคิดไม่ได้ว่ามันช้าไปหน่อยหรือเปล่า..
ตอนนี้เออร์เรอร์มันเยอะมากจนทุกคนพูดกันว่าเริ่มหนีออกไปกันแล้ว ฮือ

[GN⁺]

ความคิดเห็นจาก Hacker News

• GitHub ล่มไปแล้ว หลายสิบครั้ง แค่นับตั้งแต่ต้นปีนี้ และเรื่อง availability กับ reliability ก็แย่ลงอย่างเห็นได้ชัดเมื่อเทียบกับปีก่อน
  ระดับนี้ถึงขั้นควรมีแดชบอร์ดกับ heatmap เฉพาะได้เลย และในที่อย่าง HN หรือ Reddit ก็รู้สึกว่า ความไม่เสถียรของ GitHub กลายเป็นมีมไปแล้ว
  ทั้งที่เป็นแบบนั้นก็ยังพูดว่าลำดับความสำคัญคือ "availability, capacity, new features" ซึ่งดูห่างไกลจากความเป็นจริงเกินไป
  ตอนนี้ลำดับความสำคัญข้อ 1, 2, 3 ควรเป็น availability ทั้งหมด และอย่างน้อย 6 เดือนก็ควรหยุดพูดเรื่องอื่นแล้วโฟกัสแก้เรื่องนี้อย่างเดียว

• เมื่อ 6 เดือนก่อนยังบอกว่า การย้ายไป Azure คือเรื่องสำคัญที่สุดเลยต้องชะลอการพัฒนาฟีเจอร์ แต่ตอนนี้กลับบอกว่า availability สำคัญที่สุด ก็เลยฟังดูไม่ค่อยต่อเนื่องกัน
  ตอนนั้นยังบอกด้วยว่าข้อจำกัดด้านความจุของดาต้าเซ็นเตอร์ในเวอร์จิเนียเพราะความต้องการ AI และ Copilot เป็นปัญหาระดับ "existential" แต่พอมาตอนนี้ก็ยังสะดุดกับปัญหาเดิมอยู่ ยิ่งทำให้งงกว่าเดิม
  บอกว่าชะลอการพัฒนาฟีเจอร์ แต่ก็ยังมีฟีเจอร์ใหม่กับการเปลี่ยน UI ออกมาทุกสัปดาห์ และไม่นานมานี้ก็เพิ่งเปลี่ยนมุมมอง issue แบบเดี่ยวอีก
  บริษัทที่มีทรัพยากรระดับ Microsoft ยังติดหล่มอยู่กับเรื่องเดิมซ้ำ ๆ แบบนี้มันน่าเหลือเชื่อมาก และกลยุทธ์ซื้อบริการยอดนิยมของนักพัฒนาแล้วค่อยย้ายทั้งหมดไปแพลตฟอร์มเดียวกันก็ดูน่ากังวลเหมือนกัน

  • มุมมองนี้ก็ดู ตีความในแง่ร้ายเกินไป อยู่เหมือนกัน
    ในองค์กรวิศวกรรมขนาดใหญ่ ลำดับความสำคัญไม่ได้排กันแบบเด็ดขาด และทีมที่ไม่ได้ช่วยเรื่องลำดับความสำคัญหลักโดยตรงก็อาจเดินหน้าทำฟีเจอร์อื่นต่อได้
  • การเปลี่ยน single issues view นั้นดูใกล้เคียงกับการแฮ็กแก้ปัญหาแบบตื่นตระหนกเพื่อบรรเทาปัญหาประสิทธิภาพมากกว่า
    https://news.ycombinator.com/item?id=47912521
  • เป็นไปได้มากเหมือนกันว่า การย้ายไป Azure นี่แหละที่ทำให้ปัญหา availability แย่ลงอีก
    ฮาร์ดแวร์เฉพาะทางมักคาดเดาได้มากกว่าคลาวด์ และการตัดสินใจแบบ "อย่าไป Azure เลย ซื้อ rack เพิ่มอีกไม่กี่ตู้ดีกว่า" อาจไม่ใช่เรื่องที่ผู้บริหาร GitHub จะตัดสินใจเองได้
  • ต่อให้ ตลอด 5 ปีที่ผ่านมาไม่มีการเปลี่ยนฟีเจอร์เลย ก็คงไม่มีใครบ่น แต่กลับยังพยายามรื้อปรับอยู่เรื่อย ๆ
    GitHub ไม่ใช่เว็บที่ต้อง redesign ทุก 5 นาที และบางครั้งก็ดูเหมือนผู้บริหารพยายามยัดฟีเจอร์ใหม่เพียงเพื่อพิสูจน์ว่าตัวเองยังจำเป็น
    ผลคือยิ่งทำพังก็ยิ่งส่งผลเสียต่อการดึงผู้ใช้
    ระบบค้นหาก็โดนเนิร์ฟลงมาก และไม่เข้าใจเหมือนกันว่าทำไมทุกเจ้าถึงชอบทำระบบค้นหาที่เดิมก็ดีอยู่แล้วให้พังลง ทั้ง Google Search และ YouTube ก็เหมือนกัน
    แถม Microsoft ก็มีทั้ง Azure DevOps ที่ดูแทบถูกปล่อยทิ้ง และมี GitHub ด้วย ซึ่งทั้งคู่โดยเฉพาะระบบ ticketing นั้นไม่น่าชอบเลย
    เคยเบื่อ Jira ที่แต่ละโปรเจ็กต์ตั้งค่าไม่เหมือนกันอยู่แล้ว แต่มาตอนนี้ถึงขั้นมีคนพูดว่า "คิดถึง Jira ขึ้นมาเลย"

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

  • กราฟก็ไม่ได้แย่ที่สุดเสียทีเดียว
    ถึงจะไม่มีป้ายกำกับแกนซ้ายล่าง แต่ใจความสำคัญว่าความเร็วในการเติบโตจาก 2023→2024→2025→2026 เร็วมากนั้นก็สื่อออกมาได้
    อ่านได้ประมาณว่าช่วงต้นหรือปลายปี 2026 การเติบโตจะมากกว่ารวม 3 ปีก่อนหน้าด้วยซ้ำ และถึงไม่รู้ตัวเลขบนแกนก็ยังมองเห็นแนวโน้มคร่าว ๆ ได้
    แน่นอนว่าต้องสมมติว่าเป็นกราฟเชิงเส้น แต่ในบริบทนี้ก็ดูเป็นสมมติฐานที่พอรับได้
    ถ้าบริษัทเจอการเติบโตที่มากกว่าที่วางแผนไว้มาก ปัญหาด้านความจุก็ย่อมเกิดขึ้น และตอนนี้ก็ดูเลยจุดที่จะอัดฮาร์ดแวร์เพิ่มอย่างเดียวได้แล้ว น่าจะต้อง เพิ่มประสิทธิภาพ backend มากขึ้น
    เป้าหมายที่เขียนไว้ก็ดูมุ่งไปทางนั้นเป็นส่วนใหญ่
  • มีตัวเลขมากกว่านี้อยู่ที่นี่ด้วย
    https://x.com/kdaigle/status/2040164759836778878
    ไม่แน่ใจว่าเป็นเพราะไม่เชื่อว่าตอนนี้การเติบโตเป็นแบบ exponential หรือมองว่าการโต 10 เท่าต่อปีก็ไม่ใช่เรื่องยากกันแน่
  • อาจต้องบอกว่าเป็นแบบนี้มา ตลอด 6 ปีหลังการเข้าซื้อกิจการ แล้วก็ได้
    https://damrnelson.github.io/github-historical-uptime/
  • สรุปแล้วมันดูเหมือนข้อความประมาณ 300 คำแบบ "เรากำลังรับฟังอยู่"
  • กราฟแต่ง ๆ แบบนี้ลูกค้าหลายเจ้าก็ใช้กันคล้าย ๆ กัน

• พอเห็นประโยคว่า "เริ่มเส้นทาง multi cloud แล้ว" มันฟังเหมือน Microsoft กำลังยอมรับกลาย ๆ ว่า Azure อย่างเดียวให้ความน่าเชื่อถือในระดับที่ต้องการไม่ได้

  • มันดูเป็นสัญญาณที่ค่อนข้างหนัก และถ้าเคยใช้ Azure มาก็พอเข้าใจได้
  • นี่อาจเป็นการตอบสนองที่มุ่งไปยัง ลูกค้าองค์กร ที่เสียเงินเมื่อเกิด downtime
    น่าจะช่วยรักษา retention ได้บ้าง
  • สำหรับระบบซับซ้อนระดับนี้ การหลีกเลี่ยง การพึ่งผู้ให้บริการรายเดียว ก็ถือเป็นเรื่องปกติอยู่แล้ว
  • จำได้ลาง ๆ ว่าเคยเห็นโพสต์ที่นี่เกี่ยวกับ วิสัยทัศน์ Azure ของ Dave Cutler ที่ถูกบิดเพราะเรื่องลำดับความสำคัญ แรงกดดัน และการบริหาร
    เดิมตั้งใจให้การปฏิบัติการแทบไม่ต้องมีมนุษย์เข้าไปยุ่ง แต่ตอนนี้กลับกลายเป็นว่ามีขั้นตอนประจำที่คนต้องไปติด serial กับ rack หรือ VM แล้วลงมือจัดการเอง
    ตอนนี้หา link ไม่เจอแล้ว
  • สำหรับ Show HN นั้น ช่วงเวลาที่โพสต์ สำคัญกว่าที่คิด
    คนอ่านที่ active ที่สุดมักอยู่ช่วงวันจันทร์ถึงพฤหัสบดี เวลา 9–11 โมงเช้า Pacific ส่วนวันหยุดสุดสัปดาห์คู่แข่งน้อยกว่าแต่ engagement ก็ต่ำกว่า

• CTO ของ GitHub ยังอยู่ในบอร์ดของ Codepath.org ด้วย และถ้าคำอธิบายที่นั่นเป็นแนวว่า "สร้างวิศวกร CTO และผู้ก่อตั้งรุ่นแรกที่เป็น AI-native" ก็พอเดาได้คร่าว ๆ ว่าปัญหาอยู่ตรงไหน

• จากที่รู้สึกมา เสถียรภาพของ GitHub แย่ลงมาก และช่วงหลังแม้แต่ข้อมูลที่แสดงบนเว็บก็เชื่อถือยาก
  ตั้งแต่เมื่อวาน ผมกับเพื่อนร่วมงานอีกหลายคนเจอว่ารายการ PR ในหลาย repo แสดงไม่ครบ
  ตัวอย่างเช่นที่ https://github.com/gap-system/gap/pulls แท็บขึ้นว่า "Pull requests 78" แต่ในมุมมองรายการกลับเห็นแค่ "35 open"
  ทั้งที่ยืนยันได้ด้วย gh pr list ว่า 78 คือตัวเลขที่ถูกต้อง แต่ https://www.githubstatus.com ก็ยังแสดงว่า "all systems operational"

  • หลายโปรเจ็กต์ของผมตอนนี้ ไม่เห็น PR ที่ปิดไปในช่วง 6 วันที่ผ่านมา เลยแม้แต่รายการเดียว
    ผ่าน CLI ยังดึงรายการได้ แต่เส้นทางบนเว็บที่ต้องผ่าน search กลับหายหมด
    ทีมซัพพอร์ตยอมรับปัญหานี้แล้ว แต่หลังจากนั้นก็เงียบไป และใน status page ก็ไม่มีอะไรเลยนอกจาก issue ของวันที่ 27 ที่อาจเกี่ยวข้องกัน
    ในบาง repo ดูเหมือนจะหายไปช่วงหนึ่งแล้ว แต่ในหลาย org และ repo ก็ยังเจอซ้ำได้อยู่
    https://github.com/orgs/community/discussions/193388
  • ผมก็เจออาการเดียวกัน และใน status page ก็ยังไม่มีระบุไว้เหมือนเดิม
    PR ที่หายไปต้องไปไล่หาจากหน้า branch ถึงจะเจอ
  • ดูมีความเป็นไปได้สูงว่านี่เป็นการแฮ็กที่ใช้ query แบบประมาณค่า เพื่อให้คืนผลลัพธ์ที่ไม่แม่นยำ 100% เพราะเหตุผลด้าน scalability
    อาจไม่ใช่บั๊กเต็มรูปแบบ แต่เป็นการตัดสินใจด้านผลิตภัณฑ์ที่แย่มากเพื่อกดโหลดของโครงสร้างพื้นฐานลง

• อย่างน้อยการเปิดเผย ข้อมูล repo/issues/commits ใหม่ ในช่วงไม่กี่ปีที่ผ่านมาก็น่าสนใจ
  มันยืนยันสิ่งที่หลายคนเดาจากภายนอกอยู่แล้วว่าเอเจนต์กำลังสร้างภาระโหลดเพิ่มเติมให้ GitHub อย่างกะทันหันและมากพอสมควร
  พอเป็นบริการที่มีฐานผู้ใช้มหาศาลอยู่แล้วแต่ยังโตแบบ exponential เหมือนสตาร์ตอัป ก็เลี่ยงไม่ได้ที่จะเป็นเป้า และก็คงไม่ง่ายที่องค์กรจะขยับตัวได้เร็ว
  ในทางกลับกันก็ยังมีข้อเท็จจริงว่าเรื่องคน โครงสร้างพื้นฐาน และเงินนั้นมีมากกว่าสตาร์ตอัปมาก

  • ไม่แน่ใจว่าหมายถึงข้อมูลไหน
    มีแค่กราฟไม่มีป้ายกำกับหนึ่งรูปกับตัวเลข peak ปัจจุบันเท่านั้นเอง

• กราฟ พวกนั้นไม่รู้ว่าทำอะไรไว้กันแน่ ดูแทบจะเป็นงาน impressionist ของศิลปิน
  ดูกราฟ commit แล้วอธิบายไม่ได้เลยว่าทำไมถึงมีขั้นใหญ่ ๆ โผล่ขึ้นมาแล้วค่อยลาดลงช้า ๆ ทำไมขั้นเหล่านั้นไม่เกิดในจุดที่สม่ำเสมอ และทำไมบางครั้งการกระโดดที่ใหญ่กว่ากลับมีความชันน้อยกว่า
  กราฟอื่น ๆ ก็ยังเคลื่อนไหวคนละทรงกันอีก เลยยิ่งแปลกเข้าไปใหญ่

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

• มองว่า federated forges น่าจะเป็นอนาคตในที่สุด
  แต่ละ repo ควรโฮสต์บน sovereign infra ของตัวเอง แล้วค่อยมี global ID กับ metadata แบบ federated สำหรับ issue, PR และอื่น ๆ ทับอยู่ด้านบน
  ดัชนีแบบ global พวกนี้ก็ทำให้รันได้ง่าย จน availability ไม่ต้องเป็นเรื่องที่น่ากังวลมาก และพวกเราก็กำลังทำงานไปในทิศทางนั้น

  • ไอเดียน่ารักดี แต่คนส่วนใหญ่ไม่ได้อยาก โฮสต์เอง
    สุดท้ายพอใช้โฮสต์ของบุคคลที่สาม ก็มีโอกาสสูงที่ผู้เล่นรายใหญ่ 1–3 รายจะกลับมาเหมือนเดิม
    และต่อให้ self-host เพื่อหลีกเลี่ยงปัญหา availability ถ้ายังพึ่งบริการใหญ่แบบ GitHub อยู่ ความล่มฝั่งนั้นก็ยังเลี่ยงไม่ได้อยู่ดี
    เพราะงั้นทางออกที่เป็นจริงกว่าก็ยังเป็นการ proxy หรือ mirror ทุกอย่างที่ใช้อยู่ เหมือนทุกวันนี้
  • จริง ๆ ตอนนี้ก็ทำแบบนั้นได้อยู่แล้ว
    วาง repo เดียวกันไว้ทั้งบน GitHub, Codeberg และ self-host แล้วดูแลให้ main branch สอดคล้องกันก็พอ
    หลังจากนั้นจะอัปเดตจากที่ไหนก็ได้ และแค่ใส่ลิงก์ไว้ใน README ให้ดี
  • เวลา coding agent ทำ VCS integration แบบลึก ๆ ก็อยากให้ไม่ตั้ง GitHub เป็นค่าเริ่มต้น
    ถ้าต่อ forge อื่นที่มี API หรือ webhook ใช้งานได้ดี แล้วได้ความสะดวกเท่ากัน ผมก็อยากย้ายไป self-host ทั้งหมด
    ฝั่ง agent เองก็คงต้องเปิด interface ให้ด้วย แต่ถ้าเป็นโครงสร้างแบบ plugin ก็น่าจะถอด dependency กับ GitHub ออกได้ แล้วให้ส่วนที่เหลือไปจัดการผ่าน MCP หรือ skills
  • เป็นไอเดียที่ดี และผมก็อยากเอามาแทน คอนเทนต์ที่สร้างโดย LLM บนเว็บของเราด้วย
    ผมโอเคกับการ self-host runner ตัวใหญ่ ๆ เลยย้ายไป Codeberg เมื่อไม่นานนี้ และงาน cron เล็ก ๆ ก็ใช้ runner ที่ Codeberg มีให้
    ที่นั่นยังมี lazy runner สำหรับงานแบบนี้ด้วย
  • เป็นแนวคิดที่เพิ่งเคยได้ยิน เดี๋ยวจะสมัครแล้วลองใช้ดู

• ตอนนี้สิ่งที่ทำอยู่ดูเหมือนเป็นแบบนี้
  เงินอุดหนุน token ดูดข้อมูลฝึกไปได้มากพอแล้ว และธุรกิจพวก agentic junkies ก็โตพอจะหมุน flywheel ได้เองแล้ว เลยกำลังจะตัดออก แล้วก็เก็บสินค้าที่ตั้งใจทำให้ขาดทุนพวกนี้ทิ้ง
  https://news.ycombinator.com/item?id=47923357