今天早上，我刚刚写完一篇介绍澳大利亚国立图书馆 Bookplate 咖啡厅的文章，就从家里出发去了图书馆。出门的时候顺便把很久没用的轮滑鞋也带上了。今天天气非常好，中午的太阳很暖，轮滑的时候甚至已经有了一点春天的感觉。
滑完以后，我正好来到 Bookplate，想着既然早上刚写完这家咖啡厅，现在就坐下来喝杯咖啡。没想到手机一碰 POS 机，付款被拒绝了。我又换手表试了一次，还是 declined。
后面还有人在排队，我觉得有点不好意思，就让别人先付，自己站到旁边打开银行网站看了一下。因为这个月买了机票，消费比较多，我第一反应是信用额度是不是不够了。我也没有仔细检查，直接把额度调高了一些，再回去付款，结果还是被拒绝。
咖啡当然也就没喝成。我当时还觉得挺好笑，早上刚刚写了一篇介绍 Bookplate 的文章，下午跑过来竟然连一杯咖啡都买不了。难道今天不该写这篇文章？
我开始给银行打电话，结果电话也怎么都打不通。后来想，既然普通刷卡不行，不如去麦当劳试试看。到了麦当劳以后，我先没有用 App，而是直接拿手机付款，结果还是被拒绝。于是我打开麦当劳 App，用同一张银行卡下单，付款却非常顺利。
这个结果马上引起了我的兴趣。
我一边吃东西，一边和 AI 分析到底是哪一个环节出了问题。同一张卡在 App 里可以支付，至少说明额度和账户本身大概率没有问题。而手机和手表都不能进行现场支付，那么单纯某一台设备 NFC 损坏的可能性也比较低。
更有意思的是，POS 机已经明确返回了 declined。用户感觉只是把手机靠近机器，响了一声，好像只发生了一次通信，但底层实际上可能已经完成了多次交互，包括识别、握手、数据传输和验证。既然 POS 机能够完成这个过程并返回拒绝结果，那么问题更可能已经到了后面的支付授权环节，而不是简单地发生在手机和 POS 机之间。
于是我和 AI 一层一层往下排除。下一步最简单的办法，就是找一张实体银行卡实际刷一下。如果实体卡可以，问题可能集中在手机支付这一条链路；如果实体卡也不可以，就更应该怀疑银行端的支付验证或者系统设置。
吃完饭的时候，我觉得故障排查路径已经基本清楚了。
可就在这时，我突然意识到一件事情——我又习惯性地钻进技术细节里去了。
我做了很多年技术工作，遇到问题以后很自然地会沿着系统结构往下分析。哪个环节成功了，哪个环节失败了，有哪些变量可以排除，再设计一个最小实验去验证。这种职业习惯本身当然没有问题，很多时候它也非常有效。
但这次的事情有一点不同。手机和手表同时失败，在不同商户也出现同样的问题，银行客服电话又异常难以接通，这已经不是一个很普通的个人设备故障了。面对这样明显不寻常的情况，也许第一件事不应该是继续往自己的手机、银行卡和 NFC 里钻，而应该先跳出来看一眼外面的世界。
我于是让 AI 查了一下当天有没有相关的支付故障消息。
果然，ABC News 当天报道，Mastercard 因银行所称的“全球性问题”出现故障，许多澳洲用户的 Mastercard 支付都被拒绝了。
到这里，前面那一大串技术推理突然都变得不那么重要了。不是我的手机坏了，也不是手表坏了，甚至不一定是我的银行卡设置出了什么问题，而是一个更大的外部系统正在发生故障。
这件小事让我重新想了一下技术人员很容易形成的一种思维惯性。排查问题当然需要逻辑，但排查之前还应该先判断这到底是不是一个“通常的问题”。如果突然出现明显反常、同时影响多个环节的现象，先看看有没有更大范围的事件正在发生，往往比马上钻进局部细节更加有效。
换句话说，故障排查不仅是从内部向下追踪，也应该先从外部看一下整个系统环境有没有发生变化。
回家的路上，我一直觉得今天这段经历挺有意思，应该把它记下来。快到家的时候，我又临时拐了个弯，到了附近的 club，想找个地方坐下来喝杯咖啡写这篇文章。
直到准备付款的时候，我才突然想起来——折腾了一下午，不就是因为付不了款吗？
我竟然完全忘了这件事。
还好，这一次手机碰上 POS 机以后，付款成功了。
于是我终于买到了今天这杯咖啡，也终于可以坐下来写这篇文章。想起来有点像一句老笑话——停电了没事干，那就看看电视吧。可是停电了，电视怎么看？
人脑有时候就是这样。一路都在研究一个问题，等真正回到日常动作里，却会暂时忘记这个问题本身还在那里。
好在今天最后这杯咖啡，终于买成了。
了解 Geoffrey Chen 的更多信息
订阅后即可通过电子邮件收到最新文章。