GitHub: เหตุขัดข้องของงาน Git

 (githubstatus.com)
3 คะแนน โดย GN⁺ 2025-11-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 18 พฤศจิกายน 2025 (UTC) บน GitHub เกิดเหตุ การทำงาน Git ทั้งหมดล้มเหลว ส่งผลให้การเข้าถึงผ่านไคลเอนต์ SSH·HTTP และการเข้าถึงไฟล์แบบ raw ใช้งานไม่ได้
  • สาเหตุของปัญหาได้รับการยืนยันว่าเกิดจาก ใบรับรอง TLS ที่หมดอายุ ซึ่งใช้ในการสื่อสารระหว่างบริการภายใน
  • GitHub ได้เปลี่ยนใบรับรองที่หมดอายุและรีสตาร์ตบริการที่ได้รับผลกระทบ จน กู้คืนการทำงานได้ตามปกติ
  • หลังจากนั้นกำลัง เสริมความเข้มงวดของการแจ้งเตือนการหมดอายุของใบรับรอง และดำเนินการ เปลี่ยนผ่านสู่ระบบอัตโนมัติ เพื่อนำใบรับรองที่ยังจัดการด้วยตนเองออกไป
  • เหตุขัดข้องครั้งนี้ส่งผลต่อ Git Operations และ Codespaces ของ GitHub และหลังการกู้คืน ทุกบริการได้กลับสู่สถานะปกติ

รายงานเหตุขัดข้องของงาน Git

  • ในช่วง 20:30~21:34 UTC ของวันที่ 18 พฤศจิกายน 2025 บน GitHub เกิด การทำงาน Git ทั้งหมดล้มเหลว

    • การโต้ตอบของไคลเอนต์ Git ผ่าน SSH และ HTTP รวมถึงการเข้าถึงไฟล์แบบ raw ได้รับผลกระทบทั้งหมด
    • ผลิตภัณฑ์ที่พึ่งพาการทำงานของ Git ก็ประสบเหตุขัดข้องเช่นเดียวกัน

  • สาเหตุ ได้รับการยืนยันว่าเป็น ใบรับรอง TLS ที่หมดอายุ ซึ่งใช้ในการสื่อสารระหว่างบริการภายใน

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

  • GitHub ได้ เสริมระบบแจ้งเตือนการหมดอายุของใบรับรอง เพื่อป้องกันไม่ให้เกิดปัญหาเดียวกันในอนาคต

    • กำลังดำเนินการ ตรวจสอบการเฝ้าระวังและระบบอัตโนมัติ สำหรับใบรับรองอื่น ๆ ในพื้นที่ที่เกี่ยวข้องด้วย
    • เร่งดำเนินการ ยกเลิกใบรับรองที่ยังจัดการด้วยตนเอง ที่เหลืออยู่ และ สร้างระบบการสื่อสารระหว่างบริการแบบอัตโนมัติ

ลำดับเหตุการณ์และขั้นตอนการกู้คืน

  • 20:39 UTC: มีรายงาน ความพร้อมใช้งานลดลง ใน Git operations และ Codespaces
  • 20:52 UTC: ยืนยันว่ามีงาน Git HTTP บางส่วนล้มเหลว
  • 21:11 UTC: ยืนยันอาการที่ งาน Git ทั้งหมดล้มเหลว
  • 21:25 UTC: ความพร้อมใช้งานลดลง ของ Codespaces ยังคงดำเนินต่อไป
  • 21:27 UTC: ระบุสาเหตุได้สำเร็จ และเริ่มดำเนินการแก้ไข
  • 21:36 UTC: เริ่ม กู้คืนบางส่วน หลังปรับใช้การแก้ไข
  • 21:55 UTC: ทุกบริการกลับสู่ภาวะปกติ, Codespaces กู้คืนเสร็จสมบูรณ์
  • 21:56 UTC: ยืนยันว่าการทำงาน Git กลับมาดำเนินการได้ตามปกติ
  • 21:59 UTC: ปิดเหตุการณ์และเผยแพร่รายงาน

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

  • Git Operations
    • งาน Git ทั้งหมดที่ทำงานผ่าน SSH และ HTTP
  • Codespaces
    • เกิดความพร้อมใช้งานลดลงชั่วคราว

