有一段时间，我发现自己越来越容易“卡住”。
事情很多。
工作不断进来。
消息不断弹出来。
脑子里同时挂着很多事情。
明明坐在电脑前，却越来越不想动。
有时候甚至一点小事，都能让我产生很大的情绪反应。
一个普通的工作消息。
一句别人说的话。
一个临时增加的任务。
以前可能觉得没什么。
那段时间却很容易烦躁。
然后我会告诉自己：
“再坚持一下。”
“这个事情做完就好了。”
“今天把这些处理完，明天就轻松了。”
但实际上：
明天还有新的事情。
于是继续扛。
继续处理。
继续压缩休息。
继续告诉自己：
“没事，我还能撑。”
直到某一天，我突然发现：
我不是在解决问题。
我是在：
用自己的系统容量，给问题兜底。
为什么人会在过载之前不知道自己已经过载？
技术系统有监控。
CPU到80%会报警。
内存到90%会报警。
请求延迟超过阈值会报警。
错误率持续升高会报警。
但人的系统没有这么明显。
我们通常不会在：
“精力剩20%。”
的时候弹出一个通知：
⚠️ 当前系统负载过高，请立即停止非必要任务。
于是很多时候：
身体已经超载，自己却还在要求自己继续运行。
直到最后：
情绪失控。
工作效率下降。
开始逃避。
失眠。
对家人没有耐心。
对工作产生强烈抵触。
甚至什么都不想做。
这时候才发现：
原来已经过载很久了。
所以我后来开始思考一个问题：
为什么服务器有熔断器，人没有？
熔断，不是逃避
在软件系统里，熔断器有一个很重要的作用：
当下游服务持续异常时，
停止继续调用。
为什么？
因为继续调用的代价可能更大。
如果服务A不断调用已经异常的服务B：
A会等待。
线程会被占用。
请求会堆积。
资源会耗尽。
最后：
B挂了。
A也挂了。
再往外扩散：
C、D、E全部受到影响。
所以熔断真正保护的不是某一个服务。
而是：
整个系统。
人的情绪和工作过载，也是一样。
当一个模块已经超负荷时，
继续往里面塞任务，
不一定是在提高效率。
可能是在：
把局部问题扩散成系统问题。
我们最容易犯的错误，是把“扛住”当成能力
程序员有一个很熟悉的状态：
线上出问题。
大家都开始加班。
凌晨两点还在查日志。
三点终于修好了。
第二天继续工作。
很多时候我们会觉得：
“还好扛住了。”
但如果这种状态持续发生：
这其实说明系统存在问题。
因为一个真正健康的系统：
不应该依赖某个人永远在线。
人的系统也一样。
偶尔扛一次，是应急。
长期靠扛，是架构问题。
情绪过载，其实也是一种系统告警
以前我不太喜欢自己的负面情绪。
烦躁。
焦虑。
愤怒。
委屈。
失望。
我会希望：
“赶紧过去。”
后来我换了一种理解。
如果把自己看成一个系统：
情绪不是系统的敌人。
它更像：
监控指标。
比如：
持续烦躁，
可能意味着资源不足。
持续焦虑，
可能意味着不确定性太高。
持续愤怒，
可能意味着边界被反复突破。
持续厌倦，
可能意味着当前任务与长期目标严重失配。
持续逃避，
可能意味着任务负载超过当前处理能力。
所以情绪本身不一定需要立刻消灭。
更重要的是：
读懂它。
我开始给自己的系统设计“熔断指标”
这件事情不需要非常复杂。
只需要找到几个：
自己能够明显感知的异常信号。
比如：
工作指标：
□ 连续多天超过正常工作时长
□ 睡眠持续被工作侵占
□ 下班以后还在不断处理工作
□ 明明很忙，但重要事情没有进展
□ 开始频繁拖延再比如：
情绪指标：
□ 对小事情反应明显变大
□ 不想和任何人沟通
□ 很容易烦躁
□ 脑子持续停不下来
□ 开始反复想着同一个问题再比如：
身体指标：
□ 明显疲惫
□ 注意力下降
□ 长时间久坐
□ 休息以后仍然无法恢复这些东西并不是医学诊断。
它们只是：
个人系统的监控指标。
真正重要的是：提前设置阈值
监控没有阈值，也没有意义。
比如：
CPU 80%。
那怎么办？
如果没有定义：
“超过80%就降低流量。”
那么这个指标只是一个数字。
人的状态也是一样。
所以我会给自己设计一个非常简单的：
三段式负载模型。
绿色区
正常运行
黄色区
负载升高
开始降级
红色区
系统过载
立即熔断重点不是数字多精准。
重点是：
提前决定自己在什么状态下应该做什么。
绿色区：正常运行
这个阶段：
精力正常。
情绪稳定。
工作可以推进。
睡眠基本正常。
能够学习。
能够思考。
能够和家人正常交流。
这时候不需要过度干预。
正常运行即可。
但这里有一个非常重要的原则：
不要因为现在状态很好，就把系统负载拉满。
很多人最容易犯的错误就是：
“今天状态特别好，那我多做一点。”
然后：
工作做到很晚。
晚上继续学习。
再做一点自己的项目。
再看一点资料。
结果把黄色区的压力提前埋进系统。
所以：
健康状态不是让你无限加负载。
而是：
给未来的不确定性留下容量。
黄色区：开始降级
这是整个熔断机制最重要的阶段。
因为：
真正好的熔断，不应该等到红色才触发。
当你发现：
连续几天工作时间明显增加。
开始频繁烦躁。
睡眠受到影响。
注意力下降。
重要事情开始拖延。
这时候不要继续说：
“我还能扛。”
而应该：
主动降级。
例如：
减少非核心任务。
暂停不重要的学习。
减少社交。
减少额外项目。
把复杂事情拆小。
推迟非紧急决定。
提前结束工作。
增加恢复时间。
这其实就是：
系统降级。
不是停机。
而是：
只保留核心服务。
什么叫“核心服务”？
这是我特别喜欢的一个概念。
当系统进入高负载状态：
不可能所有服务都保持正常。
所以需要定义：
哪些服务必须继续运行。
放到人生里，我觉得通常可以是：
核心服务
睡眠
家庭核心事务
必要工作
基本身体维护
关键责任而下面这些可以暂时降级：
非核心服务
刷资讯
无目的社交
额外项目
非必要会议
低价值任务
过度学习
无休止的信息输入这个逻辑非常重要。
因为人在过载的时候，最容易犯的错误是：
什么都想保住。
结果：
什么都保不住。
红色区：触发熔断
如果已经出现非常明显的过载信号：
工作完全无法集中。
情绪持续失控。
连续严重睡眠不足。
身体明显不适。
已经无法正常处理日常事务。
这时候就不能再靠：
“再坚持一下。”
来解决。
因为：
系统已经进入危险状态。
此时需要的是：
熔断。
停止非必要工作。
暂停额外项目。
减少输入。
离开持续刺激环境。
恢复基本睡眠和生活节奏。
必要时寻求专业帮助。
这不是失败。
而是：
保护系统。
如果身体或情绪问题已经严重影响日常生活，或者出现需要紧急处理的情况，专业医疗/心理支持应该优先于任何“自我管理技巧”。
熔断以后，还不能马上恢复满载
这是很多人容易忽略的一点。
技术系统发生故障之后：
不会刚恢复就直接把100%的流量全部放回来。
通常会：
0%
↓
10%
↓
30%
↓
50%
↓
100%也就是：
逐步恢复。
人的状态也一样。
熬了一个星期以后，终于休息了一天。
然后：
“好了，我满血复活。”
于是：
工作。
学习。
运动。
副业。
社交。
全部重新开始。
结果：
三天以后又过载。
所以真正合理的方式是：
恢复以后，逐步增加负载。
给自己一个“半开模式”
如果把系统设计得更工程化一点：
可以把熔断状态分成：
CLOSED
正常运行
OPEN
熔断
HALF-OPEN
半开测试
CLOSED
恢复正常这和很多熔断器的逻辑很像。
当系统过载：
CLOSED
↓
OPEN停止高负载任务。
经过一段恢复时间以后：
OPEN
↓
HALF-OPEN开始测试：
今天能不能正常工作？
能不能集中注意力？
情绪稳定吗？
睡眠恢复了吗？
如果稳定：
HALF-OPEN
↓
CLOSED恢复正常。
如果再次出现异常：
HALF-OPEN
↓
OPEN继续恢复。
这套机制给我最大的启发是：
恢复不是一次性的。
它也是一个过程。
工作上的熔断机制，可以非常具体
比如给自己设置几条规则：
规则一：
非紧急工作，不默认占用休息时间。
规则二：
连续高负载几天以后，主动降低任务量。
规则三：
下班以后，除真正紧急事件外，不进入工作模式。
规则四：
同一时间只允许少数几个高优先级任务运行。
规则五：
当任务开始影响睡眠时，视为系统异常。这些规则可能看起来有点“不努力”。
但其实：
边界本身就是生产力的一部分。
情绪上的熔断机制，也需要一个“停止按钮”
比如当我发现自己已经非常烦躁的时候。
以前可能继续争论。
继续解释。
继续证明自己是对的。
继续回复消息。
现在更合理的方式可能是：
先退出当前线程。
不是逃避。
而是：
Detect
↓
Pause
↓
Reduce Input
↓
Recover
↓
Re-evaluate
↓
Respond很多时候：
你并不是不知道答案。
只是：
当系统负载过高的时候，已经没有足够资源做出好的判断。
所以：
暂停本身，也是一种决策能力。
最危险的事情，是在过载状态下做重大决定
这一点我越来越有感触。
人在极度疲惫、愤怒、焦虑的时候，很容易产生：
“我要辞职。”
“我不干了。”
“以后再也不做这个了。”
“我什么都不想管了。”
这些决定不一定是错的。
但问题在于：
此时系统状态可能并不适合做高成本决策。
所以我更愿意给自己设置一个规则：
高负载状态
+
高情绪状态
=
暂停重大决策先恢复。
再判断。
这不是压抑自己的真实感受。
而是：
避免在系统异常状态下执行不可逆操作。
熔断的真正目的，是保护长期系统
如果一个系统偶尔熔断一次：
其实没什么。
如果一个人偶尔需要停下来休息：
也没什么。
真正值得关注的是：
为什么频繁过载？
如果每周都需要熔断。
那问题就不是：
“熔断机制设计得不好。”
而可能是：
系统长期容量不足。
这时候应该继续往下追：
工作量是不是过高？
任务是不是太多？
有没有大量低价值工作？
时间分配是不是失衡？
是不是长期睡眠不足？
是不是承担了太多别人应该承担的责任？
是不是一直在用意志力弥补系统设计问题？
所以：
熔断机制不是最终解决方案。
它是：
最后一道防线。
真正的目标，是让系统不那么容易过载
如果一个服务器每天都触发熔断。
我们不会说：
“熔断器真厉害。”
我们会问：
为什么流量这么大？
为什么资源这么少？
为什么没有扩容？
为什么请求没有限流？
为什么某个接口效率这么低？
人生也是一样。
如果你每天都需要靠“休息一天”才能恢复。
那就应该检查：
到底是什么东西一直在制造过载？
这才是更深层的重构。
给自己建立一份“个人熔断配置”
我现在觉得，每个人都应该有这样一份东西。
不用复杂。
甚至可以写在自己的笔记里：
# My Circuit Breaker
## 黄色预警
当出现：
- 连续高负载
- 睡眠明显下降
- 情绪明显波动
- 注意力持续下降
执行：
- 减少非核心任务
- 停止额外项目
- 减少信息输入
- 提前结束工作
- 增加恢复时间
## 红色熔断
当出现：
- 已无法正常工作
- 情绪持续失控
- 身体明显不适
- 基本生活受到影响
执行：
- 停止非必要任务
- 优先恢复
- 暂停重大决策
- 必要时寻求专业帮助
## 恢复
状态稳定后：
- 逐步恢复工作
- 逐步增加负载
- 观察是否再次异常
## 永久修复
如果反复触发：
- 检查工作结构
- 检查时间分配
- 检查长期压力源
- 重构系统写给未来自己的代码注释
// 不要等系统崩溃
// 才知道自己已经超载
if (load > WARNING_THRESHOLD) {
degrade();
}
if (load > CRITICAL_THRESHOLD) {
circuitBreaker.open();
}
// 熔断不是失败
// 是为了阻止故障扩散
while (circuitBreaker.isOpen()) {
recover();
reduceInput();
protectCoreServices();
}
// 恢复以后
// 不要一次性恢复全部负载
if (system.isStable()) {
enterHalfOpen();
graduallyIncreaseLoad();
}
// 如果反复熔断
// 不要继续优化熔断器
// 去寻找真正的过载源
if (circuitBreaker.repeatedlyOpens()) {
redesignSystem();
}写在最后
以前我总觉得：
一个厉害的人，应该很能扛。
事情多也能扛。
压力大也能扛。
情绪不好也能扛。
连续加班也能扛。
遇到问题继续扛。
但现在我越来越觉得：
真正成熟的人，不一定是最能扛的人。
而是：
知道什么时候应该继续，什么时候应该降级，什么时候必须停下来。
因为人生不是一次性的项目。
你不是要把今天的任务全部完成，就可以关机退休。
你还要运行很多年。
还有工作。
还有家庭。
还有自己的成长。
还有很多没有开始的事情。
所以：
短期的满负荷，不一定值得用长期的系统损耗来交换。
以前我把休息理解成：
“什么都不做。”
现在我更愿意把它理解成：
系统恢复。
以前我把暂停理解成：
“我不够努力。”
现在我会把它理解成：
主动保护系统。
以前我害怕自己停下来以后，会不会落后。
现在我更担心：
如果永远不停下来，我最后还剩下多少能力去走未来的路？
所以我想给自己留一个按钮。
当工作开始失控的时候：
降级。
当情绪开始失控的时候：
暂停。
当身体发出明显信号的时候：
熔断。
等系统恢复以后：
重新上线。
人生真正需要的，也许不是：
永不宕机。
而是：
知道什么时候应该主动断开。
因为有时候，
停下来，
不是离开人生。
恰恰是为了：
让人生还能继续运行。
我是语霖。
执笔为语，心落成霖。
记录一个40岁程序员重新设计人生系统的过程。
以前我想成为一个：
永远在线的人。
现在我更希望成为一个：
懂得保护自己系统容量的人。
因为真正长期稳定的系统，
从来不是没有熔断。
而是：
它知道什么时候，该把自己保护起来。