GitHub ดูเหมือนจะรับมือไม่ไหว แม้แต่การรักษาความพร้อมใช้งาน 99.9%

 (theregister.com)
4 คะแนน โดย GN⁺ 2026-03-24 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ช่วงหลังมานี้ GitHub เกิดเหตุบริการขัดข้องบ่อยครั้ง ต่อเนื่อง จนไม่ต้องพูดถึงมาตรฐานอุตสาหกรรมอย่าง ‘5 nines(99.999%)’ เพราะแม้แต่ ‘3 nines(99.9%)’ ก็ยังทำได้ยาก
  • เมื่อวันที่ 9 กุมภาพันธ์ ฟังก์ชันหลักอย่าง Actions, Pull Request, การแจ้งเตือน, Copilot ต่างประสบปัญหาพร้อมกัน และบางบริการเกิด ความล่าช้านานหลายชั่วโมง
  • จาก ปัญหาการเผยแพร่นโยบายของ Copilot ทำให้ผู้ใช้บางรายพบ ข้อผิดพลาดในการแสดงโมเดล ไปจนถึงช่วงเช้าของวันที่ 10 กุมภาพันธ์
  • หลังจาก GitHub เปลี่ยนโครงสร้างหน้าสถานะบริการ ก็ทำให้ ติดตามความพร้อมใช้งานย้อนหลัง 90 วันได้ยากขึ้น และในข้อมูลไม่เป็นทางการยังพบช่วงที่ ความพร้อมใช้งานต่ำกว่า 90%
  • แม้ Enterprise Cloud SLA จะระบุอัปไทม์ 99.9% แต่ในทางปฏิบัติไม่ได้รับประกันกับผู้ใช้ทุกคน จึงยิ่งตอกย้ำความจำเป็นของ กลยุทธ์การดำเนินงานที่เตรียมรับมือดาวน์ไทม์

ความพร้อมใช้งานที่ลดลงและเหตุขัดข้องของบริการ GitHub ที่เกิดขึ้นบ่อย

  • ท่ามกลางสถานการณ์ที่ บริการคลาวด์ล่มบ่อย กลายเป็นเรื่องปกติ GitHub เองก็เผชิญปัญหาด้านเสถียรภาพเช่นกัน
    • มีถึงขั้นใช้คำว่า “แทบไม่มีวันไหนที่ไม่มีเหตุขัดข้อง” และถูกพูดถึงว่าต่อให้ไม่ถึง ‘5 nines(99.999%)’ ก็แม้แต่ ‘1 nine(90%)’ ก็ยังทำได้ยาก
  • ในวันที่ 9 กุมภาพันธ์ (อิงตาม UTC) ฟังก์ชันหลักของ GitHub อย่าง Actions, Pull Request, การแจ้งเตือน, Copilot ต่างเกิดปัญหาทั้งหมด
    • GitHub แจ้งเมื่อราว 15:54 ว่า “บางบริการมีปัญหา” และระบุว่าการแจ้งเตือนล่าช้าประมาณ 50 นาที
    • เวลา 17:57 ความล่าช้าลดลงเหลือราว 30 นาที และเวลา 19:29 ได้แจ้งว่ากลับสู่ภาวะปกติแล้ว
  • เหตุขัดข้องที่เกี่ยวข้องกับ Copilot กินเวลานานกว่า
    • ตั้งแต่ 9 กุมภาพันธ์ 16:29 ถึง 10 กุมภาพันธ์ 9:57 ผู้ใช้บางรายได้รับผลกระทบจาก ปัญหาการเผยแพร่นโยบายของ Copilot
    • ส่งผลให้มีรายงานว่าโมเดลที่เพิ่งเปิดใช้งานใหม่ไม่แสดงต่อผู้ใช้
  • GitHub เปลี่ยนโครงสร้างหน้าสถานะบริการ ทำให้ ติดตามความพร้อมใช้งานย้อนหลัง 90 วันได้ยากขึ้น
    • แม้ยังมีข้อมูลรายละเอียดให้ แต่รูปแบบถูกเปลี่ยนไปจน มองภาพรวมแนวโน้มอัปไทม์ได้ยากด้วยสายตา
    • จากข้อมูลในหน้ากู้คืนแบบไม่เป็นทางการ (mrshu.github.io/github-statuses/) พบว่ามีช่วงหนึ่งในปี 2025 ที่ความพร้อมใช้งานลดลงต่ำกว่า 90%
  • Enterprise Cloud SLA ของ GitHub ระบุอัปไทม์ 99.9% แต่ ไม่ได้รับประกันสิ่งนี้กับผู้ใช้ทุกคน
    • ในอุตสาหกรรมมองว่า ‘5 nines’ คือเกณฑ์อุดมคติ แต่ผู้ให้บริการบางรายกลับถูกประเมินว่า แม้แต่การรักษาระดับ 90% ก็ยังยาก
    • สถานการณ์นี้ชี้ให้เห็นว่า ลูกค้าจำเป็นต้องจัดทำแผนการดำเนินงานโดยสมมติว่าจะมีดาวน์ไทม์เกิดขึ้น

