浅谈SRE工作内容和方法论

今年的618大促是我第一次担任部门的S级大促负责人，做完了618大促的复盘，整体的618保障就算结束了，我也有空可以好好梳理一下我在这四年里工作内容的进化和方法论。之前看过一篇 https://www.kawabangga.com/posts/4481 ，这篇文章里比较系统的整理了一下SRE的工作。但跟我这4年所做的事情还是有点区别，这篇文章只是我个人的一个阶段性的总结和记录。

我要先说一下，SRE这玩意基本就是大厂才有的东西，小厂是不会专门养这样一个团队的。现在大厂里的SRE有两拨人，有些是属于开发团队，这些人一部分的工作是业务开发，另一部分工作是稳定性保障，比较垂直。还有一些SRE是在质量QA团队的，他们的工作主要是跟测试同学一起辅助开发，比较横向。QA团队的SRE不会很多，基本开发:SRE人数比应该是50:1（我所在的部门是100:1）。QA团队的SRE人太多，要么说明基础能力太差，很多东西都是手工作坊，要么就是无效的卷来卷去，精力都拿去搞一些奇奇怪怪的东西。这两拨SRE在平时工作中紧密合作的关系。

我这四年主要的工作内容是：

灵活掌握公司内部的运维和监控平台如何使用。消除告警噪声，补全监控缺口。
熟悉开发流程，了解核心应用的发布计划、灰度计划和放量计划。
确定部门的故障场景，梳理出故障场景的等级，而且要跟上下游部门拉通对齐（很多人对“拉通对齐”这个词嗤之以鼻，但是我也不知道能有啥词来替换它）。
参与系统的设计，如果不能做到，那么至少要了解熔断、降级等策略。
深度参与压测，含单链路压测和全链路压测，了解系统的容量。
做容量规划，包含但不限于容器、数据库、缓存以及离线相关的云资源的容量规划。所以有些公司也会把降成本、做预算的工作交给SRE来做。
业务侧的 7*24 Oncall。
故障发生时参与定位，以及故障后复盘。
能独立开发一些平台、看板、工具，用于提升工作效率或者展示进度。
梳理核心链路，了解基本业务。

梳理故障场景&核心链路

做安全生产稳定性的方法论其实很简单，就是“变更前、变更中、变更后”。这里最好的抓手（好吧，又一个被人嗤之以鼻的词，但是我也不知道拿什么词替换它）就是故障场景，毕竟故障场景直接跟具体负责人的绩效挂钩。我见过很多开发牛的不行，在安全生产上特别狂野，结果搞出一个故障被业务方跟骂孙子似的骂了一顿后就怂的一匹。

通过故障场景也是一个了解业务的好机会，可能新人SRE刚到，还不了解自己所在的部门的核心业务是啥，整个故障场景定义会全程是懵逼的。懵逼很正常，懵逼不要怕，多看看开发PRD文档和技术文档，把公司产品下载到自己手机里，去感受一下探索一下，就有更深刻的理解了。所以说，如果一个SRE连自己公司的产品都不咋用，那就别想当SRE了。

通过故障场景的等级定义的分布，我们可以“抓大放小”，优先关注高级别的故障情况。然后对高级别的故障情况进行拆解，也就是“要达到这样具体的故障情况”那么系统会有哪些不正常，那么针对这些不正常的情况，就准备对应的接口限流和降级方案。

然后我们还要梳理核心链路以及核心链路上的强弱依赖，啥样的算核心链路？大流量和有核心功能接口的链路肯定是核心链路。这里先梳理一个大概，然后先算出一个理论的qps跟监控平台上实际的qps，然后根据两者的差异看出来是不是有奇怪的流量方或者流量在某些地方被意外的放大，针对情况作出优化。

整个梳理完毕之后，才能付于压测来验收整个链路的稳定性，没经过压测的链路是绝对不可以上大促的。

压测结束的时候，我们也要对比一下压测结果，我认为判断压测是否成功通过主要就是以下几个标准：

涉及的场景齐全，接口qps也符合事前预期。
各接口成功率满足4个9。这是首先要满足的，然后关注一下TP99等数据。
系统水位符合预期，且是一个较高的状态，这样才能压测出极限。
还有隐藏的一点，中间件的情况要跟日常情况相比较。我曾经压过一条链路，发现缓存命中率99%，但是实际日常缓存命中率只有95%左右，这代表我们的压测数据跟实际相差较大，没有压到DB，所以这次压测试不成功的。

