ปัญหา Issues และ Webhooks – แก้ไขแล้ว

 (githubstatus.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GitHub ได้ตรวจสอบปัญหาประสิทธิภาพลดลงของ Issues และ Webhooks ก่อนเปลี่ยนสถานะเหตุขัดข้องเป็น แก้ไขแล้ว เมื่อวันที่ 4 พฤษภาคม 2026 เวลา 16:40 UTC
  • เหตุขัดข้องครั้งนี้ส่งผลกระทบต่อ Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages และ Codespaces
  • เมื่อเวลา 15:45 UTC ได้เริ่มตรวจสอบปัญหาประสิทธิภาพลดลงของ Issues และ Webhooks และในเวลา 15:48 UTC ได้ขยายการตรวจสอบไปยังปัญหา latency เพิ่มขึ้น และ timeout ของหลายบริการบน GitHub
  • ตั้งแต่เวลา 16:25 UTC เป็นต้นไป Git Operations, Actions, Packages, Pages, Pull Requests, Issues, Codespaces และ Webhooks ทยอย กลับมาทำงานปกติ หรือได้รับการบรรเทาปัญหา
  • GitHub ระบุว่า latency โดยรวมของบริการกลับสู่ภาวะปกติแล้ว และจะเดินหน้ามาตรการป้องกันการเกิดซ้ำพร้อม การวิเคราะห์สาเหตุราก ต่อไป และจะแชร์เมื่อพร้อม

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

  • GitHub ประกาศว่าเหตุขัดข้องได้รับการแก้ไขแล้ว หลังตรวจสอบรายงานปัญหาประสิทธิภาพลดลงของ Issues และ Webhooks
  • เหตุขัดข้องส่งผลกระทบต่อ Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
  • GitHub กล่าวขอบคุณผู้ใช้ที่รอระหว่างการแก้ไขปัญหา และระบุว่าจะเผยแพร่ การวิเคราะห์สาเหตุราก แบบละเอียดเมื่อพร้อม

ลำดับเหตุการณ์

  • เริ่มการตรวจสอบ

    • เมื่อวันที่ 4 พฤษภาคม 2026 เวลา 15:45 UTC มีประกาศว่ากำลังตรวจสอบรายงานปัญหาประสิทธิภาพลดลงของ Issues และ Webhooks
    • ในเวลา 15:48 UTC ได้ขยายประกาศว่ากำลังตรวจสอบ latency เพิ่มขึ้น และ timeout ในหลายบริการของ GitHub

  • ขยายขอบเขตบริการที่ได้รับผลกระทบ

    • เวลา 15:48 UTC มีประกาศว่า Git Operations กำลังประสบปัญหาประสิทธิภาพลดลง
    • เวลา 15:50 UTC มีประกาศว่า Packages กำลังประสบปัญหาประสิทธิภาพลดลง
    • เวลา 15:51 UTC มีประกาศว่า Actions กำลังประสบปัญหาประสิทธิภาพลดลง
    • เวลา 15:51 UTC มีประกาศว่า Pull Requests กำลังประสบปัญหาความพร้อมใช้งานลดลง
    • เวลา 15:56 UTC มีประกาศว่า Pull Requests กำลังประสบปัญหาประสิทธิภาพลดลง
    • เวลา 16:05 UTC มีประกาศว่า Codespaces กำลังประสบปัญหาประสิทธิภาพลดลง
    • เวลา 16:06 UTC มีประกาศว่า Pages กำลังประสบปัญหาประสิทธิภาพลดลง

  • การกลับสู่ภาวะปกติและการบรรเทาปัญหา

    • เวลา 16:25 UTC มีประกาศว่า Git Operations กลับมาทำงานได้ตามปกติ
    • เวลา 16:28 UTC มีประกาศว่า Actions และ Packages กลับมาทำงานได้ตามปกติ
    • เวลา 16:29 UTC มีประกาศว่า Pages กลับมาทำงานได้ตามปกติ
    • เวลา 16:29 UTC มีประกาศว่า latency โดยรวมของบริการกลับสู่ภาวะปกติแล้ว และยังคงดำเนินการตรวจสอบสาเหตุรากและป้องกันการเกิดซ้ำต่อไป
    • เวลา 16:32 UTC มีประกาศว่า Pull Requests กลับมาทำงานได้ตามปกติ
    • เวลา 16:34 UTC มีประกาศว่าปัญหาประสิทธิภาพลดลงที่ส่งผลต่อ Issues ได้รับการบรรเทาแล้ว และกำลังเฝ้าติดตามเพื่อยืนยันเสถียรภาพ
    • เวลา 16:35 UTC มีประกาศว่าปัญหาประสิทธิภาพลดลงที่ส่งผลต่อ Codespaces ได้รับการบรรเทาแล้ว และกำลังเฝ้าติดตามเพื่อยืนยันเสถียรภาพ
    • เวลา 16:35 UTC มีประกาศว่า Webhooks กลับมาทำงานได้ตามปกติ

  • การแก้ไขเสร็จสิ้น

    • เวลา 16:36 UTC มีประกาศว่าปัญหาประสิทธิภาพลดลงได้รับการบรรเทาแล้ว และกำลังเฝ้าติดตามเพื่อยืนยันเสถียรภาพ
    • เวลา 16:40 UTC สถานะเหตุขัดข้องถูกเปลี่ยนเป็น แก้ไขแล้ว
    • การวิเคราะห์สาเหตุราก แบบละเอียดจะถูกแชร์ทันทีที่สามารถเผยแพร่ได้

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

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

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

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

    • เมื่อวันที่ 3 เมษายน COO ของ GitHub ก็พูดไว้แล้วว่ากิจกรรมบนแพลตฟอร์มกำลังพุ่งขึ้นอย่างรวดเร็ว
      ในปี 2025 มีคอมมิต 1 พันล้านครั้ง แต่ตอนนี้อยู่ที่ 275 ล้านครั้งต่อสัปดาห์ ซึ่งถ้าโตแบบเชิงเส้นก็เท่ากับอัตรา 1.4 หมื่นล้านครั้งในปีนี้ GitHub Actions ก็เพิ่มจาก 500 ล้านนาทีต่อสัปดาห์ในปี 2023 เป็น 1 พันล้านนาทีต่อสัปดาห์ในปี 2025 และสัปดาห์นี้ก็แตะ 2.1 พันล้านนาทีไปแล้ว
      เขาบอกว่ากำลังเร่งเพิ่ม CPU ขยายบริการ และเสริมความแข็งแกร่งให้ความสามารถหลักของ GitHub อย่างหนักมาก
      https://x.com/kdaigle/status/2040164759836778878
      ยังมีโพสต์บล็อกล่าสุดเกี่ยวกับ availability ด้วย: https://github.blog/news-insights/company-news/an-update-on-...
      ปัญหาเรื่อง scalability ที่วิศวกร GitHub เจอดูน่าจะหนักจริง ๆ
    • ถ้าดูมาหลายสิบปี จะเห็นว่ามีทั้งระบบที่ทำให้งานแต่ละชิ้นราคาถูกลง กับระบบที่พยายาม scale แบบแนวนอนอย่างหนัก และบ่อยครั้งแบบแรกชนะขาด
      ตัวอย่างเช่น GitHub ดูเหมือนจะทำให้หน้า /pulls ของรีโปทำงานเหมือน search query โดยช่องค้นหาที่เติมข้อความไว้ล่วงหน้าก็เป็นเบาะแส และแทบยืนยันได้จากตอนที่ backend ของ search ล่มเมื่อสัปดาห์ก่อนแล้ว pull request โหลดไม่ขึ้น แต่จริง ๆ มันทำได้ด้วย API call ธรรมดาที่ดึงเฉพาะ pull request ที่เปิดอยู่ ซึ่ง API นั้นก็มีอยู่และไม่ได้ล่ม
      ถ้า GitHub โฟกัสหางานระดับท็อป 95% อย่างการโหลดหน้าและ API call ที่พ่วงมากับมัน แล้วปรับให้มีประสิทธิภาพขึ้น แค่ทำให้เรียบง่ายลงก็น่าจะลดโหลด backend ได้ มากกว่า 5 เท่า
      ตัว diff viewer ก็ดูยังมีช่องให้ปรับปรุงอีกเยอะ ความไร้ประสิทธิภาพที่เลวร้ายส่วนหนึ่งอาจอยู่ฝั่ง frontend ที่ไม่ได้โหลด backend โดยตรง แต่ความสามารถปกติของ git บน command line นั้นเร็วมาก
    • ตอนนี้ดูเหมือนใกล้ถึง จุดที่ย้อนกลับไม่ได้ แล้ว ถ้าไม่แยกโครงสร้างพื้นฐานของฟรีกับแบบจ่ายเงินออกจากกัน ก็ไม่แน่ใจว่าจะปีนออกจากหลุมที่ตัวเองขุดไว้ได้ด้วยการ scale แนวนอนอย่างเดียวหรือไม่
      เหมือนกับที่การจะบังคับให้คนเปลี่ยนผลิตภัณฑ์ได้ ของใหม่ต้องดีกว่า 10 เท่า แต่ถ้าของเดิมแย่ลง 10 เท่า คู่แข่งก็ได้กำไรฟรี 10 เท่าโดยไม่ต้องทำอะไร
    • พอ GitHub โพสต์เรื่องนี้ลงบล็อกเมื่อสัปดาห์ก่อน แล้ววันถัดมาผู้บริหาร GitHub ก็พูดซ้ำในคอมเมนต์ HN ก็กลายเป็นความเชื่อทั่วไปอย่างรวดเร็วว่าความน่าเชื่อถือที่ลดลงต่อเนื่องตั้งแต่ปี 2019 ไม่ได้มาจาก การรวมเข้ากับ Microsoft ในปี 2019 แต่เกิดจากอะไรบางอย่างที่เพิ่งโผล่มาในปี 2023
      PR ได้ผลจริง สรุปกันไปแล้วว่าเหตุที่ GitHub ใช้การไม่ได้ ก็เพราะมันดังเกินไป
    • ผมสนับสนุนอย่างเต็มที่ให้ย้ายความจุเซิร์ฟเวอร์ของ LinkedIn ทั้งหมดมาให้ GitHub

  • ตามข้อมูลจาก https://mrshu.github.io/github-statuses uptime ในช่วง 90 วันล่าสุดของ GitHub อยู่ที่ 84.92%
    ไม่เข้าใจเลยว่านี่จะถือว่ายอมรับได้แม้แต่นิดเดียวได้อย่างไร

    • ดูเหมือนเว็บนั้นจะนับเวลาหยุดทำงานเกินจริง ถ้ากรองเฉพาะเหตุขัดข้องระดับ major และ critical ที่พอจะขึ้นหน้าแรก HN ได้ มันก็ยังแย่อยู่ดี แต่ไม่ถึงกับแย่ระดับ 84.92%
      https://isgithubcooked.com/?severities=major.critical
    • ยอมรับไม่ได้ ช่วงนี้มีหลายอย่างที่ยอมรับไม่ได้เกิดขึ้น แต่ทุกคนกลับดูเหมือนรับมันได้แบบไม่มีปัญหา
    • ไม่ต้องพูดถึง three nines เลย แค่ two eights ยังทำไม่ได้

  • ตอนนี้ประสิทธิภาพตกมาถึงระดับที่ยอมรับไม่ได้แล้ว แทบไม่มีสัปดาห์ไหนที่งานไม่สะดุดเพราะ GitHub

    • พวก AI agent ได้เปลี่ยนลักษณะการ scale ของทั้งอินเทอร์เน็ตไปแล้วในทางปฏิบัติ
      เมื่อก่อน GitHub พอจะตั้งสมมติฐานได้ว่ามีคนจำนวนจำกัดที่ใช้งานแพลตฟอร์มแบบมนุษย์ ๆ และมีแพตเทิร์นที่สังเกตได้ จึง scale และ optimize คอขวดด้าน UI/UX ตามแพตเทิร์นเหล่านั้นได้
      แต่ตอนนี้ทุกคนมีบอตรันตลอด 24 ชั่วโมงคนละตัว บางทีก็หลายตัว ทำให้หลายบริการรับโหลดไม่ไหว โดยเฉพาะบริการที่เน้น agent แบบ GitHub ในตอนนี้
    • หลายเดือนก่อนก็มาถึงระดับยอมรับไม่ได้แล้ว และตอนนี้ก็ใกล้ถึงขั้นที่ ต้องเริ่มมองหาทางเลือกอย่างจริงจัง
    • ไม่ใช่แค่สัปดาห์หรอก แค่มีวันเดียวที่ผ่านไปโดยไม่มีเหตุขัดข้องก็น่าดีใจแล้ว
      เช้าวันจันทร์ตามเวลาแปซิฟิกแบบนี้ เกิดซ้ำมาจนผมนับไม่ไหวแล้วว่าเป็นครั้งที่เท่าไร
    • ในยุโรปดูดีกว่ามาก เหตุขัดข้องครั้งนี้เริ่มขึ้นหลังผมเลิกงานไปไม่กี่ชั่วโมง และในช่วงหลายเดือนที่ผ่านมา ผมแทบจำไม่ได้เลยว่ามีเหตุใหญ่ที่ทำให้งานต้องหยุด
      มีแค่ครั้งหนึ่งเมื่อไม่นานมานี้ที่ได้รับผลกระทบตอนเย็นระหว่างทำโปรเจกต์งานอดิเรก
    • ผมว่ามันเลยระดับยอมรับไม่ได้มาไกลมากแล้ว

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

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

  • ตลกตรงที่ดูเหมือนเกือบทุกอย่างยกเว้น Copilot กำลัง degraded อยู่ เป็นสถานการณ์ที่มุกมันแต่งตัวเองได้เลย

    • เทียบกับความสามารถที่กำลัง degraded อยู่ตอนนี้ ฟังก์ชันทั้งหมดของ Copilot มีประโยชน์แค่บางส่วนเท่านั้น
    • Copilot น่าจะเป็นอิสระจากฝั่งที่เก็บโค้ดของ GitHub โดยสิ้นเชิง และคงรันอยู่บนโครงสร้างพื้นฐานอีกชุดที่ไม่ได้พึ่งพา Rails monolith มากนัก

  • เริ่มรู้สึกเหมือนตัวเองกำลังมี สัมผัสที่หก ไว้จับช่วงที่ GitHub จะเกิด service outage ซึ่งทั้งแปลกและเศร้านิด ๆ
    ราวหนึ่งชั่วโมงก่อน ผมกด “Resolve Conversation” ใน pull request แล้วมันล้มเหลวอยู่หลายครั้ง และข้อความ error ก็เด้งไปอยู่ล่างหน้าจอนอกสายตา เลยไม่เห็นในตอนแรก ทุกครั้งที่ทำอะไรไปสองสามอย่างก็ต้องรีเฟรชหน้าเพื่อให้เซิร์ฟเวอร์สะท้อนการกระทำล่าสุด
    ผมบอกเพื่อนไปร่วมงานว่า GitHub น่าจะมีปัญหาจากบริการอื่นแล้วลามมาที่คอมเมนต์ PR และอาจบานปลายเป็น outage ใหญ่ได้

    • เมื่อกี้ผมก็เห็นสัญญาณเดียวกันในคอมเมนต์รีวิว PR พอไปเช็ก status page ก็ยังเป็นสีเขียวอยู่ เลยเดาว่าคงอยู่แบบนั้นได้ไม่นาน และก็เป็นอย่างที่คิด

  • ควรลดฟรีเทียร์ลง
    ในช่วง 2.5 เดือนที่ผ่านมา ผมคอมมิตไป 4,000 ครั้ง และนี่ยังนับเฉพาะ main ด้วยนะ แถมยังอัปโหลด artifact สำหรับ regression test วันละกองโต
    ค่าใช้จ่ายคือ 0 ดอลลาร์

    • พูดตามตรง ผมไม่ชอบ ฟรีเทียร์ ของผลิตภัณฑ์ SaaS แบบนี้
      เมื่อก่อนตอน Google เคยมีบริการ Git แบบคิดตามการใช้งานบน GCP อยู่ช่วงสั้น ๆ ผมก็ใช้ เพราะอยากเป็นเจ้าของของตัวเอง แต่ทุกคนใช้ GitHub ที่ “ฟรี” กันหมด และบริการนั้นก็คงถูกปิดไปเหมือนบริการอื่น ๆ ของ Google หลายตัว
      ดังนั้นตอนนี้ผมเลยใช้ฟรี GitHub อยู่ แต่จริง ๆ แล้วอยากจ่ายค่าที่เก็บรีโปและค่าการใช้งานให้ผู้ให้บริการคลาวด์รายใหญ่มากกว่า
    • ถ้าทำแบบนั้น โปรเจกต์โอเพนซอร์ส ที่ยังไม่ย้ายก็น่าจะย้ายออก
    • ถ้ามองเฉพาะฝั่งรีโป นั่นใกล้เคียงกับการใช้ CPU แค่ประมาณ 2 นาที
    • GitHub ควรเก็บ ภาษีขยะโค้ด เขียนร่วมกับ Claude เหรอ จ่ายเงินซะ มี em dash เยอะในคอมเมนต์เหรอ จ่ายเงินซะ เขียนโค้ดได้เยอะผิดปกติในเวลาสั้น ๆ เหรอ จ่ายเงินซะ

  • มันกำลังไปถึงระดับที่น่าขันจริง ๆ แม้บางครั้ง status page จะถูกมองข้ามเพราะรวม Copilot ไว้ด้วยและบอกว่า “ล่ม” แต่สิ่งที่ต้องดูคือ availability ของ pull request อยู่ที่ 95.5% ซึ่งยังต่ำกว่า 96.4% ของ Copilot อีก
    เข้า PR ไม่ได้เลย แล้วจะให้ไปคอมเมนต์ “LGTM” ได้ยังไง

  • อย่างน้อยผู้คนก็กำลังได้เรียนรู้วิธีใช้คำสั่ง git remote