Ngày 24/9/2026, Nhật Bản đã nâng cấp quy mô lớn hệ thống thuế quốc gia. Ngay sau đó, quầy giao dịch tại các cục thuế mất "khá nhiều thời gian" để thu tiền mặt hay cấp giấy chứng nhận nộp thuế, còn cổng khai thuế trực tuyến e-Tax cũng liên tục gặp lỗi và phải bảo trì khẩn cấp. Một hệ thống tích hợp khổng lồ trở nên chập chờn ngay sau khi chuyển đổi là điều ai từng làm việc với hệ thống phân tán hay tự động hóa quy trình đều dễ hiểu. Nhưng "hiểu là nó có thể hỏng" và "khi hỏng đã có đường thoát đủ tốt" là hai chuyện hoàn toàn khác nhau.
Giả sử bạn đang cần làm gấp một thủ tục, và nhân viên quầy nói: "Cả hệ thống đang trục trặc, chưa biết khi nào khôi phục. Nếu gấp thì bạn cứ đến trực tiếp, chúng tôi sẽ xử lý."
Phản ứng thông thường là: "Vậy thì cứ đến là được."
Nhưng nghĩ sâu thêm một chút, cảnh tượng sẽ khá ảm đạm.
Những người không giải quyết được qua mạng hay đường thông thường sẽ đổ về quầy. Phía nhân viên thì hệ thống chập chờn, mỗi hồ sơ mất nhiều thời gian hơn. Người đến tăng lên, trong khi năng lực xử lý lại giảm.
"Cứ đến, chúng tôi sẽ xử lý" không có nghĩa là "đến là xong trong nháy mắt".
Vì vậy, nếu hạn của bạn còn rộng, chọn cách chờ là quyết định khá hợp lý.
Và trong lòng, ai cũng muốn hét lên:
"Nhận hồ sơ giấy đi, nghiêm túc đấy!"
Nhưng giấy không phải là cơ sở dữ liệu dự phòng thần kỳ.
1. Chuyện gì đã xảy ra vào tháng 9/2026
Tổng cục Thuế quốc gia Nhật Bản (NTA) đã nâng cấp hệ thống vào ngày 24/9/2026. Về hệ thống thế hệ mới KSK2, NTA từ lâu đã nêu ba ý tưởng phát triển:
- Chuyển từ xử lý lấy hồ sơ giấy làm trung tâm sang xử lý lấy dữ liệu làm trung tâm
- Hợp nhất cơ sở dữ liệu và ứng dụng vốn tách riêng theo từng sắc thuế
- Chuyển từ máy tính lớn chạy hệ điều hành riêng sang hệ thống mở chạy hệ điều hành phổ thông
Nói cách khác, đây không chỉ là thay giao diện màn hình. Cách lưu dữ liệu, ranh giới giữa các ứng dụng và cả nền tảng bên dưới đều được thay đổi cùng lúc.
Đúng ngày nâng cấp 24/9, NTA đã công bố thông báo về "sự chậm trễ của các thủ tục tại quầy cục thuế". Thông báo nói rằng việc thu tiền mặt, cấp giấy chứng nhận nộp thuế và các việc khác mất khá nhiều thời gian, và ngay cả khi yêu cầu qua e-Tax cũng không thể cấp ngay lập tức. Việc nâng cấp đã hoàn tất, nhưng hệ thống cần cho nghiệp vụ tại quầy gặp vấn đề khi vận hành.
Trong cùng tuần chuyển đổi, còn có lỗi đăng nhập qua Mynaportal (cổng dịch vụ công của Nhật gắn với thẻ mã số cá nhân), lỗi hiển thị hoàn tất thanh toán qua internet banking, việc ngừng một số chức năng của e-Tax và bảo trì khẩn cấp để xử lý sự cố. Việc ngừng một số chức năng e-Tax được thông báo đã khắc phục trước ngày 27/9.
Mặt khác, thông báo về sự chậm trễ tại quầy đến ngày 28/9 vẫn còn trên trang thông tin khẩn của NTA. Nguyên nhân gốc chi tiết chưa được công bố vào thời điểm đó.
Quan trọng hơn nữa, đừng nhầm lẫn bảo trì theo kế hoạch với sự cố. Trong đợt nâng cấp này, vốn đã có kế hoạch ngừng dài từ 0 giờ ngày 19/9 đến 8 giờ 30 ngày 24/9, cùng một đợt ngừng cả ngày vào 26/9. Chồng lên đó là các lỗi sau chuyển đổi và bảo trì khẩn cấp.
Vì vậy cảm giác "sao hình như lúc nào cũng dừng?" là tự nhiên, nhưng trong đó có lẫn cả ngừng theo kế hoạch và ngừng do sự cố.
2. Hệ thống nghiêm túc xử lý tiền bạc cũng hỏng. Thậm chí, đôi khi chính vì thế mà phải dừng
"Nếu là hệ thống xử lý thuế và tiền bạc, chẳng phải phải được làm sao cho tuyệt đối không dừng sao?"
Theo trực giác thì đúng vậy.
Nhưng với hệ thống quan trọng, ngoài tính sẵn sàng còn có tính nhất quán.
Ví dụ trong xử lý nộp thuế, điều đáng sợ nhất không phải là màn hình không mở được trong năm phút.
- Đã nộp tiền nhưng bị coi là chưa nộp
- Một giao dịch bị ghi nhận hai lần
- Giấy chứng nhận được cấp dựa trên dữ liệu cũ
- Chỉ một hệ thống được cập nhật, hệ thống kia bị bỏ lại
- Chạy lại sau khi khôi phục khiến cùng một giao dịch chạy thêm lần nữa
Trong tình trạng đó, "cứ để chạy tiếp" có thể nguy hiểm hơn dừng lại.
Tài liệu SRE (kỹ thuật độ tin cậy của hệ thống) của Google cũng giải thích rằng khi có sự cố lớn, nên chặn thiệt hại lan rộng trước khi điều tra nguyên nhân gốc, và nếu có khả năng hỏng dữ liệu thì đóng băng hệ thống có thể tốt hơn.
Không phải dừng dù liên quan đến tiền.
Mà chính vì liên quan đến tiền, đôi khi cần quyết định dừng thay vì cứ chạy mà không đảm bảo được trạng thái đúng.
Nếu "bạn đã thử khởi động lại chưa?" giải quyết được mọi thứ, những người vận hành hệ thống lõi trên cả nước đã được về sớm từ lâu.
3. Dù mọi bài kiểm thử đơn vị đều qua, khi tích hợp vẫn nổ như thường
Điều khó chịu của hệ thống tích hợp là từng bộ phận đều bình thường mà toàn bộ vẫn hỏng.
Hệ thống A bình thường.
Hệ thống B cũng bình thường.
Cơ sở dữ liệu bình thường.
Xác thực cũng bình thường.
Vậy mà chỉ cần định dạng truyền từ A sang B lệch một ký tự là dừng.
Dữ liệu chuyển từ hệ thống cũ sang hệ thống mới có một giá trị ngoại lệ là dừng.
Nếu trong lúc thử lại chỉ mất phần phản hồi, sẽ không biết giao dịch đã được xử lý hay chưa.
Bộ nhớ đệm cũ, biểu mẫu cũ, kết nối với cơ quan bên ngoài, quyền truy cập, thời gian, xử lý theo lô, mã hóa ký tự, chữ Hán cổ, gửi lại khi có sự cố. Ranh giới càng nhiều thì càng có nhiều tổ hợp mà kiểm thử riêng lẻ không thấy được.
Ngay cả một tự động hóa nhỏ của cá nhân cũng dễ gặp sự cố vì trạng thái cũ, chạy trùng, bỏ sót, khác biệt API bên ngoài và tác dụng phụ của việc thử lại.
Giờ hãy làm điều đó trên hệ thống lõi bao gồm cục thuế toàn quốc, nhiều sắc thuế, thu nộp, hoàn thuế, cấp giấy chứng nhận, e-Tax và các cơ quan bên ngoài.
Càng hiểu tích hợp khó đến đâu, người ta càng nghĩ "ừ thì ngay sau chuyển đổi kiểu gì cũng có chuyện".
Nhưng đó không phải là tấm miễn trách.
Điều cần đánh giá không chỉ là có hay không một sự cố nào, mà là khi sự cố xảy ra, hệ thống đã thu hẹp hoạt động một cách an toàn đến mức nào.
4. Vì sao lại là "chưa có dự kiến khôi phục"
Với người dùng, đây là một trong những câu khó chịu nhất:
"Thời điểm khôi phục chưa xác định."
Nhưng hứa bừa một giờ nào đó khi chưa biết nguyên nhân có thể còn nguy hiểm hơn.
Khôi phục hệ thống quan trọng không phải cứ khởi động lại máy chủ là xong.
Trước hết phải khoanh vùng phạm vi sự cố.
Tiếp theo kiểm tra xem dữ liệu có bị ghi dở dang không.
Kiểm tra xem chạy lại có gây xử lý trùng không.
Kiểm tra xem trạng thái có lệch với các hệ thống bên ngoài được kết nối không.
Nếu cần thì cân nhắc quay lui hoặc dùng đường thay thế.
Sau khi khôi phục, các xử lý dồn lại trong lúc dừng được chạy lần lượt và đối chiếu kết quả.
Đặc biệt rắc rối khi lẫn vào những trạng thái như "bên gửi thấy thành công nhưng bên nhận chưa xác nhận".
Trong bài viết về thiết kế hệ thống phân tán do Amazon công bố cũng giải thích rằng, để thử lại an toàn, tính lũy đẳng rất quan trọng, tức là thiết kế sao cho gửi lại cùng một yêu cầu không làm nhân đôi tác dụng.
Không đưa ra được thời điểm khôi phục không phải bằng chứng là người phụ trách không làm gì.
Chưa biết hỏng đến đâu, quay lui được đến đâu, bắt đầu lại từ đâu để không xử lý trùng, thì bản thân việc dự báo chính xác đã khó.
5. "Gấp thì cứ ra quầy" nhìn như hàng đợi thì khá đáng sợ
Đến đây quầy giao dịch xuất hiện.
Ngay cả khi hệ thống gặp sự cố, đôi khi vẫn nói "đến trực tiếp thì chúng tôi xử lý".
Đó là một lối thoát đáng quý.
Nhưng xét về thời gian chờ, nhiều điều kiện nguy hiểm cùng lúc xuất hiện.
Hãy đơn giản hóa tình huống bình thường.
Gọi lượng người đến quầy là λ, và lượng nhân viên có thể xử lý là μ.
Khi có sự cố, hai điều có thể xảy ra cùng lúc.
Thứ nhất, cả những người bình thường làm qua mạng hay quy trình nội bộ cũng đổ ra quầy, nên λ tăng.
Thứ hai, nhân viên khó dùng hệ thống hơn, mỗi hồ sơ tốn thêm thời gian kiểm tra và nhập tay, nên μ giảm.
Nhu cầu tăng, năng lực phục vụ giảm.
Đối với hàng đợi, đây là tổ hợp tồi tệ nhất.
Hơn nữa, nhân viên cục thuế không tự nhân lên khi sự cố xảy ra.
Tài liệu SRE của Google cũng chỉ ra rằng khi gần quá tải, hệ thống không chỉ chậm đi một chút mà có thể xấu đi theo kiểu phi tuyến do thời gian chờ tăng và lỗi dây chuyền. Vì vậy kiểm soát tải và phản hồi ở chế độ thu hẹp là rất quan trọng.
"Ra quầy là được xử lý" không có nghĩa là "quầy đang vắng".
Nếu hạn của bạn còn rộng, việc không lao vào đúng ngày cao điểm sự cố mà chờ khôi phục là quyết định hoàn toàn hợp lý khi tính chi phí thời gian.
Ngược lại, nếu liên quan đến hạn luật định hay tình huống khẩn cấp, đừng tự phán đoán rồi bỏ mặc, mà hãy xem thông báo chính thức của NTA hay cục thuế vào thời điểm đó để biết cách thay thế.
6. "Làm bằng giấy đi" đúng một nửa. Giấy là lối thoát cho khâu tiếp nhận, nhưng không phải cơ sở dữ liệu dự phòng
Nhìn những sự cố này, dần dần người ta nghĩ:
"Nhận bằng giấy là được mà."
Ý tưởng này không hoàn toàn sai.
Hướng dẫn lập kế hoạch duy trì hoạt động cho hệ thống thông tin của NIST (cơ quan tiêu chuẩn của Mỹ) cũng nêu, như một cách xử lý thay thế khi có sự cố, việc thực hiện thủ công một phần hoặc toàn bộ quy trình nghiệp vụ trong thời gian ngắn.
Tức là xử lý thủ công là một biện pháp duy trì hoạt động đàng hoàng.
Nhưng không phải cứ "ghi ra giấy là xong hết".
Những việc giấy làm được, chẳng hạn:
- Lưu lại sự thật là đã tiếp nhận đơn hoặc yêu cầu tư vấn
- Chốt ngày giờ tiếp nhận
- Giữ các giấy tờ cần thiết
- Lập thứ tự để xử lý sau khi khôi phục
- Đưa mã số tra cứu hoặc biên nhận
Ngược lại, đối chiếu dữ liệu trung tâm, kiểm tra tình trạng nộp thuế, tra cứu hồ sơ quá khứ, cấp giấy chứng nhận chính xác và liên kết với cơ quan bên ngoài có thể không hoàn tất được nếu thiếu hệ thống lõi.
Vì vậy lý tưởng không phải là "đưa tất cả về giấy".
Lý tưởng là "dù hệ thống lõi chết, khâu tiếp nhận không chết theo".
Giấy không phải cơ sở dữ liệu dự phòng.
Nhưng phiếu tiếp nhận bằng giấy có thể là một cửa thoát hiểm.
7. Điều thực sự cần là "vận hành thu hẹp" không dừng hẳn
Hệ thống chịu sự cố tốt không nhất thiết duy trì 100% chức năng bình thường.
Ngược lại, nó chỉ giữ lại các chức năng quan trọng và hạ xuống chế độ đơn giản.
Google SRE gọi đây là suy giảm chức năng theo từng bậc, tức graceful degradation. NIST cũng nêu cơ sở thay thế, địa điểm thay thế và xử lý thủ công như các lựa chọn của kế hoạch duy trì hoạt động.
Áp dụng vào thủ tục thuế, hình mẫu lý tưởng sẽ như sau:
- Không dừng tiếp nhận. Dù ngoại tuyến hay bằng giấy, vẫn nhận được thông tin đơn tối thiểu.
- Cấp số tiếp nhận. Xóa bỏ tình trạng "không biết đã nhận chưa".
- Đưa vào hàng đợi xử lý sau. Sau khi khôi phục có thể xử lý lại theo thứ tự.
- Ngăn xử lý trùng. Có mã định danh để cùng một đơn, dù nhập lại, vẫn chỉ tính một lần.
- Phân loại mức khẩn cấp. Ưu tiên việc có hạn gần hoặc ảnh hưởng lớn đến đời sống.
- Cho người dùng thấy trạng thái. Công bố riêng cái gì đang dừng, cái gì dùng được, cái gì đã khôi phục.
- Đối chiếu sau khi khôi phục. So khớp phần tiếp nhận bằng giấy và ngoại tuyến với dữ liệu chính thức để phát hiện sót và trùng.
Điều quan trọng không phải ảo tưởng rằng "có sự cố vẫn chạy y như cũ".
Mà là thiết kế cách nó hỏng.
8. Vậy e-Tax gặp trục trặc với tần suất bao nhiêu?
Xem các thông báo chính thức của e-Tax năm 2026, có thể thấy nhiều thông báo sự cố trong năm: tháng 1 là chậm thông báo hoàn tất nộp thuế, tháng 2 là lỗi liên kết Mynaportal và khó đăng nhập, tháng 3 là khó đăng nhập, tháng 7 là lỗi khi dùng qua Mynaportal, tháng 8 là không dùng được thanh toán trực tiếp và các chức năng khác, tháng 9 là nhiều lỗi ngay sau nâng cấp.
Nhưng ở đây không được đếm qua loa.
Đó không phải tất cả cùng một sự cố.
Có vấn đề của chính e-Tax, cũng có vấn đề ở liên kết Mynaportal, thanh toán, hiển thị và dịch vụ bên ngoài. Hơn nữa, bảo trì theo kế hoạch không phải sự cố.
Do đó, từ danh sách chính thức chỉ có thể nói rằng "lỗi cục bộ và sự cố ở các liên kết xung quanh được thông báo nhiều lần mỗi năm", chứ không thể nói "toàn bộ hệ thống thuế thường xuyên sập trên cả nước".
Vụ tháng 9/2026 nổi bật đặc biệt vì trong tuần chuyển đổi của đợt nâng cấp khổng lồ, đợt ngừng dài theo kế hoạch và nhiều lỗi sau chuyển đổi đã chồng lên nhau.
9. Biết cái địa ngục của tích hợp rồi, cách tức giận cũng hơi khác
Người đã từng tự làm một hệ thống tự động hóa nhỏ sẽ nhìn sự cố hệ thống lớn khác đi một chút.
Trước đây chỉ là:
"Sao thứ này lại dừng được nhỉ?"
Rồi thôi.
Nhưng một khi đã nối nhiều dịch vụ, dùng hàng đợi, thêm thử lại, lưu trạng thái, kết nối API bên ngoài, sẽ có thêm cảm giác:
"Ôi, chuyển đổi hệ thống tích hợp. Đúng là địa ngục."
Riêng lẻ thì chạy hết, gộp lại thì hỏng.
Sửa chỗ này thì ranh giới khác hỏng.
Trạng thái cũ còn sót lại.
Thử lại thì thành trùng.
Mở nhật ký ra thì là thông tin của hôm qua.
Chỉ cần trải qua một phiên bản thu nhỏ của chuyện đó, đã dễ hình dung độ khó của hệ thống lõi khổng lồ.
Tuy nhiên hiểu và đánh giá là hai việc khác nhau.
Đừng dừng ở "khó nên đành chịu", mà hãy nhìn các điểm sau:
- Trước chuyển đổi đã kiểm thử tải và kiểm thử di chuyển dữ liệu đến mức nào
- Khi sự cố, vận hành thu hẹp được đến mức nào
- Tiếp nhận thủ công hoạt động được đến đâu
- Thông báo trạng thái có đủ cho người dùng không
- Sau khôi phục có công bố nguyên nhân và biện pháp phòng tái diễn không
- Lần chuyển đổi tới có loại bỏ được cùng kiểu sự cố không
Vì phức tạp nên sự cố có thể xảy ra.
Chính vì phức tạp nên thiết kế và bài học sau sự cố mới quan trọng.
10. Kết luận: không phải "làm hết bằng giấy", mà là "dù bằng giấy cũng đừng để cửa vào chết"
Khi hệ thống lõi của cục thuế dừng, người dùng thấy khá vô lý.
Nơi xử lý tiền bạc và thủ tục pháp lý mà lại dừng.
Cũng không biết khi nào khôi phục.
Nghe nói ra quầy là được, nhưng nghĩ thế nào cũng thấy sẽ rất đông.
Thế là muốn nói: "Cứ làm bằng giấy đi."
Trong cảm giác đó có một yêu cầu thiết kế khá quan trọng.
Dùng riêng giấy để thay cho cả hệ thống thuế là không thực tế.
Nhưng cũng không cần phải để tiếp nhận, ghi nhận, xếp thứ tự ưu tiên và hàng đợi xử lý sau cùng chết ngay khi hệ thống sập.
Hệ thống khổng lồ không cần huyền thoại "tuyệt đối không hỏng".
Mà cần giữ lại công việc tối thiểu dù có hỏng.
Cần quay lại được mà không xử lý trùng.
Cần báo cho người dùng biết cái gì dùng được, cái gì không.
Và sau khi khôi phục, cần thu hồi an toàn phần việc đã bị dừng.
Vậy yêu cầu cuối cùng là thế này:
Không phải "tất cả làm bằng giấy".
Mà là "ít nhất khâu tiếp nhận phải dựng lại được, dù bằng giấy. Nghiêm túc đấy."
- Tổng cục Thuế quốc gia (NTA), "Về sự chậm trễ của các thủ tục tại quầy cục thuế", 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, "Về việc nâng cấp hệ thống thuế quốc gia"
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - Báo cáo NTA 2025, "Hệ thống thế hệ mới (KSK2)"
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, "Về thời gian bảo trì khi nâng cấp hệ thống thuế quốc gia"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, "Danh sách thông báo"
https://www.e-tax.nta.go.jp/topics/ - e-Tax, "[Đã khắc phục] Về tình trạng không thể sử dụng e-Tax"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
