东京时间不是 UTC+9：时区背后是另一种工作方式

搬来日本之前，时区对我来说就是一个偏移量。服务器要同步时间，CI 要打个时间戳，跨时区的同事发消息我晚点回——全部都是 +8 和 +9 之间加减的事情。

在东京住下来之后，我才意识到，时区不是数字，是工作方式。

数字之外的东西

日本的职场有一个我从没见过的现象：会议很少卡着整点开始。

上海的时候，"3 点开会"意味着 3:00:00 投影仪已经亮着，主持人在白板前等。在东京，"3 時から"常常意味着 3:00–3:05 之间大家陆续坐下来，第一句话往往是"お待たせしました"。迟到 5 分钟不算迟到，是礼貌留出来的缓冲。

这件事对工程师的影响是：你的"上线时间"和"客户感知时间"中间，永远有一个 5 到 15 分钟的隐性 buffer。你以为 deadline 是 T+0，实际是 T+grace。

日历上的「夕方」

我刚来的时候，日历上用中文写"下班"。后来发现日本同事的日历会写"退勤"、"終業"、"上がり"。再后来我注意到，他们日历上的事件经常带一个"夕方"标签——下午 5 点到 7 点之间，是不能排硬会议的窗口。

那个窗口是给"看不见的工作"的：整理当天的票、写日报、回复还没回的邮件、给同事过一遍下午的 commit。一个工程师如果连续 3 天没有"夕方"的时间，往往第 4 天就会出问题——不是技术出问题，是判断力出问题。

这个洞察来自我自己的一个事故：有一周我连续 5 天把日历排到 22 点，第六天我上线了一个有 race condition 的 hotfix，本地复现不出来，最后在生产环境炸了一个不相关的服务。事后复盘，根本原因不是代码，是我累到不会写测试了。

凌晨 3 点的运维

另一个我没预料到的，是 on-call 习惯的差异。

上海的运维 on-call 经常是"电话一来就跳起来"，原因是客户在上班、监控告警经常要立即响应。在东京，凌晨 3 点的 PagerDuty 告警优先级会被自动调低——不是因为不重视，是因为这个时段活跃的用户极少，自动恢复的概率很高，系统设计会优先"等 15 分钟看自己会不会好"。

这跟国内的"先响应再排查"哲学完全相反。一开始我很不习惯，觉得"这不就是不负责任吗"。后来发现，这是把"响应"和"修复"分开的一个具体实践。响应是值班同学的事，修复是工作时间的事。凌晨 3 点能不修就别修，不是因为懒，是因为仓促修复造成的二次事故比原始告警更贵。

我后来在自己的小项目里也学了这个模式：P2 告警在 23:00–7:00 之间只发 Slack 不打电话，15 分钟内自动消失就当没事，没消失第二天再处理。

写在最后

一年前我以为，从上海到东京，是从一个 +8 的服务器搬到一个 +9 的服务器。

现在我觉得，是从一种对"时间"的看法，搬到另一种。"时间"在日本不是一个能被精确切割的资源，它是一个有节奏、有礼仪、有"看不见的部分"的东西。

工程师学一个新的时区，调一下服务器就够了。
人学一个新的时区，需要把日历重新排一遍。