บริบทและกรณีที่เกี่ยวข้อง

  • ช่วงหลัง GitHub เผชิญข้อถกเถียงหลายประเด็นจาก ฟีเจอร์ AI และการเปลี่ยนนโยบาย
    • การพิจารณา ‘คิลสวิตช์’ สำหรับบล็อกโค้ด AI ใน Pull Request

    • การยกเลิกแผนแพ็กเกจสำหรับ self-hosted runner

      • มีกรณีที่ โครงการภาษา Zig ย้ายออกจาก GitHub โดยให้เหตุผลเรื่องนโยบายที่มุ่งเน้น AI ของ Microsoft
      • เมื่อรวมกับเหตุการณ์เหล่านี้ ความเสถียรของบริการที่ลดลง ก็ยิ่งเป็นปัจจัยที่เพิ่มความไม่พอใจในชุมชนนักพัฒนา

บทสรุป

  • เหตุขัดข้องล่าสุดของ GitHub สะท้อนปัญหาความพร้อมใช้งานที่ แม้แต่ ‘สามเลข 9’ (99.9%) ก็ยังบรรลุได้ยาก
  • เมื่อ ฟังก์ชันสำคัญอย่าง Copilot ยังขาดเสถียรภาพ การสร้าง ความน่าเชื่อถือให้แพลตฟอร์มพัฒนาบนคลาวด์ จึงกลายเป็นโจทย์สำคัญ
  • ความจำเป็นในการ วางกลยุทธ์รับมือดาวน์ไทม์ ถูกเน้นย้ำอีกครั้ง

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

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

 
elbanic 2026-03-26

GitHub เป็นบริการฟรี การจะคาดหวังให้มีความพร้อมใช้งานสูงอยู่แล้วนี่ก็...
 
cosine20 2026-03-27

ถ้า KakaoTalk ล่มขึ้นมา คุณก็จะพูดแบบเดียวกันหรือเปล่า...
 
malkeu 2026-03-26

น่าจะใช้ git reset --hard ได้มั้งนะ
 
master6559 2026-03-25

ถ้า GitHub ไม่ล่ม แบบนี้ต่อไปก็ดีอยู่แล้ว
 
