2026年9月24日，日本的國稅系統完成了一次大規模汰換。切換才剛結束，稅務署櫃檯辦理現金繳納、核發納稅證明等業務就出現了「相當長的等待時間」，電子報稅平台e-Tax周邊也接連出現多起異常和緊急維護。巨型整合系統在切換後不穩定，做過分散式系統或業務自動化的人其實很容易理解。但「知道會出問題」和「出問題時退路夠不夠」，完全是兩回事。
假設你有件事趕著辦，櫃檯的人告訴你：「系統整體狀況不太好，什麼時候恢復還不確定。如果很急，可以直接來稅務署，我們幫您處理。」
一般人會想：「那我去不就好了。」
可是再多想一步，就會看到一幅令人頭痛的畫面。
線上辦不了、一般流程走不通的人，全都湧向櫃檯。承辦人員這邊，系統不穩，每件案子的處理都變慢了。來的人變多，處理能力卻在下降。
「來了就幫您處理」，不等於「來了馬上就能辦完」。
所以如果期限還很充裕，乾脆等一等，反而是相當合理的選擇。
心裡難免想大喊一聲：
「直接收紙本啦，拜託。」
不過，紙本可不是什麼神奇的備份資料庫。
1. 2026年9月到底發生了什麼事
日本國稅廳在2026年9月24日汰換了國稅系統。關於新一代系統KSK2，國稅廳早就公布過三個開發理念：
- 從以書面文件為中心，轉向以資料為中心的業務處理
- 把原本依稅目分開的資料庫和應用程式整合在一起
- 把使用專有作業系統的大型主機架構，改為使用通用作業系統的開放式系統
也就是說，這不是換個畫面外觀而已。資料怎麼存、應用程式之間的邊界怎麼劃、底層平台本身，都要一併換掉，是一次大改造。
汰換當天，也就是9月24日，國稅廳發布了「稅務署櫃檯各項手續出現延遲」的公告。公告說明，現金繳納、核發納稅證明等業務需要相當長的時間，透過e-Tax申請納稅證明也無法立即核發。系統汰換本身雖已完成，但櫃檯業務所需系統的運作出了問題。
同一個切換週內，還發生了透過「Mynaportal」（日本的個人號碼卡行政入口網站）登入的異常、網路銀行繳稅的完成顯示錯誤、e-Tax部分功能停用，以及為處理障礙而進行的緊急維護。e-Tax部分功能停用的問題，已在9月27日前公告解決。
另一方面，櫃檯延遲的公告到9月28日仍掛在國稅廳網站的緊急資訊欄。詳細的根本原因，截至當時尚未公布。
更重要的是，不要把預定維護和障礙混為一談。這次汰換原本就預定9月19日0點到24日8點30分長時間停機，以及9月26日全天停機。切換後的異常和緊急維護，是疊加在這之上的。
所以體感上覺得「怎麼好像一直都停著？」很自然，但其中既有計畫性停機，也有障礙造成的停機。
2. 管錢的正經系統也會壞，甚至正因如此才會主動停下來
「既然是處理稅金和錢的系統，不是應該做到絕對不會停嗎？」
直覺上確實如此。
但重要系統除了可用性，還有一致性。
例如繳納處理中最可怕的，並不是畫面五分鐘打不開。
- 明明繳了款，卻被當成未繳
- 同一筆處理被重複登記
- 引用舊資料去核發證明
- 只有一個系統更新了，另一個被落在後面
- 恢復後重新執行，同一筆處理又跑了一遍
在這種狀態下「先讓它繼續跑著」，有時比停下來更危險。
Google的SRE（網站可靠性工程）資料也提到：發生大規模障礙時，應先阻止損害擴大，再去查根本原因；如果有資料毀損的可能，凍結系統反而比較好。
不是因為牽涉到錢才停。
而是因為牽涉到錢，在無法保證狀態正確的情況下，與其讓它跑，不如停下來。
如果「有重新開機試試看嗎？」就能解決一切，全國核心系統的維運人員早就可以準時下班了。
3. 單元測試全過了，一整合照樣爆炸
整合系統最討厭的地方在於：每個零件都正常，合起來卻會壞。
A系統正常。
B系統也正常。
資料庫正常。
認證也正常。
但從A傳給B的格式只差一個字元，就會卡住。
從舊系統搬到新系統的資料裡有個例外值，就會卡住。
重試的過程中只掉了回應，就會變成「到底處理了還是沒處理」說不清楚。
舊快取、舊報表、與外部機關的連線、權限、時間、批次處理、字元編碼、舊字體漢字、障礙時的重送。邊界越多，單獨看不出來的組合就越多。
連個人做的小型自動化，也會因為舊狀態、重複執行、漏處理、外部API差異、重試的副作用而輕易出事。
現在要在涵蓋全國稅務署、多個稅目、收款、退稅、證明、e-Tax和外部機關的核心系統上做同樣的事。
越清楚整合有多難的人，越會覺得「切換之後總會冒出一些問題吧」。
但這不是免死金牌。
該評價的不只是「有沒有出過任何一起障礙」，而是「出了障礙之後，能多安全地降級運作」。
4. 為什麼會說「無法確定恢復時間」
對使用者來說，這是最令人困擾的話之一：
「恢復時間未定。」
但在原因還沒釐清的階段，隨口承諾一個時間，反而更危險。
重要系統的恢復，不是把伺服器重新開機就算完。
首先要劃定障礙範圍。
接著確認資料有沒有只寫到一半。
確認重新執行會不會造成重複處理。
確認和外部串接對象的狀態有沒有對不上。
必要時考慮回復原狀或啟用替代路徑。
恢復之後，要把停機期間積壓的處理依序放行，並核對結果。
尤其是出現「寄送端看起來成功了，接收端卻還沒確認」這種狀態時，最麻煩。
Amazon公開的分散式系統設計文章也說，要讓重試安全，關鍵在於冪等性，也就是同一個請求重送多次，副作用也不會重複。
給不出恢復時間，並不能證明負責人什麼都沒做。
壞到哪一步、能退回到哪一步、從哪裡重新開始才不會重複處理，這些都沒弄清楚的話，精確的預測本身就很困難。
5. 「急的話就來櫃檯」，從排隊理論來看相當可怕
這時櫃檯登場了。
即使系統故障，有時也會被告知「來了就能辦」。
這是個難得的退路。
但從等待時間的角度來看，條件湊得相當危險。
先把平時的情況簡化一下。
設到櫃檯的人數到達率為λ，承辦人員的處理能力為μ。
一旦發生障礙，可能同時出現兩件事。
第一，平時在線上或內部流程就能辦完的人也來了櫃檯，λ上升。
第二，承辦人員使用系統變得不順，每件案子的確認和手動輸入變多，μ下降。
需求上升，供給能力下降。
對排隊來說，這是最糟的組合。
而且稅務署的承辦人員不會在障礙發生的同時自動增加。
Google的SRE資料也提到，系統接近過載時，不是單純慢一點而已，而是會因為等待時間增加和連鎖障礙而非線性惡化。所以負載控制和降級回應才重要。
「來櫃檯就能辦」不等於「櫃檯很空」。
如果期限有餘裕，障礙高峰那幾天不去硬擠、等恢復再說，從時間成本來看完全合理。
反過來，如果牽涉法定期限或緊急狀況，就不要自行判斷後放著不管，而應在當時查看國稅廳、稅務署的官方公告，確認替代辦法。
6. 「用紙本辦」只說對了一半：紙本能當受理的退路，但不是備份資料庫
看著這些障礙，慢慢會冒出一個念頭：
「用紙本收件不就好了嗎。」
這個想法並非完全錯誤。
美國NIST的資訊系統營運持續計畫指南中，也把「短期內以人工方式執行部分或全部業務流程」列為障礙時的替代處理手段。
也就是說，人工處理是正式的持續營運措施之一。
不過，「寫在紙上就全部搞定」可不一定。
紙本能做的，大致是這些：
- 留下「已受理申請或諮詢」的事實
- 確定受理的日期時間
- 收下必要的文件
- 排出恢復後處理的先後順序
- 把諮詢編號或收據交給辦理人
至於中央資料的比對、繳納狀態的確認、歷史紀錄的查詢、證明的正確核發、與外部機關的串接，沒有核心系統可能就辦不成。
所以理想的做法不是「全部退回紙本」。
而是「核心系統倒了，受理這一環不能跟著倒」。
紙本不是備份資料庫。
但紙本受理單可以是一扇安全出口。
7. 真正需要的是「不會徹底停擺的降級運作」
抗障礙能力強的系統，未必能維持100%的正常功能。
相反地，它們會只保留關鍵功能，切換到簡易模式。
Google SRE把這稱為逐級的功能降低，也就是graceful degradation（優雅降級）。NIST也把替代設施、替代據點、人工處理等列為持續營運計畫的選項。
套用到稅務手續上，理想的樣子大概是這樣：
- 受理不能停。 即使離線或用紙本，也能收下最基本的申請資訊。
- 發放受理編號。 消除「不知道對方有沒有收到」的狀態。
- 放進後處理佇列。 恢復後可以依序重新處理。
- 防止重複處理。 同一份申請再次輸入，也能被視為一次，需要有對應的識別碼。
- 區分緊急程度。 優先處理期限逼近或對生活影響大的事項。
- 向使用者呈現狀態。 把什麼停了、什麼能用、什麼已恢復分開公布。
- 恢復後比對。 把紙本、離線受理的內容和正式資料逐一核對，找出遺漏和重複。
重要的不是「出了障礙也一切照常」的幻想。
而是設計好「怎麼壞」。
8. 那麼，e-Tax出問題的頻率有多高
翻看2026年e-Tax官方公告，可以看到1月的繳納完成通知延遲，2月的Mynaportal串接異常和登入困難，3月的登入困難，7月透過Mynaportal辦理時的異常，8月直接繳納等功能無法使用，9月汰換後的多起異常等，全年有多次障礙公告。
不過，這裡不能草率地數。
這些不是同一個障礙。
有e-Tax本身的問題，也有Mynaportal串接、繳納、畫面顯示和外部服務端的問題。而且，計畫性維護不算障礙。
因此，從官方列表只能說：「局部異常和周邊串接障礙每年會公告好幾次」，不能說「國稅系統整體動不動就全國停擺」。
2026年9月這次之所以特別醒目，是因為在巨型系統汰換的切換週裡，長時間的計畫停機和切換後的多起異常撞在了一起。
9. 懂了整合的地獄，生氣的方式會有點不同
自己做過小型自動化系統的人，看巨型系統障礙的眼光會有些改變。
以前的反應是：
「這種東西怎麼也會停？」
然後就結束了。
但只要有過一次把多個服務串起來、建佇列、加重試、儲存狀態、串接外部API的經驗，就會多出一種感想：
「哇，整合切換啊，這可是地獄。」
單獨都能跑，合起來就壞。
修好一處，另一個邊界又壞了。
舊狀態殘留。
一重試就重複了。
一看日誌，發現是昨天的資訊。
光是體驗過這種小號版本，就更容易想像巨型核心系統有多難。
不過，理解和評價是兩回事。
不能以「太難了，沒辦法」收場，而要看下面這些：
- 切換前壓力測試、遷移測試做到什麼程度
- 發生障礙時降級運作做到什麼程度
- 人工受理在多大程度上發揮了作用
- 狀態公告對使用者是否足夠
- 恢復後是否公布原因和防止再發的措施
- 下一次切換能否杜絕同類事故
系統複雜，事故就可能發生。
正因為複雜，事故之後的設計與檢討才更重要。
10. 結論——不是「全靠紙本辦」，而是「就算用紙本，也別讓入口死掉」
稅務署的核心系統一停，在使用者看來相當不合理。
這是處理金錢和法律手續的地方，卻停了。
恢復時間也不知道。
說去櫃檯就能辦，但怎麼想都會很擠。
於是忍不住想說：「直接用紙本辦吧。」
這種感覺裡，其實藏著一個相當重要的設計需求。
只靠紙本來取代整個稅務系統，並不實際。
但系統一倒，就連受理、紀錄、排優先順序、後處理佇列也一起倒，同樣沒有必要。
巨型系統需要的不是「絕對不會壞」的神話。
而是壞了也能保住最基本的工作。
能在不重複處理的前提下恢復原狀。
能告訴使用者什麼能用、什麼不能用。
並且在恢復後，能安全地把停擺期間積壓的事務接回來。
所以最終的要求就是這一句：
不是「全部用紙本辦」。
而是「至少受理這一步，就算靠紙本也要撐起來。拜託。」
參考資料
- 國稅廳〈關於稅務署櫃檯各項手續的延遲〉2026-09-24
https://www.nta.go.jp/files/000041014.pdf - 國稅廳〈關於國稅系統的汰換〉
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - 國稅廳報告2025〈新一代系統（KSK2）〉
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax〈關於國稅系統汰換期間的維護時間〉
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax〈公告一覽〉
https://www.e-tax.nta.go.jp/topics/ - e-Tax〈【已解決】關於無法使用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/
