Bauxite Việt Nam

Mai Phan Lợi 

Giấc mơ dang dở về một “Google Maps cho nước dềnh đô thị”!

Khoảng cách giữa một ứng dụng ra mắt với đầy kỳ vọng truyền thông và một hệ thống thực sự đứng vững giữa cơn mưa lớn, như Google Maps đã làm được với giao thông, vẫn còn là khoảng cách của hạ tầng, dữ liệu và, trên hết, của việc thiết kế cho khả năng hỏng mà không sụp đổ.

Ngày 3/9/2026, Sở Khoa học và Công nghệ Hà Nội ra mắt Mini app “Bản đồ mưa ngập”, tích hợp trên nền tảng công dân số iHanoi với gần 6,5 triệu tài khoản, với lời hứa giúp người dân “chọn khung đường” trước khi ra đường mùa mưa. 

Chưa đầy nửa tháng sau, một trận mưa lớn đã cho thấy khoảng cách giữa lời hứa ấy và năng lực hạ tầng thực tế: chính công cụ được kỳ vọng dẫn đường qua nước lại là thứ đầu tiên “chết” giữa cơn mưa. 

Câu chuyện kỹ thuật phía sau sự cố này, khi đặt cạnh một mô hình đã vận hành trơn tru trong túi hàng tỷ người dùng suốt hơn một thập kỷ: Google Maps giao thông — hé lộ những gì một thành phố cần có, và chưa có, để dữ liệu thời gian thực thực sự cứu được người dân giữa nước ngập.

Một ứng dụng ra đời giữa kỳ vọng lớn

Trên giấy tờ, “Bản đồ mưa ngập” là một thiết kế hợp lý: thay vì người dân phải dò hỏi trên mạng xã hội OFFB như suốt đêm qua đến sáng nay hay gọi điện cho người quen, dữ liệu mưa và điểm ngập được lấy trực tiếp qua API từ hệ thống trạm giám sát tự động của Công ty TNHH MTV Thoát nước Hà Nội, hiển thị theo thời gian thực trên nền bản đồ có thể chuyển đổi giữa bản đồ nền của thành phố và Google Maps.

Nhưng một thiết kế hợp lý trên sơ đồ kiến trúc không đồng nghĩa với một hệ thống chịu được áp lực thực tế. Khi mưa lớn trút xuống và hàng loạt tuyến phố, từ Nguyễn Trãi, Khuất Duy Tiến đến Phạm Hùng, Lê Đức Thọ... biến thành sông, đúng vào thời điểm người dân cần tra cứu nhiều nhất, ứng dụng lại không tải được bản đồ. 

Nghịch lý nằm ở chỗ: nhu cầu sử dụng và mức độ nghiêm trọng của sự cố ngập luôn tăng cùng một lúc, và đó lại chính là lúc hệ thống dữ liệu yếu nhất.

Giải phẫu một sự cố: bốn lớp yếu điểm

Theo lời đại diện đơn vị thoát nước, nguyên nhân trực tiếp là do các bên vẫn “đang trong quá trình khớp nối lại dữ liệu giữa các hệ thống với nhau”. Đây không phải một câu giải thích chống chế, mà mô tả khá chính xác một lỗi kiến trúc phần mềm kinh điển, thường gặp khi một lớp hiển thị (giao diện người dùng nhìn thấy) được ghép vào một lớp dữ liệu (hệ thống trạm đo) do một đơn vị khác quản lý, mà không có cơ chế dự phòng khi lưu lượng truy cập tăng đột biến.

 “Các bên đang trong quá trình khớp nối lại dữ liệu giữa các hệ thống với nhau” — Đại diện Công ty TNHH MTV Thoát nước Hà Nội – Đằng sau lời giải thích ấy là ít nhất bốn lớp yếu điểm cộng dồn:

- Thứ nhất, nút thắt tích hợp dữ liệu. Ứng dụng chỉ là một “lớp hiển thị” gắn lên trên hệ thống trạm đo có sẵn. Khi lượng truy cập tăng vọt lúc mưa lớn, lớp giao diện không kịp lấy dữ liệu từ lớp phía sau, dẫn tới tình trạng đứng hình, điều mà giới kỹ thuật gọi là thiếu cơ chế “cầu dao ngắt mạch” (circuit breaker) để hệ thống tự bảo vệ khi quá tải, thay vì sụp đổ toàn bộ.

- Thứ hai, mạng cảm biến còn quá thưa. Giám đốc Sở Khoa học và Công nghệ Hà Nội cũng thừa nhận thành phố “thiếu nhiều cảm biến tự động”. Khi các điểm đo chỉ rải rác, hệ thống phải nội suy (ước đoán) tình trạng ngập ở những khu vực không có cảm biến, và phần ước đoán đó có thể sai lệch hoàn toàn so với thực tế, như trường hợp một tuyến đường ngập nửa bánh xe nhưng bản đồ không hề hiển thị.

- Thứ ba, mô hình dự báo bám theo dữ liệu lịch sử. Phần lớn các mô hình thủy văn ở Việt Nam, kể cả các mô hình thủy lực truyền thống, đều được hiệu chỉnh dựa trên các trận mưa đã từng xảy ra trong quá khứ. Nhưng biến đổi khí hậu đang tạo ra những trận mưa cực đoan và bất thường hơn nhiều so với chuỗi số liệu cũ — giới chuyên gia gọi đây là hiện tượng “lũ đôi” ngày càng phổ biến, trong khi mô hình vẫn quen xử lý “lũ đơn”.

