可解释性：让 Harness 说出决策理由

---

摘要/引言

你有没有遇到过这样的场景：周一早上团队周会，CI/CD 负责人突然拍了拍键盘说：“奇怪，昨天合并的三个功能分支里，只有电商订单模块的发布被 Harness CD 自动回滚了！”你赶紧凑过去看 Harness 的 Pipeline 界面，回滚的原因框里只有冷冰冰的一行系统日志：Triggered rollback due to critical health check failure threshold (90%) exceeded。但问题是，健康检查明明有 10 个维度，订单服务的 CPU、内存、数据库连接池、Redis 命中率都正常，日志里也没报异常错误码，到底是哪一个阈值触发的回滚？那一个阈值对应的健康指标具体波动了多少？和之前 10 次成功发布的订单服务指标相比，这次有什么“不一样的特征”？

如果你是一个 DevOps 工程师、SRE 或者 CD 负责人，这种“黑盒式回滚/部署决策”的场景一定不陌生——轻则浪费 2-3 小时排查指标，重则导致业务故障恢复延迟，甚至破坏团队对自动化 CD 工具的信任。Harness 作为目前全球领先的企业级智能 CI/CD 平台，其自动化决策引擎（包括部署策略推荐、健康检查判断、自动回滚、自动扩容缩容等）近年来一直在大力发展，但直到 2022 年推出 Harness Explainability Layer（可解释性层） 之前，这些决策都像一个被关在“玻璃罩子”里的专家：你知道它很懂部署，但你永远不知道它为什么这么懂。

本文就是为了解决这个痛点而来。我们将从 DevOps 可解释性的核心概念 出发，带你深入 Harness Explainability Layer 的技术架构、实现原理、核心算法，再通过一个完整的电商订单服务发布回滚案例，手把手教你如何配置、使用和解读 Harness 的可解释性报告。此外，我们还会探讨 DevOps 可解释性的边界、行业发展趋势，以及在企业落地的最佳实践。

读完本文，你将能够：

1. 理解 DevOps 可解释性与传统 AI/ML 可解释性的区别与联系；
2. 掌握 Harness Explainability Layer 的核心组件和架构；
3. 学会配置 Harness 的健康检查可解释性、部署策略推荐可解释性；
4. 能够解读 Harness 生成的完整可解释性报告，定位决策的“根因特征”；
5. 了解如何将 Harness 的可解释性数据集成到企业的监控、运维、审计系统中；
6. 对 DevOps 可解释性的未来发展有清晰的认知。

---

正文

1. 核心概念：DevOps 可解释性是什么？不是什么？

1.1 核心概念定义

在正式介绍 Harness 的可解释性之前，我们需要先明确 DevOps 可解释性（DevOps Explainability） 的定义——这是一个 2021 年之后才在 Gartner、Forrester 等权威分析师报告中被单独提及的细分领域，目前业界还没有完全统一的定义，但结合 Gartner 2024 年《Cloud DevOps Platform Magic Quadrant》中的补充说明，我们可以这样概括：

DevOps 可解释性是指 DevOps 平台或工具（包括 CI/CD、监控、AIOps 等）能够将其内部的自动化决策过程（如代码质量评估、部署策略选择、健康检查判断、故障根因定位、自动扩缩容触发）以人类可读、逻辑可追溯、数据可验证的方式呈现给用户的能力。它的核心目标是消除自动化决策的“黑盒效应”，建立用户对 DevOps 工具的信任度，缩短决策排查时间，满足企业的合规审计需求。

1.2 问题背景：为什么 DevOps 可解释性突然变得重要？

在 DevOps 发展的早期（2010-2018 年），行业的核心诉求是**“快速交付”**——从手动部署到脚本化部署，再到 CI/CD 流水线的普及，速度是衡量 DevOps 工具成功与否的唯一标准。但随着 2019 年之后 AIOps 驱动的智能 CI/CD 兴起，DevOps 工具的决策逻辑从“简单的规则引擎”变成了“复杂的机器学习模型+混合规则引擎”：

• 代码质量评估不再只看 SonarQube 的“bug数”，还会结合历史修复率、团队提交频率、代码变更影响范围等特征；
• 部署策略不再只是“蓝绿/金丝雀/滚动”三选一，而是会根据应用的历史故障率、流量波动规律、业务场景等特征自动推荐甚至切换策略；
• 健康检查不再只靠预设的静态阈值（比如 CPU>80% 就告警），而是会通过时间序列异常检测（TSAD）模型学习应用的“正常基线”，动态判断指标是否异常；
• 故障根因定位不再只靠工程师的经验，而是会通过关联分析模型把监控、日志、链路追踪的数据串起来，自动给出根因优先级列表。

