本篇要回答的问题：服务治理充满事务性工作，那么什么才是真正的"工程师思维 / 工程师文化"？它如何把人从无止境的事务中解放出来，去彻底 Close 一个个问题？
承接上一讲——服务治理没有简洁的抽象模型，要面对现实世界的复杂性，背后是大量的事务性工作（运维 / SRE 由此诞生）。本讲是一次"看似跳跃"的话题切换：从具体技术抽身，谈支撑这一切日新月异发展的底层心法——工程师思维。
事务 vs 工程：事务繁重就是危险信号
| 维度 | 事务性工作 | 工程性工作 |
|---|---|---|
| 性质 | 已知的、重复性的、低风险低压力 | 不确定、创新、把问题彻底解决 |
| 心理感受 | 平静、满足感、快速胜利感 | 需要思考，但带来长期成长 |
| 对职业发展 | 太多则让职业发展变慢甚至停滞 | 推动个人与团队往前走 |
关键判断：SRE 一定数量的事务不可避免，少量不是问题；但事务一旦变多就有害，特别繁重就该非常担忧——没有人能靠不停做脏活累活实现职业发展。
把问题彻底解决（Close 问题）
关键洞见：工程师文化不是去尊崇"工程师"这个职业，而是推崇"把问题彻底解决掉"的思维——编码只是其中一种工具。
- DON’T REPEAT YOURSELF：某件重复发生的事只干一次，以后不再重复做。
- 自动化思维的内在逻辑是"如何把问题 Close"；很多问题（如海底捞的服务质量、线下活动的内容质量）不需要编码也要用"彻底解决它"的思维去完成。
- 所有健康的公司都是业务导向的，技术人想要好发展也必须理解业务；销售、产品、支持、开发每个角色都是平等的。
| 对比 | 在做"事务" | 在做"工程" |
|---|---|---|
| 例：每天发公众号文章 | 把"每天发一篇"当目标→只是在做任务 | 先想清"在解决什么问题"→定义目标再彻底解决 |
| 长期价值 | 没实质解决问题→长期价值为零 | 看重工作内容的长期价值 |
把问题定义清楚 = 把目标设定清楚，然后才谈得上彻底解决它。判断自己是否在做"新的事"，就看问题是否解决得够彻底。
系统化思维与批判精神
更深一层，工程师思维是一种系统化 / 结构化的思维——光会编码和自动化不够，编码本身也可能只是在做事务。
关键判断：真正的工程师追求用最小化的编码工作解决更大范围的问题——“少就是指数级的多！”
对待代码的态度（反"情感依附"）：
| 糟糕的建议 | 为什么糟糕 |
|---|---|
| “以后可能用得到，先留着” | 源码管理系统回滚很容易，留着只是负担 |
| “先注释掉，方便以后用” | 大量注释代码造成干扰和混乱 |
| “加个功能开关吧” | 未启用的代码像定时炸弹等待爆炸 |
当你指望软件 24h 不间断服务时，每一行代码都是负担——SRE 应保证所有代码行都有必须存在的目的。
最后，软件工程要在**"不确定性（创新）与复制性"这对矛盾中平衡**，所以优秀工程师还需要批判精神：经验有价值，但过于相信惯例会抑制创新；要寻求本源、不迷信权威、以数据为指导、从根源系统性解决问题。
总结
服务治理背后是大量事务工作，尤其在对问题还不够了解时。正是工程师思维在背后支撑——坚持批判精神、坚持用系统化思维把问题彻底解决，才有今天服务治理日新月异的发展。工程师文化本质上也是产品文化：把问题以自动化的方式解决掉。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 事务 vs 工程 | 事务是重复劳动；工程是把问题彻底 Close |
| Close 问题 | 让某件事不再重复发生，编码只是工具之一 |
| 工程师文化 | 不尊崇职业本身，而推崇"彻底解决问题"的思维 |
| 系统化思维 | 用最小化编码解决更大范围问题 |
| 批判精神 | 不迷信惯例与权威，从根源系统性解决问题 |
一句话速记
工程师文化 = 把问题彻底 Close 的产品思维；“少就是指数级的多”——用最小的代码解决最大的问题，每一行多余代码都是定时炸弹。
几条值得记住的判断
- 事务繁重是危险信号，靠脏活累活换不来职业发展。
- DON’T REPEAT YOURSELF：重复的事只干一次。
- 每一行代码都是负担，留着/注释/功能开关都是坏建议。
- 工程师不是特殊群体，所有岗位平等，都应秉承"Close 问题"的工程师精神。
思考题
回到你手头最繁重的那块事务：你能清楚说出它在"解决什么问题"吗？如果说不清，你大概率只是在重复做任务而非 Close 问题。试着用"系统化 + 最小编码"的思路，给它设计一个能让它"不再发生"的方案。
