作者 | 悟鹏
来源 | 阿里巴巴云原生公众号
《Kubernetes 稳定性保障手册》系列文章：
- Kubernetes 稳定性保障手册 -- 极简版
- Kubernetes 稳定性保障手册 -- 日志专题
- Kubernetes 稳定性保障手册 -- 可观测性专题（本文）
伴随大家对稳定性重视程度的不断提升、社区可观测性项目的火热，可观测性成为了一个很热门的话题，站在不同的角度会产生不同的理解。
我们从软件开发的生命周期出发，尝试形成对可观测性的一个宏观理解，并从 SRE 和 Serverless 两个角度具化可观测性的理解以及实践。
目的
- 增强认知，通过全局把握来提升竞争力
- 通过合理的设计和实践，为未来带来可能性
目标
- 针对可观测性的理解达成一致
- 针对可观测性的发展方向达成一致
什么是可观测性？
从 wikipedia: Observability 可理解到 可观测性 的定义：
In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs.
Consider a physical system modeled in state-space representation. A system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs (physically, this generally corresponds to information obtained by sensors). In other words, one can determine the behavior of the entire system from the system's outputs. On the other hand, if the system is not observable, there are state trajectories that are not distinguishable by only measuring the outputs.
简单表述为，可观测性是一种方法，通过系统的外部输出推导出系统内部的状态。
下图简化了系统的组成和系统间的交互：
从上述交互图可了解到，系统的交互行为有如下几种形态：
系统内部
- 组件功能闭环，不与其他组件或系统交互
- 组件之间交互
系统之间
- 系统和系统之间进行交互
这样，通过如下两种形态的信息，就可以通过系统的外部输出了解到系统的内部状态：
- 组件闭环的信息
- 组件间或系统间流动的信息
可观测性的问题域是什么？
可观测性的核心在于 通过观测数据、满足不同人群、对于系统状态的理解需求，这里先抽象观测数据的生命周期，有如下图示：
观测数据通过 App 生成，经过中间处理环节后进行存储，然后提供查询服务。
观测数据服务于不同类型的人群，如产品的用户、业务、研发、SRE，不同的人群通过不同的形态来使用这些数据，包括 SLA / SLO / SLI / Alert 等。
根据可观测数据的生命周期，可粗略总结可观测性的问题域：
生成端
- 观测数据的数据模型
- 观测数据的生成
- 观测数据的导出
处理端
- 观测数据的采集
- 观测数据的处理
- 观测数据的导出
存储端
- 观测数据的存储
- 观测数据的查询
- 观测数据的使用
使用端
- 观测数据的消费
软件开发生命周期中，可观测性的服务目标是什么？
从项目整体视角来看软件开发的生命周期，有如下的流程：
细化下来：
在软件开发生命周期中，有 4 类角色。面对 4 类角色，可观测性的服务目标会有差异：
Note:
- 可靠 与 稳定 不是等同的关系，可靠 包含了 稳定+及时满足功能需求 特征
SRE 可以投入的方向
基础服务：
可以将 OpenTelemetry 作为基础落地上述事项，参见：《OpenTelemetry 简析》。
与此同时，可以探索可视化的稳定性保障服务，从全局视角加快问题发现、定位、解决，一张图把握集群中「组件自身」和「组件之间交互」的健康状态 ，形如下图：
以此为入口，从整体把握集群状态，关联异常信息，处理问题时有的放矢。
Serverless 场景下可观测性
Serverless 是目前很有前景的云上计算形态，阿里云提供了比较完整的 Serverless 计算产品，如下：
不同 Serverless 计算环境的一个主要差异点在于运行环境的持续时间，以此为出发点，可以抽象出 Serverless 计算环境中可观测性的核心，然后分解出相应的解决方案：
根据运行环境持续时长的不同，可粗略划分为 3 类：
- 天级别
- 小时级别
- 分钟或秒级别
这些运行环境均可以通过虚拟机、容器或 WebAssembly 等技术实现，区别点在于业务层面限定的运行环境持续时长。
根据运行环境持续时长的特征，平台和用户的关注核心会有相应的变化：
天级别的运行环境，平台方的核心在于提供可靠的运行环境，由用户自由管理应用
- 对于可观测性，平台方核心在于运行环境可靠性，用户核心在于应用环境稳定性和请求响应性能
小时级别的运行环境，平台方的核心在于围绕应用提供管理服务，用户聚焦于业务自身
- 对于可观测性，平台方核心在于应用运行稳定性和请求响应性能，用户核心在于业务特征
分钟或秒级别的运行环境，平台方的核心在于细粒度的用户业务逻辑管理，用户更聚焦在业务的敏感特征
- 对于可观测性，平台方核心在于请求响应可靠性和业务特征，用户核心在于核心业务特征
对于 FaaS 场景，THUNDRA 公司 的 demo 提供了比较好的示例以供参考 (截取 3 个示例)：
- 函数
- 应用
- 架构
小结
通过对可观测性概念、问题域、不同层级需求等形成深入理解，可以形成对可观测性的理解大图，然后在此基础上与业务结合，增强业务在可观测性方面的竞争力，同时迭代理解，技术与业务相互促进。
References
- wikipedia: Observability
- wikipedia: Service-level objective
- wikipedia: Service-level agreement
- wikipedia: Service level
- Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers
- conprof - Continuous Profiling
- OpenTelemetry Proposal issues: Adding profiling as a support event type
- Kubernetes scalability and performance SLIs/SLOs
- 从 DevOps 到 NoOps，Serverless 技术的落地方式探讨
欢迎大家留言交流使用 Kubernetes 过程中的稳定性保障问题，以及对稳定性保障的期待工具或服务。大家也可通过邮箱联系作者，进一步深入交流：flyer.zyf@alibaba-inc.com。
