APNIC Blog đăng ngày 05/11/2026 phân tích bài học từ đợt gián đoạn Internet Bangladesh tháng 7/2024: không phải mọi dịch vụ ngừng hoạt động đều do mạng nội địa sập. Khi kết nối quốc tế bị hạn chế, DNS ở nước ngoài, API từ xa, đồng bộ thời gian, cloud và thanh toán số có thể thành điểm gãy, kể cả khi hạ tầng local vẫn vận hành.
Theo bài viết, hạn chế truy cập Internet tại Bangladesh bắt đầu ngày 18/07/2024. Internet Society Pulse và OONI ghi nhận kết nối suy giảm gần như hoàn toàn, blackout toàn phần kéo dài từ 18 đến 23/07; sau đó mạng xã hội và ứng dụng nhắn tin còn tiếp tục bị chặn đến 31/07. APNIC lưu ý cần phân biệt rõ đây không phải sự cố cáp.
Tác động kinh tế không nhỏ. e-CAB ước tính thiệt hại của thương mại điện tử khoảng 20 tỷ BDT; NetLoss của Internet Society ước tính hơn 21 triệu USD trong năm ngày đầu. Đây là các ước tính, không phải số liệu kiểm toán, nhưng cùng cho thấy cost của mất kết nối tăng rất nhanh.
Câu hỏi quan trọng với đội vận hành không chỉ là đường quốc tế mất vì nguyên nhân nào, mà là: còn gì hoạt động khi không thể đi ra ngoài? APNIC nêu các phụ thuộc thường bị bỏ quên: recursive DNS đặt ở nước khác, thành phần ứng dụng chạy cloud, API từ xa, nguồn thời gian và nền tảng thanh toán di động.
Một ứng dụng phục vụ khách hàng trong nước có thể vẫn có server local, nhưng không khởi tạo phiên nếu DNS resolver, OAuth/API, NTP hoặc endpoint thanh toán nằm ngoài biên giới. Khi đó người dùng thấy “Internet chết”, trong khi phần mạng nội địa có thể chưa hề mất hoàn toàn.
Bangladesh hiện dựa vào tuyến cáp biển SEA-ME-WE 4, SEA-ME-WE 5 và các tuyến mặt đất qua Ấn Độ. Bảo trì SEA-ME-WE 5 tháng 04/2026 từng gây chậm và gián đoạn một phần; SEA-ME-WE 4 vẫn hoạt động. SEA-ME-WE 6 cùng các tuyến mới sẽ tăng capacity và đa dạng đường đi, nhưng không tự loại bỏ dependency của dịch vụ local vào hạ tầng ở bên ngoài.
Bài viết cũng nhắc ví dụ Ấn Độ: international connectivity tập trung ở số ít điểm cập bờ, nhất là Mumbai và Chennai. Capacity lớn không đồng nghĩa failure domain nhỏ; vị trí landing station, POP, DNS và cloud dependency đều phải được xét cùng nhau.
Routing redundancy, dual upstream và tăng transit giúp chống lỗi vật lý hay mất capacity. Chúng không đảm bảo truy cập khi sự cố đến từ hạn chế chính sách hoặc các dependency bị đặt ngoài phạm vi có thể kiểm soát. Playbook incident cần phân loại nguyên nhân để tránh lãng phí thời gian đổi route khi vấn đề thực tế nằm ở DNS, API hoặc lớp policy.
Bài học có giá trị cho mọi mạng: resilience không chỉ đo bằng số tuyến hay tổng Gbps, mà bằng tỷ lệ dịch vụ còn dùng được khi một miền phụ thuộc biến mất. Đội hạ tầng nên coi DNS, identity, time sync và API như thành phần của sơ đồ mạng, gán owner, vùng đặt dịch vụ và phương án degraded mode rõ ràng. Thiết kế tốt không hứa “không bao giờ outage”; nó giúp dịch vụ trọng yếu tiếp tục phục vụ được khi Internet quốc tế, cloud hoặc một quyết định bên ngoài đột ngột không còn sẵn sàng.
APNIC Blog, “The Internet didn’t break; we just forgot what it was leaning on”, 05/11/2026. Bài công khai không đặt liên kết nguồn ngoài.
