เกิดเหตุขัดข้องใน GitHub กระทบ Issues, Actions และงาน Git

 (githubstatus.com)
1 คะแนน โดย GN⁺ 2026-02-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีรายงาน ประสิทธิภาพลดลงและข้อผิดพลาด ในบริการหลักของ GitHub เช่น Actions, Issues และงาน Git
  • ขอบเขตผลกระทบขยายไปยัง Webhooks, Pull Requests, Packages, Pages, Codespaces และบริการอื่น ๆ
  • GitHub ระบุว่าได้ใช้ มาตรการบรรเทาผลกระทบ (mitigation) และยืนยันการฟื้นตัวแบบค่อยเป็นค่อยไป ก่อนที่ทุกบริการจะกลับมาเป็นปกติ
  • เหตุขัดข้องยังส่งผลต่อบางบริการ เช่น Dependabot, Copilot แต่ท้ายที่สุดก็กลับสู่สถานะ ทำงานปกติ
  • GitHub ระบุว่าจะเผยแพร่ การวิเคราะห์สาเหตุราก (RCA) ในภายหลัง และขอบคุณผู้ใช้สำหรับ ความอดทนและความร่วมมือ

ภาพรวมของเหตุขัดข้อง

  • GitHub ประกาศว่ากำลังตรวจสอบรายงานประสิทธิภาพลดลงใน Actions, Git Operations และ Issues
    • ในช่วงแรกพบ การตอบสนองช้าและคำขอที่ล้มเหลว รวมถึง งาน Actions ที่ล่าช้า
    • เหตุขัดข้องถูกรายงานครั้งแรกเมื่อ 9 กุมภาพันธ์ 2026 เวลา 19:01 UTC

บริการที่ได้รับผลกระทบ

  • องค์ประกอบที่ได้รับผลกระทบ ได้แก่ Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
    • ต่อมาพบปัญหาใน Dependabot และ Copilot ด้วย
    • แต่ละบริการถูกแสดงสถานะเป็น “degraded performance (ประสิทธิภาพลดลง)”

การรับมือและกระบวนการกู้คืน

  • GitHub รายงานว่าหลังจากใช้ มาตรการบรรเทาผลกระทบ แล้ว ก็เริ่มเห็น สัญญาณการฟื้นตัว
    • หลัง 19:29 UTC ระบบเริ่มฟื้นตัวอย่างค่อยเป็นค่อยไป
    • เวลา 19:54 UTC หลายบริการกลับมาฟื้นตัวแล้ว แต่บางส่วนยังอยู่ระหว่างการตรวจสอบ
  • เวลา 20:08 UTC มีรายงานว่า “ทุกบริการกำลังประมวลผลตามปกติ”
    • เวลา 20:09 UTC สถานะถูกเปลี่ยนเป็น Resolved (แก้ไขแล้ว)

สถานะสุดท้ายและการดำเนินการต่อเนื่อง

  • GitHub ระบุว่าทุกบริการกลับสู่ สถานะการดำเนินงานปกติ แล้ว
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, Webhooks กลับมาเป็นปกติทั้งหมด
  • จะมีการแชร์ การวิเคราะห์สาเหตุราก (Root Cause Analysis) เมื่อจัดเตรียมเสร็จ
  • บริษัทแสดง ความขอบคุณต่อความอดทนและความเข้าใจ ของผู้ใช้

สรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-10
ความคิดเห็นจาก Hacker News

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

    • เห็นด้วยมาก เมื่อก่อนยอดเยี่ยม แต่ตอนนี้แม้แต่ฟังก์ชันพื้นฐานก็ยังไม่เสถียร
      แค่เปิด PR diff ธรรมดาก็ใช้เวลาเกิน 15 วินาที และ UI ก็เหมือนค้างซ้ำๆ
      น่าแปลกที่คนเริ่มยอมรับ ประสิทธิภาพที่เสื่อมลงแบบผิดปกติ นี้เป็นเรื่องปกติ
    • คำว่า “ชอบใช้ Copilot” ฟังดูเหมือนมุกตลก
    • น่าขันตรงที่ Linus Torvalds ออกแบบ git เพื่อ โครงสร้างที่ไม่รวมศูนย์
      ท้ายที่สุดแล้ว แก่นแท้ของ git คือสามารถรัน CI pipeline ในเครื่องโลคัลได้ด้วย
      ฉันใช้ GH แค่สำหรับซิงก์เท่านั้น
    • เมื่อก่อน GitHub มักเผยแพร่ postmortem บ่อย แต่ช่วงหลังแทบไม่มีแล้ว
      ถ้าย้อนไปดูโพสต์เก่าๆ จะเห็นว่าพวกเขาเคยชนกับ ข้อจำกัดด้านการสเกล ของ SQL DB
      คล้ายกับกรณี การขยาย Postgres ของ OpenAI แต่ GitHub ดูเหมือนรับมือได้ไม่ดีเท่า
    • มองว่าเป็นปัญหาของ Microsoft ในทำนองว่า “คาดหวังผลิตภัณฑ์ที่เชื่อถือได้คงยาก”

  • การล่มบ่อยของ GitHub กลับกลายเป็นโอกาสให้ตรวจสอบ ความยืดหยุ่นของ deployment pipeline
    ทีมส่วนใหญ่พึ่ง GitHub แบบเต็มตัว จนถ้าล่มเมื่อไรการ deploy ก็หยุดทันที
    จึงลองใช้ทางเลือกดังนี้

    1. มิเรอร์ repo สำคัญไปยัง GitLab หรือ Gitea
    2. ทำ dependency caching เพื่อป้องกัน build ล้มเหลว
    3. เตรียม runbook สำหรับ deploy แบบแมนนวลได้โดยไม่ต้องพึ่ง GitHub Actions
      หน้า status อย่างเป็นทางการอัปเดตช้าเสมอ จนตอนนี้มองว่าเป็นข้อมูลแบบ “eventually consistent” เท่านั้น

  • GitHub อาจกำลังรับภาระจาก การระเบิดของ workflow การพัฒนาแบบอัตโนมัติ
    commit ใน repo ส่วนตัวเพิ่มขึ้นอย่างมาก แต่แทบไม่มีการเปลี่ยนเป็นลูกค้าแบบเสียเงิน

    • ปัญหาจริงๆ เริ่มมาตั้งแต่หลัง Microsoft เข้าซื้อกิจการแล้ว
      มองว่าการเปิดให้ repo แบบ private ใช้งานฟรี ในปี 2019 ทำให้พลาดโอกาสในการสร้างรายได้
    • ที่จริงแล้วกำลังอยู่ระหว่าง ย้ายระบบจาก AWS ไป Azure จึงเกิดปัญหาล่มบ่อย
      และยังขาดความรับผิดชอบต่อ downtime ด้วย
    • สุดท้ายก็คือชนกับ ข้อจำกัดด้านการสเกล
    • การสร้างโค้ดด้วย AI ทำให้ repo, commit และ dataset เพิ่มขึ้นแบบระเบิด
    • สรุปได้ด้วยประโยคว่า “อยู่รอดด้วยกระแส AI Agent และอาจพังเพราะ AI Agent”

  • มีคนยืนยันว่า GitLab คือทางเลือก
    ตอนนี้ GitHub สนใจแต่ กลยุทธ์ที่เอา AI เป็นศูนย์กลาง จนตัวแพลตฟอร์มถูกละเลย
    อัตราการใช้งาน Copilot ก็ต่ำ และองค์กรต่างๆ ใช้ Claude มากกว่า
    ถ้า Microsoft เปลี่ยนทิศทางเมื่อไร สถานการณ์จะยิ่งแย่ลง

    • มีคนถามว่า Copilot ใช้โมเดลของตัวเองหรือไม่
    • แต่ GitLab ก็ไม่ได้สมบูรณ์แบบ
      หลายฟีเจอร์เปิดตัวทั้งที่ยัง เสร็จไม่สุด และความเร็วก็ช้า
      จุดเด่นของโมเดล open-core เองก็เริ่มเลือนราง
    • GitLab เองก็หันไปทาง AI เช่นกัน
      จาก Dev → DevOps → DevSecOps → AI DevSecOps แต่ละช่วงพัฒนามาเรื่อยๆ
      ทว่าทุกช่วงกลับยังไม่ค่อยสมบูรณ์ และยังบังคับให้ อัปเกรดไลเซนส์ จนใช้งานลำบาก

  • มองว่าโครงสร้างที่ ผูก CI/CD และ code hosting ไว้ด้วยกัน เองนี่แหละคือปัญหา
    ต่อให้ทำงานสมบูรณ์แบบ ก็หนี vendor lock-in ไม่พ้น
    เดิมทีควรแค่เปลี่ยน remote ก็จบ แต่ตอนนี้กลับผูกติดด้วย PR, wiki และอย่างอื่นอีก

    • ที่จริงนี่ไม่ใช่ความผิดพลาด แต่เป็น กลยุทธ์ล็อกอินโดยตั้งใจ มากกว่า
    • มองว่าถ้าใช้ระบบ CI ที่เป็นอิสระอย่าง forgejo ซึ่งเป็นโอเพนซอร์ส ก็น่าจะดีกว่า

  • ตอนนี้ปัญหาของ GitHub ไม่ใช่แค่ปัญหา SaaS ธรรมดา แต่รู้สึกเหมือนเป็น ปัญหาระดับคลาวด์ แล้ว
    เลยมีหลายทีมกำลังย้ายไปใช้ GitLab/Gitea แบบ self-hosted

    • เคยใช้ GitLab สำเร็จในสตาร์ทอัป 2 แห่ง
      ส่วนองค์กรใหญ่ใช้ GitLab Enterprise แบบ on-premises ด้วยเหตุผลด้านความปลอดภัย และ
      โปรเจกต์ส่วนตัวก็ดูแลด้วย Forgejo
      ทั้ง Git, issue, board, wiki ใช้งานได้ดี และ scoped label ก็ฟรี
    • self-hosted Gitea ก็ใช้ได้ดี แค่ต้องจัดการแบ็กอัปให้ดี
    • GitLab แบบ self-hosted รุ่นเต็ม ก็คุ้มค่ากับค่าใช้จ่าย
    • GitLab แบบ self-hosted น่าพอใจอย่างชัดเจน

  • มีหน้าเว็บที่แสดงภาพรวม ประวัติการขัดข้องหลายครั้ง ของ GitHub
    ดูได้ที่ mrshu.github.io/github-statuses

    • updog.ai/status/github ก็อ้างอิงข้อมูลจาก Datadog เช่นกัน
    • แต่ดูเหมือนการอัปเดตจะหยุดไปแล้ว (ล่าสุดคือ 6 กุมภาพันธ์)

  • ยังมีคอมเมนต์เชิงล้อว่า “ทีม GitHub ไม่ต้องรีบ ค่อยๆ ทำก็ได้”

  • อยากเลิกใช้ GitHub แต่ก็ยังต้องการ CI ที่เสถียรและ container registry
    ถ้าเป็นโซลูชันที่ “ใช้งานได้ดีเฉยๆ” ก็ยินดีจ่ายเงิน

    • แนะนำ Lithus.eu ที่ให้ CI บนพื้นฐาน Forgejo + Firecracker VM
      เหมาะกับ workload ขนาดใหญ่ แต่ค่าเริ่มต้นสูง
    • GitLab CI เรียบง่ายแต่ทรงพลัง
      การจัดการสิทธิ์ของ registry อาจซับซ้อนนิดหน่อย แต่การรวมระบบโดยรวมทำได้ดี
    • มีคำถามว่า repo ควรเป็นผู้รับผิดชอบ CI หรือไม่
      มองว่าควรกลับไปใช้เครื่องมือแบบจุดประสงค์เดียวตาม ปรัชญา Unix
    • มีคนแนะนำ nix-ci.com เช่นกัน
    • CircleCI ก็ยังเป็นทางเลือกที่ใช้งานได้ดี

  • ถ้าทำกราฟเปรียบเทียบ อัตราการนำ AI มาใช้กับความถี่ของการล่ม ก็น่าจะน่าสนใจ

    • แน่นอนว่ายังมีปัจจัยอื่นร่วมด้วย