- Thứ tư, sự phân mảnh giữa các hệ thống đô thị. Khí tượng, giao thông, thoát nước và điều hành đô thị ở Hà Nội hiện vận hành như những ốc đảo dữ liệu riêng biệt, chưa liên thông. Khi có sự cố, việc xác định và khắc phục đòi hỏi phối hợp giữa nhiều đơn vị chủ quản khác nhau, khiến phản ứng luôn chậm hơn tốc độ của cơn mưa.

Vì sao Google Maps không “tê liệt” khi cả thành phố tắc đường?

Đặt cạnh sự cố này, mô hình giao thông thời gian thực của Google Maps là một đối chứng đáng để soi. Mỗi ngày, hàng triệu người lái xe qua những cơn tắc đường tồi tệ nhất, nhưng ứng dụng hiếm khi “đứng hình” đúng lúc họ cần nó nhất. Sự khác biệt không nằm ở việc Google có công nghệ “cao siêu” hơn, mà ở ba nguyên tắc thiết kế mà hệ thống chống ngập của Hà Nội hiện chưa có.

- Nguyên tắc thứ nhất: cảm biến là chính người dùng, không phải thiết bị cố định. Thay vì dựa vào vài chục trạm đo lắp đặt cố định, Google Maps biến mỗi chiếc điện thoại đang di chuyển thành một cảm biến GPS. Mật độ dữ liệu vì vậy tăng theo đúng mật độ nơi cần theo dõi nhất: chỗ đông người chính là chỗ có nhiều dữ liệu nhất, một cơ chế tự cân bằng mà hệ thống cảm biến cố định không thể có được nếu không đầu tư phủ khắp thành phố.

- Nguyên tắc thứ hai: suy giảm có kiểm soát, không sụp đổ toàn phần (graceful degradation). Khi dữ liệu ở một khu vực bị thưa hoặc trễ, Google Maps không “đứng hình” cả ứng dụng, nó hạ độ chính xác cục bộ, dùng mẫu hình lịch sử để ước đoán tạm thời, rồi cập nhật lại ngay khi có dữ liệu mới. Ngược lại, kiến trúc “lớp hiển thị chờ dữ liệu” của iHanoi không có phương án dự phòng: khi luồng dữ liệu tắc, cả ứng dụng tắc theo.

- Nguyên tắc thứ ba: hạ tầng đám mây có khả năng co giãn theo tải (auto-scaling), không phải một điểm nghẽn cố định. Lưu lượng truy cập Google Maps tăng vọt vào giờ cao điểm được hạ tầng đám mây toàn cầu tự động phân bổ thêm năng lực xử lý. Một ứng dụng công vụ vận hành trên hạ tầng cấp sở, tích hợp thủ công giữa hai đơn vị, khó có được độ co giãn tương tự nếu không được thiết kế và đầu tư cho việc đó ngay từ đầu.

Nói cách khác, Google Maps không hoàn hảo, nhưng nó được thiết kế để hỏng từng phần, chứ không hỏng toàn bộ. Đó là bài học kiến trúc, hơn là bài học công nghệ.

Một phép thử cho hạ tầng dữ liệu đô thị

Sự cố của “Bản đồ mưa ngập” không nên được đọc như một thất bại kỹ thuật đơn lẻ, mà như một phép thử áp lực (stress test) ngoài đời thật cho toàn bộ hạ tầng dữ liệu đô thị của Hà Nội, và phép thử ấy đã chỉ ra chính xác nơi hệ thống còn mỏng: cảm biến chưa đủ dày, dữ liệu chưa liên thông, mô hình dự báo chưa bắt kịp một khí hậu đang thay đổi nhanh hơn dữ liệu lịch sử có thể mô tả.

Dự án hệ thống AIoT trị giá khoảng 70 tỷ đồng đang được xây dựng, cùng các mô hình học sâu đang thử nghiệm tại Đà Nẵng hay TP.HCM, cho thấy hướng đi đúng đã được nhận diện. 

Nhưng khoảng cách giữa một ứng dụng ra mắt với đầy kỳ vọng truyền thông và một hệ thống thực sự đứng vững giữa cơn mưa lớn, như Google Maps đã làm được với giao thông, vẫn còn là khoảng cách của hạ tầng, dữ liệu và, trên hết, của việc thiết kế cho khả năng hỏng mà không sụp đổ.

---

Thuật ngữ kỹ thuật trong bài 

- Data integration bottleneck: Nút thắt tích hợp dữ liệu — điểm nghẽn khi hai hệ thống khác nhau (dữ liệu và hiển thị) phải đồng bộ với nhau theo thời gian thực.

- Circuit breaker: Cầu dao ngắt mạch phần mềm — cơ chế tự bảo vệ hệ thống khi quá tải, thay vì để toàn bộ dịch vụ sập.

- Interpolation (Nội suy): Kỹ thuật ước đoán giá trị tại nơi không có dữ liệu, dựa trên các điểm đo lân cận đã biết.

- Graceful degradation (Suy giảm có kiểm soát): hệ thống giảm độ chính xác hoặc tính năng cục bộ thay vì ngừng hoạt động hoàn toàn khi thiếu dữ liệu hoặc quá tải.

- Auto-scaling: Khả năng hạ tầng đám mây tự động tăng/giảm năng lực xử lý theo lưu lượng truy cập thực tế.

- LSTM / GNN: Hai kiến trúc học sâu (deep learning): LSTM xử lý dữ liệu chuỗi thời gian, GNN xử lý dữ liệu có cấu trúc mạng lưới (ví dụ hệ thống sông, cống) — thường được kết hợp để thay thế mô hình thủy lực truyền thống, cho tốc độ tính toán nhanh hơn.

M.P.L.

Nguồn: FB Lợi Phan Mai