Repository navigation
docs: 重写 CI 可观测目标，并把失败告警按信息增量分五类 - #42
Conversation
原稿按「参与型 / 主导型两种 CI」分章罗列评审待确认项，读起来是评审批记， 看不出「现在到哪一步、下一步的进入门槛是什么」。改为按目标→标准→架构→ 建设内容→选型→分期组织的路线文档： - §1 三级目标（问题发现 / 根因分析 / 故障自愈）与现状基线； - §2 逐层给出标准化程度与可对齐的锚点，明确 L2/L3 无标准、只有参考架构； - §4 建设内容按 L0 数据地基 → 失败分类法 → 根因分析 → 故障自愈 → 效果评估展开； - §6 分期表把每项能力绑到「依赖哪一期数据 + 进入门槛 + 覆盖率硬指标」， 避免三期能力被提前承诺； - §7/§8 收敛为边界风险与待决事项。 Co-Authored-By: Claude Code <noreply@anthropic.com>
§5.3.1 原先只有一个笼统的「失败告警」，没有回答「什么失败值得发一封」。 按 vllm-project / triton-lang 两组织 58 个仓、7 天实测（892 次失败/天） 重新设计：逐条失败告警能写，但输出没有信息增量，改为状态型分层。 - §5.2.1 固定 conclusion 取值策略：GitHub 原值透传不归并，并统一「失败」口径； last_success 在从未成功时落 0，避免 L3 对新接入的定时任务失明； - §5.3.1 拆成 L1 基建（startup_failure / timed_out）、L2 门禁（默认分支 schedule/push，首次失败即报）、L2′ nightly（dispatch 白名单，连续两次）、 L3 静默（24h 无成功且未被 L2 覆盖）、L4 PR 突增（1 小时失败率 > 0.8 且样本 ≥ 10）， 每类给出判据、实测发信量与排除清单； - §5.3.1 给出「为什么不统一成失败即报」的实测依据：PR 失败 2.4 次/PR、 合并成单序列后状态翻转 51~89 次/天/仓、cancelled 与 bot 自红占大头； - §5.4.1 workflow 标签改取 run.path 文件名：run-name 带 PR 号会把每趟 PR 变成新序列，实测把破损趟数从 30 抬到 113； - §5.5 已知边界补 PR 侧只有「整体崩塌」一种告警。 Co-Authored-By: Claude Code <noreply@anthropic.com>
Welcome To opensourceways CommunityHey @TangJia025 , thanks for your contribution to the community. Bot Usage ManualI'm the Bot here serving you. You can find the instructions on how to interact with me at Here . That means you can comment below every pull request or issue to trigger Bot Commands. Contact GuideIf you have any questions, please contact the SIG: infratructure , |
CLA Signature PassTangJia025, thanks for your pull request. All authors of the commits have signed the CLA. 👍 |
Linking Issue Notice@TangJia025 , the pull request must be linked to at least one issue. |
该缩写只在指南 5.1.4 定义，目标文档里裸用要看另一篇才能解码，改为 「平台排队 / 扩容与启动 / 任务执行」的直接表述。 Co-Authored-By: Claude Code <noreply@anthropic.com>
CLA Signature PassTangJia025, thanks for your pull request. All authors of the commits have signed the CLA. 👍 |
改了什么
两篇文档，都在 CI 可观测这条线上，合在一起看才完整：一篇讲「要建成什么」，一篇讲「失败告警到底怎么发」。
1.
docs/CI可观测目标.md—— 整篇重写原稿按「参与型 / 主导型两种 CI」分章罗列评审待确认项，读起来是评审批记，看不出「现在到哪一步、下一步的进入门槛是什么」。改为按目标 → 标准 → 架构 → 建设内容 → 选型 → 分期组织的路线文档：
2.
docs/可观测接入指南.md—— §5.2.1 / §5.3.1 / §5.4.1 / §5.5§5.3.1 原先只有一句笼统的「失败告警」，没回答「什么失败值得发一封」。按
vllm-project/triton-lang两组织 58 个仓、7 天实测（892 次失败/天）重新设计：§5.2.1 固定
conclusion取值策略：GitHub 原值透传、不做语义归并；统一「失败」口径；last_success在「从未成功」时落0，否则 L3 对新接入、一次都没跑通的定时任务完全失明。§5.3.1 拆成五类，每类给出判据、实测发信量与排除清单：
conclusion ∈ {startup_failure, timed_out}，全部 event/分支consecutive_failures > 0（首次即报）>= 2> 0.8且样本>= 10「为什么不统一成失败即报」给了实测依据：PR 失败平均 2.4 次/PR；合并成单序列后 5%
12% 的 run 会翻转状态，落到 5189 次/天/仓；cancelled（vllm 72h 949 次）与 bot 自红占了大头。§5.4.1
workflow标签改取run.path文件名：run-name:里带 PR 号（Nightly-A3 (PR) 19513）会把每趟 PR 变成新序列，实测把 vllm-project 的破损趟数从 30 抬到 113。§5.5 已知边界补一条：PR 侧只有「整体崩塌」一种告警，逐 PR 通知交给 GitHub 原生通知。
说明
spec/契约与四个语言实现。/actions/runs（失败计数不受total_count2500 上限影响，run 总数按截断值取下界）。🤖 Generated with Claude Code
AI 使用声明
当前 PR 是否有 AI 参与：