多团队协作构建可观测性

实施 SRE 工程，守护系统的可靠性是一个⻓期的工作，需要开发、测试、运维以及 SRE 整个团队的努力。而可观测性平台天生就是为 SRE 工程服务的，它致力于实现 SLO 目标。建立可观测性不仅仅是运维团队的事情，更是整个开发、测试以及 SRE 团队的事情，这是全团队的工作。

1、开发团队

从数据采集的埋点开始，开发团队就必须为可观测性负责，因为整个产品、服务和组件都是这个系统的开发人员构建的，没有人比开发本身更了解这个系统，更能知道系统在运行状态下该暴露哪些指标、日志和链路追踪等遥测数据。虽然可观测性平台的 Agent 做了很多自动化的工作，但仍然需要开发人员将属于自己组件特性的遥测数据有效地暴露出来。

2、运维团队

运维团队是很多企业中的基础设施团队，也是 SRE 工程中重要的一环。在建立可观测性时，更需要注重下面这几个领域的工作。

• 构建与管理包括云平台、Kubernetes 集群、CI/CD、Git 环境、研发任务管理平台、文档中心等一系列的面向公司内部开发者的基础环境。定义测试环境、预发验证环境和生产环境。
• 充分和合理地利用云原生的特性。例如，使用云计算服务意味着你将一部分的 SRE 工程交给了云厂商，可以充分利用优秀云厂商提供的服务能力和水平；Kubernetes 已经成为了分布式集群事实上的操作系统，而云原生标准下的组件都实现了可观测性的支持，接入云原生组件可以降低构建可观测性的成本。
• 尽可能地收集所有组件系统的所有相关面的基础数据。组件包括云、主机、容器、Kubernetes 集群、应用、各种终端，相关面是指性能、网络、安全、容量，基础数据包括指标、日志、链路。实时收集数据的成本并不高，但如果没有收集，一旦系统故障，在需要排查分析问题的时候，就无法有效评估当时的状态了。
• 设置相关的监控告警。运维团队应该和开发团队合作，对产品和服务重要的指标建立告警，包括一些低优先级的监控告警。这样做的目的是在最终用户的使用体验真正受到影响之前，优先得知系统中潜在的问题，提前进行分析定位，及时修复。

3、测试团队

此外，测试团队也需要加入到可观测性的建立当中来，测试团队要做的更多的是对产品和功能的理解，他们需要通过可观测性及时发现每一次新功能和新版本发布的问题，并及时反馈给开发（例如代码质量问题或产品 Bug）或运维团队（例如有关基础设施的问题）。

而另一方面，测试团队会通过对系统进行压测、引入混沌工程等操作进一步验证系统的可靠性，提升系统质量。这时候，测试人员更加需要借助可观测平台了解系统的基线状态，搞清现场执行情况与预期存在偏差的原因，甚至发现之前可能根本就无法预料到的问题，从而对系统进行优化和完善。

4、SRE 团队

在有的企业，会设立专门的 SRE 团队，而在有些企业，这并不是一个固定的岗位，而是多个岗位之间的协同。从建立可观测的角度来说，SRE 团队需要能够完成下面这些工作。

• 构建和实施软件，提高系统和服务的可靠性。例如，建立自动化评估系统的 SLO 状态，而不是手工根据一个清单来一一对照。建立可观测，包括各维度的监测、告警等，随时明确地知道 SLO 的满足情况。
• On Call 支持。在如今云原生的时代，期望系统 100% 没有问题是不现实的。出现故障时，我们需要快速找到根本原因。把 SRE 工程师加入到 On Call 支持团队，能让他们了解应用有什么样的问题、如何解决这些问题以及该如何改进（例如，告警是否提供了足够的信息，问题的分析是否足够高效等等）。
• 事后的分析和复盘也很重要。这也是持续改进，逐渐提高系统可靠性的重要一环。每次未被观测的故障都是进一步提升可观测范围的绝佳机会。

系统的可观测性也需要持续优化和改进。针对整个系统的可观测，包括数据收集和分析、监测和告警构建、标签体系建立等等都需要时间。

此文章为3月Day9 学习笔记，内容来源于极客时间《深入浅出可观测性》，推荐该课程。