Hiểu đúng ranh giới lỗi của vùng khả dụng: hai dạng shared fate nằm ngoài Multi-AZ 

Railway là một PaaS (Platform-as-a-Service) cho developer: kết nối GitHub repo là tự động build, deploy và có database managed (Postgres, MySQL, Redis) mà không cần tự quản lý hạ tầng bên dưới. Để tránh phụ thuộc một cloud provider duy nhất, Railway chạy workload trên cả AWS, Google Cloud và cụm bare-metal riêng (Railway Metal). Sự cố Railway ngày 19/5/2026 diễn ra theo bốn mốc: 

• 22:11 UTC, dashboard Railway bắt đầu trả lỗi 503.  

• 22:19, nguyên nhân được xác định: tài khoản production trên Google Cloud bị tự động khóa không báo trước 

• 22:29, quyền truy cập được khôi phục nhưng toàn bộ compute vẫn dừng. 

• 22:35, cache định tuyến bắt đầu hết hạn. Máy chủ trên AWS và Railway Metal vẫn sống nhưng các edge proxy không dựng lại được bảng định tuyến vì network control plane API mà nó phụ thuộc nằm trên chính các máy trong Google Cloud, khiến workload khách hàng tràn ngập lỗi 404. 

Railway sau đó xác nhận chính phụ thuộc này biến sự cố ở một nhà cung cấp thành sự cố toàn nền tảng. Phân tán hạ tầng ra nhiều nơi không đồng nghĩa với phân tán được ranh giới lỗi (failure boundary). Multi-AZ cần được hiểu trong cùng giới hạn đó: một cơ chế khoanh vùng sự cố, không phải một minh chứng rằng các thành phần trong hệ thống có tính độc lập. 

Multi-AZ thực sự cô lập lớp lỗi nào 

Vật lý: Vùng khả dụng (AZ) được thiết kế trước hết để cô lập lỗi tương quan theo vị trí vật lý: nguồn điện, làm mát, hạ tầng mạng và những thành phần cùng chịu tác động trong một khuôn viên. Nhưng tự thân điều đó chưa đủ để đảm bảo high availability, cần thêm 3 điều kiện đúng: locality, quorum và capacity. 

Điều kiện để AZ phát huy tác dụng 

Locality: Giá trị của thiết kế zonal định lượng được. Giả định một trong ba vùng hỏng hoàn toàn, tài nguyên phân bố đều: nếu dịch vụ gọi ngẫu nhiên qua các AZ (kiểu regional), một lần gọi chỉ còn 4/9 khả năng thành công, và với chuỗi gọi dài N bước, khả năng đó giảm dần theo (2/3)^N. Nếu dịch vụ chỉ gọi trong cùng một vùng (kiểu zonal), khả năng thành công luôn giữ ở mức 2/3, bất kể chuỗi gọi dài bao nhiêu - nguyên tắc "ưu tiên gọi trong cùng AZ" này gọi là locality, giúp tránh rủi ro cộng dồn qua từng bước gọi. Nhưng cả hai công thức trên đều giả định các AZ hoàn toàn độc lập với nhau - đây là điều kiện cần, chưa đủ để đảm bảo high availability. 

Quorum và capacity: Cụ thể, dù đã chạy trên nhiều vùng, high availability vẫn chưa được đảm bảo do hai yếu tố thường bị bỏ sót: 

1. Quorum: cluster 3 node đặt theo cấu hình 2+1 (2 node cùng một AZ, 1 node ở AZ khác) không chịu được mất AZ đang chứa 2 node đó. AZ đó sập nghĩa là mất quorum, vì chỉ còn 1 node, dưới ngưỡng đa số (2/3). Để chịu được mất bất kỳ AZ nào trong số 3 AZ, phải đặt đúng 1 node/AZ (cấu hình 1+1+1), không dồn 2 node vào cùng 1 AZ. 

2. Capacity (static stability): nếu capacity dự phòng chỉ được provision sau khi một AZ đã sập (dynamic scale-up), việc phục hồi lại phụ thuộc đúng vào control plane thứ đang chịu tải cao nhất lúc đó, nên dễ chậm hoặc kẹt. Static stability yêu cầu cấp phát sẵn capacity dư từ trước khi có sự cố: với 3 AZ, mỗi AZ chỉ vận hành ở ~66% tải đã test (tức dư khoảng 50% headroom); mất 1 AZ, 2 AZ còn lại nhận thêm tải ngay không cần chờ tạo máy mới. 

Giới hạn: nơi Multi-AZ không còn bảo vệ 

