ปัญหา Fly.io ได้รับการแก้ไขแล้ว

 (status.flyio.net)
1 คะแนน โดย GN⁺ 2024-11-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หน้าสถานะของ Fly.io ปัจจุบันเป็น All Systems Operational และองค์ประกอบหลัก เช่น การรันแอป แดชบอร์ด Machines API และความพร้อมใช้งานตามภูมิภาค อยู่ในสถานะทำงาน
  • เหตุการณ์ Elevated API Errors เมื่อวันที่ 1 ก.ค. 2026 ได้รับการแก้ไขเมื่อ 07:50 UTC หลังจากแก้ไขข้อผิดพลาดของ GraphQL API และปัญหาการประมวลผลงานเบื้องหลัง
  • เหตุการณ์ Delayed Metrics เมื่อวันที่ 30 มิ.ย. ทำให้แดชบอร์ด fly-metrics.net ของลูกค้าบางรายมีเมตริกล่าช้าหรือขาดหาย และกลับสู่ภาวะปกติหลังประมวลผล backlog และเพิ่ม capacity
  • หน้าสถานะนี้ใช้สำหรับอัปเดต เหตุขัดข้องระดับโลก จึงไม่รวมเหตุขัดข้องของฮาร์ดแวร์ที่มีผลกระทบจำกัดหรือเหตุการณ์โครงสร้างพื้นฐานที่เกิดแบบแยกส่วน
  • ควรตรวจสอบผลกระทบเฉพาะแอปได้จาก personalized status page ในแดชบอร์ด Fly Organization และแนะนำให้ดู incident ภายในกับกิจกรรมต่าง ๆ ที่ Infra Log

สถานะบริการปัจจุบัน

  • หน้าสถานะของ Fly.io ปัจจุบันอยู่ในสถานะ All Systems Operational
  • รายการหลักที่แสดงว่าใช้งานได้ ได้แก่ Customer Applications, Dashboard, Machines API, Regional Availability, Persistent Storage (Volumes), Deployments, Remote Builds, Logs, Metrics, SSL/TLS Certificate Provisioning, UDP Anycast, Fly Machine Image Registry 1·2, Extensions, Upstash for Redis, DNS, Billing, Managed Postgres
  • สถานะรายภูมิภาคก็แสดงว่าใช้งานได้ โดยภูมิภาคเป้าหมายคือ AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD, YYZ

ขอบเขตของหน้าสถานะ

  • หน้านี้ใช้สำหรับอัปเดต global incidents
  • ไม่รวมการอัปเดตเหตุขัดข้องของฮาร์ดแวร์ประจำวันซึ่งมีผลกระทบจำกัด หรือเหตุการณ์โครงสร้างพื้นฐานที่เกิดแบบแยกส่วน
  • มุมมองแบบปรับให้เฉพาะบุคคลของเหตุการณ์ทั้งหมดที่อาจส่งผลต่อแอป สามารถตรวจสอบได้จาก personalized status page ในแดชบอร์ด Fly Organization
  • แนะนำให้ตรวจสอบ incident ภายในและกิจกรรมอื่น ๆ ที่ Infra Log

1 ก.ค. 2026: Elevated API Errors

  • Elevated API Errors ถูกทำเครื่องหมายว่า Resolved เมื่อวันที่ 1 ก.ค. เวลา 07:50 UTC
  • เวลา 06:14 UTC เริ่มตรวจสอบ elevated errors ใน GraphQL API และการประมวลผลงานเบื้องหลัง
  • เวลา 06:27 UTC ระบุสาเหตุได้แล้ว และดำเนินการแก้ไข
  • เวลา 07:05 UTC มีการปรับใช้การแก้ไข และไม่พบ elevated API errors อีกต่อไป
    • งานบางอย่างบน dashboard อาจล่าช้าในช่วงที่การประมวลผลเบื้องหลังกำลังไล่ backlog ให้ทัน
  • เวลา 07:26 UTC งานเบื้องหลังไล่ทันแล้ว และยังคงมอนิเตอร์ API ในสถานะที่ใช้งานได้เต็มรูปแบบต่อไป

