首先, 应该明确一个观点: SRE 本质上也是软件工程师, 应该习惯于通过软件工程师的思维来解决问题。这个观点，我认为可以是 SRE 领域的第一性原理。
对于不接触代码, 不愿意深入到代码实现细节的工作方式, 我认为在当前这个阶段是不行的。
线上的很多问题，本质上是业务问题，单靠运维手段是做不好稳定性保障的。而如果能从业务角度出发，从根源上解决问题，那稳定性天然就会得到保障。
所以从这个角度, SRE 花时间花精力去学习业务，理解实现，修复代码，可能反而是性价比更高的一种方式。
当然, SRE 本身就很忙，需要解决各种线上问题，可能并没有太多时间去深入理解业务，更没时间去深入到代码实现。
这是个问题，但不管是从组织侧，还是 SRE 团队内部，都可以有一定的优化空间。此处我们暂且不表，只说个人应该如何做。
从个人角度，如果说以前我们还有各种理由去拖延，比如不熟悉语言，不熟悉框架，不熟悉工具的话，但是现在已经是 AI 时代，借助 AI, 这些都不是问题。
知识平权，人人都可以成为专家。
我个人体验也是如此。以前我是搞测开的，没怎么做过线上相关工作，但是现在干了一两个月，仍感觉信心满满。因为我发现，工程技术领域没有秘密，只要有正确的认知和做事方式，没有什么是搞不定的。
那什么才是正确认知和做事方式呢？
践行最佳工程实践
我认为最重要的一点是: 寻找和践行最佳工程实践。
得过且过要不得，只解决表面问题也要不得。
拿到一件事，我们首先应该思考的是，这到底是什么问题？本质是啥？有没有上下文依赖项？到底要不要做？如果需要做，那应该如何做？是直接上手干，还是先调研一下？
其实在我看来，很多司空见惯的事情，背后都有很多值得思考的地方。如果只是按部就班的做，那可能永远只能停留在表面，无法深入，同样的问题还是可能会反复出现。
太阳底下没有新鲜事，很多问题，其实早就已经有人遇到过，甚至已经总结出了最佳实践。我们只需要站在巨人的肩膀上，就可以少走很多弯路。
那如何落实这个工作法呢？
这同样也不是个新鲜事，最重要的做法就是要有设计文档。不管是 aws，google，还是国内的其他优秀公司，我们都能看到对方案设计的重视。
我们大家可以思考下，你所在的公司、团队，有没有非常重视设计文档？你个人最近又有几篇设计文档输出？
如果数字不那么好看，那可能就需要反思下，这里面是不是有可以优化的地方。
当然，不能光看数量，更重要的是质量。
从组织侧，我认为把控设计文档的质量，是非常重要的一件事。
一定要推行强 review 文化。团队内部的 review 是基本的，如果能做到跨团队 review，那更好。
甚至，如果能向公司内部更高级别的技术领导者寻求建议，那无疑是最佳的。
一人计短，达者为先 。
review 的好处在于能补充更多的上下文，也能学习到不同的思考方式，同时也能减少方案后续推广的心智负担，因此性价比很高。
不断提升 SRE 工作专业性
软件工程没有银弹, 稳定性更是个系统性工程。SRE 工作内容很多，甚至很杂，这些都是事实，但总有做的好的行业前辈值得我们学习。
比如，就拿设立团队目标来说，可能会有人这么设计: 提升业务稳定性，确保 P1/P2 故障单季度次数小于 xx 次。
这个目标看似合理，但怎么定义 P1/P2 优先级？有没有具体的量化标准？若有的话，是不是全公司都认同？如果没有形成共识，那这个目标说服力就不足。
其次, 以事故数量来定义工作目标也不够科学, 如果说目标是 0 事故到还可以接受，但若目标定义在发生 2 次或者 3 次，谁又真正分辨出他们之间的区别和好坏？
所以，从这个角度，稳定性目标应该要更客观、更具有指导性。
参照《SRE: Google 运维解密》一书，构建面向 SLO 的工作方式，就显得相对科学和专业。
SLO 是 Service Level Objective 的缩写，是指 服务质量目标。
这本书，有花一大段文字来讲清楚，如何在指标建模、指标选择、指标分析等维度上的思考框架，我认为非常有参考性, 比如:
- SLO 目标应该从用户最关心的方面入手，而不是看现在能度量什么。与其选择指标，再想出对应的目标，不如从想要的目标反向推导具体的指标。
- 选择目标 SLO 不是一个纯粹的技术活动，必然涉及到产品和业务层面的决策。因为现实中，经常可能牺牲某些产品特性，或者承受一定的风险，以满足商业化的需求。所以 SLO 目标不是 SRE 一方就能决策的，务必前后拉通后，大家认知一致。
- SLO 越少越好，一定要确保每个 SLO 目标都是必不可少的。如果我们无法针对某个 SLO 目标说服开发团队，那么可能这个目标就是不必要的。
确定了 SLO 目标，也就确定了 SRE 在稳定性方面的工作目标。在这样一个可量化的目标中，我们可以看到我们的工作效果，也更能指导我们工作的改进。
黄金 4 指标
SLO 目标要做好，一定要有监控，而对任何用户可见的系统来讲，如果只能监控 4 个指标，那一定是 Latency(延迟)、Traffic(流量)、Errors(错误) 和 Saturation(饱和度).
相信对所有专业同学来讲，这个认知一定不陌生。不过，这里面有一些细节认知，我觉得还是需要注意的，比如:
-
延迟指标要区分成功和错误的情况。尤其一些慢错误情况，对系统的伤害更大，甚至有可能拖垮整个系统，要特别注意。
-
流量要基于不同的业务来看，比如有些系统适合监控 QPS（每秒查询数），有些则需要关注带宽使用率或数据传输量。例如，对于 Web 服务可以看每秒 HTTP 请求数；对于流媒体系统，可能更关注网络 I/O 速率和并发会话数；对于数据库或存储系统，可能要监控 IOPS（每秒 I/O 操作数）和吞吐量；对于消息队列系统，则重点关注消息处理速率。监控流量不仅要看总量，还需要分析流量模式和趋势，这有助于容量规划和异常流量的及时发现。
-
错误 率指标统计显示失败的情况，可能比较普遍，但极容易忽视隐式失败。比如返回请求是 200，但内容有问题。或者客户端对时间有要求，超过 1s 的请求都认为失败等等。
- 我就遇到过 CDN 相关服务，因为网络波动，导致在大文件场景下，返回码是 200，但后续吐数据极易失败的场景。这种时候如果只看返回码，就会遗漏。
-
饱和度指标，反应当前服务的容量有多 "满"，通常是系统中最受限的那个资源决定的，也就是符合 "木桶理论"。当然复杂系统下，挺难一下知道哪个是短板，但我们可以通过压力测试大略得到。实际上，饱和度指标通常都可以通过其他高层次的间接指标代替，比如 延迟增加就可能是饱和度的前导现象，我们就可以将 99% 的请求延迟（在某一个小的时间范围内，例如一分钟）可以作为一个饱和度早期预警的指标。
黄金四指标对用户可见系统的重要性不言而喻，它其实就是入口指标，日常 SRE 要做好这块的监控和响应，那监控方面基本就问题不大。
专业性也体现在如何对待琐事上
琐事是指运维服务中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。Google 会把 SRE 的工作时间中用于琐事的比例低于 50%作为很重要的管理目标。
我觉得虽然我们今天可能达不到这个目标，但是每一位 SRE 从业者都应该往这个目标靠齐。因为，这体现了我们作为软件工程师的追求问题。只有不断从技术工程中要创新，要效率，我们才能从繁琐的手动操作中解放出来，所谓'咖啡运维'才能成为可能。
SRE 本身是个技术含量很高的职业选择，做得越好，接触的工程技术越复杂。因为从业务服务角度，它需要的东西是恒定的，无外乎硬件资源、网络资源、系统中间件等。而如何提供这些资源却非常讲究，资源和服务提供的越方便、越便捷，那对业务一定越有利。我相信没有任何一个业务方愿意花大精力无脑造轮子的，除非支持不到位。而这理论上都是 SRE 可以解决的问题范畴。所以你看《SRE: Google 运维解密》这本书，有大量的篇幅在讲啥？在讲他们如何做负载均衡，如何应对过载；在讲如何提供分布式共识服务(Chubby)；在讲他们的分布式任务系统是啥样；也在前面的章节讲了他们如何管理物理机系统(Borg)等等，而这些领域，我们深入想想就会发现，其实是个必然，对吧？毕竟问题是一样的。
当然，想做好的 SRE 真的也不容易，不管是技术还是认知，都需要花大力气不断学习，不断成长。
大家一起加油！
参考资料：
