รายงานเหตุขัดข้อง: Railway ถูก Google Cloud บล็อก [แก้ไขแล้ว]

 (status.railway.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การขัดข้องของบริการในวงกว้างของ Railway ได้รับการแก้ไขแล้ว โดยยืนยันสาเหตุว่าเกิดจากบัญชี Google Cloud ของ Railway ถูกบล็อก
  • ระหว่างเกิดเหตุ ผู้ใช้อาจพบ "no healthy upstream", "unconditional drop overload", เข้าสู่ระบบล้มเหลว, และไม่สามารถเข้าถึงแดชบอร์ดได้
  • Railway ได้ติดต่อกับทีม Google Cloud Support โดยตรงเพื่อกู้คืนการเข้าถึงบัญชี และดำเนินการกู้คืน control plane กับ workload
  • ระหว่างกระบวนการกู้คืน ยังมี ปัญหาเครือข่าย ฝั่ง Google Cloud เหลืออยู่ ทำให้บางบริการไม่สามารถเริ่มทำงานได้ และมีการจำกัดบิลด์ที่ไม่ใช่ enterprise ชั่วคราว
  • บริการกลับมาทำงานได้สมบูรณ์แล้ว แต่ workload บางส่วนที่ถูกตรวจพบว่าผิดปกติกำลังถูก redeploy อัตโนมัติ และหากจำเป็น ผู้ใช้อาจต้อง redeploy ด้วยตนเอง

ภาพรวมเหตุขัดข้องและสถานะสุดท้าย

  • Railway ได้แก้ไขเหตุขัดข้องของบริการในวงกว้างแล้ว และสามารถดูการวิเคราะห์หลังเหตุการณ์ได้ที่ Incident Report
  • ระหว่างช่วงเวลาที่เกิดเหตุ ผู้ใช้อาจพบ "no healthy upstream", "unconditional drop overload", การเข้าสู่ระบบล้มเหลว และไม่สามารถเข้าถึงแดชบอร์ดได้
  • สาเหตุคือ บัญชี Google Cloud ของ Railway ถูกบล็อก ส่งผลให้บางบริการของ Railway ใช้งานไม่ได้
  • Railway ได้ติดต่อกับทีม Google Cloud Support โดยตรงเพื่อกู้คืนการเข้าถึงบัญชีและดำเนินการกู้คืน workload
  • บริการกลับมาทำงานได้สมบูรณ์แล้ว แต่ workload บางส่วนที่ถูกตรวจพบว่าอยู่ในสถานะผิดปกติกำลังถูก redeploy อัตโนมัติ และบริการที่ยังตอบสนองไม่ปกติอาจต้องให้ผู้ใช้ redeploy เอง

ความคืบหน้าในการกู้คืนและผลกระทบต่อผู้ใช้

  • การตรวจสอบเบื้องต้นและการยืนยันสาเหตุ

    • Railway ได้กู้คืนโครงสร้างพื้นฐาน Google Cloud ที่ใช้รัน control plane ของแดชบอร์ด, API และเครือข่ายภายในแล้ว
    • แม้จะกู้คืนการเข้าถึงผู้ให้บริการคลาวด์ต้นทางได้แล้ว แต่แดชบอร์ดของ Railway และบริการที่รันบนโครงสร้างพื้นฐานคลาวด์ยังอาจได้รับผลกระทบต่อเนื่องจนกว่าจะมีการปล่อยการแก้ไข
    • หลังจากบัญชี Google Cloud ถูกบล็อก ทีมแพลตฟอร์มของ Railway ได้ยืนยันการเข้าถึงโครงสร้างพื้นฐานบางส่วนที่โฮสต์บน Google Cloud และกู้คืนการเข้าถึงบริการส่วนที่เหลือ

  • Google Cloud และปัญหาเครือข่าย

    • Railway ได้กู้คืน compute บน Google Cloud แล้ว แต่ยังมี ปัญหาเครือข่าย ฝั่ง Google Cloud ค้างอยู่ ทำให้บางบริการไม่สามารถเริ่มทำงานได้
    • ระหว่างการกู้คืน workload ที่โฮสต์บน Google Cloud อาจยังพบปัญหาเป็นระยะ
    • ทีมโครงสร้างพื้นฐานของ Railway ยังพิจารณา เส้นทางทางเลือก เพื่อทำให้บริการที่ได้รับผลกระทบกลับมาออนไลน์อีกครั้ง

  • ข้อจำกัดด้านบิลด์และการ deploy

    • workload แบบ metal ของ Railway เริ่มกลับมาทำงานได้ทีละส่วน
    • ระหว่างกระบวนการกู้คืน มีการจำกัด บิลด์ที่ไม่ใช่ enterprise ทั้งหมดชั่วคราวเพื่อหลีกเลี่ยงภาระเกินของโครงสร้างพื้นฐานด้านบิลด์
    • ต่อมา deployment ที่ไม่ใช่ enterprise ยังคงอยู่ในสถานะหยุดชั่วคราว ขณะที่ deployment สำหรับ enterprise ไม่ได้รับผลกระทบ
    • แม้จะกลับมา deploy ได้อีกครั้งแล้ว แต่ workload ที่ยังคงอยู่บน Google Cloud อาจยังพบปัญหาเป็นระยะจนกว่าการกู้คืนจะเสร็จสมบูรณ์

  • มาตรการปัจจุบัน

    • บริการของ Railway กลับมาทำงานได้สมบูรณ์แล้ว และบริการที่ยังตอบสนองไม่ปกติควร redeploy ผ่านแดชบอร์ดหรือ CLI
    • ดูบริบทเพิ่มเติมได้ที่ FAQ และหากต้องการความช่วยเหลือโดยตรง สามารถเปิดเธรดได้ที่ Railway Station

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

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

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

  • Railway แก้ไขเหตุขัดข้องนี้แล้วและเผยแพร่การวิเคราะห์หลังเหตุการณ์
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    ณ เวลา 07:57 UTC ของวันที่ 20 พฤษภาคม มีหน้า status ขึ้นแล้ว
    https://status.railway.com/incident/I23M92U0

    • ในกรณีแบบนี้ควรจะสามารถ เรียกค่าเสียหายจาก Google ได้ นี่ไม่ใช่ปัญหาประเภทเครือข่ายล่มหรือบริการล้มเหลวที่พอจะอยู่ในเงื่อนไขการให้บริการได้
    • Railway บอกว่าเหตุขัดข้องได้รับการแก้ไขแล้ว แต่หลายบริการยังคงล่มและตอบกลับเป็น 502 ฝั่งเราต้องสั่ง redeploy ด้วยตนเองถึงจะกลับมาได้ ทั้งที่ Railway ควรทำให้อัตโนมัติ
      โดยรวมแล้ว downtime ของฝั่งเรานานกว่า 11 ชั่วโมง

  • นับเป็นวันที่ 0 อีกครั้งที่ GCP ทำสตาร์ตอัปล่ม
    รู้สึกว่าอย่างน้อยปีละครั้งจะเห็นอะไรแบบนี้ และไม่เคยได้ยินว่า AWS หรือ Azure ทำแบบนี้
    พูดกันจริง ๆ นี่แหละเหตุผลที่ไม่ใช้ GCP ทั้งที่เป็นคลาวด์ของบิ๊ก 3 ที่ใช้ง่ายที่สุด แต่กลับทำลายตัวเองด้วยชื่อเสียงแบบนี้

    • กลับกัน ผมแทบจำไม่ได้เลยว่า GCP เคยมี outage ใหญ่ ๆ ส่วน AWS/Azure เหมือนจะมีล่มระดับหายนะปีละหลายครั้ง
    • AWS ทำได้มีประสิทธิภาพกว่า ถ้า us-east-1 ล่ม ก็ล้มสตาร์ตอัปหลายแห่งพร้อมกันได้เลย
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      ฝั่ง Azure เองปีที่แล้วก็ทำ front door ของ Azure และ O365 พังทั้งชุด
      บริษัทพวกนี้ต่างก็มีสิ่งที่ตัวเองทำได้ดี แต่บางครั้งก็พังหนักเหมือนกัน
    • เคยมีครั้งที่ AWS throttle บริการของเราหนักเกินจนใช้งานต่อไม่ได้ ผมเคยคิดจะเขียนว่าพวกเขาหยุดการเติบโตของเราไปหนึ่งเดือนเต็ม แต่ตอนนี้คงไม่มีประโยชน์มากแล้ว
    • เราก็ไม่แตะ GCP ด้วยเหตุผลเดียวกัน

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

    • ผมก็มีแค่ประสบการณ์ส่วนตัวเหมือนกัน แต่เห็นด้วย ทีมพัฒนาของ Railway ให้ความรู้สึกว่าทำงานแบบหลวม ๆ และผสม vibe coding ไปทั่ว มีระดับของคำว่า “ก็ยังเป็นสตาร์ตอัป ขอให้เข้าใจกันหน่อย” อยู่ แต่ Railway ข้ามเส้นนั้นไปแล้ว
    • ใช่ ในอีกเธรดหนึ่งเห็นหลายแอ็กเคานต์วิจารณ์ผู้ให้บริการคลาวด์อย่างรุนแรง แต่กลับแทบไม่มีใครในกระแสความโกรธนี้สนใจถามถึง สาเหตุราก หรือพิจารณาความเป็นไปได้อื่นเลย ซึ่งแปลกมาก
    • เมื่อ 2 ปีก่อนผมต้องการความช่วยเหลือ แต่เจอประสบการณ์แย่มากจนย้ายไป Vercel แล้วบอกลาไปเลย
      ตอนหาสิ่งที่คล้ายกันสำหรับบริการอื่น ผมไปเจอ coolify ถ้าใช้ coolify ได้ ก็ไม่มีเหตุผลอะไรเลยที่จะใช้ Railway
    • ถ้าพอจะเล่ากรณีในอดีตแบบเจาะจงได้ ผมอยากอ่าน
    • ผมได้ยินรายละเอียดบางอย่างที่ผมไม่ควรรู้ และกล้าพูดได้อย่างมั่นใจว่านี่เป็นความผิดของ Google 100% ถ้า Railway แบ่งปันข้อมูลได้มากกว่านี้ไม่ได้ ผมคงผิดหวัง
      นอกจากหลีกเลี่ยง GCP ไปเลยแล้ว Railway ไม่มีทางป้องกันเรื่องนี้ได้จริง ๆ

  • ยังมี เหตุขัดข้องของ UniSuper ในเดือนพฤษภาคม 2024 ด้วย: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    ตามแถลงการณ์ร่วมของ Peter Chun ซีอีโอของ UniSuper และ Thomas Kurian ซีอีโอของ Google Cloud มีความผิดพลาดจากการตั้งค่าที่ประมาทระหว่างการ provision บริการ Private Cloud ของ UniSuper และท้ายที่สุด subscription ของ Private Cloud ของ UniSuper ถูกลบ
    Google Cloud ระบุว่านี่เป็น “เหตุการณ์ครั้งเดียวที่ไม่เคยเกิดขึ้นมาก่อน” แบบเฉพาะจุดสำหรับลูกค้า Google Cloud รายใดก็ตามทั่วโลก แต่การลบ subscription นี้กลับทำให้เกิดการลบทั้งสอง region และต้องใช้การกู้คืน virtual machine, database และ application หลายร้อยรายการ

    • ตอนนั้นผมเขียนเกี่ยวกับกรณี UniSuper ไว้: https://danielcompton.net/google-cloud-unisuper
      มันเป็นบั๊กที่ร้ายแรงมาก และ environment VMWare ของพวกเขาถูกสร้างขึ้นโดยมี วันหมดอายุ 1 ปี และจากมุมมองของ Google Cloud มันถูกมองเป็น “resource” เดียว
    • ประโยคที่ว่า “การลบ subscription ของ Private Cloud ทำให้ทั้งสอง region ถูกลบ” นี่แหละที่เรียกว่า single point of failure และสำหรับใครก็ตามที่เคยรับผิดชอบเรื่องความปลอดภัย นี่คือฝันร้ายชัด ๆ
    • โครงสร้างที่พอปิดหรือลบ subscription แล้วเกิดการลบต่อเนื่องทั่วโลกทันที ฟังดูเหมือนสูตรสำเร็จของหายนะ ไม่เข้าใจว่าทำไมไม่แค่ mark ไว้ก่อนแล้วค่อยลบหลังจากหนึ่งวันหรือหนึ่งสัปดาห์

  • ไม่เข้าใจจริง ๆ ว่าเรื่องแบบนี้เกิดขึ้นได้อย่างไรกับบริษัทที่มียอดใช้จ่ายรายเดือนสูง ขณะที่งานก่อน ตอนมี workload น่าสงสัยรันอยู่บน AWS TAM จะติดต่อมาก่อนลงมือเสมอ
    กรณีนี้ดูเหมือนเป็นระบบอัตโนมัติจาก AI ที่ทำงานผิดพลาด และ GCP ก็ดูเหมือนไม่ชอบติดต่อมนุษย์จริง ๆ เพื่อให้ตอบกลับ เลยอาจจบลงที่ผู้รับจ้างภายนอกมาเห็นในคิวซัพพอร์ตหลายชั่วโมงให้หลังแล้วส่งคำตอบตามสคริปต์กลับมา

    • ถ้าเป็นเรื่องเกี่ยวกับซัพพอร์ตของ GCP ตอนนี้คงไม่มีอะไรทำให้ผมแปลกใจแล้ว ทั้งที่เราไม่ต้องการเลย แต่ใน 6 ปีที่ผ่านมาเปลี่ยน Account Executive ให้เราเกิน 12 คน และทุกคนก็ไร้ประโยชน์โดยสิ้นเชิง
      ทุกครั้งก็เข้ามาแนะนำตัว ขอจัดประชุมกับทีมวิศวกรรมของเรา พร้อมสไลด์มาตรฐานที่ไม่เกี่ยวข้องกับเราเลยจนมีแต่จะขำ และครั้งถัดไปที่ได้ยินข่าวก็ตอนมี AE คนใหม่มารับช่วง
      ผมชอบ GCP และบริการของมัน และพอใจมาหลายปี แต่ฝั่งคนแย่มากจริง ๆ จนไม่เข้าใจว่าทำไมต้องมีระบบนี้ด้วย
    • เหมือนจะมีคำตอบที่มีสาระอยู่ในอีกเธรดหนึ่งด้วย เราเองก็ได้ account กลับคืนมา แต่ถึงจะมี Account Rep และ CSM ก็ยังต้องใช้เวลากว่าจะรู้ว่าเกิดอะไรขึ้น
      ถ้าไม่มีคนประจำดูแลอาจจะแย่กว่านี้อีก
    • ก็เพราะเป็น Google น่ะสิ ปล่อยให้คุณใช้บริการได้ แต่พอคุณออกนอกบรรทัดฐานเมื่อไร ก็สั่งระงับทันที

  • ในฐานะคนที่ดูแล public API ปริมาณสแปมที่มาจาก Railway IP นั้นมากจนน่าตกใจ ระบบป้องกันการใช้งานในทางที่ผิดแย่มาก และหวังว่าเหตุการณ์นี้จะเป็นแรงผลักดันให้พวกเขาปรับปรุงการปฏิบัติการ

    • ตอนที่ผมทำบริษัทโฮสติ้ง ความขัดแย้งหลักก็คือเรื่องนี้เลย ถ้าทำให้สมัครง่าย ก็จะมีผู้ใช้ใหม่เยอะ แต่ก็มี การใช้งานในทางที่ผิด เยอะตามมา
      ถ้าใส่มาตรการป้องกัน ก็จะมี false positive เสียงดังตามมา และกรณี GCP ครั้งนี้ก็อาจเป็นแบบนั้นได้
      ผมไม่อิจฉาใครก็ตามที่ทำธุรกิจโฮสติ้งเลย อินเทอร์เน็ตใต้ผิวน้ำนั้นสกปรกมากจริง ๆ
      เพิ่มเติมคือ AWS ทำเรื่องนี้ได้ดีมาก น่าจะเพราะมีประสบการณ์รับมือการฉ้อโกงและการใช้งานผิดประเภทจากธุรกิจค้าปลีกมาราว 30 ปี

  • เดี๋ยวก่อน Railway รันอยู่บน GCP เหรอ? ไม่ใช่ว่าเคยพูดเสียงดังมากว่า “เราไม่สร้างคลาวด์บนคลาวด์อื่น” หรอกหรือ?
    หรือหมายถึงพวกเขาไม่ได้เช่า VPS แต่เช่าเฉพาะ bare metal จากผู้ให้บริการคลาวด์?
    อย่างน้อยผมเคยหวังว่าจะมีผู้ให้บริการอีกรายที่ไม่ได้แค่จ่ายเงินให้ hyperscaler เจ้าใดเจ้าหนึ่ง แต่ทำ colocation และเป็นเจ้าของสแตกมากกว่านี้
    https://blog.railway.com/p/heroku-walked-railway-run

    • ในบทความที่ลิงก์ไว้ซึ่งดูผ่าน Wayback Machine มีข้อความว่า
      “ตั้งแต่วันแรก เราให้แนวคิดนี้อยู่แถวหน้ามาตลอด
      และอีกสิ่งที่เราสัมผัสได้จากสัญชาตญาณคือ เราไม่สามารถสร้าง cloud บน cloud ของคนอื่นได้ Railway จึงทุ่มเวลาหลายปีไปกับการรันเซิร์ฟเวอร์ของตัวเองและพัฒนาการปฏิบัติจริงเพื่ออยู่ร่วมกับคลาวด์อื่นอย่างกลมกลืน เพื่อให้ธุรกิจของ Railway และท้ายที่สุดคือลูกค้าของเรา แข็งแกร่งที่สุดเท่าที่จะเป็นไปได้”
    • ใช่ และนั่นแหละที่ทำให้โกรธ พวกเขาโกหก พวกเขาพึ่งพา GCP อย่างเต็มตัว
      ตอนนี้คงต้องเริ่มหาข้อมูลแล้วว่ามีอะไรที่เสถียรกว่านี้และพึ่งพาความแปรปรวนของบริษัทเดียวได้น้อยกว่านี้บ้าง
      สำหรับ Railway เองนี่ก็เป็นเรื่องเลวร้าย เพราะมันโจมตีตรงหัวใจของคำกล่าวอ้างใหญ่ของพวกเขาเรื่อง การ deploy ซอฟต์แวร์อย่างสงบสุข นี่ไม่ใช่ความสงบ นี่คือความโกลาหล

  • ผมนึกว่า Railway กำลังสร้าง data center ของตัวเองอยู่ [0]
    “ในทางปฏิบัติแล้ว เราไม่สามารถสร้างคลาวด์บนคลาวด์ของคนอื่นได้”
    ก็เห็นได้ชัดจริง ๆ ...
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel ดูเหมือนจะทำได้ ส่วน PlanetScale ก็เหมือนจะทำได้อย่างน้อยในมุมของ database และเอาเข้าจริงทุกอย่างก็คือ database อยู่แล้ว

  • ตอนสมัคร Railway วิธีที่ให้ยืนยันว่าได้อ่านและเข้าใจข้อกำหนดเกี่ยวกับการใช้งานระบบในทางที่ผิด การขุดคริปโต ฯลฯ นั้นค่อนข้างแปลก
    เดาได้ว่ามีผู้ใช้จำนวนมาก ใช้ free tier ในทางที่ผิด จนทำให้ผู้ให้บริการมีปัญหา
    ต่อให้เป็นคู่แข่งกัน ผมก็ไม่ได้ยินดีกับการที่ Railway โดนเล่นงานแบบนี้ แต่ compute ฟรีดึงดูดผู้ใช้ประหลาดสารพัด เราเองก็เคยเจอ และตัดสินใจหลีกเลี่ยง compute ฟรีในช่วงแรก แม้ว่าจะทำให้จำนวนผู้ใช้ช่วงบนของ funnel ลดลงก็ตาม

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

    • ผมไม่ค่อยเข้าใจว่าคุณหมายถึงอะไร คุณคาดหวังจริง ๆ เหรอว่า Railway ควรใช้ สถาปัตยกรรม multi-cloud เพื่อโฮสต์ทุกโปรเจกต์ของลูกค้า? มองภาพรวมแล้วผมคิดว่านั่นน่าจะยิ่งลดความพร้อมใช้งานมากกว่า
    • ระบบ disaster recovery มันก็แพงมากไม่ใช่เหรอ โดยเฉพาะในขนาดของ Railway