30 มิ.ย. 2026: Delayed Metrics และ egress IP ใน SIN/NRT

  • Delayed Metrics ได้รับการแก้ไขเมื่อวันที่ 30 มิ.ย. เวลา 22:19 UTC
  • เกิดปัญหากับเมตริกสำหรับลูกค้าบนแดชบอร์ด fly-metrics.net ทำให้ผู้ใช้อาจเห็นเมตริกล่าช้าหรือขาดหาย
  • ปัญหาบนหลาย host ทำให้การรวบรวมเมตริกล่าช้า และมีการระบุว่า resource contention บน metrics ingestion hosts บางส่วนเป็นสาเหตุ
  • เพื่อประมวลผล backlog ได้เพิ่ม throughput ของ metrics cluster และมีการปรับสมดุล ingestion traffic พร้อมเพิ่ม capacity สำหรับการประมวลผล
  • วันที่ 30 มิ.ย. เวลา 19:58 UTC เมตริกเกือบทั้งหมดไล่ทันแล้ว แต่ยังเหลือเมตริกจำนวนน้อยจาก sin และ syd
  • Egress IP issues in SIN and NRT ได้รับการแก้ไขเมื่อวันที่ 30 มิ.ย. เวลา 14:03 UTC
    • Machines บางส่วนที่ใช้ egress IP ใน SIN และ NRT อาจสูญเสียการเชื่อมต่อชั่วคราวหรือประสบปัญหาประสิทธิภาพลดลง

26~25 มิ.ย. 2026: เหตุการณ์ด้านเครือข่าย การ deploy และ control plane

  • IPv6 Connectivity Issues in EWR ได้รับการแก้ไขเมื่อวันที่ 26 มิ.ย. เวลา 23:48 UTC
    • เกิดปัญหาการเชื่อมต่อเครือข่าย IPv6 ของ upstream provider ใน EWR
    • แอปที่มี Machines บน host ที่ได้รับผลกระทบอาจได้รับผลกระทบต่อการเชื่อมต่อไปยังปลายทาง IPv6 บางแห่ง
  • Network maintenance in YYZ เป็นการบำรุงรักษาตามกำหนดที่ดำเนินการในวันที่ 26 มิ.ย. เวลา 08:00~09:00 UTC และเสร็จสิ้นแล้ว
    • คาดว่าอาจเกิด การสูญเสียการเชื่อมต่อสูงสุด 15 นาที ภายในช่วงเวลาบำรุงรักษา
  • Deploys defaulting to Fly-hosted Builders ได้รับการแก้ไขเมื่อวันที่ 25 มิ.ย. เวลา 15:38 UTC
    • ระหว่างตรวจสอบความล่าช้าในการ provisioning ของ Depot backed builders กลยุทธ์เริ่มต้นของ fly deploy ถูกเปลี่ยนไปใช้ Fly-hosted builders
    • ผู้ใช้สามารถบังคับใช้การ deploy แบบ Depot-based ด้วย fly deploy --depot=true และภายหลังสามารถ deploy แบบใช้ Fly builder ด้วย fly deploy --depot=false ได้เช่นกัน
  • Elevated control plane latency ได้รับการแก้ไขเมื่อวันที่ 25 มิ.ย. เวลา 15:18 UTC
    • เกิด control plane latency และ saturation ที่ส่งผลต่อภูมิภาค BOM และ NRT
    • แอปที่มี Machines ในภูมิภาคดังกล่าวอาจพบเวลาตอบสนองยาวขึ้นและอาจเกิด 502 errors

