SRE 要有工程洁癖

做研发、做架构我们通常会追求工程优雅性，讲究代码质量、架构设计、方案合理性等，但 SRE 领域好像很少有人谈这些？

实际上，SRE 领域对工程规范的追求同样重要，甚至更需要，因为 SRE 的工作直接关系到系统的稳定性和可靠性。线上出了问题，我们是第一责任人，理应要有更高的要求。

当然，有同学可能会说，当前绝大部分的 SRE 工作还是偏向于运维，偏向于事务型工作，这种好像没办法追求工程优雅性？

其实不是的，细节中有魔鬼，比如:

• 你们的配置文件中，服务间调用有没有直接用 IP、写死端口的情况? 如果有这样的情况，你是听之任之将就继续，还是追根溯源，思考和推动使用更优雅的方案？这种配置方式看似简单直接，省了一时之事。但一旦服务器迁移或扩容，就需要手动修改大量配置，更糟糕的是，如果忘记修改某些配置，甚至可能导致事故。

• 你有没有遇到服务下线，机器上的配置，仓库中的配置清理不干净的情况？这种时候，在解决当前问题的同时，我们要不要思考为什么会出现这种情况，是哪里做的不到位，还是有人没有遵守 SOP 规范？配置文件残留可能导致新服务启动时读取到错误的配置，代码仓库中的废弃配置会误导其他同事，增加维护成本，甚至机器上的残留配置可能占用系统资源，甚至可能被误用，这些很明显有可能引发问题。

• 谈到 SOP 规范，SRE 同学一定觉得司空见惯，但它一定就合理吗？出一个问题，就来一个 SOP 规范，这么多 SOP 规范，我们真的能记住吗？对于不合理、不友好的 SOP 规范，你有没有去 Challenge，有没有思考更好的方案？

• 某些业务服务参数，比如数据库连接池大小、线程池配置、缓存参数等，每次都是研发让 SRE 手动去调。这种时候，你是选择被动接受，还是主动思考，每次都这么搞，不仅效率低下，而且容易出错。有没有想过，也许有更好的解决方案？比如业务程序自身实现自适应机制，根据负载自动调整参数；比如开发自动化工具，实现参数的智能调整等等。

• 大家每天处理的告警数有多少？被 OnCall 几次？如果是半夜被叫醒，难不难受？这里面的合理性到底在哪？真的不能 0 告警或者趋近于 0 吗？

此类场景在 SRE 日常工作中有很多，看似都是"小问题"，实际上都是工程实践不完美的体现，都是可改进的。

将就的方案可以临时解决问题，短期内也许不会有明显的负担，但长期来看，这些工程债务会不断累积，最终导致系统维护成本越来越高，进而引发事故。

当然，即使最终出问题，也许不会归咎于 SRE。但 SRE 作为最密切的接触者，直接的受害者，是有责任，也应该有动力去推动改进的。

所以我认为，SRE 要有工程洁癖。

什么意思？ 简单讲，就是你得嫌它"脏"啊。

因为有工程洁癖，我们才会:

• 能发现不优雅的地方，会想着改进
• 会不满足于现状，精益求精
• 会追求完美，不断进步

这种"洁癖"不是吹毛求疵，而是一种对工程质量的追求。

这些"脏"的问题，很多时候我们不提，可能就没人会提了。因为研发侧更关注业务功能的实现，对运维工程层面的问题不够敏感，动力也没那么足，毕竟不是他在难受。管理层也可能更关注业务指标，线上不出问题，他们可能天然会觉得没有问题。这时候，就需要依赖 SRE 的不断的提出问题。

当然提出问题的同时，也不能仅仅停留于此，还需要思考更好的解决方案。

我在之前的文章提到, SRE 本质上也是软件工程师, 应该习惯于通过软件工程师的思维来解决问题，这是 SRE 领域的第一性原理。

太阳底下没有新鲜事。

在工程领域，几乎没有问题是不可解决的，也没有问题是前人没遇到过的。站在巨人的肩膀上，我们可以少走很多弯路。

尤其现在是 AI 时代，知识平权，AI 就是最好的老师。

只要我们保持品味，不断探索，一切皆有可能。

大家觉得呢？