程序员的工资是唯一现金流，时间才是本金。这个说法我越用越觉得准确。本金放在哪里，哪里就长出东西来——放在焦虑上长焦虑，放在比较上长比较，放在具体的事情上长实感。
前阵子我干了一件很小的事：把书架上的书按“还会不会再读一遍”重新分了一次。手边只留了七八本，其余全塞进柜子深处。书架没整齐多少，人倒是轻了一点。因为我第一次清楚知道，什么值得留在光线够得着的地方。
这事跟技术选型是一个道理。不是把能用的组件都塞进系统，而是挑少数几样放进架构，让它们各就各位，陪你穿过时间。选型的核心从来不只是“选对”，更是“放对”——知道什么值得占用你有限的复杂度预算，也知道放进去之后别轻易挪来挪去。
刚写代码那几年我不懂这个。那时以为架构最重要的问题是“用什么”：哪个框架、哪种数据库、追哪个新东西。结果是系统越来越复杂，人越来越累，问题一个没少。后来才明白，一个系统能不能长久跑下去，不取决于你用了什么，而取决于它能不能在稳定结构里待够久。让系统稳住的，往往不是你改了多少行代码，而是你有没有给它时间暴露问题、沉淀经验。
容量规划的思路搬到时间上
做容量规划的人不会让一台机器长期跑在 90% 以上。冗余不是闲置，是留给尖峰流量和未知异常的缓冲。用尽了，系统就会在某个不起眼的时刻突然崩掉。
这个道理在 Linux 上是能动手验证的。cgroup v2 里用 cpu.max 限制一个 cgroup 的 CPU 带宽，格式是“配额 周期”，比如 50000 100000 表示每 100ms 周期内最多用 50ms，折合半个核。写进 /sys/fs/cgroup/<组名>/cpu.max 之后，在该组里跑压测，同时用 cpu.stat 看 throttled 计数：
cat /sys/fs/cgroup/demo/cpu.max
cat /sys/fs/cgroup/demo/cpu.stat
判定标准很直接：nr_throttled 持续增长、throttled_usec 明显累积，说明这个组已经被限流，实际拿到的算力低于它以为自己能拿到的。这跟人是一个模型——你以为自己还有余量，其实早就被节流了，只是没看计数器。
我做过一次核心系统重构。上线前每个模块的资源占用都算得很细，信心满满。前几周平稳。直到某天下午，一个上游系统开始大量重试，流量十几分钟内翻了近一倍。预留容量看着够，监控大盘却开始陡峭上升：CPU 从 70% 冲到 95%，响应时间从 200ms 涨到两秒，排队堆积，一个平时不起眼的边缘服务率先超时，报错沿调用链一路传回来。
复盘时我在白板上画了一条曲线：响应时间不是线性上升的，接近饱和的某个点之后突然拐弯，然后失控。拐点之前一切正常，拐点之后做什么都来不及。
这里有个容易被忽略的观测口径问题。判断是否接近拐点，看平均响应时间会骗人——少数慢请求被大量快请求稀释掉了。要看 P99 甚至 P999，配合队列深度和 CPU 利用率一起看。经验上单核利用率越过 70% 左右，排队延迟就开始非线性膨胀，具体阈值随负载特征浮动，但趋势是稳的：均值还好看的时候，尾部已经烂了。容量决策要拿尾部数据做，不是拿均值。
生活同理。我不再把每一分钟排满，而是把时间分成几块：工作里最核心的产出、阅读和思考、家人朋友、留给自己。系统不会把所有资源分给同一个服务，人也不该。与其精算每分钟吞吐，不如先把最重要的几块预留出来，别让它们轻易被挤占。把时间锚在几个固定位置，比切得过于细碎更重要。
团队也需要再平衡
投资里有个词叫再平衡：定期把资产比例调回最初设定，让组合停在你能承受的风险区间。系统需要，生活需要，团队更需要。
做管理久了会发现，一个团队长期把全部精力压在同一个项目上，短期交付快，技术债却越积越多，人的状态也越来越紧。
有一年接了个重要项目，团队几乎全压上去。需求排得密密麻麻，日程精确到半小时。那段时间交付确实快，三个月后问题集中爆发：文档没人维护，新人上手困难；测试覆盖率持续下滑，偶发线上问题排查要花好几倍时间；几个核心成员开始疲惫，有一个人直接提了离职。
我那时才意识到，我们一直在交付，从没检修。团队也需要再平衡：短期交付和长期能力、紧急任务和基础建设、输出和休息。不能等人走了才想他的活有没有人接得住，不能等线上出故障才发现某个模块只有一个人能改。需要定期检视的，恰恰是那些看起来还撑得住的地方。
偏了就轻轻调
有段时间我把太多时间放在工作上。白天不停切任务，晚上到家整个人是空的。对家人没耐心，说话短促，像一根拉得太紧的弦。
不是生活出了大问题，是配置偏了：工作那块太重，别的太轻。这时候不该一把掀翻天平，而是轻轻调——少一点，或者挪一点，让它慢慢回到你能呼吸、也能睡着的状态。好的调整大多不剧烈。
想明白“配置”这件事，是在一个很普通的周末下午。我坐在沙发上，手边一杯茶，阳光斜着照进来，落在地板上也落在杯沿上。没有急着要做的事，也没有特别想逃开的东西，就坐着，什么也没干。
然后我意识到，已经很久没这样坐过了。没刷手机，没看盘，没想下一步。只是坐着，让时间安静流过去。
后来我把这段时间也放进了配置，管它叫“什么也不做的时间”。看上去毫无产出，容易被误解成浪费。可它不是多余的，像系统里的冗余容量，不创造价值，却在流量尖峰到来时给你留缓冲。一台机器长期跑满 100% 负载，不是在高效运转，是在加速老化。人也一样，那些看起来没有产出的时间，是系统在自我修复。
配置的终点是能长久运转
现在做任何安排，我最后都问自己一句：这个配置，能让我睡得着吗？能，大概率就适合；不能，再漂亮也该调。
我见过系统架构很先进、团队却天天救火的；也见过技术栈普通、系统很稳、业务增长也卷不走团队的。后者是我更想成为的那种。配置的终点不是让每一部分都最优，而是让整体能长久运转。不是架构图上每个组件都光鲜，而是你愿意继续维护它，每次发布上线心里没那么多拉扯。
回到那摞书。留在手边的七八本，是我决定留给自己的东西。它们不一定立刻给回报，也不一定马上派上用场，但我知道需要的时候它们就在手边。
你把时间放在哪里，哪里就会生长。
ID:6545