GN⁺ 2026-03-24
ความเห็นจาก Hacker News

  • ปัญหา uptime ของ Github เห็นได้ชัดว่าร้ายแรง แต่จะบอกว่า “Github ทั้งหมดล่ม” เพียงเพราะทุกฟังก์ชันไม่ได้หยุดพร้อมกัน ก็ดูเกินจริงไปหน่อย
    ฉันแทบไม่ได้ใช้ Copilot เลย ดังนั้นถึงบริการนั้นจะล่มบ่อยก็ไม่ได้สนใจ
    สิ่งที่สำคัญจริง ๆ คือเสถียรภาพของฟังก์ชันหลักอย่าง Git, เว็บไซต์, API, Actions

    • เห็นด้วย แต่ในช่วง 90 วันที่ผ่านมา ไม่มีบริการใดบริการหนึ่งที่ทำ 3x9(99.9%) uptime ได้เลย
      ตาม Enterprise SLA ของ GitHub แต่ละบริการควรได้รับการการันตีขั้นต่ำ 99.9% และดูตัวเลขจริงได้ที่นี่
    • คำว่า “Github ล่ม” อาจจะพูดเกินไปจริง แต่ในความเป็นจริงแม้แต่ API ก็ยังได้แค่ 99.69% หรือมีแค่เลข 9 สองตัวเท่านั้น
      Copilot อยู่ในระดับเลข 9 ตัวเดียว และบริการหลักอย่าง Git กับ Actions ก็เช่นกัน
    • บริษัทนี้อยู่ในพอร์ตโฟลิโอของ บริษัทระดับโลกมูลค่า 1 ล้านล้านดอลลาร์
      บริษัทที่มีทรัพยากรขนาดนี้แต่ยังปล่อยลูกค้าไว้แบบนี้ ไม่มีข้อแก้ตัวใด ๆ
    • ทุกวันนี้คำว่า “5 nines” ที่บริษัทยักษ์ใหญ่พูดกัน แทบเป็นภาพลวงตา
      ในทางปฏิบัติ แค่ตอบกลับด้วย error ก็ยังถูกนับว่า “ทำงานปกติ”
      กรณีที่ทำได้ถึง 99.999% จริง ๆ แบบวงการเครือข่ายนั้นมีน้อยมาก ส่วนใหญ่ก็แค่ใช้ กลเม็ดการแบ่งข้อมูล เพื่อให้หน้า status ยังเป็นสีเขียว

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

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

  • ตอนนี้ GitHub กำลังเจอกับปัญหาสามเด้งคือ การย้ายไป Azure, การเปลี่ยนโครงสร้างพื้นฐานโดยใช้ AI, และ ทราฟฟิกจาก AI ที่พุ่งขึ้นอย่างรุนแรง
    โปรเจกต์ยอดนิยมมักจะมี PR หลายสิบรายการ ที่สร้างโดย AI ถาโถมเข้ามาภายในไม่กี่นาทีหลังเปิด issue
    ภาระลักษณะนี้รับมือได้ยาก และ “N 9s” ก่อนยุค AI กับหลังยุค AI นั้นมีระดับความยากต่างกันโดยสิ้นเชิง

    • ใช่เลย GitHub ไม่ได้ถูกออกแบบมาโดยมีสมมติฐานว่าจะต้องรองรับ สภาพแวดล้อมที่ AI agent วิ่งพล่าน แบบนี้ตั้งแต่แรก

  • ถ้าดู หน้า status ของ GitHub จะเห็นว่าความพร้อมใช้งานจริงอยู่ที่ 90.21% หรือระดับเลข 9 ตัวเดียว
    ใน archive ปี 2019 ที่เมื่อก่อนมี incident เดือนละ 1–4 ครั้ง ตอนนี้กลายเป็นเฉลี่ยวันละครั้งไปแล้ว

    • เหตุผลที่ตัวเลขนี้ดูแย่ ไม่ได้มีแค่ downtime อย่างเดียว แต่ยังรวม degraded performance ด้วย
    • แต่ก็ยังมีคนแซวว่าดีกว่า status.claude.com ของ Claude

  • ระหว่างที่ GitHub หมกมุ่นกับฟีเจอร์ AI ความปลอดภัยของแพลตฟอร์มกลับกำลังพังลง
    ไม่นานมานี้ Aqua Security ถูกโจมตีจนมีหลาย repo ติดเชื้อ และนี่คือกรณีที่อาศัย ช่องโหว่ mutable reference ของ GitHub Actions
    GitHub รับรู้ปัญหานี้แล้วแต่ก็ยังไม่แก้

    • ทางแก้ชั่วคราวคือควร pin เวอร์ชันของ Actions ด้วย hash
      ตัวอย่าง: uses: actions/checkout@11bd7190...
      เครื่องมืออัตโนมัติดูได้ที่ mheap/pin-github-action
    • คิดว่า CI/CD มันยุ่งเหยิงเกินไปเพราะ ความซับซ้อนแบบ YAML-based
      เมื่อก่อน deploy ด้วย Jenkins แล้วให้สคริปต์จัดการเทสต์ง่าย ๆ แต่ตอนนี้มันกลายเป็น นรก YAML แบบกระจัดกระจาย ไปแล้ว
    • ความปลอดภัยของ GHA แย่ถึงขั้นมีคนพูดว่า “มีรูมากกว่าชีสสวิสเสียอีก”
    • ยังมี การถกเถียงในชุมชน ที่ปล่อยปัญหาพวกนี้ค้างมาหลายปี

  • uptime 90% เป็นตัวเลขที่รวมทุกบริการเข้าด้วยกัน ดังนั้นประสบการณ์จริงอาจไม่ตรงกันเป๊ะ
    แต่แม้แต่ 96.47% ของ Copilot ก็ยังมีแค่เลข 9 ตัวเดียวอยู่ดี
    GitHub แนะนำให้ “ใช้ทุกฟังก์ชันร่วมกัน” แต่ยิ่งทำแบบนั้น ความน่าเชื่อถือก็ยิ่งลดฮวบ

    • แถมกรณีที่ “ช้าแต่ยังพอใช้ได้” ก็ไม่ได้ถูกนับในสถิติ
      อย่างเช่นแค่เปิด PR diff ธรรมดายังใช้เวลาเกิน 30 วินาที
    • incident บางอย่างก็ถูกรายงานอย่างเป็นทางการ ล่าช้า ด้วย
      เคยมีกรณีที่ CI/CD, git และฟังก์ชัน PR หยุดพร้อมกันทั้งหมด
    • ถ้าเทียบกับ ข้อมูลปี 2019 ตอนนี้มัน แย่ลงมากกว่า 10 เท่า
    • 96% เป็นตัวเลขที่แย่มากจริง ๆ

  • จากมุมมองของคนที่เคยดูแล GitHub Enterprise Server เอง ปัญหาเหล่านี้ไม่น่าแปลกใจเลย
    มันไม่รองรับข้อกำหนดพื้นฐานของ high availability อย่าง ไม่รองรับ active-active, อัปเกรดแบบไม่มี downtime ไม่ได้, rollback ไม่ได้
    ถ้ามีบั๊กก็แทบไม่มีทางเลือกนอกจาก restore จาก backup ซึ่งระหว่างนั้นก็เกิด การสูญเสียข้อมูล
    การที่ยังขายผลิตภัณฑ์แบบนี้ให้ลูกค้าระดับพรีเมียม สะท้อนถึง ความไม่ใส่ใจเรื่อง availability อย่างชัดเจน

    • สุดท้ายบริษัทเราก็เลิกใช้ GHES แล้ว ย้ายไป GHEC

  • Microsoft มีพรสวรรค์ในการ ทำของดีให้พัง
    Skype เป็นตัวอย่างเด่น และ Windows, Notepad, Explorer ก็เช่นกัน
    ความสับสนด้านแบรนด์แบบ Office → Office 365 → Microsoft 365 → Copilot 365 ก็หนักไม่แพ้กัน

    • ดูท่าวันที่ “GitHub for Business” จะออกมาก็คงอีกไม่นาน

  • บริษัทของเราใช้ GitHub Actions สแกนความปลอดภัย ทุกครั้งที่มี PR
    ถ้า GitHub ล่ม security gate ก็หยุดไปด้วย และนักพัฒนาก็ merge โดยไม่มีการตรวจสอบ
    ในสถานการณ์แบบนี้ โค้ดที่มีช่องโหว่ ก็หลุดเข้ามาได้ แต่ GitHub กลับทุ่มคนไปที่ Copilot อย่างเดียว

    • ก็มีคนถามเหมือนกันว่ามี กรณีตัวอย่างที่เปิดเผยต่อสาธารณะ เกี่ยวกับเรื่องนี้ไหม

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

    • คุณภาพของการตรวจสอบก็ ย่ำแย่พอ ๆ กับระดับสถาปัตยกรรม