大促风险梳理

大促的风险梳理的方法论也很简单：

1
2
3

面向上游看业务玩法和业务方流量有哪些变化。
面向自身和核心依赖看各域应用架构有哪些重要迭代。
面向下游看基建有哪些升级，目前基本都在阿里云上，包括容器、中间件、数据存储和缓存、VPC拓扑、ECS和服务器、文件存储、网络等等。

第一个是要跟产品和业务交流，而且是实时交流，因为有些时候大促突然间要有玩法的变更。比如我们今年618虽然公告说了没有官方预售，但是架不住几个KA商家非要自己玩，那我们也要配合。
第二个是要跟自己部门的开发同学交流，看看自己部门的应用架构有哪些重要的技改。举个例子，比如我们有些业务场景随着数据量的增加，是需要从memcache 改成rdb的，因为memcache只支持k-v格式，而rdb除了k-v格式，还支持string、list、hash、set等格式。那么这样的技改会对稳定性有哪些影响，同时rdb自身运维与mdb又有什么不同，都要check以及压测中验证。
第三个是要跟下游的基建同学交流，看看基建有哪些升级。比如物理机的调整，数据库物理盘升级云盘等等，这些也要check。

当然还是有一些小的铁律，举个我们踩过坑的消息队列的例子：一次我们发现某个工具应用刚刚清空了磁盘，但是没几分钟又满了，经过排查发现它被接入了两个大吞吐的消息队列。后来紧急看了一下这俩消息队列能否在大促高峰期降级，毕竟这只是一个工具应用，往往机器数很少，那么这钟应用就不要接入那么多的业务侧大体量消息队列，会把磁盘打爆。

总结

要唠SRE肯定要唠“稳定性”，毕竟稳定性就是衡量SRE的重要标准，这个标准的具体量化就是SLI/SLO。那么稳定性其实也分为两个方面，一个是稳定，字面意思很好理解。另一个是“性”，不过这个性不是18禁，而是性能优化。所以说基本上SRE要做的事情就是“发现问题”、“产出方案”、“跟进方案”、“解决问题”。

整个四年感受下来，我对业务的了解越来越深。SRE脱胎于开发/运维，再往上走就是架构师。如果不懂业务的SRE，将来是会被AI替代的，这不是危言耸听。

SRE是不是擦屁股的救火队员，这一点其实是看自己的心态和心态驱动的工作内容的，如果你走在系统的后面，你能看到的就只有系统的屁股，也只能做擦屁股的工作，如果你走到了系统的前面，你就能看到系统的方向，做的也就是探索性的工作。

再推荐一篇文章，https://mp.weixin.qq.com/s/IB0p6hckb_2yRkQ-WNg8rw?spm=ata.21736010.0.0.27cb6d37fNavw7 ，是我司SRE大神总结的，很长但是非常精华。

最后也是之前面试里遇到的一个很有意思的问题：如果你是集团安全生产的一号位，与业务一号位搭配，共同保障业务的稳定性，那么你会如何做？你的战略是什么？这个问题当然有点大，而且我也没当过一号位，我个人想了想主要是6个方面：

监控体系的搭建：监控是最重要的一环，有了监控我们知道过去，知道现在，也会推测出未来。
稳定性与成本的平衡：稳定性不能要求无止境的完美，不然产品永远不能上线。同时也要关注哪些业务是赚钱的，那么这些业务的稳定性要更投入。
预案和容灾能力：单元化其实已经能解决一定的问题，但是有限。
一线开发同学的排查和小队配合能力：系统完备，人的技能也要跟上，尽量不要口口相传，而是有文字有配合。
内容安全、合规、数据审计：这块我觉得是最重要的，懂得都懂。
生产关系和职责边界：作为管理者，权责利的分配和内容肯定都是非常重要的，而生产关系单独拉出来说是因为有些产品由于历史组织架构变来变去的问题，导致相关方利益不清晰，进而可能会不配合，导致风险。

在有限的认知里，我只能回答这么多，都是很具体的东西，果然农民一下子当了皇帝也是拿金锄头锄地的。