Giả sử cả ba điều kiện trên: locality, quorum, capacity đều đã đúng, vẫn còn một lớp phụ thuộc chưa được tính tới: control plane dùng để vận hành chính các AZ đó, đây là hạ tầng nằm phía trên ranh giới AZ.  Dù có bao nhiêu AZ, chúng vẫn thường dùng chung một control plane duy nhất để điều phối (DNS, orchestration, network state). Khi control plane này gặp lỗi, tất cả AZ bên dưới đều bị ảnh hưởng cùng lúc, bất kể locality, quorum hay capacity đã cấu hình đúng. Hai dạng shared fate - tình trạng các thành phần đặt ở AZ khác nhau nhưng vẫn cùng sập chung vì chia sẻ một điểm phụ thuộc nào đó, trình bày dưới đây là hai trường hợp điển hình: 

Shared fate #1: Control Plane nằm phía trên ranh giới của AZ 

Bản chất: Nhân bản (Replication) không đồng nghĩa với tính độc lập. Nhiều bản sao đặt tại các AZ khác nhau vẫn sẽ chung số phận nếu cùng phụ thuộc vào một shared state, một Single point of failure, hay một control plane ở tầng cao hơn. 

Thực tế: 

• Railway: Dù ứng dụng và hạ tầng mạng được phân tán qua AWS, Google Cloud lẫn Railway Metal, việc phát hiện workload lại phụ thuộc hoàn toàn vào một Control Plane API duy nhất trên Google Cloud. Kiến trúc trông có vẻ phân tán, nhưng điểm phụ thuộc lại mang tính tập trung. Route cache hết hạn sau ~1 giờ; tổng downtime kéo dài 8 giờ 

• AWS DynamoDB (20/10/2025): 3 tiến trình DNS Enactor chạy độc lập trên 3 AZ nhưng lại cùng thao tác lên một DNS state cấp Region. Một Enactor bị trễ đã ghi đè DNS plan cũ lên plan mới; cleanup process sau đó xóa nhầm bản cũ (lúc này đang là bản thực thi), gỡ toàn bộ IP khỏi DNS. Kết quả: 3 Enactor ở 3 AZ hoàn toàn vô dụng vì quyết định cuối cùng lại nằm ở shared DNS state 

Shared fate #2: Blast Radius của cấu hình vượt ranh giới hạ tầng vật lý 

Bản chất: Cô lập vật lý không bảo vệ hệ thống trước một cấu hình lỗi được phát tán đồng loạt. Blast Radius của cấu hình tỷ lệ thuận với phạm vi quyền hạn của nó, không bị giới hạn bởi ranh giới địa lý. Đáng cảnh giác nhất là các self-healing mechanism: phản ứng càng nhanh và rộng thì sức tàn phá càng lớn khi đánh giá sai. 

Thực tế: 

• Azure (2/2/2026): Workflow khắc phục tự động áp nhầm chính sách tắt anonymous access lên nhóm Storage Account phục vụ hạ tầng (chứa gói extension của VM). Khâu đánh giá tình trạng không phát hiện trạng thái nhắm sai đủ sớm, chính sách này lan ra nhiều vùng địa lý public cloud khiến hàng loạt VM, AKS và dịch vụ phụ thuộc bị tê liệt Control Plane trong nhiều giờ. Pha rollback sau đó gây quá tải Managed Identities ở East US/West US thêm ~6 giờ — bản thân remediation cũng tạo blast radius riêng 

• Cloudflare (18/11/2025): Một permission change trên ClickHouse tạo ra các dòng metadata trùng lặp, khiến feature file của Bot Management vượt hard limit (từ ~60 lên >200). File này lập tức đồng bộ toàn mạng, kích hoạt sự cố proxy panic trên diện rộng. Vì file được regenerate mỗi 5 phút trong lúc cluster rollout dần, hệ thống lúc tốt lúc xấu outage dao động khiến ban đầu bị nhầm là DDoS. 

Bước tiếp theo 

Cả hai dạng Shared fate kể trên đều có chung một dấu hiệu nhận biết: tồn tại một shared logic nằm ngoài phạm vi cô lập của từng AZ. 

Việc bạn có thể làm ngay lúc này là mở sơ đồ kiến trúc của hệ thống đang vận hành và đánh dấu đỏ toàn bộ các thành phần duy nhất cấp Region/Tài khoản - bao gồm bản ghi DNS, centralized config store, hay các automation process có quyền ghi diện rộng. Mỗi dấu là một điểm thể hiện số vùng khả dụng không có ý nghĩa. 

Shared fate mới chỉ là một phần của bức tranh. Còn 3 dạng Failure mode khác mà mô hình Multi-AZ không thể tự bảo vệ: 

1. Đường khôi phục đi qua đúng thành phần đang sụp đổ (Recovery dependency). 

2. Trạng thái nghẽn kéo dài dù nguyên nhân gốc đã xử lý xong (Metastable failure). 

3. Lỗi ngầm khiến người dùng chịu trận nhưng giám sát vẫn "xanh" (Gray failure). 

Phần 2 đi sâu phân tích 3 dạng này. 

Nguyễn Phúc Lộc
Phó Giám Đốc Trung Tâm Phát Triển Dịch Vụ Hạ Tầng Cloud