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. 管钱的正经系统也会坏，甚至正因如此才会主动停下来
“既然是管税、管钱的系统，不是应该做到绝对不停吗？”
直觉上确实如此。
但重要系统除了可用性，还有一致性。
比如缴税处理中最可怕的，并不是页面五分钟打不开。
- 明明付过款，却被当成欠缴
- 同一笔操作被重复登记
- 引用了旧数据去开证明
- 只有一个系统更新了，另一个被落在后面
- 恢复后重新执行，同一笔处理又跑了一遍
在这种状态下“先让它继续跑着”，有时比停下来更危险。
谷歌的SRE（站点可靠性工程）资料里也讲过：发生大规模故障时，应先遏制损害扩大，再去查根因；如果有数据损坏的可能，冻结系统反而更好。
不是因为涉及钱才停。
而是因为涉及钱，在无法保证状态正确的情况下，与其让它跑，不如停下来。
要是“重启试过了吗？”就能解决一切，全国核心系统的运维人员早就能准时下班了。
3. 单元测试全过了，一整合照样炸
整合系统最讨厌的地方在于：每个零件都正常，合起来却会坏。
A系统正常。
B系统也正常。
数据库正常。
认证也正常。
可是从A传给B的格式只差一个字符，就会卡住。
从旧系统迁到新系统的数据里有个异常值，就会卡住。
重试的过程中只丢了响应，就会变成“到底处理了还是没处理”说不清。
旧缓存、旧报表、与外部机构的连接、权限、时间、批处理、字符编码、旧字体汉字、故障时的重发。边界越多，单独看不出来的组合就越多。
就连个人做的小型自动化，也会因为旧状态、重复执行、漏处理、外部API差异、重试的副作用而轻易出事。
现在要在涵盖全国税务署、多个税种、收款、退税、证明、e-Tax和外部机构的核心系统上做同样的事。
越清楚整合有多难的人，越会觉得“切换之后总会冒点问题出来”。
但这不是免罪金牌。
该评价的不只是“有没有出过一起故障”，更是“出了故障之后，能多安全地降级运行”。
4. 为什么会说“无法确定恢复时间”
对用户来说，这是最让人头疼的话之一：
“恢复时间待定。”
但在原因还没搞清的阶段，随口承诺一个时间，反而更危险。
重要系统的恢复，不是把服务器重新启动就算完。
先要划定故障范围。
再确认数据有没有只写了一半。
确认重新执行会不会造成重复处理。
确认和外部对接方的状态有没有对不上。
必要时考虑回滚或启用替代路径。
恢复之后，要把停机期间积压的处理按顺序放行，并核对结果。
尤其是出现“发送方看起来成功了，接收方却没有确认”这种状态时，最麻烦。
亚马逊公开的分布式系统设计文章里也说过，要让重试安全，关键是幂等性，也就是同一个请求重发多次，副作用也不会重复。
给不出恢复时间，并不能证明负责人什么都没做。
坏到哪一步、能退回到哪一步、从哪里重新开始才不会重复处理，这些都没弄清的话，精确的预测本身就很难。
5. “着急就来窗口”，从排队论看相当可怕
这时窗口登场了。
即使系统故障，有时也会被告知“来了就能办”。
这是个难得的退路。
但从等待时间的角度看，条件凑得相当危险。
先把平时的情况简化一下。
设来窗口的人数到达率为λ，工作人员的处理能力为μ。
一旦出故障，可能同时发生两件事。
第一，平时在网上或内部流程就能办完的人也来了窗口，λ上升。
第二，工作人员用系统变得不顺手，每件事的确认和手工录入变多，μ下降。
需求上升，供给能力下降。
对排队来说，这是最糟的组合。
而且税务署的工作人员不会在故障发生的同时自动增加。
谷歌的SRE资料也提到，系统接近过载时，不是简单地变慢一点，而是会因为等待时间增加和连锁故障而非线性恶化。所以负载控制和降级响应才重要。
“来窗口就能办”不等于“窗口很空”。
如果期限有余量，故障高峰那几天不去硬挤、等恢复再说，从时间成本看完全合理。
反过来，如果牵涉法定期限或紧急情况，不要自己判断后放着不管，而应在当时查看国税厅、税务署的官方通知，确认替代办法。
6. “用纸办”只说对了一半：纸能当受理的退路，但不是备份数据库
看着这些故障，慢慢会冒出一个念头：
“用纸收不就行了吗。”
这个想法并非完全错误。
美国NIST的信息系统业务连续性计划指南里，也把“短期内用手工方式执行部分或全部业务流程”列为故障时的替代处理手段。
也就是说，手工处理是正经的连续性措施之一。
不过，“拿笔写在纸上就全搞定”可不一定。
纸能做的，大致是这些：
- 留下“已受理申请或咨询”的事实
- 确定受理的日期时间
- 收下必要的材料
- 排出恢复后处理的先后顺序
- 把咨询编号或回执交给办事人
而中央数据的核对、缴纳状态的确认、历史记录的查询、证明的准确出具、与外部机构的联动，没有核心系统可能就办不成。
所以理想的做法不是“全部退回纸质”。
而是“核心系统倒了，受理这一环不能跟着倒”。
纸不是备份数据库。
但纸质受理单可以是一扇安全出口。
7. 真正需要的是“不会彻底停摆的降级运行”
抗故障能力强的系统，未必能保持100%的正常功能。
相反，它们会只保留关键功能，切换到简易模式。
谷歌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/
