1. 两年前选了一条不一样的路

现在回顾，2021 年应该是近些年武汉互联网打工人跳槽的黄金年份。疫情过去，我们对未来充满期待；货币政策宽松，公司对市场前景满怀信心。

在这个背景下，当时一批做 Kubernetes 开源产品的同事纷纷跳槽，去云厂商继续做云基础设施。凭借过硬的技术和开源产品的加持，他们都拿到了不错的 offer。

但我没有选择云厂商，而是选择了偏业务型的公司。从技术的角度来说，云厂商的技术栈更加先进，技术是他们的核心竞争力; 而业务型公司的技术栈更加保守，他们的核心在于业务的发展。目标不同，决策时的出发点，工作时的推进策略，都会有所不同。

做出这个决定的原因在于，我想了解一下平时支撑的业务，他们是如何工作的，为什么在支撑他们时总能提出一些奇奇怪怪的问题。然后，我干脆就直接去了业务型公司，看看他们是如何思考的、如何决策的。还有一个原因就是，从社会发展的角度来看，技术很重要，但是能将技术融合于生产生活的业务型公司能给人类带来更多的幸福感。发明电很伟大，但对普通人来说，能用上电灯、电风扇，看上电视，用上电脑，才是更重要的。

2. 业务型公司需要怎样的 SRE

2.1 当好救火队员

能缩短 MTTF 平均故障时间的人很重要，业务的稳定性优先级高于一切。业务型公司的 SRE 需要能够快速定位问题、恢复服务，能做到这一点并不容易。

基础设施层计算、存储、网络的问题，需要的是技术深度的挖掘、技术面的扩展，一般技术同学点到即止，遇到源码级别的 Bug，不一定能兜得住，流量各层转发十几跳，每个地方都可能有问题。一个节点十几个 Pod，谁知道哪个 Pod 会突然抽风狂写 IO。

平台层的问题，需要对 SRE 相关设施非常熟悉。你会写 PromQL ，但你找不到 Grafana、VictoriaMetrics 的地址；你看到了监控面板，但里面有些指标绘制错了；你怀疑是负载不均导致的，但你找不到监控和日志来证明；你想看看 Kubelet 日志，但你登录不了操作系统。通用的 SRE 技能，我相信大家都能掌握，但每个公司的用法、实践路径、掌握水平都不一样，需要花时间去熟悉，才能快速定位问题。与其他同事的合作需要磨合，建立信任也需要时间。

应用层的问题，需要能帮业务落地最佳实践、最好能看懂业务代码。当有故障，背锅的大概率是 SRE。如果你不服气，又找不到原因，就得去看业务代码。也许看个几次，和业务多交流几次，就能找到问题所在；也许翻烂了代码，还是一脸懵逼，就只能听天由命，祈祷不要再次出现这类问题了。

救火队员是团队中最有存在感的角色，无论是贡献度，还是影响力，都是最高的。当好救火队员是立足 SRE 团队不错的一个切入点。

2.2 以创业心态去做产品

想要站稳业务型 SRE，是需要有支撑点的。除了技术本身外，还需要 SRE 产品。产品是技术的放大器，个人的技术只能服务有限的对象，产品可以在不显著增加边际成本的情况下，服务更多的对象，这也是老板喜闻乐见的事情。

整天救火不是长久之计，有了主导的产品，SRE 才有了发展空间。向上有了明确的 OKR、KPI 导向，体现出价值，向下有了更多的工作内容，发挥能力。

为什么说要以创业的心态去做产品？业务型公司的 SRE，没有一个完善的工作流。SRE 人员应该是一个多面手，我们能定 SLI，还能保障 SLA；我们能当开发，还能当运维；我们能当产品，还能当运营。总之，我们需要关注产品的完整生命周期。

但创业的难点不在技术与产品，而在于找到客户。在业务型公司，客户就是业务同学。业务同学的需求，往往是模糊的，甚至是不可描述的。这就需要 SRE 能够主动去挖掘需求，主动去和业务同学沟通，主动去推动产品的落地。

整个过程可能会持续很久，几个月、一两年、甚至更久，在这个过程中需要不断地向上汇报，展示成果，赢得支持；向下推动，做好样板，保障产品的落地。这需要 SRE 有很强的执行力、销售能力、抗压能力。