24~17 มิ.ย. 2026: เครือข่ายอเมริกาเหนือและ SIN/NRT กับการค้นหา log

  • Degraded networking in North America ได้รับการแก้ไขเมื่อวันที่ 24 มิ.ย. เวลา 06:57 UTC
    • มีการตรวจสอบประสิทธิภาพเครือข่ายระหว่างไซต์ในอเมริกาเหนือที่ลดลง เนื่องจาก upstream incident
    • Machines บางส่วนอาจพบ packet loss และ latency สูงขึ้นในเส้นทางบางเส้น
    • ผลกระทบต่อทราฟฟิก 6PN Private Networking บางส่วนที่เข้าออกภูมิภาค LAX ยังคงเหลืออยู่
  • Network issues in SIN, NRT ได้รับการแก้ไขเมื่อวันที่ 22 มิ.ย. เวลา 21:56 UTC
    • upstream provider ประสบปัญหาเครือข่ายในภูมิภาค SIN และ NRT และแอปในภูมิภาคดังกล่าวอาจเข้าถึงไม่ได้หรือมี packet loss สูง
  • SIN, NRT network issues ได้รับการแก้ไขเมื่อวันที่ 22 มิ.ย. เวลา 19:48 UTC
    • ในตอนแรกมีการตรวจสอบเป็น upstream network issue ในภูมิภาค SIN และภายหลังแอปในภูมิภาค NRT ก็อาจพบปัญหาในการเข้าถึงปลายทางบางแห่งด้วย
  • Log search unavailable ได้รับการแก้ไขเมื่อวันที่ 19 มิ.ย. เวลา 21:53 UTC
    • ส่งผลต่อ Fly Metrics log search panels และ historical application logs ที่ส่งกลับครั้งแรกจากคำสั่ง fly logs
    • การสตรีม fly logs, หน้า Live Logs ใน dashboard และ Fly Log Shipper services ทำงานได้ตามปกติ
    • หลังแก้ไขแล้ว historical logs ถูก backfill และ queued historical logs ส่วนใหญ่ค้นหาได้แล้ว
  • Network Issues in SIN ได้รับการแก้ไขเมื่อวันที่ 17 มิ.ย. เวลา 04:55 UTC
    • มีปัญหาการเชื่อมต่อเครือข่ายในภูมิภาค SIN และ hosted apps อาจใช้งานไม่ได้
    • Machines บางส่วนไม่สามารถเข้าถึงได้ และ Managed Postgres clusters บางส่วนอาจ fail-over หรือ update ไม่สำเร็จ

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

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

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

  • เว็บไซต์ของผมที่เอาขึ้นไว้บน fly.io ล่มไป 5 นาที เมื่อประมาณ 6 ชั่วโมงก่อน แล้วก็กลับมาใช้งานได้ทันที หลังจากนั้นก็ปกติมาตลอด
    บริการมอนิเตอร์ฟรีตรวจทุก 5 นาที เลยอาจพลาด downtime ที่สั้นกว่านั้นไปก็ได้ แต่โดยรวมถือว่าค่อนข้างเสถียร

    • ถ้าได้ดูข้อมูลย้อนหลังหลายเดือนน่าจะน่าสนใจ
      uptime ของแอปพลิเคชันก็ไม่ค่อยนิ่งอยู่แล้ว แต่ที่แย่กว่าคือมีกรณีที่ fly deploy ล้มเหลว โดยไม่มีสาเหตุ บางครั้ง layer ก็ค้างอยู่อย่างนั้นแล้วสุดท้ายก็ล้มเหลว พอผ่านไป 1–2 ชั่วโมงแล้วรันคำสั่งเดิมอีกครั้งโดยไม่ได้เปลี่ยนอะไร กลับทำงานได้ปกติ
      อยากเห็นบริการมอนิเตอร์ที่ลอง deploy แอปพื้นฐานทุก 5 นาที หรือก็คือรันคำสั่ง fly deploy เป็นระยะ เพื่อดูว่า deployment ล้มเหลวหรือค้างบ่อยแค่ไหน คิดคร่าว ๆ ว่าน่าจะมีประมาณ 5% ที่ล้มเหลวโดยไม่มีคำอธิบาย และถ้าเวลาไม่เหลือเฟือก็น่าหงุดหงิดพอสมควร
    • มีการมอนิเตอร์ fly.io และเอกสารจากภายนอกไว้ที่นี่: https://flyio.onlineornot.com/
      จากฝั่งนี้ดูเหมือนว่า กินเวลาต่อเนื่อง 16 นาที
    • ของเราก็คล้ายกัน คือล่มประมาณ 5 นาทีแล้วกลับมา จากนั้นก็โอเค และ error คือ 501

  • fly.io เผยแพร่ postmortem ไว้ที่นี่: https://fly.io/infra-log/
    postmortem ล่าสุดค่อนข้างน่าสนใจและมีรายละเอียดเยอะ ในปี 2016 องค์ประกอบหลักของโครงสร้างพื้นฐานปฏิบัติการของ fly.io คือเซิร์ฟเวอร์ TLS ความปลอดภัยสูงชื่อ consul ซึ่งต้องติดตาม shared state พร้อมกับยืนยันตัวตนทั้ง server certificate และ client certificate
    ด้วยโครงสร้างแบบรวมศูนย์จึงเกิดปัญหาเรื่องการขยายสเกล และในปี 2020 fly.io จึงสร้าง corrosion ขึ้นมาแทน แล้วก็ลืม consul ไปอย่างรวดเร็ว แต่ก็ยังเอาออกไม่หมด
    ต่อมาในเดือนตุลาคม 2024 signing key ของ root key ของ consul หมดอายุ ทำให้การเชื่อมต่อทั้งหมดตกลงไป และเพราะใช้การยืนยันตัวตนสองทาง จึงกู้คืนไม่ได้จนกว่าจะกระจาย SSL certificate ชุดใหม่ไปยังเครื่องทั้งหมด พวกเขาทำได้สำเร็จภายใน 30 นาที somehow แต่โดมิโนเริ่มล้มไปแล้ว และจุดอ่อนอื่น ๆ ของโครงสร้างพื้นฐานก็โผล่ออกมา
    ยังมีบริการภายในอีกตัวหนึ่งที่ชุด TLS key แยกต่างหากหมดอายุไปนานแล้ว แต่ไม่มีใครรู้จนกระทั่งมันถูกรีสตาร์ตระหว่างขั้นตอนออก key ใหม่ให้ consul เรื่องนี้ถูกเปิดเผยเพราะการเชื่อมต่อ TCP ที่เคยสร้างไว้ตอน certificate ยังใช้ได้ถูกตัดจากการรีสตาร์ต ระหว่างนั้นเครื่องมือ logging ก็กำลังยิงใส่ผู้ให้บริการเครือข่ายเหมือน DDoS อยู่ด้วย คนที่ช่วยให้บริษัทอยู่รอดและยังปกป้องลูกค้าได้ในตอนที่หลายอย่างระเบิดพร้อมกันขนาดนี้ น่าทึ่งจริง ๆ

    • เกี่ยวกับเหตุขัดข้องของ Consul ครั้งนั้น Fly Infra สรุปว่า “บทเรียนคือจะไม่มีมาตรการครึ่ง ๆ กลาง ๆ อีกต่อไป”
      แต่ในหน้ารับสมัครงาน [1] กลับบอกว่า “เราไม่ค่อยเชื่อเรื่อง technical debt”
      มองจากข้างนอกแล้วอ่านเหมือนเป็น คอรัสแห่งความย้อนแย้ง
      [1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...

  • Fly.io ดูเป็นบริการที่ค่อนข้างมี สองด้าน
    https://news.ycombinator.com/item?id=41917436
    https://news.ycombinator.com/item?id=35044516
    https://news.ycombinator.com/item?id=34742946
    https://news.ycombinator.com/item?id=34229751
    ผมมองว่าถ้าแพลตฟอร์มคลาวด์ให้ความน่าเชื่อถือได้ไม่ดีพอ ก็ไม่คุ้มค่าเท่าไร อาจจะดีกว่าถ้าเช่าเซิร์ฟเวอร์เสมือนแล้วประหยัด ภาษีคลาวด์ ไป

    • สำหรับการทดลองหรือโปรเจกต์งานอดิเรก value proposition ถือว่ายอดเยี่ยม จะมีที่ไหนอีกที่ให้รันอินสแตนซ์แยกได้ในราคาเดือนละ $1.94
      แต่ราคานี้เป็นสำหรับอินสแตนซ์ RAM 256MB (https://fly.io/docs/about/pricing/) ถึงอย่างนั้นก็ยังพอรันโปรเจกต์ที่มีความหมายบนเครื่องนั้นได้ เว็บเซิร์ฟเวอร์ที่ใช้ Rust อย่าง Rocket ต้องการ RAM แค่ราว 10MB และจากที่ลองค้นดู เซิร์ฟเวอร์ PHP พื้นฐานก็น่าจะใส่ได้
    • ความน่าเชื่อถือแย่มากจริง ๆ ช่วงไม่กี่เดือนที่ผ่านมา แดชบอร์ดหลักล่มถึงสองครั้ง ตอนที่ผมกำลังเดโมอยู่ ซึ่งรับไม่ได้เลย
      ไม่ใช่แค่ปัญหาการ deploy แต่แทบทุกวันจะมีอะไรสักอย่างที่ใช้งานไม่ได้แบบสุ่มหรือหน่วง
      การขึ้นราคา และการที่หัวหน้าเห็นปัญหาหลายครั้งในโปรเจกต์ที่ผมเอาขึ้น Fly ทำให้ผมจำเป็นต้องย้ายออกไปเมื่อไม่กี่เดือนก่อน
      แถมยังเลิกและถอดบริการสำรองข้อมูล sqlite ออกไปด้วย ตอนนี้กลับไปใช้ GCP แล้ว ไม่ต้องกังวลกับปัญหาล่มสารพัด
    • ไม่ค่อยเข้าใจ value proposition ของ fly.io เท่าไร แม้จะมีปัญหาล่ม แต่ทีมวิศวกรรมก็น่าประทับใจ ทว่า edge computing จำเป็นจริง ๆ สำหรับนักพัฒนา 99.9% หรือ?
      มีบริการของบริษัทใหญ่จำนวนมากที่รันใน AWS region เดียวแต่มีผู้ใช้หลายล้านคนทั่วโลก มันให้ความรู้สึกเหมือนเป็นอะไรที่เปิดทางให้ทำ premature optimization ตั้งแต่ค่าเริ่มต้น
    • มุมมองนี้สมเหตุสมผลโดยสิ้นเชิง และผมจะไม่พยายามโต้แย้ง เรากำลังสร้างสิ่งที่ยากมาก เป็นบริษัทที่ค่อนข้างใหม่ และไม่มีทรัพยากรแม้เพียงเศษเสี้ยวของ hyperscaler แม้เทียบกับตอนที่ AWS, GCP, OCI เริ่มต้นก็ตาม
      ถ้าจะ optimize โดยมีเป้าหมายเพื่อ เพิ่มความน่าเชื่อถือให้สูงสุด นั่นก็เป็นทางเลือกที่สมเหตุสมผลอย่างยิ่งเช่นกัน ผมจะไม่บอกว่าในปี 2024 เราดีกว่า UE1
      เผื่อเป็นข้อมูลอ้างอิง มีหลายอย่างที่อาจผิดพลาดและก็ผิดพลาดจริง แต่รูปแบบปัญหาที่คุณน่าจะเห็นบ่อยที่สุดที่นี่คือช่วงเวลาที่ deploy ไม่ได้ เหตุการณ์ครั้งนี้เป็นปัญหา deploy/orchestration เมื่อไม่กี่เดือนก่อนเราเหยียบกับดัก concurrency ใน Rust จนเกิดปัญหา routing คำขอทั้งหมด แต่เรื่องแบบนั้นเกิดขึ้นน้อยมาก
      ปัญหา deploy และอัปเดตสถานะก็เป็นเรื่องใหญ่ และถ้าคุณ deploy ต่อเนื่องไปยังกลุ่ม Fly Machines หลายกลุ่มตามที่เราแนะนำ ก็อาจกระทบ availability ได้ เพราะเป็นหนึ่งในฟีเจอร์หลักของแพลตฟอร์ม ผมไม่ได้พยายามพูดให้ดูเล็กลง
    • fly.io มีชื่อเสียงแย่มากด้านความน่าเชื่อถือ และนอก Hacker News ก็แทบไม่เห็นการกู้ภาพลักษณ์อะไร แม้แต่ที่นี่ consensus ก็ดูใกล้เคียงกับว่า “อย่ารันงานสำคัญบน fly.io และอย่าคาดหวังความซ้ำซ้อนของข้อมูล”
      จริง ๆ แล้วถ้ารัน Firecracker บนเซิร์ฟเวอร์ bare metal ของตัวเอง ก็ทำสิ่งที่ fly.io ทำได้แทบเหมือนกันในราคาถูกกว่า
      ภาพจำของสาธารณะต่อ fly.io ดูเหมือนจะมัวหมองจนยากจะกู้คืนแล้ว ตอนนี้นับไม่ไหวแล้วว่าขอโทษไปกี่ครั้ง

  • แม้หัวข้อบทความจะว่าอย่างนั้น แต่ Fly.io API ยังเข้าถึงไม่ได้อยู่ หมายความว่าผู้ใช้ยังเข้าถึงการ deploy, database ฯลฯ ไม่ได้
    ดูอัปเดตที่ถูกต้องได้ที่ https://community.fly.io/t/fly-io-site-is-currently-inaccess...

  • จากประสบการณ์ส่วนตัวที่เคยใช้ทั้ง Fly.io และ Railway.com Railway ชนะขาด ฝ่าย support ของ Railway ก็ดีมากเมื่อเทียบกัน
    Fly.io ยังไม่เคยตอบคำถามเรื่องการลบข้อมูลที่ส่งไปทางอีเมล support เลยจนถึงตอนนี้
    แอปบน Railway ออนไลน์มาตลอดโดยไม่มี downtime ใหญ่ ๆ ใครที่กำลังมองหาทางเลือกที่ดี แนะนำให้ลอง Railway

    • ผมใช้ control panel ของ Railway รวม ๆ ตลอดชีวิตน่าจะประมาณ 10 ครั้ง และครึ่งหนึ่งมีปัญหาแปลก ๆ UI ของ control panel ไม่ขึ้นหรือใช้งานไม่ได้ งานล้มเหลว และการ deploy ล้มเหลวแบบสุ่ม
      ไอเดียดีก็จริง แต่ในทางปฏิบัติไม่อยากใช้กับงานจริงจัง
    • Fly สร้างบนฮาร์ดแวร์ของตัวเอง Railway ก็ทำแบบเดียวกันไหม? ถ้าไม่ใช่ นั่นก็อธิบายได้ส่วนหนึ่งว่าทำไม Railway ถึงมีปัญหาล่มน้อยกว่าเมื่อเทียบกัน เพราะมีสิ่งที่ต้องวิศวกรรมน้อยกว่า
      ผมเข้าใจว่าผู้ใช้ปลายทางต้องการความน่าเชื่อถือ และก็รู้ว่า Fly ลงทุนกับเรื่องนี้ค่อนข้างมากในช่วง 2 ปีที่ผ่านมาแต่ชื่อเสียงก็ยังไม่ดี อย่างไรก็ตาม ปัญหาลักษณะนี้ไม่ใช่เรื่องที่มีเฉพาะผู้ให้บริการรายหนึ่งแต่ไม่มีในอีกราย การ สร้าง cloud infrastructure ไม่ใช่เรื่องง่ายสำหรับใครทั้งนั้น

  • เท่าที่ผมเห็นด้วยตัวเอง นี่น่าจะเป็นปัญหาล่มใหญ่ครั้งที่ 5 หรือ 6 ของ Fly.io แล้ว ยังมีปัญหาอื่นอีกมาก และบางอันผมอาจพลาดไม่ได้เห็น
    ผมแนะนำบริการนี้ให้เพื่อน แล้วภายในสองวันเขาเจอปัญหาล่มสองครั้ง
    Fly.io จำเป็นต้องตั้งสติจริง ๆ ทำไมยังทำไม่ได้จนถึงตอนนี้ก็ยังเป็นปริศนา ผลิตภัณฑ์ดี แต่ถ้าเป็นบริการโฮสติ้ง เสถียรภาพ ต้องเป็นสิ่งสำคัญอันดับหนึ่งแบบไม่มีข้อโต้แย้ง ที่เหลือทั้งหมดเป็นเรื่องรอง

    • เข้าใจนะ แต่ถ้าผู้คนยอมปล่อยผ่านเวลาที่ GitHub ล่มหนักทุก 2 สัปดาห์ ก็น่าจะให้ความปรารถนาดีกับ Fly บ้างสักระดับหนึ่ง ผมไม่ได้เกี่ยวข้องกับ Fly เลย แต่ถ้าแม้แต่บริษัทใหญ่ยักษ์ยังทำให้ดีไม่ได้ ก็ควรลดความคาดหวังลง
      เคล็ดลับดูเหมือนจะเป็นการกลายเป็นเจ้าตลาดเดิมที่ไม่มีตัวแทนเหมาะ ๆ แบบนั้นต่อให้ความน่าเชื่อถือเละเทะ ทุกคนก็จะปล่อยผ่านความล้มเหลวในการดำเนินงานไปแบบคร่าว ๆ
    • ผมย้ายออกไปเมื่อประมาณ 1 ปีก่อนเพราะ ปัญหาความน่าเชื่อถือ ตอนนี้ใช้ DigitalOcean Apps อยู่ และทำงานได้ดีมาก บน DO downtime เป็น 0
    • ถ้าปริมาณทราฟฟิกโตแบบทวีคูณ การรักษาความน่าเชื่อถือก็เป็นเรื่องยาก
    • มีคนใช้จริงเกิน free tier ด้วยหรือ? Vercel ก็เหมือนกัน

  • น่าสงสัยว่า Turso ก็เริ่มมีปัญหาแทบจะในเวลาเดียวกัน CEO ยืนยันใน Discord ว่าเป็น เพราะเหตุขัดข้องของ Fly

    Ok.I caught up with our oncall and This seems related to the Fly.io incident that is reported in our status page. Our login does call things in the Fly.io API
    we are already in touch with Fly and will see if we can speed this up

    • นี่ไม่ใช่ครั้งแรกที่ Turso ล่มเพราะปัญหาของ Fly สร้างบริการฐานข้อมูลขึ้นมาแล้วมี downtime แบบนี้คงเจ็บปวดมาก
      ดูเหมือนว่าในอนาคต Turso จะมี AWS tier ให้บริการ

  • ไม่น่าแปลกใจ ประมาณ 1 ปีก่อนผมดู fly.io เพราะราคาถูก และสงสัยว่าเขาลดต้นทุนตรงไหนถึงทำเงินได้ สุดท้ายก็เจอคำตอบในเอกสารเทคนิค ซึ่งเขียนไว้ชัดเจนว่า อินสแตนซ์ของ fly ถูกตรึงอยู่กับเซิร์ฟเวอร์จริงเครื่องเดียว และถ้าเซิร์ฟเวอร์นั้นตายก็ไม่สามารถทำ failover ได้ ไม่แน่ใจว่าส่วนนั้นยังอยู่ในเอกสารทางการหรือไม่
    ในทางปฏิบัตินั่นหมายความว่า ถ้าเซิร์ฟเวอร์ล่ม ก็ต้องโหลด snapshot ล่าสุดของอินสแตนซ์นั้นจากแบ็กอัปขึ้นไปบนเซิร์ฟเวอร์ใหม่ อัปเดตเส้นทางเครือข่าย แล้วภาวนาว่าจะไม่มีเซิร์ฟเวอร์ล่มมากกว่ากำลังสำรองที่มี มิฉะนั้นก็ต้องรอการกู้คืนจนกว่าดาต้าเซ็นเตอร์จะเสียบเซิร์ฟเวอร์เพิ่มอีกสองสามเครื่องเข้ารैक
    นั่นจึงอธิบายได้ค่อนข้างดีว่าทำไมรายงานเหตุขัดข้องจึงดูสุ่ม ๆ บางแอปล่ม บางแอปปกติ บางแอปกลับมาใน 5 นาที แต่อีกบางแอปใช้เวลานาน
    ถ้าเป็นธุรกิจที่งบจำกัด ผมคิดว่าตัวเลือกอื่นอย่างคลัสเตอร์ civo ขนาดเล็กอาจดีกว่า

    • ตอนนี้ Fly.io สามารถ migrate VM และ volume ได้แล้ว: https://fly.io/docs/reference/machine-migration/ / https://archive.md/rAK0V
      ส่วนที่ว่า “อินสแตนซ์ของ fly ถูกตรึงอยู่กับเซิร์ฟเวอร์จริงเครื่องเดียวและทำ failover ไม่ได้” ผมไม่ค่อยเข้าใจว่าถ้าไม่ใช่แบบนั้นแล้วควรเป็นอย่างไร รู้ว่ามี live migration แต่ถึงอย่างนั้น VM ก็ยังต้อง “ตรึง” อยู่กับเซิร์ฟเวอร์จริงสักเครื่องอยู่ดีไม่ใช่หรือ?
    • ประเภทอินสแตนซ์ EC2 ส่วนใหญ่ก็เพิ่งจะไม่มี live migration จนถึงไม่นานมานี้ บางประเภทอาจยังไม่มีด้วยซ้ำ และก็ไม่ได้เขียนไว้อย่างชัดเจนว่ามันทำงานเมื่อไรและอย่างไร
      แถมมันก็ไม่ฟรีด้วย เช่น ใน GCP ตอนที่ VM ถูก migrate จะมีประสิทธิภาพตกชั่วคราวจนรู้สึกได้
    • ถ้าต้องการ high availability บน Fly ต้อง deploy แอปไปหลาย region หรือก็คือหลายเครื่อง
      ถ้า proxy layer ล้มเหลว Fly ทั้งหมดก็ยังล่มได้อยู่ แต่กรณีแบบนั้นพบได้น้อยกว่ามาก
    • ดูจาก status page แล้วเหมือนเป็น ความล้มเหลวของระบบ high availability/clustering ครั้งนี้ดูใกล้เคียงกับกรณีที่ความซับซ้อนของอุปกรณ์ high availability กลับทำร้าย availability ของระบบ มากกว่าการตั้งค่าแบบ VPS ธรรมดา

  • รูปแบบที่เห็นซ้ำ ๆ คือเหตุขัดข้องมักเกิดขึ้นในสัปดาห์ที่มีวันหยุดสำคัญของสหรัฐฯ
    MS 365/Teams/Exchange ก็มีปัญหาช่วงสั้น ๆ ตอนเช้า, Fly.io ล่มเต็มรูปแบบ และหลังจากนั้นเว็บไซต์กับบริการหลายแห่งก็สั่นคลอนตามไปด้วย
    ปกติผมไม่เห็นด้วยกับ “change freeze” แต่คิดว่ารอบ ๆ วันหยุดสำคัญ change freeze มีเหตุผล มันทำให้ทุกทีมมีเวลาชาร์จพลัง หยุดพัก และซ่อมบำรุงได้
    ไม่ควรโยนแรงกดดันหนักเกินไปให้ทีม B ที่บังเอิญเข้าเวรอยู่

    • เหตุขัดข้องระดับนี้ไม่ค่อยมีสาเหตุจากโค้ดแย่ ๆ ผู้ร้ายแทบจะเป็น การเปลี่ยนแปลงคอนฟิก เสมอ
      ช่วงวันหยุดอาจพยายามลดการเปลี่ยนแปลงพวกนั้นได้ แต่ถ้าต้องต่ออายุ certificate ล่ะ? ถ้าต้องลงแพตช์ความปลอดภัยสำคัญล่ะ? ถ้าต้อง provision ชุดเซิร์ฟเวอร์ใหม่ล่ะ? ถ้าพื้นที่ฮาร์ดดิสก์ใกล้หมดล่ะ?
      ไม่ว่าช่วงไหนของปี ปัญหาหนัก ๆ ด้าน operation ก็หลีกเลี่ยงด้วยการวางแผนอย่างเดียวไม่ได้
    • หลีกเลี่ยงไม่ได้ว่าสัปดาห์วันหยุดแบบนี้ต่างจากช่วงปกติ เมื่อประกาศ “change freeze” การแก้ไขเล็ก ๆ และการปรับ performance tuning ที่ปกติทำกันทั่วทั้งระบบก็มักถูกบล็อกไปด้วย ด้วยเหตุผลว่า “ไม่สำคัญ”
      แล้วสุดท้ายก็มีแคมเปญการตลาด/ผลิตภัณฑ์พิเศษเกิดขึ้น ตรรกะราคาพิเศษต้องใช้โค้ดใหม่และ UI widget ใหม่ ทราฟฟิกกับโหลดพุ่งขึ้นมาก และทั้งที่อยู่ในช่วง freeze ก็ต้องปล่อยเดี๋ยวนั้น เพราะเกี่ยวกับรายได้ จึงสำคัญสำหรับผู้บริหาร
      ทีมวิศวกรรมและทีมโครงสร้างพื้นฐานส่วนใหญ่ไม่รู้เรื่องนี้ เพราะทีมผลิตภัณฑ์เร่งกันจนวินาทีสุดท้ายและทำค่อนข้างเป็นความลับ สุดท้ายเลย freeze การแก้ไขเล็ก ๆ คุณภาพดีได้ แต่ freeze ฟีเจอร์ใหม่ที่ไม่เสถียรให้ถูกต้องไม่ได้
      เป็นเรื่องยาก และถึงอย่างนั้นก็แนะนำให้ลืมเรื่อง freeze ไป แล้วดำเนินงานอย่างสมเหตุสมผล ไม่หักโหม ทั้งก่อน ระหว่าง และหลังช่วงนั้น
    • ปัญหาชั่วคราวงั้นหรือ? 365 มีเหตุขัดข้องที่ดำเนินต่อเนื่องมาตั้งแต่เช้าวานตามเวลายุโรป ผมรู้เพราะกำลังใช้ เครื่องมือ compliance เพื่อปกป้องข้อมูลในคดีล้มละลายขนาดใหญ่
    • ถ้าอย่างนั้นนักพัฒนาก็จะแค่รีบยัดการเปลี่ยนแปลงเข้าไปก่อน freeze เท่านั้นเอง
    • “freeze” หมายความว่าอะไรกันแน่? หยุดต่ออายุ certificate หรือ? ไม่รับอัปเดตความปลอดภัยของซอฟต์แวร์หรือ?
      การเปลี่ยนแปลงที่ “ไม่จำเป็น” อาจถูกกันไว้ได้ แต่เส้นแบ่งนั้นจะกลายเป็นพื้นที่สีเทาอย่างรวดเร็วมาก

  • ในเหตุขัดข้องต่อเนื่องช่วงต้นปี 2023 ก็มี ความเจ็บปวดเกี่ยวกับ Corrosion ด้วย: https://community.fly.io/t/reliability-its-not-great/11253

    • การเลือกสร้าง data store เองดูเหมือนจะเป็นการเดิมพันที่แย่
      ผมไม่ได้รู้ข้อจำกัดดีมากนัก แต่ ScyllaDB รองรับ eventual consistency และโดยรวมก็ค่อนข้างยืดหยุ่น สำหรับ multi-leader replication ก็มี CouchDB เป็นตัวเลือกด้วย