标签：evo determine 外部 技术 目的 can 开发 sig 简单
作者 | 悟鹏
来源 | 阿里巴巴云原生公众号
《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:
基础服务：
可以将 OpenTelemetry 作为基础落地上述事项，参见：《OpenTelemetry 简析》。
与此同时，可以探索可视化的稳定性保障服务，从全局视角加快问题发现、定位、解决，一张图把握集群中「组件自身」和「组件之间交互」的健康状态 ，形如下图：
以此为入口，从整体把握集群状态，关联异常信息，处理问题时有的放矢。
Serverless 是目前很有前景的云上计算形态，阿里云提供了比较完整的 Serverless 计算产品，如下：
不同 Serverless 计算环境的一个主要差异点在于运行环境的持续时间，以此为出发点，可以抽象出 Serverless 计算环境中可观测性的核心，然后分解出相应的解决方案：
根据运行环境持续时长的不同，可粗略划分为 3 类：
这些运行环境均可以通过虚拟机、容器或 WebAssembly 等技术实现，区别点在于业务层面限定的运行环境持续时长。
根据运行环境持续时长的特征，平台和用户的关注核心会有相应的变化：
天级别的运行环境，平台方的核心在于提供可靠的运行环境，由用户自由管理应用
小时级别的运行环境，平台方的核心在于围绕应用提供管理服务，用户聚焦于业务自身
分钟或秒级别的运行环境，平台方的核心在于细粒度的用户业务逻辑管理，用户更聚焦在业务的敏感特征
对于 FaaS 场景，THUNDRA 公司 的 demo 提供了比较好的示例以供参考 (截取 3 个示例)：
通过对可观测性概念、问题域、不同层级需求等形成深入理解，可以形成对可观测性的理解大图，然后在此基础上与业务结合，增强业务在可观测性方面的竞争力，同时迭代理解，技术与业务相互促进。
欢迎大家留言交流使用 Kubernetes 过程中的稳定性保障问题，以及对稳定性保障的期待工具或服务。大家也可通过邮箱联系作者，进一步深入交流：flyer.zyf@alibaba-inc.com。
标签：evo determine 外部 技术 目的 can 开发 sig 简单
原文地址：https://www.cnblogs.com/alisystemsoftware/p/14607116.html