2.3 杂草丛生处开花

前面说到了做产品的心态，这部分我们聊聊产品。

运维领域的基本功能诉求是发布、构建、监控、日志、告警、CMDB、工单等。这些核心的命题已经被前辈们研究得太多，你想从 0 到 1，不拖泥带水地按照自己的想法去落地一个产品，几乎是不可能的。

最佳实践网上一大片一大片的，但想要在内部落地，执行力远比想象力重要得多。你可以拿着 PPT 到处讲，但回到具体事项上，还是得日拱一卒，一点点地去做。

这里的杂草并不是贬低原有的系统，只是表示会有很多的干扰、历史负担、新的需求。这些都是实际工作时，很普遍碰到的问题。如果没有一个有魄力的领导引领，与业务同学的默契配合，很难做出成绩。

重构原有的产品是比较困难的，我们需要将重点放在增量上，这也契合业务地快速发展需要。面向未来去做设计，不要被眼前的杂草所困扰，让老的系统慢慢退化直至下线。

3. 机会与挑战

3.1 跟着业务一起成长

业务型公司的 SRE 相较于云厂商的 SRE 有一个很大的优势，扩张系数更大。

同等量的扩张，业务型公司会增加更多的技术人员。业务型公司不会像云厂商一样，考虑扩展性问题。考虑扩展性会加大设计的难度，会增加开发、运维的成本。业务型公司的目标是业务的发展，而不是技术的发展。这与云厂商的思维方式不同。

业务增长时，会增加技术人员的储备，就有机会升职。业务型公司赚到了钱，就有机会加薪。我们才能过上更好的生活。

3.2 检验自己的方法论

在平台型的公司，员工很容易误将平台能力当做是自己的能力。平台产品牛逼，就觉得自己也是一个档次，其实不然。

知识和方法是需要内化的。当我们听见、看见、记住之后，更重要的是要自己去实践，去总结，去提炼，去形成自己的方法论，一套能够自洽完整的逻辑。

对于技术人员，形成自己的思考之后，要具象化和自己绑定在一起，就像 https://www.chenshaowen.com/ops ，做最优解，而不要写防御性的代码。这其实是与公司双赢的过程，我们开发了工具让大家的工作更高效，开放的工具也让我们更加具市场竞争力。

独当一面，内生沉淀，这样的机会在大厂其实是难以得到的。

3.3 技术的退化

相较于云厂商，业务型公司专注于业务使用的技术栈，而不会太关注技术的演化和发展。

云厂商因为服务的客户更多元化，看到的技术周期更完整，会更具前瞻性，这也是云厂商的卖点之一。他们不仅能提供云服务，还能提供技术兜底，甚至还能做公司的技术顾问，指明未来三到五年的技术路线。

也正是这样的卖点，促使云厂商必须深入研究每一个细节和可能的缺陷。但业务公司不一定需要解决这些难题，我们可以浪费点资源、写点不那么优雅的代码绕过去。

另一方面是技术氛围。业务型公司的 SRE 日常讨论的都与业务息息相关。技术上的布局不会超前于公司战略，只能略超前于业务规划。

业务型公司 SRE 的技术退化问题很难避免，但这也算是一种交易，我们会增加对业务的理解。这种交易值不值，得看业务领域是否有前景，是否有进入的壁垒。

3.4 人员调整频繁

焦虑时，中小型公司可能会不断地调整组织架构，变动人事。

人一变，事项就变了，目标也变了，今年干的事情，明年就不干了。这种没有持续性的事情，谁干起来都会不得劲，没有成就感，容易衍生懈怠的情绪。

如果在哪儿都是摸鱼，频繁变动其实也挺好；如果真的想干点事，有点积累，那认真就输了。

运维领域不同于研发显著的点是，运维得稳，研发要快。目标清晰，长久而持续地投入，运维体系就能建设得很好，因为核心问题定义非常明确；研发很多时候是在赌市场能不能爆发，只会锦上添花，不会雪中送炭。

4. 总结

本文主要是关于这两年在业务型公司做 SRE 的一些体会。主要是从 SRE 的角度出发，谈谈业务型公司的 SRE 需要做什么，会遇到什么样的机会和挑战。