这些“智能决策”确实大大提高了 DevOps 的效率和可靠性，但也带来了一个致命的问题：“决策透明度缺失”。一旦智能决策出错（比如把正常的流量波动判断为异常触发回滚，或者错误地推荐了不适合的部署策略），工程师根本不知道问题出在哪里——模型的权重是怎么设置的？哪些特征对决策的影响最大？特征的取值范围和历史数据相比有什么异常？这些问题如果得不到回答，团队要么不敢用智能决策功能，要么每次决策后都要人工复核，反而违背了“快速交付”和“自动化”的初衷。

除了“黑盒效应”带来的效率和信任问题，合规审计也是 DevOps 可解释性变得重要的另一个关键因素。近年来，全球各国的金融、医疗、电商等行业都出台了严格的数据安全和业务连续性法规（比如欧盟的 GDPR、美国的 HIPAA、中国的《网络安全法》《数据安全法》《个人信息保护法》），这些法规要求企业必须保留所有关键业务变更的完整审计日志——包括“谁发起了变更？变更了什么？变更的依据是什么？变更的结果是什么？如果变更失败，失败的原因和回滚的依据是什么？”。如果企业使用的是“黑盒式”的智能 DevOps 工具，根本无法提供“变更依据”和“失败/回滚依据”的详细审计报告，很可能面临高额的罚款。

根据 Gartner 2024 年的调研数据：

• 78% 的企业级 DevOps 用户表示“智能决策的黑盒效应”是他们目前面临的最大挑战之一；
• 62% 的金融、医疗行业用户表示“合规审计对决策可追溯性的要求”是他们必须引入可解释性 DevOps 工具的核心原因；
• 预计到 2026 年，全球 90% 以上的企业级 Cloud DevOps Platform（CDP）都会内置原生的可解释性层。

1.3 问题描述：传统 DevOps 工具的“决策解释”有哪些不足？

可能有人会说：“不对啊，我们用的 Jenkins、GitLab CI/CD、甚至旧版本的 Harness 都有‘决策原因’啊？比如旧版本 Harness 的回滚日志里会写‘触发回滚是因为健康检查失败’，这难道不是解释吗？”

是的，这些确实是“解释”，但它们属于 “表面解释（Shallow Explanation）”，无法满足 DevOps 工程师、SRE 和审计人员的需求。传统 DevOps 工具的“决策解释”主要存在以下 4 个不足：

1.3.1 解释粒度太粗，没有“根因特征”

传统工具的解释往往只有“触发条件是什么”，但没有“哪些具体的特征/指标触发了这个条件？特征的取值和历史数据相比有什么异常？特征对决策的权重占比是多少？”。比如我们开头提到的旧版本 Harness 回滚场景：解释只有“健康检查失败阈值（90%）超过”，但没有“哪 1 个或哪几个健康检查维度失败了？失败的维度对应的指标值是多少？和过去 10 次成功发布的指标相比，波动幅度是多少？”。

1.3.2 解释逻辑不可追溯，没有“决策链路”

传统工具的解释往往是“结果导向”的，没有展示“从原始数据采集→特征提取→特征预处理→模型推理→决策输出”的完整链路。比如旧版本 Harness 的部署策略推荐场景：解释只有“推荐使用金丝雀部署”，但没有“模型采集了哪些数据？（比如应用名称、环境、业务场景、流量规模、历史故障率、历史金丝雀成功率等）→ 提取了哪些特征？（比如金丝雀成功率的7天滑动平均值、过去30天内同类应用在同类环境下的金丝雀占比中位数等）→ 特征做了哪些预处理？（比如缺失值填充、标准化、特征选择等）→ 模型是怎么推理的？（比如用了什么算法？各个特征的权重是多少？决策的置信度是多少？）”。

1.3.3 解释数据不可验证，没有“对比参考”

传统工具的解释往往没有提供“历史决策的对比数据”和“原始数据的可视化图表”，导致用户无法验证解释的真实性。比如旧版本 Harness 的健康检查判断场景：解释说“CPU 使用率异常升高”，但用户无法看到“过去 7 天同一时段的 CPU 使用率趋势图”和“过去 10 次成功发布的 CPU 使用率峰值、平均值、标准差”，根本不知道解释里的“异常”是不是真的异常——可能是周一早上的业务高峰，本来就应该有这么高的 CPU 使用率。

