1. 课程导论：Sigstore在API延迟诊断中的价值、策略即代码的核心思想、观测标签体系的设计目标

1.1 从“可观测”到“可审计”：API延迟诊断的信任缺口

现代微服务架构中，API延迟诊断依赖三大支柱：指标（Metrics）、日志（Logs）、链路追踪（Traces）。然而，传统可观测体系存在一个根本性信任缺口——观测数据的完整性无法被验证。

• 数据篡改风险：延迟指标可能在传输或存储过程中被篡改，导致根因分析误判。
• 身份伪造：恶意Agent可能伪造观测数据，掩盖真实延迟瓶颈。
• 审计缺失：合规场景下，无法证明某条延迟记录在特定时间点确实由特定服务产生。

1.2 Sigstore在API延迟诊断中的价值

Sigstore是一套用于代码签名和验证的开源标准，其核心组件包括Fulcio（证书颁发机构）、Rekor（透明日志）和Cosign（签名工具）。在API延迟诊断场景中，Sigstore的价值体现在三个层面：

1.3 策略即代码（Policy as Code）的核心思想

策略即代码将运维策略从人工审核的文档或脚本，转变为可版本控制、可自动化执行、可测试验证的代码。其核心思想包含三个原则：

1. 声明式策略定义：使用结构化语言（如Rego、CEL）描述“允许什么”和“禁止什么”，而非“如何执行”。
2. 策略与执行分离：策略引擎（如OPA、Kyverno）独立于业务服务运行，通过API评估决策。
3. 持续验证：策略在CI/CD、运行时、审计阶段均被强制执行，形成“策略即护栏”。

# 示例：使用Rego定义API延迟策略（OPA策略片段）
package api_latency_policy

# 允许P99延迟小于500ms的请求通过
default allow = false

allow {
    input.p99_latency_ms < 500
    input.service == "payment-api"
}

# 拒绝未签名的观测数据
deny[msg] {
    not input.sigstore_signature
    msg = "观测数据缺少Sigstore签名，拒绝入库"
}

1.4 观测标签体系的设计目标

本课程构建的Sigstore观测标签体系，旨在将Sigstore的签名元数据与API延迟诊断的上下文深度融合。设计目标如下：

• 标准化：定义统一的标签键值规范，覆盖签名身份、签名时间、证书指纹、透明日志条目等维度。
• 可查询：标签需支持Prometheus、OpenTelemetry等主流观测系统的多维聚合与过滤。
• 可审计：每条延迟记录通过标签关联到Rekor条目，实现“一键溯源”。
• 策略友好：标签结构需适配OPA、Kyverno等策略引擎的输入格式，降低策略编写复杂度。

1.5 课程知识体系总览

本课程共30章，按知识递进关系分为五个模块：