รายงานเหตุขัดข้อง: 19 พฤษภาคม 2026 – การระงับบัญชี GCP

 (blog.railway.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิด เหตุขัดข้องทั่วทั้งแพลตฟอร์มของ Railway เป็นเวลาประมาณ 8 ชั่วโมงตั้งแต่ 19 พฤษภาคม 2026 เวลา 22:20 UTC และสาเหตุโดยตรงคือการระงับบัญชีโปรดักชันของ Google Cloud
  • แดชบอร์ดและ API เริ่มส่งกลับ ข้อผิดพลาด 503 ทันที และคอมพิวต์, ฐานข้อมูล, control plane และโครงสร้างพื้นฐาน burst-compute ที่โฮสต์บน Google Cloud ถูกเปลี่ยนเป็นออฟไลน์
  • เวิร์กโหลดบน Railway Metal และ AWS ยังคงทำงานต่อ แต่ edge proxy พึ่งพา control plane API บน Google Cloud และหลังแคชเส้นทางหมดอายุ ข้อผิดพลาด 404 ก็แพร่กระจายออกไป
  • แม้กู้คืนการเข้าถึงบัญชีได้แล้ว แต่ persistent disk, compute instance และ networking ยังต้องกู้คืนแยกกัน และการจำกัดอัตราของ GitHub OAuth กับ webhook ก็ยิ่งขัดขวางการล็อกอินและการบิลด์เพิ่มเติม
  • Railway ยอมรับความรับผิดชอบต่อ การตัดสินใจด้านสถาปัตยกรรม ที่ทำให้การดำเนินการของผู้ให้บริการต้นทางรายเดียวลุกลามเป็นเหตุขัดข้องทั้งระบบ และกำลังออกแบบระบบใหม่เพื่อนำ Google Cloud ออกจาก hot path ของ data plane

ผลกระทบ

  • ตั้งแต่ 19 พฤษภาคม 2026 เวลา 22:20 UTC ถึงประมาณ 20 พฤษภาคม เวลา 06:14 UTC Railway เกิดเหตุขัดข้องทั่วทั้งแพลตฟอร์มเป็นเวลาประมาณ 8 ชั่วโมง
  • เมื่อ Google Cloud ระงับบริการของ บัญชีโปรดักชัน ของ Railway ทำให้ API, control plane, ฐานข้อมูล และโครงสร้างพื้นฐานคอมพิวต์ที่โฮสต์บน Google Cloud ถูกเปลี่ยนเป็นออฟไลน์
  • ผู้ใช้พบ ข้อผิดพลาด 503 ทันทีบนแดชบอร์ดและ API และไม่สามารถล็อกอินได้ พร้อมข้อความ "no healthy upstream" และ "unconditional drop overload"
  • เวิร์กโหลดทั้งหมดที่โฮสต์บน Google Cloud Compute กลายเป็นออฟไลน์
  • แม้ตัวเวิร์กโหลดบนสภาพแวดล้อม Railway Metal และ AWS burst-cloud จะยังทำงานต่อ แต่ edge proxy ของ Railway ยังพึ่งพา control plane API ที่โฮสต์บน Google Cloud เพื่อเติมตาราง routing
  • เมื่อแคช network route หมดอายุ เวิร์กโหลดที่อยู่นอก Google Cloud ก็ไม่สามารถเข้าถึงได้ และ network control plane ไม่สามารถ resolve route ของอินสแตนซ์ที่ยังทำงานอยู่ จึงส่งกลับ ข้อผิดพลาด 404
  • ณ จุดที่ได้รับผลกระทบสูงสุด เวิร์กโหลด Railway ในทุกรีเจียนไม่สามารถเข้าถึงได้
  • ระหว่างกู้คืนสภาพแวดล้อม Google Cloud การบิลด์และการ deploy ทั่วทั้งแพลตฟอร์มถูกบล็อกไปด้วยขณะกู้คืนบริการแต่ละส่วน
  • หลังโครงสร้างพื้นฐานทั้งหมดกลับมาแล้ว งาน deploy ที่ค้างอยู่จำนวนมากถูกประมวลผลแบบค่อยเป็นค่อยไปเพื่อไม่ให้แพลตฟอร์มรับภาระเกิน
  • ในเวลาเดียวกัน GitHub ได้จำกัดอัตรา การเชื่อมต่อ OAuth และ webhook ของ Railway ทำให้การล็อกอินและการบิลด์ถูกบล็อกชั่วคราว
  • ปริมาณการเรียกใช้งานที่เพิ่มขึ้นเป็นผลจากแคชถูกล้างเพราะเหตุขัดข้องของ Google Cloud
  • บันทึกการยอมรับข้อกำหนดในการให้บริการก็ถูกรีเซ็ต ทำให้ผู้ใช้ต้องยอมรับใหม่เมื่อเข้าแดชบอร์ดครั้งถัดไป
  • Railway ยอมรับความรับผิดชอบต่อ การตัดสินใจด้านสถาปัตยกรรม ที่ทำให้การดำเนินการของผู้ให้บริการต้นทางรายเดียวลุกลามเป็นเหตุขัดข้องทั่วทั้งแพลตฟอร์ม

ไทม์ไลน์ของเหตุขัดข้อง

  • 19 พฤษภาคม 22:10 UTC: ระบบมอนิเตอร์อัตโนมัติตรวจพบการตรวจสอบสถานะ API ล้มเหลวและแจ้งเตือนผู้รับผิดชอบ on-call
  • 19 พฤษภาคม 22:11 UTC: แดชบอร์ดเริ่มส่งกลับ ข้อผิดพลาด 503 และผู้ใช้ไม่สามารถล็อกอินได้
  • 19 พฤษภาคม 22:19 UTC: ยืนยันได้ว่าสาเหตุรากคือ Google Cloud Platform ระงับบัญชีโปรดักชันของ Railway
  • 19 พฤษภาคม 22:22 UTC: ส่ง ตั๋ว P0 ไปยัง Google Cloud และผู้จัดการบัญชี GCP ของ Railway เข้ามามีส่วนร่วมโดยตรง
  • 19 พฤษภาคม 22:29 UTC: ประกาศเหตุขัดข้อง
  • 19 พฤษภาคม 22:29 UTC: การเข้าถึงบัญชี GCP ถูกกู้คืนแล้ว แต่ compute instance ทั้งหมดยังคงหยุดทำงาน และ persistent disk ยังเข้าถึงไม่ได้
  • 19 พฤษภาคม 22:35 UTC: Railway Metal และเวิร์กโหลดบน AWS เริ่มส่งข้อผิดพลาด 404 เมื่อแคช network route เริ่มหมดอายุ
  • 19 พฤษภาคม 23:09 UTC: persistent disk ตัวแรกกลับมาออนไลน์
  • 19 พฤษภาคม 23:54 UTC: persistent disk ทั้งหมดกลับสู่สถานะ ready แล้ว แต่เครือข่ายยังล่มอยู่
  • 20 พฤษภาคม 00:39 UTC: ยืนยันสถานะ ready ของดิสก์แล้ว และการกู้คืนติดขัดอยู่ที่การกู้คืนเครือข่ายของ Google Cloud
  • 20 พฤษภาคม 01:30 UTC: compute instance เริ่มกลับมาทำงาน
  • 20 พฤษภาคม 01:38 UTC: edge traffic เริ่มให้บริการอีกครั้งและเครือข่ายได้รับการกู้คืน
  • 20 พฤษภาคม 01:57 UTC: orchestration และโครงสร้างพื้นฐานการบิลด์ได้รับการกู้คืน และหยุดการ deploy ชั่วคราวเพื่อไม่ให้งานที่ค้างรันพร้อมกันจนระบบรับไม่ไหว
  • 20 พฤษภาคม 02:04 UTC: compute host ค่อย ๆ กลับมาออนไลน์
  • 20 พฤษภาคม 02:47 UTC: GitHub เริ่มจำกัดอัตราการเชื่อมต่อ OAuth และ webhook ของ Railway ทำให้ผู้ใช้บางส่วนล็อกอินไม่ได้และการบิลด์ถูกบล็อก
  • 20 พฤษภาคม 02:55 UTC: สามารถเข้าถึงแดชบอร์ดได้อีกครั้ง
  • 20 พฤษภาคม 03:59 UTC: เริ่มประมวลผลการ deploy อีกครั้งในทุก tier
  • 20 พฤษภาคม 04:00 UTC: ยืนยันว่า API, แดชบอร์ด และ OAuth endpoint ทำงานอยู่ และยังคงกู้คืนเวิร์กโหลดที่เหลือต่อไป
  • 20 พฤษภาคม 06:14 UTC: เหตุขัดข้องเข้าสู่ช่วงเฝ้าติดตาม
  • 20 พฤษภาคม 07:58 UTC: เหตุขัดข้องได้รับการแก้ไขแล้ว

สิ่งที่เกิดขึ้นและกระบวนการกู้คืน

  • การระงับบัญชี Google Cloud

    • 19 พฤษภาคม เวลา 22:20 UTC Google Cloud เปลี่ยนบัญชีโปรดักชันของ Railway ไปเป็นสถานะ ระงับ โดยผิดพลาด ซึ่งเป็นส่วนหนึ่งของการดำเนินการอัตโนมัติ
    • การดำเนินการนี้ส่งผลต่อหลายบัญชีภายใน Google Cloud
    • เนื่องจากเป็นการดำเนินการในระดับแพลตฟอร์ม จึงไม่มีการติดต่อแจ้งลูกค้าแต่ละรายล่วงหน้าก่อนการจำกัด
    • สถานะระงับทำให้โครงสร้างพื้นฐานที่เกี่ยวข้องกับ GCP ถูกปิดใช้งาน รวมถึง Railway Dashboard, API, โครงสร้างพื้นฐานเครือข่ายบางส่วน และโครงสร้างพื้นฐาน burst-compute เพิ่มเติมที่โฮสต์บน Google Cloud

  • การพึ่งพา control plane

    • control plane ของ Railway คือชุด dependency หลักที่ใช้ให้บริการแดชบอร์ด, ประมวลผลการบิลด์และการ deploy และเติมตาราง routing ที่ edge ใช้งาน
    • เวิร์กโหลดทั้งหมดบน Google Cloud ได้รับผลกระทบทันที
    • edge proxy ของ Railway เก็บแคชตาราง routing ของ network control plane ที่โฮสต์อยู่ภายใน Google Cloud
    • ตราบใดที่แคชยังอยู่ เวิร์กโหลดบน Railway Metal และ AWS ก็ยังให้บริการทราฟฟิกต่อได้
    • แต่เมื่อแคชหมดอายุ edge ก็ไม่สามารถ resolve route ของอินสแตนซ์ที่ยังทำงานอยู่ได้อีกต่อไป และเวิร์กโหลดในทุกรีเจียนรวมถึง Metal และ AWS ก็เริ่มส่งข้อผิดพลาด 404
    • ตัวเวิร์กโหลดยังคงออนไลน์อยู่ แต่ผลกระทบจากปัญหาเครือข่ายได้ลุกลามออกไปยังรีเจียนนอก Google Cloud

  • ข้อจำกัดของการออกแบบ high availability

    • โครงสร้างพื้นฐานของ Railway ถูกออกแบบมาโดยมุ่งสู่ high availability โดยฐานข้อมูลทำงานข้ามหลาย availability zone และเครือข่ายใช้การเชื่อมต่อสำรองระหว่าง AWS, GCP และ Railway Metal
    • แม้การเข้าถึงบัญชีจะถูกกู้คืนแล้ว แต่บริการแต่ละส่วนไม่ได้ฟื้นตัวกลับมาโดยอัตโนมัติ
    • persistent disk, compute instance และ networking ต้องกู้คืนแยกจากกัน และลักษณะการกู้คืนนี้ทำให้เหตุขัดข้องยืดเยื้อออกไปอีกหลายชั่วโมง
    • ดิสก์กลับสู่สถานะ ready ตอน 23:54 UTC แต่เครือข่ายหลักและ edge routing ยังไม่ฟื้นตัวสมบูรณ์จนกระทั่งประมาณ 20 พฤษภาคม 01:30 UTC
    • Railway กำลังรอการยืนยันว่า ความล่าช้านี้และข้อผิดพลาดที่เกี่ยวข้องเกิดขึ้นจากฝั่ง Google หรือไม่

  • การกู้คืนแบบเป็นขั้นตอนและผลกระทบลำดับรอง

    • เมื่อเครือข่ายฟื้นตัว Railway ได้ตรวจสอบบริการหลักและเวิร์กโหลดของผู้ใช้ปลายทางเป็นลำดับตามแต่ละชั้น
    • เพื่อป้องกันระบบบิลด์รับภาระเกิน จึงหยุดการ deploy ชั่วคราวก่อนแล้วค่อยทยอยกลับมาเปิดอีกครั้ง
    • ควบคู่กับการกู้คืนระบบหลัก GitHub ก็จำกัดอัตราการเชื่อมต่อ OAuth และ webhook ของ Railway
    • เนื่องจาก ปริมาณและลักษณะ burst ของคำขอ retry ทั้งหมด ผู้ใช้จึงล็อกอินและบิลด์ไม่ได้ชั่วคราว
    • เมื่อถึงประมาณ 20 พฤษภาคม 04:00 UTC ได้ยืนยันว่า API, แดชบอร์ด และ OAuth endpoint ทำงานอยู่ และยังคงกู้คืนเวิร์กโหลดที่เหลือต่อไป

มาตรการป้องกัน

  • การออกแบบความทนทานที่มีอยู่เดิม

    • network control plane ของ Railway ถูกออกแบบเป็น multi-AZ, multi-zone เพื่อให้ยังทำงานต่อได้โดยไม่กระทบผู้ใช้ แม้สูญเสียหลายเครื่องและหลายคอมโพเนนต์
    • การออกแบบนี้ผ่านการทดสอบทั้งในสภาพแวดล้อม staging และทราฟฟิกจริงก่อนเปิดใช้งานเมื่อหลายเดือนก่อน
    • Railway ลงทุนด้านความทนทานมาตั้งแต่เหตุขัดข้องก่อนหน้า และผลลัพธ์คือเคยกู้คืน GitHub installation ของผู้ใช้ได้อย่างเสถียรโดยไม่เกิดการจำกัดอัตรารอบสอง

  • การตัด dependency จุดเดียวทิ้ง

    • เครือข่ายของ Railway เป็น mesh ring ที่ประกอบด้วยการเชื่อมต่อใยแก้วนำแสงแบบ high availability ระหว่าง Metal <> GCP <> AWS
    • แต่แม้อยู่ภายใน ring นี้ ความสามารถในการค้นหาเวิร์กโหลดยังคงมี dependency ที่แน่นหนากับ network control plane API ที่ทำงานอยู่บนเครื่องของ Google Cloud
    • mesh ยังคงทำงานต่อได้ประมาณหนึ่งชั่วโมง แต่เมื่อแคช route หมดอายุ ก็ไม่สามารถเติมตาราง routing ได้อีกและล้มเหลวในที่สุด
    • Railway กำลังเร่งนำ dependency นี้ออกทันทีเพื่อให้กลายเป็น mesh ที่แท้จริง
    • เป้าหมายคือไม่ว่าการเชื่อมต่อใดจะขาด ก็ยังต้องมีเส้นทางคงเหลือระหว่างคลาวด์เสมอ

  • การปรับปรุงฐานข้อมูลและ failover

    • Railway จะขยาย database shard แบบ high availability ให้ครอบคลุมทั่ว AWS และ Metal
    • ในอนาคต แม้อินสแตนซ์ทั้งหมดในคลาวด์ใดคลาวด์หนึ่งจะหายไปทันที quorum ของฐานข้อมูลก็จะยังคงให้บริการต่อได้ และทำ failover ไปจากเวิร์กโหลดที่ไม่ได้ทำงานอยู่แล้วได้ทันที

  • การออกแบบ data plane และ control plane ใหม่

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

ความรับผิดชอบและบทสรุป

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

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

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

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

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

    • ราวปี 2017 ตอนดูแล https://www.fatherly.com/ ก็เจอเรื่องแบบเดียวกันเป๊ะ
      Google ปิดบัญชีเราไปโดยไม่มีการเตือนล่วงหน้า ทั้งที่ตอนนั้นจ่ายอยู่ราว 10,000 ดอลลาร์ต่อเดือน
      แม้แต่บัญชีซัพพอร์ตระดับพรีเมียมก็ถูกล็อก เลยแจ้งทีมซัพพอร์ตไม่ได้ด้วยซ้ำว่า “เราถูกล็อกอยู่”
      ราว 8 ชั่วโมงต่อมา วิศวกรซัพพอร์ตของ Google คนหนึ่งบอกว่าเป็นเพราะเราขุดบิตคอยน์ ซึ่งไร้สาระสิ้นดี
      เรามีกราฟการใช้ CPU และล็อกตลอดช่วงเวลานั้น และไม่มีสไปก์ใด ๆ
      ผ่านไปราว 12 ชั่วโมงก็เปิดกลับให้ พร้อมบอกว่าเป็น “การตั้งค่าตรวจจับการใช้งานผิดประเภทผิดพลาด” และให้เครดิตมาราว 100 ดอลลาร์
      จะพูดเรื่อง AWS อย่างไรก็ได้ แต่ถ้าเป็น AWS คงไม่ทำแบบนี้กับลูกค้าโดยไม่มีผู้ดูแลติดต่อมาก่อน
      ตั้งแต่นั้นมาก็ไม่เชื่อใจ GCP อีกเลย
    • ถ้า Google ไม่ชอบรายงานอุบัติการณ์นี้ ก็ควรออกมาตอบเองไม่ใช่หรือ? ตั้งแต่แรกก็ยังไม่แน่ใจด้วยซ้ำว่า Railway รู้เหตุผลหรือเปล่า
    • ปกติเรื่องแบบนี้ดูเหมือนจะไม่บอกว่าเพราะอะไร และเท่าที่เห็นส่วนใหญ่ก็เป็น ระบบอัตโนมัติ
      ระบบอัตโนมัติย่อมพลาดได้ แต่ปัญหาใหญ่กว่าคือมันโปร่งใสเป็นศูนย์
      มีโอกาสสูงว่าแม้แต่ Google เองก็ไม่รู้เหมือนกันว่าระบบนั้นทำงานอย่างไรแน่
    • ไม่แน่ใจว่า “คุณ” ในประโยค “ไม่ได้แตะสาเหตุราก” หมายถึงใคร
      ถ้าหมายถึงอยากให้ Railway ทุ่มแรงกับเรื่องนี้แทนที่จะย้ายออกจาก GCP ก็ไม่เข้าใจว่าทำไมต้องทำ เว้นแต่จะคิดจะฟ้อง GCP เพื่อเรียกค่าเสียหายด้านแบรนด์และการรักษาลูกค้าระยะยาว
      ทันทีที่ GCP ปิดมันลงโดยไม่มีการเตือนล่วงหน้า เรื่องมันก็จบแล้ว และผมไม่คิดว่าจำเป็นต้องถามต่ออีก
    • ตามเคย คอมเมนต์บน ๆ ถูกกลบอยู่ในความไม่ชอบ Google อย่างรุนแรง และดูไม่เหมือนว่าจะกดดันให้ Railway จัดการปัญหานี้ได้มากนัก

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

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

  • น่าเสียดายที่เพราะเรื่องนี้ เมื่อวานต้อง ย้ายฉุกเฉินไป Azure
    โชคดีที่ไม่ได้วางฐานข้อมูลไว้บน Railway เลยกู้กลับมาได้ภายในไม่กี่ชั่วโมง
    ความเรียบง่ายที่ Railway ให้มานั้นดีมากจริง ๆ แต่มี incident และข้อจำกัดมากเกินไปกว่าจะรันแอป B2B enterprise บนโครงสร้างพื้นฐานนั้นต่อไป
    เป็นวันที่เศร้า :(

    • Railway น่าจะฟ้อง Google เพื่อเรียกค่าเสียหายจากรายได้ที่เสียไปจากคุณได้นะ คงน่าสนุกดี
    • สงสัยว่าตอนแรกเลือก Railway เพราะอะไร
      ไม่ได้รู้จักบริการนี้ลึกนัก เลยอยากรู้ว่าเลือกเพราะฟีเจอร์เฉพาะอะไร หรือใช้แทบจะเป็นเสมือน virtual machine?
      ถ้าเป็นเพราะฟีเจอร์เฉพาะ ก็อยากรู้เหมือนกันว่าการย้ายออกยากแค่ไหน
    • หมายความว่า Azure ก็สั่งระงับบัญชีด้วยหรือ?

  • สำหรับเครื่องมือ SaaS เล็ก ๆ หรือผลิตภัณฑ์ภายใน ถ้าทีมไม่อยากดูแล AWS หรือ ผู้ให้บริการ IaaS รายอื่นโดยตรง ทางเลือกถัดไปที่ดีคืออะไร?

    1. Vercel - เดือนนี้อาการไม่ค่อยดี
    2. Supabase - เดือนนี้อาการไม่ค่อยดี
    3. Railway - ตอนนี้เดือนนี้อาการไม่ค่อยดีเช่นกัน
    • DigitalOcean. พูดจริงนะ อยู่มานานมากแล้ว และสร้างโครงสร้างพื้นฐานแกนหลักที่ต้องพึ่งทุกวันไว้เยอะ เช่น Ceph
    • ถ้าใช้ IaaS โดยตรงไม่ได้ ก็ต้องยอมรับว่าบริการอาจล่มได้
      ต่อให้ใช้ AWS ถ้าไม่มีการทำซ้ำข้ามหลาย availability zone ก็มี downtime เป็นครั้งคราวอยู่ดี
      ต่อให้ทำซ้ำข้ามหลาย availability zone แล้ว AWS ก็ไม่ได้แยกทุกอย่างอย่างสมบูรณ์ บางบริการอาจพังได้และยังเกิด downtime ได้อยู่
      เพราะงั้นก็ยอมรับ downtime แล้วใช้เครื่องมือที่เหมาะกับตัวเองที่สุด ยกเว้นกรณีที่แย่มากระดับ GitHub
      ถ้ารับ downtime ไม่ได้เลย คุณจะต้องใช้เงินหลายล้านดอลลาร์และเวลาหลายเดือน เพื่อให้ได้ความน่าเชื่อถือระดับที่คาดหวังว่า downtime จะไม่เกิด
      มีระดับ Chaos Monkey ของ Netflix และโครงสร้างพื้นฐานของมันถึงจะพอ
    • บทเรียนที่ได้จากตรงนี้น่าจะคือ อย่าไว้ใจผู้ให้บริการคลาวด์รายเดียว
      อย่างน้อยควรมีผู้ให้บริการที่มีความสามารถด้านปฏิบัติการเต็มรูปแบบ สองราย
    • ไม่เข้าใจว่าทำไมไม่มีใครนึกถึงการซื้อ เซิร์ฟเวอร์แบบ bare metal หรือ VPS ได้
      ไปได้ไกลพอสมควรโดยไม่ต้องมีค่าใช้จ่ายแบบคิดตามการใช้งาน
    • ผู้ให้บริการตัวกลางอาจสร้างคุณค่าได้ แต่ก็มีความเสี่ยงด้วย ดังนั้นผมจะเริ่มจากถามก่อนว่าทำไมถึงไม่อยากใช้ AWS, GCP ฯลฯ โดยตรง
      ผู้ให้บริการคลาวด์รายใหญ่ให้บริการที่ยากกว่า Railway แค่นิดเดียว และเมื่อความต้องการเพิ่มก็ขยายไปใช้ฟีเจอร์ขั้นสูงได้
      โดยไม่ต้องเพิ่มบุคคลที่สามมาควบคุมฟีเจอร์ ความปลอดภัย และความพร้อมใช้งาน
      เช่น ตามไทม์ไลน์นี้ GCP ตอบสนองภายใน 7 นาที
      ถ้าใช้ Cloud Run ก็น่าจะลด downtime ไปได้มากกว่า 7 ชั่วโมง และถ้าทริกเกอร์ที่ไม่ทราบสาเหตุเกี่ยวข้องกับกิจกรรมของลูกค้ารายอื่นหรือพฤติกรรมแปลก ๆ ของ Railway ก็อาจจะไม่ล่มตั้งแต่แรกด้วยซ้ำ
      มันยังมีเรื่องความซับซ้อนด้วย
      โครงสร้างพื้นฐานซับซ้อนหลายส่วนที่ Railway เขียนว่าต้องแก้นั้น ถ้าใช้แค่บัญชีของตัวเองก็คงไม่จำเป็น
      โค้ดนั้นคงทำงานที่มีประโยชน์แน่ แต่มีชิ้นส่วนเคลื่อนไหวเยอะที่จำเป็นกับผู้ให้บริการโฮสต์ แต่ไม่จำเป็นกับผู้ใช้ทั่วไป
      outage ครั้งนี้ทำให้ทุกคนล้มไปพร้อมกัน แต่ถ้าเป็นผู้ใช้ AWS รายบุคคลหรือผู้ใช้ bare metal เดิมทีก็คงไม่โดนผลกระทบ
      ไม่มีคำตอบสากลแบบเดียวที่ดีที่สุดสำหรับทุกคน แต่เหล่านักพัฒนามักประเมินต่ำเกินไปทั้งต้นทุนตรงและต้นทุนแฝงของการทำงานอยู่ในสภาพแวดล้อมของคนอื่น เมื่อเทียบกับเวลาที่ประหยัดได้จากการลดขั้นตอน deploy ไปไม่กี่ขั้น

  • “19 พฤษภาคม 22:10 UTC - ระบบมอนิเตอร์อัตโนมัติตรวจพบว่าการตรวจสอบสถานะ API ล้มเหลว จึงเรียก on-call และผู้รับผิดชอบเริ่มตรวจสอบ”
    “19 พฤษภาคม 22:20 UTC - Google Cloud เปลี่ยนบัญชี production ของ Railway ไปเป็นสถานะถูกระงับโดยผิดพลาดในฐานะส่วนหนึ่งของการดำเนินการอัตโนมัติ”
    ถ้าไทม์สแตมป์ถูกต้อง ข้อผิดพลาด 10 นาทีก่อน การระงับบัญชีเกิดจากอะไร?
    คำอธิบายที่ง่ายที่สุดคือไทม์สแตมป์อันใดอันหนึ่งผิด ซึ่งตัวมันเองไม่ใช่เรื่องใหญ่
    แต่ถ้าไม่แน่ใจเรื่องไทม์สแตมป์ การใส่มันลงรายงานเหมือนเป็นข้อเท็จจริงที่ยืนยันแล้ว ทั้งที่ขัดแย้งกันชัดเจน ก็ถือว่าแปลกพอสมควร

    • ถ้าสมมติว่าไทม์สแตมป์ถูกต้อง ก็เป็นไปได้ว่า Google เริ่มปิดทรัพยากรก่อนที่บัญชีจะเข้าไปอยู่ในสถานะ “ถูกระงับ” และสถานะนั้นเพิ่งสมบูรณ์หลังจากทรัพยากรทั้งหมดถูกปิดการทำงานแล้ว
    • ไทม์สแตมป์ 22:20 ในเนื้อหาหลักผิด
      ส่วนไทม์ไลน์ที่มี 22:10 นั้นสอดคล้องกันในตัวเอง และยังมีข้อความต่อไปนี้ด้วย
      “19 พฤษภาคม 22:19 UTC - ยืนยันสาเหตุราก: Google Cloud Platform ระงับบัญชี production ของ Railway”
      จะยืนยันสาเหตุรากก่อนที่มันจะเกิดขึ้นไม่ได้
    • 10 นาทีนั้นมีแนวโน้มจะเป็นเรื่องปกติมาก
      เช่น พนักงาน Google ไปแตะการตั้งค่าผิดจนเกิดสัญญาณที่ทำให้ดูเหมือนต้องระงับ เหมือน incident ก่อน ๆ และต้องใช้เวลา 10 นาทีกว่ากระบวนการระงับจะไหลไปจนจบ
      หรืออาจเป็นลูกค้า Railway ทำบางอย่างที่เป็นการฉ้อโกงหรือดูเหมือนฉ้อโกง แล้วระบบของ Google เริ่มจำกัดการเข้าถึงก่อน และใช้เวลา 10 นาทีตัดสินใจว่าจะยกระดับเป็นการระงับหรือไม่
      ถ้ามีคนเข้ามาอนุมัติในกระบวนการด้วยก็ยิ่งสมเหตุสมผล
      เพียงแต่คนนั้นชัดเจนว่าไม่ได้ขุดลึกพอจะเห็นว่าไม่ควรทำแบบนั้น

  • นี่ควรเป็นสัญญาณเตือนสำหรับทุกคนที่รันงานอยู่บน GCP
    ดูเหมือน GCP จะระงับบัญชีไปทั่วโดยไม่คิดเลยว่าตัวเองกำลังทำอะไร
    เหมือนเอาการตัดสินใจใน production ไปให้ Gemini 3.1 Pro ตัดสิน
    TK มีประวัติทำลายวัฒนธรรมองค์กรจนพังหมดอย่างที่ OCI และเท่าที่ได้ยินมาก็ดูเหมือนทำคล้ายกันใน GCP
    GCP กับ Google เป็นองค์กรที่วิธีทำงานต่างกันโดยสิ้นเชิง
    อย่าคาดหวังคุณภาพแบบ Google เพียงเพราะเห็นชื่อ
    มันคล้ายแบรนด์เก่าที่ตอนนี้ไปติดอยู่บนสินค้าลิขสิทธิ์ราคาถูกแบบ Nokia แม้จะพูดเกินไปหน่อยแต่ก็ไม่ไกลจากความจริง
    ไม่ใช่แค่นั้น ยังขึ้นชื่อเรื่องการปิดบริการแบบสุ่มพร้อมให้เวลาย้ายระบบประมาณ 6 เดือน
    มีวิศวกรมากพอที่ไม่มีอะไรทำ เลยเอาไปย้ายผู้ใช้ภายในออกจากบริการเหล่านั้นได้ แต่ลูกค้าส่วนใหญ่ทำแบบนั้นไม่ได้
    เคยมีบทความดีมากจากอดีตพนักงาน GCP แต่ตอนนี้หาไม่เจอ
    ถ้าจริงจังกับธุรกิจของคุณ ควรเลี่ยง GCP ให้เหมือนโรคระบาด
    แก้ไข: น่าขันดีที่ Gemini ช่วยหาบทความนั้นให้แล้ว อ่านคุ้มอยู่: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

    • นี่ยังเป็น Railway เลยนะ
      มีชื่อพอจะขึ้นไปอยู่บนสุดของหน้าแรก HN และน่าจะใหญ่พอที่จะหาคนใน Google มาช่วยแทรกแซงได้ในบางจุด
      ถ้าเป็นโปรดักต์เล็ก ๆ ที่ผมทำเอง คงไม่มีทางเยียวยาอะไรได้เลย
    • ประโยคที่ว่า “อย่าคาดหวังคุณภาพแบบ Google เพียงเพราะเห็นชื่อ” สอดคล้องกับ คุณภาพของ Google ที่ผมเจอมาตลอดหลายทศวรรษพอดี
    • GCP ไม่เคยขึ้นชื่อเรื่องซัพพอร์ต และการยุติบริการก็เป็นความเสี่ยงใหญ่มาตลอด
      ยิ่งน่าเสียดายเพราะคุณภาพของตัวผลิตภัณฑ์จริง ๆ ถือว่าดี
      มันควรเป็นผู้ให้บริการอันดับ 2 ได้สบาย ๆ แต่ Azure เองก็ไม่เสถียรอย่างมากและเอกสารก็ต่ำกว่ามาตรฐาน
      ที่ GCP อยู่อันดับ 3 ก็ส่วนใหญ่เพราะตัวเองล้วน ๆ
    • มองจากข้างนอก TK ดูเหมือนจะทำได้ดี ถ้าดูจากการเติบโตของ GCP
      ความเห็นส่วนตัวแบบไม่มีหลักฐานของผมคือ เขาเข้ามารับบทผู้ใหญ่ที่มีวินัยเพื่อแก้แนวทาง enterprise ที่หลวม ๆ ของ Google
      อย่างที่ incident นี้แสดงให้เห็น ยังต้องไปอีกไกล แต่ก็น่าจะเป็นสิ่งจำเป็นหากอยากเป็นองค์กร enterprise ที่ “จริงจัง”
      เพียงแต่ในกระบวนการนั้นอาจสร้างวัฒนธรรมที่ปะทะกับองค์กรส่วนที่เหลือของ Google
      ถึงอย่างนั้น ฝั่ง Oracle อย่าง OCI เดิมมีวัฒนธรรมที่ควรถูกทำลายอยู่แล้วหรือเปล่า? ในทางกลับกันก็ดูเป็นไปได้ว่า TK เอาวัฒนธรรมนั้นเข้ามาใน Google
    • ผลิตภัณฑ์ของ Google ทุกตัวทำงานแบบนี้แหละ
      อย่าใช้กับเรื่องสำคัญเด็ดขาด

  • นี่ไม่ใช่ครั้งแรกที่ Google Cloud ทำพังหนักกับบัญชีลูกค้า: https://cloud.google.com/blog/products/infrastructure/detail...

  • “Railway รับผิดชอบต่อการเลือกผู้ขาย และท้ายที่สุดแล้วการเลือกครั้งนี้ก็เป็นความรับผิดชอบของเรา ลูกค้าไม่สนใจหรอกว่า outage เกิดจาก Google หรือ Railway สิ่งที่ลูกค้าเห็นคือผลิตภัณฑ์ของเรา uptime ของคุณคือความรับผิดชอบของเรา และเราจะเดินหน้าส่งมอบสิ่งนั้นต่อไป”
    ต้องชมที่ยอมรับเรื่องนี้ ไม่ใช่สำนวนแบบ PR
    การไว้ใจ GCP เป็น ความล้มเหลวด้านสถาปัตยกรรม ของ Railway และสิ่งนี้แสดงให้เห็นว่าพวกเขากำลังพยายามแก้ไขมัน
    ควรคาดการณ์ล่วงหน้าได้ไหม? ใช่ แต่ก็ยังดีกว่าไม่ทำอะไรเลยแม้จะช้าไปหน่อย

    • ฟังดูเหมือนข้อความเทมเพลตจากออฟฟิศ UVic ESS ที่ไหนสักแห่ง :P

  • “สุดท้ายนี้ เรากำลังวางแผนถอดบริการ Google Cloud ออกจาก hot path ของ data plane และคงไว้เฉพาะสำหรับงานสำรอง/กู้คืนเมื่อเกิดเหตุขัดข้องเท่านั้น”
    ชัดเจนมาก
    Google เชื่อถือในฐานะ ผู้ให้บริการ B2B ไม่ได้อีกต่อไป

    • Meta ก็ไม่ได้ต่างกัน
      มีบริษัทหนึ่งที่แอป OAuth ของ Meta ใช้งานไม่ได้ทั้งระบบ เพียงเพราะบัญชี Facebook ส่วนตัวของพนักงานสาย dev คนหนึ่งถูก Meta แบนโดยไม่มีเหตุผล
      เอสคาเลตหลายรอบก็ไปไม่ถึงไหน
      Meta แย่กว่าเพราะบัญชีต้องเป็น “บัญชีส่วนตัว”
      ต่อให้มี Business Manager ผู้ใช้ที่ถูกเพิ่มเข้าไปก็ยังผูกกับบัญชี Meta/Facebook ส่วนตัวอยู่ดี
      ไร้สาระมาก
    • บริษัทต่าง ๆ ควรได้ยินข้อความนี้มากกว่านี้
      Google พิสูจน์มาหลายครั้งแล้วว่าเชื่อถือไม่ได้ในฐานะผู้ให้บริการ เพราะปัญหาแบบนี้นี่แหละ
    • ถึงอย่างนั้นก็ยังเชื่อใจพอจะจ่ายเงินให้ต่อ ซึ่งยิ่งแสดงให้เห็นว่าบริษัทเทคยักษ์ใหญ่ฝังรากลึกแค่ไหน
      นั่นจึงเป็นเหตุผลว่าทำไมควรถูกแยกออกเป็นหลายสิบชิ้น
    • Google มีประวัติยาวนานในการระงับหรือยกเลิกบัญชีโดยไม่อธิบาย
      มักจะกลับลำทีหลังเมื่อผู้ใช้โวยวายต่อสาธารณะและเรื่องเริ่มแพร่กระจายไปแล้ว
      Google ทำตัวมาตลอดราวกับว่าไม่มีภาระผูกพันใด ๆ ต่อผู้ใช้ที่จ่ายเงิน
    • พวกเขาไม่ได้อธิบายเลยว่า ทำไมบัญชีถึงถูกระงับ
      สำหรับผม นั่นคือส่วนที่สำคัญที่สุด
      ผู้ให้บริการคลาวด์จะไม่ระงับทั้งบัญชีโดยไม่มีเหตุผลหรอก