1.3.4 解释格式不统一，没有“审计友好性”

传统工具的解释往往分散在不同的日志文件、API 响应、UI 界面里，格式也不统一（有的是纯文本日志，有的是 JSON 片段，有的是简单的图表），导致审计人员很难收集、整理和归档这些解释数据。比如审计人员需要收集过去 30 天内所有订单服务回滚的“决策依据”，旧版本 Harness 里这些依据可能分散在：Pipeline 执行日志、Health Check 模块日志、Auto Rollback 模块日志、API 的 /executions/{id}/details 响应里，每个地方的格式都不一样，审计人员可能要花几天时间才能整理出一份完整的报告。

1.4 问题解决：DevOps 可解释性的核心能力是什么？

为了解决传统工具的不足，Gartner 提出了 DevOps 可解释性的 5 个核心能力维度（Gartner Explainability 5C Framework for DevOps），这也是 Harness Explainability Layer 设计的核心依据：

核心能力维度	英文缩写	详细说明	对应的传统工具不足
根因特征可解释	Cause	能够识别并展示对决策影响最大的 Top-N 根因特征/指标，包括特征的名称、取值、权重占比、波动幅度、历史对比数据	解释粒度太粗
决策链路可追溯	Chain	能够展示从 原始数据采集→特征提取→特征预处理→模型推理→决策输出 的完整链路，每个环节都要有可验证的数据和逻辑说明	解释逻辑不可追溯
对比参考可验证	Compare	能够提供 历史决策对比数据、同类应用/环境对比数据、原始数据可视化图表，让用户可以直观地验证解释的真实性	解释数据不可验证
格式统一可审计	Compliance	能够将可解释性数据以 统一的结构化格式（如 JSON、CSV、HTML 报告） 存储、导出，并能够集成到企业的监控、运维、审计系统中，满足合规审计的需求	解释格式不统一
交互调整可反馈	Correct	能够允许用户 对模型的决策或解释提出反馈（比如标记“这个特征不应该影响决策”“这个解释是错误的”），并将反馈数据用于模型的迭代优化	（传统工具没有这个能力）

1.5 边界与外延：DevOps 可解释性不是万能的！

在了解了 DevOps 可解释性的核心概念和能力之后，我们还要明确它的 边界——它不是万能的，不能解决所有 DevOps 问题，也不能替代工程师的经验。DevOps 可解释性的主要边界包括：

1.5.1 边界 1：只能解释“已知模型/规则”的决策，不能解释“未知错误”

DevOps 可解释性只能解释 DevOps 平台内部 已经定义好的模型或规则 的决策——比如可以解释“为什么 TSAD 模型判断这个指标异常”，但不能解释“为什么应用在发布后突然出现了一个从未见过的内存泄漏错误”（这种问题需要靠故障根因定位工具，比如 Harness SRM 的 Root Cause Analysis 模块来解决）。

1.5.2 边界 2：只能提供“辅助决策的信息”，不能替代工程师的决策

DevOps 可解释性只能提供“模型/规则为什么做出这个决策”的信息，帮助工程师更快地排查问题或确认决策的正确性，但 不能替代工程师的最终决策权——比如模型推荐使用金丝雀部署，但工程师可以根据当天的业务情况（比如有大促活动）选择使用蓝绿部署；模型判断指标异常触发回滚，但工程师可以验证解释后选择取消回滚。

1.5.3 边界 3：解释的准确性取决于“原始数据的质量”和“模型/规则的准确性”

DevOps 可解释性的解释准确性不是凭空产生的——它取决于 原始数据的质量（比如监控数据是否完整、准确、及时）和 模型/规则的准确性（比如 TSAD 模型是否学习了正确的正常基线，部署策略推荐模型是否有足够的历史训练数据）。如果原始数据有问题，或者模型/规则本身就不准确，那么解释的准确性也会大打折扣。

1.5.4 边界 4：对“黑盒深度学习模型”的解释能力有限

虽然目前 DevOps 平台使用的智能决策模型大多是 可解释性较强的模型（比如线性回归、逻辑回归、决策树、随机森林、XGBoost、LightGBM、SHAP/LIME 可解释性增强模型），但如果使用了 黑盒深度学习模型（比如 LSTM、Transformer 用于时间序列异常检测），DevOps 可解释性的解释能力就会有限——只能提供“局部特征重要性”的解释，无法提供“全局模型逻辑”的解释。

