背景
云计算成为信息时代的算力底座，服务千家万户。作为重要的基础实施，稳定压倒一切。但同时云计算也在追求扩大规模以及适配上层业务。因此带来频繁的变更难免会引发故障。
变更任务大致可以分为两类。第一类白屏变更是通过运维工具执行操作，适用于版本变更、资源扩缩容、灾备倒换等流程固定的任务。但是灵活性差，只能执行标准流程。另一类黑屏变更需要运维人员登录系统，通过执行命令来完成变更过程。黑屏变更简单灵活，适合中小型企业的 IT 运维与复杂的运维任务，例如根因分析或故障修复。黑屏变更是变更不确定性的主要来源，也更容易引发故障，需要加强可观测性。
目前对于变更过程的主要观测方法是记录变更过程中运维人员输入的所有命令。在变更结束后，通过审计监察发现潜在的风险。这种方式需要大量的专家经验。因为命令日志很难表示变更过程。例如 2022-09-12 00:00:00.0 张三 obs_cmd.sh 1818 华东 10.164.179.21，包含时间、人员、主机IP，主机集群（华东）和最重要的命令（obs_cmd.sh 1818）。但是如果没有专家经验，这条命令是无法解读的。
Agith与变更影响面
Agith 是 Agent Smith 的缩写。这是致敬《黑客帝国》的 Smith 探员。虽然 Smith 探员是电影中的反派角色，但从运维工程师的视角来看，探员是 Matrix 系统中最优秀的运维工程师。Matrix 系统每时每刻有数十亿的流量接入，但是探员却可以感知轻微的变更异常，并通过最近的节点登入以处理故障（Kill Neo）。这种观测能力正是 Agith 的设计目标。系统每时每刻都在处理大量的请求，包括正常的上层服务与变更任务。Agith 需要从中区分出变更任务，将变更的行为记录下来，整理为变更影响面拓扑图。
Agith 是一款面向变更过程的观测工具。相比只记录命令名，Agith 更关注命令的行为。这种区别体现在最终输出上。传统方法输出的是运维人员的所有输入，组织为日志数据。而 Agith 的输出的是变更影响面，如下图所示：
图1 变更影响面示例
Agith架构
Agith 在设计中采用数据流与控制流分离的策略。eBPF 模块、Consumer、Repository 和 Monitor 可以组成数据筛选-采集-整理-输出的数据流（图 2 中实线）。控制流（图 2 中虚线）则以 Controller 模块为核心，其他模块受 Controller 模块的统一管理。启动时 Controller 模块检测环境，分析配置文件，检查启动参数。然后依次启动部署各个模块。当程序结束时管理各个模块完成清理任务后依次退出。
图2 Agith架构图
应用场景
Agith功能是观测变更过程，最终得到的变更影响面可以应用在风险告警、根因定位、变更审计、依赖分析等。
风险告警可以直接使用 Agith。首先在配置文件中声明含有风险的行为，例如修改某个文件，访问某项服务，删除进程等等。Agith 在整理过程中发现这类数据，会向配置文件中的邮箱发送告警信息。例如美联航故障事件中删除文件的行为，Agith 可以发现这种异常操作。目前邮件告警功能在开发中，敬请期待。
根因定位是变更影响面最重要的用途。相比命令日志，变更影响面数据含有更细粒度的行为数据，可以更容易地发现与故障相关的命令行为。
变更审计可以在变更后检查是否有超出预期的行为。对于重要的变更操作，可以在灰度环境中先执行一遍，获取变更影响面。然后在目标环境中执行，得到另一份变更影响面。将两份数据比较，可以发现在变更操作中有没有错误操作。
依赖分析是获取一个服务在运行时依赖的各种本地资源与周边服务。这个功能虽然与变更无关。但是只要在终端中启动这个服务，Agith 就可以获取该服务的所有行为，从而得到所依赖的各种资源，例如动态依赖库，配置文件等。
路线图
当前 Agith 的功能只能覆盖进程、文件、网络的一部分行为。但是黑屏变更过程中命令行为远远超过这部分。
表1 Agith开发计划
表1是未来 Agith 计划覆盖的变更行为。变更行为的整理是一个复杂的过程。我们一开始采用的方案是自底向上。无论什么样的上层服务，从OS的视角来看无非5类行为：进程，内存，文件，网络，外设。只要对这5类行为监控，就可以覆盖所有的命令行为。但是实践并非如此。
首先过度抽象将失去数据的价值。例如执行 mysql、docker、kubernetes 的命令，都是向已有的服务进程发送命令，可以统一为进程交互行为。但是如果只有交互的进程名，根本不能从中判定风险。其次过度抽象意味着所有的底层行为都是需要记录的，会产生巨大的数据冗余。例如一次进程启动，会频繁申请内存，记录这些数据没有意义。
由此我们认识到观测这张网既不能太粗，也不能太细，应当结合运维需求灵活调整。所以我们采用了一种自顶向下的方法。首先收集 239万条变更命令，逐条去分析变更命令，得出这条命令所产生的数据。然后根据数据的相似性合并。例如文件都会有文件名，容器类操作有容器 id 或者镜像 id。合并过程中会舍弃两者差别的数据项。如果这个数据项对于运维价值不大，就是可以舍弃的。如果这个数据对运维很重要，说明这个合并是错误的。在整理的过程中有太多收益与成本的博弈，相信未来还会不断演进。我们最终梳理出需要监控的行为如下图。
图3 运维变更行为
欢迎加入
如果您对 Agith 有任何建议，欢迎在https://gitee.com/openeuler/Agith/issues提出，也可以添加小助手微信，加入 eBPF 技术交流微信群。如果有合作意向，可以与笔者联系（shangguandongdong1@huawei.com）。
扫码添加小助手
