Sự cố của Fly.io đã được khắc phục
(status.flyio.net)- Trang trạng thái của Fly.io hiện ở trạng thái All Systems Operational, với các thành phần chính như chạy ứng dụng, dashboard, Machines API và khả dụng theo khu vực đều đang hoạt động
- Sự cố Elevated API Errors ngày Jul 1, 2026 đã được khắc phục lúc 07:50 UTC sau khi sửa lỗi GraphQL API và vấn đề xử lý tác vụ nền
- Sự cố Delayed Metrics ngày Jun 30 khiến một số khách hàng thấy metric bị trễ hoặc thiếu trên dashboard fly-metrics.net, và đã trở lại bình thường sau khi xử lý backlog và mở rộng năng lực
- Trang trạng thái này dùng để cập nhật sự cố toàn cục, nên không bao gồm các lỗi phần cứng có ảnh hưởng giới hạn hoặc các sự kiện hạ tầng bị cô lập
- Ảnh hưởng theo từng ứng dụng cần được kiểm tra trên personalized status page trong Fly Organization dashboard, và người dùng cũng được hướng dẫn xem incident nội bộ cùng hoạt động tại Infra Log
Trạng thái dịch vụ hiện tại
- Trang trạng thái của Fly.io hiện ở trạng thái All Systems Operational
- Các hạng mục chính được hiển thị là đang hoạt động gồm 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
- Trạng thái theo khu vực cũng được hiển thị là đang hoạt động, với các khu vực AMS, ARN, BOM, CDG, DFW, EWR, FRA, GRU, IAD, JNB, LAX, LHR, NRT, ORD, SIN, SJC, SYD, YYZ
Phạm vi áp dụng của trang trạng thái
- Trang này dùng để cập nhật global incidents
- Không bao gồm cập nhật về các lỗi phần cứng thường ngày có ảnh hưởng giới hạn hoặc các sự kiện hạ tầng bị cô lập
- Để xem góc nhìn cá nhân hóa về mọi sự kiện có thể ảnh hưởng đến ứng dụng, cần kiểm tra personalized status page trong Fly Organization dashboard
- Người dùng cũng được hướng dẫn kiểm tra Infra Log để xem incident nội bộ và các hoạt động khác
Jul 1, 2026: Elevated API Errors
- Elevated API Errors được đánh dấu Resolved lúc 07:50 UTC ngày Jul 1
- Lúc 06:14 UTC, việc điều tra được bắt đầu đối với elevated errors trong GraphQL API và xử lý tác vụ nền
- Lúc 06:27 UTC, nguyên nhân đã được xác định và việc sửa lỗi được tiến hành
- Lúc 07:05 UTC, bản sửa lỗi được áp dụng và không còn thấy elevated API errors nữa
- Một số tác vụ trên dashboard có thể đã bị chậm trong lúc xử lý nền bắt kịp
- Đến 07:26 UTC, các tác vụ nền đã bắt kịp và API tiếp tục được theo dõi trong trạng thái hoạt động hoàn toàn
Jun 30, 2026: Delayed Metrics và egress IP tại SIN/NRT
- Delayed Metrics đã được khắc phục lúc 22:19 UTC ngày Jun 30
- Đã xảy ra sự cố với metric dành cho khách hàng trên dashboard fly-metrics.net, khiến người dùng có thể thấy metric bị trễ hoặc thiếu
- Vấn đề trên nhiều host đã làm chậm việc thu thập metric, và resource contention trên một số metrics ingestion hosts được xem là nguyên nhân
- Để xử lý backlog, thông lượng của metrics cluster đã được tăng lên, đồng thời lưu lượng ingestion được tái phân bổ và bổ sung thêm năng lực xử lý
- Lúc 19:58 UTC ngày Jun 30, gần như tất cả metric đã bắt kịp, nhưng vẫn còn một số ít metric ở
sinvàsyd - Egress IP issues in SIN and NRT đã được khắc phục lúc 14:03 UTC ngày Jun 30
- Một số Machines dùng egress IP tại SIN và NRT có thể đã tạm thời mất kết nối hoặc gặp suy giảm hiệu năng
Jun 26~25, 2026: Sự cố mạng, triển khai và control plane
- IPv6 Connectivity Issues in EWR đã được khắc phục lúc 23:48 UTC ngày Jun 26
- Sự cố kết nối mạng IPv6 từ upstream provider đã xảy ra tại EWR
- Các ứng dụng có Machines trên host bị ảnh hưởng có thể bị tác động khi kết nối đến một số đích IPv6 nhất định
- Network maintenance in YYZ là đợt bảo trì theo lịch diễn ra từ 08:00 đến 09:00 UTC ngày Jun 26 và đã hoàn tất
- Trong khung bảo trì, dự kiến có thể xảy ra mất kết nối tối đa 15 phút
- Deploys defaulting to Fly-hosted Builders đã được khắc phục lúc 15:38 UTC ngày Jun 25
- Trong khi điều tra độ trễ cấp phát của Depot backed builders, chiến lược mặc định của
fly deployđã được chuyển sang Fly-hosted builders - Người dùng có thể ép triển khai dựa trên Depot bằng
fly deploy --depot=true, và sau đó cũng có thể triển khai bằng Fly builder quafly deploy --depot=false
- Trong khi điều tra độ trễ cấp phát của Depot backed builders, chiến lược mặc định của
- Elevated control plane latency đã được khắc phục lúc 15:18 UTC ngày Jun 25
- Đã xảy ra tình trạng độ trễ và bão hòa ở control plane ảnh hưởng đến các khu vực BOM và NRT
- Các ứng dụng có Machines tại những khu vực đó có thể gặp thời gian phản hồi dài hơn và có khả năng phát sinh 502 errors
Jun 24~17, 2026: Mạng tại Bắc Mỹ, SIN/NRT và tìm kiếm log
- Degraded networking in North America đã được khắc phục lúc 06:57 UTC ngày Jun 24
- Việc suy giảm hiệu năng mạng giữa các site tại Bắc Mỹ đã được điều tra do một upstream incident
- Một số Machines có thể gặp mất gói và độ trễ cao hơn trên một số tuyến cụ thể
- Một phần lưu lượng 6PN Private Networking đi đến và đi từ khu vực LAX vẫn còn bị ảnh hưởng
- Network issues in SIN, NRT đã được khắc phục lúc 21:56 UTC ngày Jun 22
- Upstream provider đã gặp sự cố mạng tại các khu vực SIN và NRT, và các ứng dụng ở đó có thể không truy cập được hoặc gặp tỷ lệ mất gói cao
- SIN, NRT network issues đã được khắc phục lúc 19:48 UTC ngày Jun 22
- Ban đầu sự cố được điều tra như một upstream network issue tại khu vực SIN, sau đó xác định các ứng dụng ở khu vực NRT cũng có thể gặp vấn đề khi truy cập đến một số đích nhất định
- Log search unavailable đã được khắc phục lúc 21:53 UTC ngày Jun 19
- Sự cố ảnh hưởng đến các bảng tìm kiếm log trong Fly Metrics và historical application logs được trả về đầu tiên trong lệnh
fly logs - Việc streaming của
fly logs, trang Live Logs trên dashboard và các dịch vụ Fly Log Shipper vẫn hoạt động bình thường - Sau khi sửa lỗi, historical logs đã được backfill và phần lớn historical logs đang chờ đã có thể tìm kiếm được
- Sự cố ảnh hưởng đến các bảng tìm kiếm log trong Fly Metrics và historical application logs được trả về đầu tiên trong lệnh
- Network Issues in SIN đã được khắc phục lúc 04:55 UTC ngày Jun 17
- Đã có sự cố kết nối mạng tại khu vực SIN và các ứng dụng được host ở đó có thể không sử dụng được
- Một số Machines không thể truy cập được, và một số Managed Postgres clusters có thể thất bại khi fail-over hoặc update
1 bình luận
Các ý kiến trên Hacker News
Website của tôi đặt trên fly.io đã sập trong 5 phút khoảng 6 giờ trước rồi khôi phục ngay, và từ đó đến nay vẫn hoạt động bình thường
Dịch vụ giám sát miễn phí kiểm tra mỗi 5 phút nên có thể đã bỏ lỡ những khoảng downtime ngắn hơn, nhưng nhìn chung thì khá ổn định
Uptime của ứng dụng cũng không ổn định, nhưng tệ hơn là các lần fly deploy thất bại xảy ra không rõ lý do. Có lúc layer cứ đứng im rồi cuối cùng thất bại, 1–2 giờ sau chạy lại cùng lệnh đó mà không thay đổi gì thì lại hoạt động bình thường
Tôi muốn thấy một dịch vụ giám sát thử deploy một app cơ bản mỗi 5 phút, tức là chạy định kỳ lệnh
fly deploy, để xem việc deploy thất bại hoặc bị treo thường xuyên đến mức nào. Tôi đoán khoảng 5% sẽ thất bại mà không có giải thích, và nếu không có nhiều thời gian thì mức đó khá bực mìnhTheo phía này thì có vẻ sự cố kéo dài 16 phút
fly.io đã công khai phân tích hậu sự cố tại đây: https://fly.io/infra-log/
Bản phân tích hậu sự cố gần đây khá thú vị và có nhiều chi tiết. Năm 2016, thành phần cốt lõi trong hạ tầng vận hành của fly.io là một máy chủ TLS bảo mật cao tên là consul, phải theo dõi trạng thái dùng chung đồng thời xác thực cả chứng chỉ máy chủ lẫn chứng chỉ máy khách
Vì là kiến trúc tập trung nên phát sinh vấn đề về khả năng mở rộng; năm 2020 fly.io đã tạo ra corrosion để thay thế và nhanh chóng quên consul, nhưng chưa thể loại bỏ hoàn toàn
Rồi đến tháng 10/2024, khóa ký khóa gốc của consul hết hạn, khiến mọi kết nối bị ngắt; do dùng xác thực hai chiều, họ không thể khôi phục cho đến khi triển khai chứng chỉ SSL mới lên toàn bộ máy. Bằng cách nào đó họ làm được trong 30 phút, nhưng hiệu ứng domino đã bắt đầu và các điểm yếu khác trong hạ tầng cũng lộ ra
Một dịch vụ nội bộ khác có bộ khóa TLS độc lập đã hết hạn từ lâu, nhưng họ không biết cho đến khi dịch vụ được khởi động lại trong quá trình cấp lại khóa consul. Các kết nối TCP được thiết lập từ thời chứng chỉ còn hợp lệ bị ngắt khi khởi động lại, nên vấn đề mới lộ ra. Trong lúc đó, công cụ logging lại đang đánh vào nhà cung cấp mạng như một vụ DDoS. Những người đã cứu được công ty và cả khách hàng khi từng ấy thứ cùng lúc nổ ra thật sự rất đáng nể
Nhưng trên trang tuyển dụng [1] họ lại nói “chúng tôi không thực sự tin vào nợ kỹ thuật”
Nhìn từ bên ngoài, điều này đọc lên như một dàn hợp xướng của sự mâu thuẫn
[1] https://fly.io/docs/hiring/working/#we-re-ruthless-about-doi...
Fly.io có vẻ là một dịch vụ khá hai mặt
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
Nếu một nền tảng cloud không cung cấp được độ tin cậy đúng nghĩa thì tôi nghĩ nó không đáng giá đến thế. Có khi chỉ thuê máy chủ ảo rồi tiết kiệm khoản thuế cloud còn hơn
Tuy nhiên, mức giá này là cho instance RAM 256MB (https://fly.io/docs/about/pricing/). Dù vậy vẫn hoàn toàn có thể chạy các dự án có ý nghĩa trên đó. Một web server dựa trên Rust như Rocket chỉ cần khoảng 10MB RAM, và theo tôi tìm hiểu thì cả server PHP cơ bản cũng có thể chạy được
Chưa kể sự cố triển khai, gần như ngày nào cũng có thứ gì đó ngẫu nhiên không hoạt động hoặc bị trễ
Vì tăng giá và vì sếp tôi đã nhiều lần thấy vấn đề ở dự án tôi đưa lên Fly, tôi buộc phải rời đi vài tháng trước
Hơn nữa họ cũng đã khai tử và gỡ bỏ dịch vụ backup sqlite. Giờ tôi quay lại GCP và không còn phải lo vô số sự cố nữa
Có rất nhiều dịch vụ của các công ty lớn chạy ở một region AWS duy nhất mà vẫn được hàng trăm triệu người trên toàn thế giới sử dụng. Nó giống như một thứ cho phép tối ưu hóa quá sớm ngay từ mặc định
Nếu bạn tối ưu với mục tiêu tối đa hóa độ tin cậy, đó cũng là lựa chọn hoàn toàn hợp lý. Tôi sẽ không nói rằng vào năm 2024 chúng tôi tốt hơn ở UE1
Để tham khảo, có nhiều thứ có thể sai và thực tế cũng sai, nhưng dạng sự cố bạn có khả năng gặp thường xuyên nhất ở đây là những khoảng thời gian không thể deploy. Sự cố lần này là sự cố deploy/orchestration. Vài tháng trước chúng tôi từng vấp phải một bẫy concurrency của Rust khiến toàn bộ request routing gặp sự cố, nhưng những chuyện như vậy rất hiếm
Sự cố deploy và cập nhật trạng thái cũng là chuyện lớn, và nếu bạn tiếp tục deploy lên nhiều nhóm Fly Machines khác nhau như chúng tôi khuyến nghị, điều đó có thể ảnh hưởng đến availability vì đây là một trong những tính năng lớn của nền tảng. Tôi không có ý nói giảm nhẹ chuyện này
Thực ra nếu chạy Firecracker trên server bare metal tự sở hữu thì có thể làm gần như cùng thứ fly.io đang làm với chi phí rẻ hơn
Nhận thức đại chúng về fly.io có vẻ đã bị vấy bẩn đến mức khó phục hồi. Giờ tôi không còn đếm nổi họ đã xin lỗi bao nhiêu lần nữa
Trái với tiêu đề bài viết, Fly.io API vẫn chưa truy cập được. Điều đó có nghĩa là người dùng vẫn chưa thể truy cập deploy, database, v.v.
Có thể xem cập nhật chính xác tại https://community.fly.io/t/fly-io-site-is-currently-inaccess...
Theo trải nghiệm cá nhân khi dùng cả Fly.io và Railway.com, Railway thắng áp đảo. Hỗ trợ của Railway cũng tuyệt vời khi so sánh
Fly.io đến giờ vẫn chưa trả lời email hỗ trợ của tôi về yêu cầu xóa dữ liệu
Ứng dụng trên Railway của tôi đến nay vẫn online mà không có downtime lớn. Tôi khuyên những ai đang tìm một lựa chọn thay thế ổn nên thử Railway
Ý tưởng thì hay, nhưng trên thực tế tôi không muốn dùng cho mục đích nghiêm túc
Tôi hiểu rằng người dùng cuối muốn độ tin cậy, và cũng biết Fly đã đầu tư khá nhiều vào mảng này trong 2 năm qua mà danh tiếng vẫn xấu. Nhưng những sự cố kiểu này không phải là thứ chỉ có ở một nhà cung cấp mà không có ở nhà cung cấp khác. Xây dựng hạ tầng cloud không hề dễ với bất kỳ ai
Chỉ tính những gì tôi tận mắt thấy thì đây có lẽ là sự cố lớn thứ 5 hoặc 6 của Fly.io. Còn nhiều sự cố khác nữa và có lẽ một số tôi chỉ đơn giản là bỏ lỡ
Tôi đã giới thiệu dịch vụ này cho một người bạn, và trong vòng hai ngày họ gặp sự cố hai lần
Fly.io thật sự cần tỉnh lại. Vì sao đến giờ họ vẫn chưa làm được thì là một bí ẩn. Sản phẩm tốt, nhưng nếu là dịch vụ hosting thì độ ổn định phải là ưu tiên tuyệt đối hàng đầu. Mọi thứ còn lại đều là thứ yếu
Bí quyết có vẻ là trở thành incumbent mạnh đến mức không có lựa chọn thay thế tử tế. Khi đó dù độ tin cậy hoàn toàn thảm hại, mọi người vẫn xuề xòa bỏ qua các thất bại vận hành
Điều đáng ngờ là Turso cũng bắt đầu gặp vấn đề gần như cùng thời điểm. CEO đã xác nhận trên Discord rằng đó là do sự cố của Fly
Có vẻ một ngày nào đó Turso sẽ cung cấp tier AWS
Không ngạc nhiên. Khoảng 1 năm trước tôi đã xem fly.io vì giá rẻ, và tò mò họ cắt giảm chi phí ở đâu để kiếm tiền. Cuối cùng tôi tìm thấy câu trả lời trong tài liệu kỹ thuật: trong đó ghi rõ rằng instance của fly bị cố định vào một máy chủ vật lý và nếu máy chủ đó chết thì không thể failover. Tôi không biết phần đó hiện còn trong tài liệu chính thức hay không
Thực tế điều đó có nghĩa là nếu máy chủ sập, họ phải lấy snapshot cuối cùng của instance đó từ bản sao lưu, đưa lên một máy chủ mới, cập nhật tuyến mạng, rồi cầu mong số máy chủ chết không vượt quá dung lượng dự phòng. Nếu không thì phải chờ trung tâm dữ liệu cắm thêm vài máy chủ vào rack mới khôi phục được
Vì vậy việc báo cáo sự cố trông có vẻ ngẫu nhiên cũng khá dễ hiểu. Có app sập, app khác vẫn ổn; có app quay lại sau 5 phút, app khác thì mất rất lâu
Nếu là một doanh nghiệp ngân sách eo hẹp, tôi nghĩ lựa chọn khác như một cụm civo nhỏ có thể tốt hơn
Phần “instance của fly bị cố định vào một máy chủ vật lý nên không thể failover” thì tôi không hiểu rõ là ngoài ra lẽ ra nó phải như thế nào. Tôi biết có live migration, nhưng ngay cả trong trường hợp đó thì cuối cùng VM chẳng phải vẫn “cố định” vào một máy chủ vật lý nào đó sao?
Và nó cũng không miễn phí. Ví dụ trên GCP, khi VM được migration sẽ có suy giảm hiệu năng tạm thời có thể cảm nhận được
Nếu tầng proxy thất bại thì toàn bộ Fly vẫn có thể sập, nhưng những trường hợp như vậy hiếm hơn nhiều
Mẫu hình lặp lại thấy được là sự cố thường xảy ra vào những tuần có kỳ nghỉ lớn ở Mỹ
MS 365/Teams/Exchange cũng có vấn đề trong chốc lát vào buổi sáng, Fly.io thì sự cố toàn diện, rồi sau đó nhiều trang và dịch vụ khác bị chao đảo theo
Bình thường tôi phản đối “đóng băng thay đổi”, nhưng quanh các kỳ nghỉ lớn thì đóng băng thay đổi là hợp lý. Nó cho mọi đội thời gian nạp lại năng lượng, tạm dừng và bảo trì
Tốt hơn là đừng đặt quá nhiều áp lực lên đội B tình cờ trực ca
Có thể cố giảm cả những thay đổi đó trong mùa nghỉ, nhưng nếu cần gia hạn chứng chỉ thì sao? Nếu phải áp dụng bản vá bảo mật quan trọng thì sao? Nếu phải provision lại một cụm máy chủ thì sao? Nếu ổ cứng sắp hết dung lượng thì sao?
Dù là thời điểm nào trong năm, không thể chỉ bằng kế hoạch mà tránh được các vấn đề vận hành hóc búa
Rồi cuối cùng lại có một chiến dịch marketing/sản phẩm đặc biệt, logic giá đặc biệt cần code mới và widget UI mới, lưu lượng và tải tăng vọt, và dù đang trong thời gian đóng băng thì vẫn phải phát hành ngay. Vì liên quan đến doanh thu nên với ban lãnh đạo đó là việc quan trọng
Hầu hết các đội engineering và hạ tầng không biết việc đó vì đội sản phẩm thúc ép đến phút cuối và làm tương đối kín. Kết cục là có thể đóng băng những chỉnh sửa nhỏ chất lượng cao, nhưng lại không đóng băng đúng cách được các tính năng mới thiếu ổn định
Đây là việc khó, nhưng dù vậy tôi khuyên nên quên chuyện đóng băng đi và vận hành hợp lý, không quá sức cả trước, trong và sau giai đoạn đó
Có thể chặn các thay đổi “không cần thiết”, nhưng ranh giới đó rất nhanh sẽ trở thành vùng xám
Trong chuỗi sự cố đầu năm 2023 cũng có nỗi đau liên quan đến Corrosion: https://community.fly.io/t/reliability-its-not-great/11253
Tôi không nắm quá rõ các ràng buộc, nhưng ScyllaDB hỗ trợ eventual consistency và nhìn chung khá linh hoạt. Với replication multi-leader thì CouchDB cũng là một lựa chọn