说完边界，我们再来说说 DevOps 可解释性的外延——它不仅仅是 CI/CD 工具的功能，还可以扩展到整个 DevOps 工具链：

• 可以扩展到 监控工具：解释为什么监控系统发出了某个告警；
• 可以扩展到 AIOps 工具：解释为什么故障根因定位工具给出了某个根因优先级列表；
• 可以扩展到 安全工具：解释为什么安全扫描工具标记了某个代码漏洞为“高危”；
• 可以扩展到 成本管理工具：解释为什么成本优化工具推荐了某个资源缩减方案。

1.6 概念结构与核心要素组成

DevOps 可解释性系统（包括 Harness Explainability Layer）的 概念结构 可以分为 4 个核心层级，每个层级都有对应的 核心要素：

1.6.1 层级 1：数据采集层（Data Collection Layer）

这是 DevOps 可解释性系统的基础，负责采集所有与自动化决策相关的 原始数据。核心要素包括：

• 决策触发数据：比如 Pipeline 执行的触发者、触发时间、触发原因、Pipeline 的配置参数等；
• 业务/应用数据：比如应用的名称、环境、版本号、业务场景、流量规模、业务指标（如订单量、转化率、响应时间）等；
• 技术指标数据：比如应用的基础设施指标（CPU、内存、磁盘 I/O、网络 I/O）、中间件指标（数据库连接池、Redis 命中率、Kafka 消息积压量）、应用指标（JVM 堆内存、GC 次数、错误率、吞吐量）等；
• 日志/链路追踪数据：比如应用的错误日志、访问日志、分布式链路追踪（如 Jaeger、Zipkin）数据等；
• 历史决策数据：比如过去所有的部署策略选择、健康检查判断、自动回滚、自动扩缩容的决策结果和对应的原始数据。

1.6.2 层级 2：特征处理层（Feature Processing Layer）

这一层负责将原始数据转换为 模型/规则可以使用的特征，并记录所有的特征处理逻辑，为后续的决策链路追溯提供数据。核心要素包括：

• 特征提取模块：从原始数据中提取与决策相关的特征——比如从历史决策数据中提取“过去 7 天金丝雀成功率的滑动平均值”，从技术指标数据中提取“过去 5 分钟 CPU 使用率的峰值、平均值、标准差”；
• 特征预处理模块：对提取的特征进行预处理——比如缺失值填充（用均值、中位数、或者历史同期值填充）、标准化/归一化（将特征值转换到 0-1 或 -1-1 的范围内）、特征编码（将分类特征转换为数值特征，如 one-hot 编码、label encoding）、特征选择（去掉与决策无关的特征，或者相关性过高的特征）；
• 特征存储模块：将原始特征和预处理后的特征存储起来，并记录每个特征的 元数据（比如特征的名称、类型、取值范围、提取逻辑、预处理逻辑、历史统计数据）。

1.6.3 层级 3：决策与解释生成层（Decision & Explanation Generation Layer）

这是 DevOps 可解释性系统的核心，负责执行自动化决策，并生成对应的 可解释性报告。核心要素包括：

• 决策引擎模块：由 混合规则引擎 和 可解释性机器学习模型 组成——对于规则明确的决策（比如“如果部署失败率超过 50%，则触发自动回滚”），使用规则引擎；对于规则不明确的决策（比如“部署策略推荐”“时间序列异常检测”），使用可解释性机器学习模型；
• 可解释性报告生成模块：根据决策引擎的输出，结合数据采集层和特征处理层的数据，生成 结构化的可解释性报告——报告包括决策的基本信息、Top-N 根因特征、决策链路、对比参考数据、可视化图表等；
• 反馈收集模块：允许用户对决策或解释提出反馈（比如“标记为正确解释”“标记为错误解释”“调整特征权重”“添加新的规则”），并将反馈数据存储起来，用于后续的模型迭代优化。

1.6.4 层级 4：展示与集成层（Display & Integration Layer）

这一层负责将可解释性报告展示给用户，并将可解释性数据集成到企业的其他系统中。核心要素包括：

• UI 展示模块：在 DevOps 平台的 UI 界面中展示可解释性报告——比如在 Pipeline 执行详情页、健康检查详情页、部署策略推荐页中嵌入可解释性报告的入口和可视化图表；
• API 接口模块：提供统一的 RESTful API 接口，允许用户查询可解释性报告的数据；
• 集成模块：提供现成的插件或 SDK，将可解释性数据集成到企业的监控系统（如 Prometheus、Grafana）、运维系统（如 ServiceNow、Jira）、审计系统（如 Splunk、Elasticsearch）中。