มาตรการติดตามผล

  • เสริมการเฝ้าระวังการหมดอายุของใบรับรองและระบบอัตโนมัติ
    • จัดตั้งระบบแจ้งเตือนล่วงหน้าก่อนใบรับรองหมดอายุ
    • ตรวจสอบกระบวนการต่ออายุอัตโนมัติของใบรับรองภายในทั้งหมด
  • ขยายระบบอัตโนมัติด้านความปลอดภัยและการปฏิบัติการ
    • ยกเลิกการจัดการใบรับรองด้วยตนเอง
    • สร้างการสื่อสารระหว่างบริการแบบอัตโนมัติที่สอดคล้องกับแนวปฏิบัติด้านความปลอดภัยสมัยใหม่

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

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

 
GN⁺ 2025-11-20
ความคิดเห็นบน Hacker News

  • รู้สึกกังวลที่ช่วงนี้ เหตุขัดข้องของระบบซอฟต์แวร์ ใหญ่ ๆ เกิดขึ้นบ่อยเกินไป
    ปีก่อนมีเหตุขัดข้องที่กระทบงานแค่สี่ครั้ง แต่ไตรมาสนี้นี่ก็เป็นครั้งที่สี่แล้ว
    เหมือน ความทนทานของระบบ (resiliency) ในซอฟต์แวร์เครือข่ายกำลังค่อย ๆ หายไป
    ทีมของเราใช้สถาปัตยกรรมแบบ monolith แต่ก็มี dependency เยอะ ทั้ง Redis, S3 และบริการเชื่อมต่อภายนอกอื่น ๆ
    เลยพยายามทำให้เรียบง่ายขึ้น เช่น จัดทำเอกสารเงื่อนไขที่ทำให้ระบบล่ม เสริมการทดสอบและระบบ deploy อัตโนมัติ และย้ายจากคลาวด์ไปใช้ VPS
    ผลคือระบบเสถียรขึ้นและคาดเดาได้มากขึ้นอย่างชัดเจน
    ถ้าไม่มี งานน่าเบื่อแต่จำเป็น แบบนี้ ความซับซ้อนก็คงเพิ่มขึ้นจนระบบเปราะบางกว่าเดิม
    เหตุขัดข้องที่เจอช่วงหลังคือ AWS us-east-1, Azure Front Door, Cloudflare และ GitHub

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

  • Git เป็น ระบบควบคุมเวอร์ชันแบบกระจายศูนย์ ดังนั้นถึงไม่มี GitHub ก็ยังทำงานได้
    GitHub เป็นแค่ฮับที่สะดวกเท่านั้น

    • แต่ถ้าเป็นบริษัทที่ พึ่ง GitHub Actions ทั้งหมด ก็จะตันสนิทแบบตอนนี้
    • มันเหมือนสถานการณ์ว่า “บันไดเลื่อนนี้ถูกเปลี่ยนเป็นบันไดชั่วคราว ขออภัยในความไม่สะดวก”
    • แก่นของปัญหาคือ GitHub ล่ม ไม่ใช่ git ล่ม
    • ถ้าไม่มี GitHub ก็จะเสียฟังก์ชันการเป็น ศูนย์กลางความร่วมมือ กับคนอื่นไป
    • ที่มาอยู่บน Hacker News ตอนนี้ก็เพราะ ทำงานไม่ได้ นี่แหละ

  • รู้สึกว่า ความน่าเชื่อถือของ GitHub แย่มากจนเป็นปัญหาร้ายแรง
    สำหรับคนที่พึ่ง CI/CD นี่ถือว่าหนักมาก
    ภายในองค์กรดูเหมือนจะรับรู้แค่ว่า “CI/CD ของทีมเราพัง” มากกว่าจะมองว่า “คนครึ่งโลกหยุดทำงานอยู่”
    วัฒนธรรมแบบไซโล และทัศนคติว่า “ไม่ใช่ปัญหาของเรา” แบบนี้ทำให้ความน่าเชื่อถือลดลง
    แถมเพราะมีสถานะกึ่งผูกขาด ลูกค้าก็ต้องทนใช้ต่อไปอยู่ดี
    มันเหมือนท่าทีแบบที่เคยเห็นจาก Verio กับ Verisign ว่า “ยังไงคุณก็ย้ายไปที่อื่นไม่ได้หรอก”

  • สงสัยว่าช่วงนี้เหตุขัดข้องของคลาวด์/SaaS เกิดบ่อยขึ้นจริงไหม
    ไม่แน่ใจว่าแค่มีข่าวเยอะขึ้น หรือความถี่เพิ่มขึ้นจริง ๆ
    หรือว่าเป็นเพราะ ตัดงบ ปลดคน เอา AI มาใช้ หรือโตเร็วเกินไป?

    • ดูเหมือน Microsoft จะเชื่อว่าถ้าย้าย GitHub ไป Azure แล้วทุกอย่างจะดีขึ้น
    • ในฐานะคนที่ใช้งานมานาน รู้สึกได้ชัดว่า ความถี่ของเหตุขัดข้องเพิ่มขึ้น
      แต่ก่อนปีละหนึ่งหรือสองครั้ง เดี๋ยวนี้แทบทุกเดือน ช่วงหลังนี่เกือบทุกสัปดาห์
    • ตอน Cloudflare ล่ม มีคนบอกว่า “วัฒนธรรมการเขียนโค้ดด้วย AI” กำลังทำให้ปัญหาแบบนี้หนักขึ้น
      ชิ้นโค้ดเล็ก ๆ จาก AI อาจก่อให้เกิด เหตุขัดข้องแบบโดมิโน ได้
    • เหมือนที่ บทความของ Techrights ว่าไว้
      คิดว่า การเลย์ออฟครั้งใหญ่ ส่งผลต่อความน่าเชื่อถือที่ลดลง
    • เพราะ FOMO (กลัวตกขบวน) จาก AI ตารางโปรเจกต์เลยยิ่งแน่นขึ้น
      สุดท้ายงานด้านความเสถียรใน 10% สุดท้ายก็มักถูกมองข้าม

  • ตอนแรกนึกว่า push ไม่ได้เพราะปัญหาที่เครื่องตัวเอง
    สุดท้ายก็เลยยอมแพ้วันนี้แล้วค่อยกลับมาทำใหม่พรุ่งนี้

    • ยืนยันตัวตนผ่าน แต่ push ไม่ได้ เป็นประสบการณ์ที่ ชวนดึงผมตัวเองมาก
    • เพิ่ม SSH key ใหม่ก็ไม่ช่วย ตอนแรกขึ้นแต่ error แปลก ๆ แล้วสุดท้ายกลายเป็นข้อความ “upstream unhealthy”
    • ผมก็เกือบจะ ตั้งค่าสภาพแวดล้อมใหม่ทั้งหมด เหมือนกัน

  • วันนี้ก็ไม่ได้อยากทำงานอยู่แล้ว พอ Cloudflare ล่มแล้ว GitHub มาล่มต่อ เหมือนเป็น สัญญาณ ให้พัก

    • ปัญหาคือการ พึ่งพาเทคโนโลยีแบบรวมศูนย์ที่มีสหรัฐเป็นศูนย์กลาง
      เราต้องการ อธิปไตยทางเทคโนโลยีและการกระจายศูนย์ ให้มากกว่านี้

  • ในบรรดาบริการที่ใช้มา 5 ปีที่ผ่านมา GitHub คือบริการที่ ไม่นิ่งที่สุด
    สงสัยว่า GitLab จะดีกว่าไหม ตอนนี้ความเชื่อมั่นใน GitHub แทบเป็นศูนย์แล้ว

    • บริษัทเราทำ self-hosting GitLab อยู่ แต่เซิร์ฟเวอร์ Gitaly ล่มบ่อย
      น่าจะเพราะเป็นสภาพแวดล้อม monorepo ขนาดใหญ่ แต่ก็ดูมีปัญหาเรื่องการขยายระบบชัดเจน
    • GitLab มีฟีเจอร์เยอะก็จริง แต่ การเชื่อมรวมยังไม่เนียน และความสมบูรณ์ยังต่ำ
      ถึงอย่างนั้นการรวม repository, CI/CD, issue และ wiki ไว้ที่เดียวก็ยังเป็นข้อดี
    • ใช้ทั้ง GitHub.com และ GitLab แบบ self-hosting
      GitHub เปราะบางกับ เหตุขัดข้องของคลาวด์ ส่วน GitLab เจอปัญหา อัปเกรดอัตโนมัติสะดุด บ่อย
      แต่ละตัวมีข้อดีข้อเสียต่างกัน
    • ปัญหาของ GitLab คือ ช้าและหนัก
      ต้องโหลด JS หลาย MB จนบนเครือข่ายช้าหน้าเว็บแทบไม่ขึ้น
    • ถ้าเอาไว้ on-premises ก็สามารถทำ ความเสถียร ได้มากเท่าที่ต้องการ

  • ในสถานการณ์ฉุกเฉินยังแก้ไฟล์ตรงจาก GitHub web UI ได้
    แต่ actions/checkout@v4 ของ GH Actions ตอนนี้ใช้ไม่ได้เพราะมีปัญหากับ git

    • จริง ๆ แล้วแค่มี โฮสต์ที่ SSH เข้าได้ ก็สามารถ git push/pull ได้
    • เราก็กำลังทำ hotfix โปรดักชันอยู่พอดี แต่โดนบล็อกไปด้วย ไม่รู้ช่วงนี้อินเทอร์เน็ตเกิดอะไรขึ้น
    • CircleCI ก็ ทำงาน git ไม่สำเร็จ เพราะมีปัญหาเรื่องการรับรู้ GitHub SSH key
    • รอบนี้ GitHub AI กลับช่วยได้แบบ เหนือความคาดหมาย เพราะบอกให้ไปเช็ก githubstatus.com
    • สงสัยว่าใน GitHub UI ยัง สร้าง branch ได้อยู่ไหม

  • ตลอด 10 ปีที่ผ่านมา จากที่ย้ายไปมาระหว่างบริษัทใหญ่กับสตาร์ตอัป เห็น รูปแบบซ้ำ ๆ อย่างหนึ่ง
    สตาร์ตอัป → รองรับลูกค้าองค์กร → รีดีไซน์ซับซ้อน → อุดมคตินิยม → ไล่ล่ากำไร → ผลิตภัณฑ์พองตัว → วิศวกรแกนหลักลาออก → คุณภาพตก
    วงจรนี้เกิดซ้ำกับบริษัทยักษ์ด้านคลาวด์ด้วย (AWS, Cloudflare, GCP ฯลฯ)
    ภายในเองแต่ละบริการก็ถูกแยกเป็น หน่วยธุรกิจเล็ก ๆ ที่ขับเคลื่อนด้วยกำไร
    สุดท้ายแม้แต่ โครงสร้างพื้นฐานระดับฐานราก ก็อ่อนแอลงเพราะแรงกดดันด้านผลกำไร
    รู้สึกว่าความเชื่อแบบ “AWS หรือ GCP ใหญ่เกินกว่าจะพัง” นั้นอันตราย

    • เห็นด้วย ตอนรองรับลูกค้าองค์กร ผลิตภัณฑ์จะ ซับซ้อนและเชื่องช้าลงอย่างหลีกเลี่ยงไม่ได้
      แต่ปัญหาหนี้เทคนิคและความปลอดภัยของสตาร์ตอัปยุคแรกก็ร้ายแรงเหมือนกัน
      ท้ายที่สุดพอระบบเติบโตในระดับใหญ่ การที่ รอยร้าวของระบบจะโผล่ออกมา ก็เป็นเรื่องธรรมดา

  • ในหน้า status ของ GitHub มีข้อความว่า “ผู้ใช้บางรายอาจประสบปัญหา” โผล่มาอีกแล้ว
    แต่ความจริงคือไม่ใช่แค่ HTTPS เท่านั้น แม้แต่ SSH push ก็ล้มเหลวทั้งหมด

    • ดูเหมือนคนที่ดูแลหน้า status จะหลุดจากคำว่า “ผู้ใช้บางราย” ไม่ได้
      การเปิดเผยข้อมูลอย่างโปร่งใสแทน ถ้อยคำอ้อมแบบ PR น่าจะสร้างความเชื่อมั่นได้มากกว่า
      แถมบางทีกว่า status page จะอัปเดตก็ช้ามาก
    • เพื่อนผมบอกว่าแป๊บหนึ่ง push ได้ แต่ส่วนใหญ่ก็ยังเจอ fatal error อยู่ดี