《Google SRE 工作手册》系列读书分享之美图 SRE 团队的「稳定性运营」实践篇三（视频 + 文字版）

​

引言

本期分享主题是美图 SRE 团队的稳定性运营实践，本期分享内容为「攻」规划 &运营：3 大方向、2 个基础、1 些探索、小结、Q&A

一、3 大方向

稳定性「监控体系梳理」

稳定性「可观测性建设-整体架构」

稳定性「监控大盘建设」

稳定性「运维元数据+应用拓扑」

​

稳定性「事件治理」

稳定性「图文告警推广」

提高告警消息的信息密度 (一图胜千言)

快速感知服务整体状态 (上下游/周边依赖)

缩短故障定位时间, 降低 MTTR

稳定性「由监到控」

稳定性「全链路压测平台」

效率/支撑「工单流程优化」

效率/支撑「例行工作自动化」

效率/支撑「命令行 &移动端工具建设」

成本「成本管控之 CAP」

成本「FinOps 探索实践」

成本「MTCC 平台」

​

成本「FinOps 落地的关键要素」

二、2 个基础

2 个基础「运维元数据 + 团队建设」

「运维元数据」

​

「团队建设：Pharos & AB 岗」

「团队建设：OKR + 敏捷」

三、1 些探索

SRE 稳定性运营的「一些探索」

建立及运营「权威消息通道」

收敛固定 SRE 支撑「官方群组」

稳定性运营平台(在线使用)

SRE 的那些困境「解决了吗？」

四、小结

关于 SRE 工作开展的「几点概括」

我所看到的几个「趋势」

​

最后的话「如何面对汹涌的技术浪潮」

​

五、互动答疑（Q&A）

石鹏(东方德胜)

2016 年加入美图，运维技术专家，美图产品 SRE 负责人。目前在美图负责社区、商业化、实验室、影像 SaaS、创新等全线产品的运维保障工作，同时参与公司日志、监控等基础设施的建设。参与或主导过多次公司基础设施的调整、改造，在监控、灾备、故障管理、稳定性运营等方面有一定的经验和积累。业界多个技术峰会的分享嘉宾或出品人。

Q1：可观测性建设整体架构中引用的工具体系非常多，它的底层的技术是 open telemetry 吗？是可以实现内核层面的观测，他可以拿到很多的信息，对吧？

A1：这里边我们其实用到了非常多的技术。Open Telemetry 的话，我们是从去年年底开始来推，目前的话我们正在逐步地把我们的基础监控的 agent 换成 Telemetry。其实现在大家讲这个内核层面的监控，大多都是用 BPF 来做的。之前，我们架构团队同学有自研过 Agent，也是用 BPF 的技术，去做一些这种内核级别的信息获取。

Q2：现在一个趋势是屏幕越做越大，但事实上里面实际用到的有用数据其实并不多，它堆砌了很多无用的东西，即可视化（visibility）做的并不好。从 SRE 的运维或者管理角度来讲，哪些是最有价值的一些信息？

A2：我的想法是这个事情可能还是要以终为始，从你要达成的目标来看。我们建设大屏是为了让我们更好地去发现问题，然后更快地去解决问题。所以说现在的一个建设思路，就是把一些更高维的一些信息，把最能够体现业务状态的关键指标抽出来，定义为一个北极星指标。但是我实际去解决问题的时候，我光靠这个北极星指标是不够的，我还是要去看日志、链路跟踪、一些堆栈的报错等。不过它可以给我一个指引，让我可以根据服务的拓扑关系，能够层层地钻下去。

Q3：所以您的建议是，大屏上并不是显示越来越多的信息就好，而是首先希望能够显示这些黄金指标，基于此能够有利于我们做 travel shooting 的这些全链路跟踪信息，您认为非常重要对吧？

A3：对，是的。我们要去做北极星指标，然后再下面的话，我们需要能够层层下钻。逐层去分析我们哪个层次、哪个环节出现了什么问题。然后要钻的话，需要有一个可靠的拓扑信息，也就是现在大家在屏幕上看大盘和报表底层的一个支撑数据。

Q4:现在已经是一个动态的环境了，在 Docker 和 K8S 里面都是。Docker 是个运行时，它其实一直在变动的，全链路跟踪也在实时的变动，你这个图是一个稳定的图吗？还是动态的？

 A4：首先这个图它是动态的，它不是说静态的，你可以看到里面它有很多 ID，这个其实就是我们不同 Pod 的这个 ID，是动态的。

Q5:所以是基于一个时间线的 trace，每一条都是代表一个 span 吗？这个 span 和 span 之间我把它串接起来以后，可以整个显示故障的影响范围和过程吗？

A5：大概的思路是这个样子，但是这个我们现在在图上看到的更多是我们的事件系统，跟 Trace 还有些区别。底层是一个我们基于 Cloud Events 的实现，用来做事件消息的管理。

Q6:从 AI 到生产还是有距离，对吧？

A6：我觉得它也是逐步发展。首先它可能是在学术领域会有比较好的成果，然后逐步的话可能会在某些垂直领域有一些行业的专家经验，或者比较丰富的一些历史素材的积累的加持，然后再这种前提下我们才能够把那一块做深、做好。

然后如果说是想直接去出一个大而全的，像 ChatGPT 这样，你去跟他聊什么他都能跟你聊两句，什么故障他都能帮你处理，这种可能大概率是不现实的。因为这个可能还会涉及到不同企业里面的个性化情况，比如基础设施并不是标准的，可能是自建的、公有云的或是其他，这些所有的可行性的预案类的东西都要基于一些标准化的前提，当然如果只是给我们提供一些专家经验、知识库的问答，应该还是比较可行的。

Q7:压测流程目前是基于人来调用，还是用那个 pipeline，用流水线都做到了目前这么一个状态？

A7：就是中间执行的部分是流水线，触发部分的话是可以去定时触发，也可以手动触发。也可以做相对比较自由的编排。

Q8:这个流程是写在 yaml 文件里面的，是吗？用 pipeline 是怎么做到的？

A8：目前不是这样的，目前我们是选择式的，为了降低用户的使用门槛，用户可能就勾勾选选就好了，然后把一些东西抽象出来，填一填。没有把类似 Pipeline 的配置文件开放出来。

Q9:这个 FinOps 最近也比较热，但它的来源是来自于公有云的，基于这个订阅式服务的，它的适用场景是就去中心化的，但是这个跟传统 ITIL 里面讲这个集中管控的财务管理不太一样。美图是公有的，都放在云上的吗？还是自己私有云呢？

A9：目前的话我们绝大多数资源都是在云上，都是公有云。但是我认为，FinOps 它所定义的这个场景范围其实是被大大缩小了的、被定义给局限了。其实 FinOps 里面的一些理念抽象之后，就是在做一个 IT 资源的一个供需管理，你的需求是什么样的，然后我的供给侧是什么样子的？我怎么去更好地去做供给，然后怎么样让资源达到一个比较理想的利用率，最终去达到降本这个目标。

Q10:在传统的 IT 环境下也是讲这个供需的平衡，但是这个平衡在公有云模式下被这个去中心化给突破了，因为没有一个管控点。你们怎么管控这个云资源、云服务的使用 ？

A10：最近在 FinOps 这个方向上，我跟多个企业的老师也有过交流。然后关于管控点这个点其实蛮重要的，就是你的基础设施资源一定要是中央集权化管控的才会更好推行 FinOps。

本期视频回看：

​

官方网站：www.sretraining.cn

​