ประวัติการให้บริการของ GitHub ในอดีต

 (damrnelson.github.io)
1 คะแนน โดย GN⁺ 29 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หน้าเว็บที่แสดงภาพข้อมูลของ เวลาพร้อมใช้งานรายเดือนของ GitHub ตั้งแต่ปี 2016 ถึง 2026
    • ข้อมูลทั้งหมดอ้างอิงจากบันทึกที่รวบรวมมาจาก หน้าสถานะอย่างเป็นทางการ
  • โครงสร้างที่สามารถแยกดูได้ระหว่าง ค่าเฉลี่ยเวลาพร้อมใช้งาน (Average) และ รายละเอียดการหยุดให้บริการ (Breakdown)
  • สามารถเข้าถึง แหล่งข้อมูลต้นฉบับ (View source) ได้โดยตรงภายในหน้าเว็บ
  • เป็นสื่อการแสดงภาพที่ช่วยให้เห็น แนวโน้มเสถียรภาพของบริการ ในระยะยาวได้อย่างรวดเร็ว
  • เป็นรูปแบบที่ เน้นการแสดงภาพข้อมูลเป็นหลัก โดยไม่มีการวิเคราะห์หรือคำอธิบายเพิ่มเติม

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

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

 
GN⁺ 29 일 전
ความคิดเห็นจาก Hacker News

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

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

  • ส่วนตัวคิดว่าหน้า สถานะทางเลือกนี้ ดีกว่า
    ใช้ชื่อว่า “The Missing GitHub Status Page” และแสดง อัตราความพร้อมใช้งาน ในช่วง 90 วันที่ผ่านมาแบบภาพรวม
    ตอนนี้อยู่ที่ 90.84% ดีขึ้นเล็กน้อยจาก 90.00% เมื่อไม่กี่วันก่อน

    • ช่วงหลังมานี้สถานการณ์ค่อนข้าง หนักหน่วง
      อัตราความพร้อมใช้งานของ GitHub Actions ในเดือนกุมภาพันธ์ 2026 อยู่ที่ 98% ซึ่งมีเลข 9 แค่ตัวเดียว
      จากความรู้สึกเหมือนล้มเหลวประมาณ 1-2 ครั้งต่อ 50 ครั้ง (ราว 2%)
    • ตัวเลข ภาพรวม แบบนี้ดูไม่ใช่ตัวชี้วัดที่สมเหตุสมผลนัก
      เช่น เวลาที่ OpenAI ล่มแล้ว CoPilot ใช้งานไม่ได้ จะนับเป็น downtime ของ GitHub ได้ไหมก็ยังน่าสงสัย
    • จริง ๆ แล้วสองหน้านี้ก็แค่แสดงสถิติเดียวกันคนละแบบ
      ดูเหมือน OP จะนำเสนอเพื่อเน้นผลลัพธ์หลัง Microsoft เข้าซื้อกิจการ
    • ถ้าคิดว่า “90% เท่ากับ downtime เกือบ 5 สัปดาห์”
      แม้จะเป็นมุกตลก แต่ตอนนี้ GitHub ก็ดูเหมือนจะมีสิทธิ์ได้รับ ‘วันลาพักร้อนแบบได้เงินเดือน’ ระดับนั้นแล้ว

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

    • ใน “Breakdown” ถ้าคลิก “Actions” ก็สามารถซ่อนรายการนั้นได้
    • ถ้าดูหน้ารายละเอียด แม้ขนาดของแต่ละบริการจะเล็กลง แต่ แนวโน้มโดยรวมยังเหมือนเดิม
    • ที่แย่กว่าคือ แม้ในช่วงที่ยังไม่มีบริการนั้นอยู่ ก็ยังแสดงเป็น “100% uptime”

  • ฉันเองก็ลองทำกราฟเดียวกันนี้ด้วย Claude เมื่อไม่กี่สัปดาห์ก่อน
    เดิมคิดว่าน่าจะมีการลดลงอย่างชัดเจนก่อนและหลัง Microsoft เข้าซื้อกิจการ แต่ในความเป็นจริง รูปแบบเหตุขัดข้องที่ไม่สม่ำเสมอ มีมาต่อเนื่องตั้งแต่ก่อนหน้านานแล้ว
    เรื่องเล่าว่าก่อนถูกซื้อกิจการเสถียรกว่านั้นก็น่าสนใจ แต่ตอนนั้นยังไม่มีผลิตภัณฑ์อย่าง Actions
    สำหรับบริการที่มีอยู่แล้ว (API, Git ops, Pages ฯลฯ) กลับดูเหมือนอธิบายได้ด้วย การปรับปรุง observability มากกว่า

    • หลังจาก Actions เปิดตัว ก็ให้ความรู้สึกเหมือนเริ่มเข้าสู่ ฝันร้าย ในแง่การปฏิบัติการและความพร้อมใช้งาน
      จากนั้นปัญหาก็ลามไปยังส่วนที่เคยเสถียรอย่าง Issues หรือ PR
    • ส่วนตัวคิดว่า GitHub Actions ควรหายไปเสียที
      เดิมที Git ถูกออกแบบมาให้ทำสิ่งเดียวให้ดี แต่การ ยัดฟีเจอร์ที่ไม่จำเป็นเข้าไปเต็มไปหมด แบบนี้เป็นความผิดพลาดครั้งใหญ่

  • ถ้าใครกำลังหาสาเหตุ บทความนี้ของ The New Stack อาจอธิบายได้

    • เห็นด้วยอย่างยิ่ง เหตุขัดข้องของ Azure และ GitHub ของทีมเรามักเกิดขึ้นแทบพร้อมกัน
      ตอนนี้มันกลายเป็นมีมไปแล้ว
    • แต่ก็คิดว่ายากจะอธิบาย ความพร้อมใช้งานต่ำ ที่ต่อเนื่องมากว่า 6 ปีด้วยเหตุผลนี้เพียงอย่างเดียว
      ควรทดสอบในสภาพแวดล้อมแยกให้เพียงพอ แล้วค่อยย้ายไป Azure ในช่วงเวลาสั้น ๆ

  • ตอนนี้ ฟังก์ชันรวม PR ใช้งานไม่ได้
    ตรวจสอบสถานะที่เกี่ยวข้องได้จาก หน้า GitHub Status Incident

  • จำได้ว่าเมื่อก่อนเห็น หน้า error รูปยูนิคอร์น บ่อยมาก
    น่าจะเป็นช่วงที่หน้า status ยังไม่ได้อัปเดตบ่อยนัก

    • ดูเหมือนว่ายูนิคอร์นจะเป็น error เฉพาะหน้าเว็บ
      บริการอย่าง Git API ก็อาจพังแยกกันได้ และในหน้า status มักจะ สะท้อนช้ากว่าเหตุการณ์จริง

  • ตอนนี้บันทึก downtime ของ GitHub แย่กว่าเซิร์ฟเวอร์ส่วนตัวของฉัน เสียอีก
    ทั้งที่ฉันรีบูตหรือหยุดบริการบ่อยเพราะทดลองอะไรหลายอย่าง

    • ถึงอย่างนั้นเราก็ยังจ่ายเงินอยู่
      เหมือนยังเชื่อว่าระดับ QoS จะคงอยู่แม้คุณภาพจะลดลง
    • แม้แต่ VPS เครื่องเล็กของฉันก็ยัง เสถียรกว่า GitHub แบบวัดได้จริง

  • ฉันไม่ได้จะปกป้อง GitHub แต่กราฟนั้น บิดเบือนแกน
    เพราะซูมเฉพาะช่วงต่ำกว่า 99.5% เลยทำให้ดูแย่กว่าความเป็นจริงมาก

    • แต่ถ้าเริ่มกราฟจาก 0 ก็จะมองไม่เห็นความต่างระหว่างบริการที่ดีและแย่
      SLA สำหรับองค์กรคือ 99.9% แต่ด้านล่างของกราฟแสดง downtime มากกว่านั้น 5 เท่า
      ดังนั้นมันไม่ได้แค่ดูแย่ แต่แย่จริง
    • กราฟไม่ได้สะท้อนปัจจัยเรื่อง โหลด (load)
      ควรคำนึงด้วยว่าก่อน Microsoft เข้าซื้อกิจการ เคยจำกัดรีโพซิทอรีส่วนตัวไว้แค่หนึ่งรายการ
    • ไม่จำเป็นต้องวาดกราฟ uptime โดยเริ่มจาก 0
      การแสดงเฉพาะช่วง 99% ขึ้นไปถือว่าสมเหตุสมผล
      ส่วน log scale นั้นฉันมองว่าเกินไปหน่อย

  • ฉัน deploy เว็บไซต์ด้วย GitHub Pages เลยไปหาข้อมูลเรื่อง ความพร้อมใช้งานของ static hosting แยกต่างหาก
    ตาม บทวิเคราะห์ในบล็อกนี้ GH Pages ทำผลงานในด้านนี้ได้ค่อนข้างดี
    แต่ความดีความชอบนั้นน่าจะยกให้ Fastly CDN มากกว่า