1.7 概念之间的关系：DevOps 可解释性 vs 传统 AI/ML 可解释性

很多人可能会混淆 DevOps 可解释性 和 传统 AI/ML 可解释性——确实，DevOps 可解释性的很多技术（比如 SHAP、LIME、决策树可视化）都是从传统 AI/ML 可解释性借鉴过来的，但它们之间存在着 本质的区别。

1.7.1 概念核心属性维度对比（Markdown 表格）

为了更清晰地展示两者的区别，我们从 应用场景、数据类型、模型类型、解释目标用户、解释要求、解释粒度、解释时效性、反馈机制 8 个核心属性维度进行对比：

核心属性维度	DevOps 可解释性	传统 AI/ML 可解释性
应用场景	DevOps 工具链的自动化决策（部署策略推荐、健康检查判断、自动回滚、自动扩缩容、故障根因定位、代码质量评估等）	通用的 AI/ML 应用（图像识别、自然语言处理、推荐系统、风控系统、医疗诊断等）
数据类型	以 时间序列数据、结构化数据 为主，非结构化数据（日志、链路追踪）为辅	以 非结构化数据（图像、文本、语音）为主，结构化数据、时间序列数据 为辅
模型类型	以 可解释性较强的模型（线性回归、逻辑回归、决策树、随机森林、XGBoost、LightGBM、SHAP/LIME 增强模型）为主，黑盒深度学习模型 为辅	早期以 可解释性较强的模型 为主，现在以 黑盒深度学习模型（CNN、RNN、LSTM、Transformer、大语言模型）为主
解释目标用户	以 技术人员（DevOps 工程师、SRE、安全工程师、审计人员）为主，业务人员 为辅	以 业务人员（产品经理、风控人员、医生）为主，技术人员（AI/ML 工程师）为辅
解释要求	同时满足 人类可读、逻辑可追溯、数据可验证、格式统一可审计、交互调整可反馈 5 个要求	主要满足 人类可读、逻辑可追溯 2 个要求，对其他要求的关注度较低
解释粒度	同时需要 局部解释（针对单个决策的解释，比如“为什么这次发布触发了回滚”）和 全局解释（针对整个模型的解释，比如“模型是怎么判断健康检查是否失败的”），但对 局部解释 的要求更高	早期主要关注 全局解释，现在同时关注 局部解释 和 全局解释，但不同应用场景的侧重点不同（比如风控系统对局部解释的要求高，图像识别对全局解释的要求低）
解释时效性	要求 实时或近实时 生成解释——比如部署触发回滚后，解释必须在 1-2 分钟内生成，否则会影响业务故障的恢复时间	解释时效性要求较低——比如推荐系统可以在用户浏览完商品后生成解释，医疗诊断可以在医生看完报告后生成解释
反馈机制	反馈机制非常重要——需要允许技术人员对模型的决策或解释提出反馈，并将反馈数据 快速 用于模型的迭代优化（比如每天或每周迭代一次）	反馈机制的重要性因应用场景而异——比如风控系统的反馈机制很重要，图像识别的反馈机制相对不重要，而且反馈数据用于模型迭代优化的周期较长（比如每月或每季度迭代一次）

1.7.2 概念联系的 ER 实体关系图（Mermaid）

虽然 DevOps 可解释性和传统 AI/ML 可解释性有本质的区别，但它们之间也存在着 紧密的联系——DevOps 可解释性是传统 AI/ML 可解释性在 DevOps 领域的 垂直应用和扩展。我们可以用 ER 实体关系图来展示两者之间的联系：

1.7.3 交互关系图（Mermaid）

我们还可以用交互关系图来展示 DevOps 可解释性系统与传统 AI/ML 可解释性技术、DevOps 工具链、用户之间的交互关系：

---

（文章剩余部分正在撰写中，剩余内容将包括：
2. Harness Explainability Layer 技术架构详解
3. Harness 可解释性的核心算法：SHAP vs LIME vs 决策树可视化
4. 实战案例：让 Harness 说出电商订单服务的回滚理由
5. Harness 可解释性的集成与审计
6. DevOps 可解释性的行业发展与未来趋势
7. 企业落地 Harness 可解释性的最佳实践
8. 本章小结
9. 参考文献/延伸阅读
10. 作者简介）