概览
{
“overview_html”: “GitHub Actions Failure Owner Audit 是一个专为 CI/CD 运维设计的诊断工具，旨在帮助团队精准定位 GitHub Actions 流水线失败的责任归属。该工具通过分析大量 Actions 运行日志数据，自动识别出那些频繁导致构建中断、测试失败或任务超时的执行者（actor）及其对应的工作流组合。其核心价值在于将原本分散在海量日志中的故障线索聚类归因，让运维人员能够从‘猜测谁该负责’转变为基于实际影响数据的精准分派。\n\n该技能支持多种灵活的输入方式，可直接读取由 `gh api` 命令导出的单个或多个仓库的 Actions 运行 JSON 文件。它默认聚焦于具有负面结论的运行状态，包括 failure、cancelled、timed_out、action_required 和 startup_failure 等类型。通过对这些失败事件按执行者、工作流或两者组合进行分组统计，工具进一步计算每个责任主体的失败次数与累计耗时分钟数，从而生成一个按严重程度排序的热点报告。这使得团队可以在站会或事故复盘时快速聚焦于最需要干预的高风险点。”,
“feature_items”: [
“按执行者或工作流组合对失败的 Actions 运行进行聚类分析”,
“支持自定义阈值设置，区分警告级与关键级故障热点”,
“提供文本和 JSON 两种输出格式，适配人工排查与自动化告警场景”,
“可通过正则表达式灵活过滤特定仓库、分支、执行者或结论类型的数据”,
“内置执行者与团队/负责人映射机制，实现从技术账号到业务实体的转换”,
“可集成至 CI 流程中作为质量门禁，自动阻断严重故障持续扩散”
],
“scenarios_html”: “在日常的 DevOps 实践中，当多个开发者在同一仓库并行提交代码并触发大量 Actions 运行时，往往难以判断究竟是某个特定开发者引入的问题，还是某个不稳定工作流本身存在缺陷。此时，Failure Owner Audit 能迅速列出过去一段时间内失败最频繁的执行者及其关联工作流，帮助 Scrum Master 或 Tech Lead 快速召集相关责任人进行根因分析。例如，在一个大型开源项目中，若发现某位贡献者的 PR 频繁触发构建超时，该工具即可将其标记为高优先级修复项，避免社区协作效率受损。\n\n对于需要建立自动化质量护栏的企业级用户而言，此工具同样适用。结合 GitHub Actions 的 workflow_dispatch 或 scheduled triggers，可将 Failure Owner Audit 脚本部署为每日定时任务。一旦检测到存在达到‘critical’级别的热区（如单个工作流在一天内失败超过6次且总耗时超过90分钟），系统便可通过 webhook 通知对应的 Slack 频道或发送邮件给指定负责人。更进一步地，若配置 FAIL_ON_CRITICAL=1，则该任务本身可作为 CI 检查步骤，强制要求所有关键故障必须在限定时间内闭环，否则整个流水线将被阻断，从而倒逼团队主动优化易出错环节。”
}