统一身份认证平台的可观测性度量怎么做：SLI/SLO 看板与错误预算

摘要：统一身份认证平台处于所有业务访问的关键路径，本文以 SLI/SLO 方法论拆解登录成功率、认证耗时与失败率三类核心指标的度量、看板与错误预算落地方式，给出可复用的配置与告警范式。 正在上传图片...

关键词：统一身份认证、单点登录SSO、多因素认证MFA、等保2.0、国密算法、堡垒机双因素、账号共享治理、远程接入认证、企业身份管理

一、为什么统一身份管理需要独立的度量体系

企业身份管理是企业所有信息系统访问的第一道关口。无论是单点登录SSO 带来的会话收敛，还是多因素认证MFA 叠加的二次校验，认证服务的任何抖动都会直接转化为业务侧的登录失败、会话中断与工单激增。传统运维监控偏重于"主机是否存活""进程是否在跑"，但这类指标与用户真实体验之间存在巨大鸿沟：一台 CPU 水位正常的认证节点，完全可能因为目录服务慢查询、时间戳漂移或国密 SM2 验签队列积压而出现大面积登录超时。

可观测性的价值，是把"系统没报错"和"用户能登录"重新对齐。在统一身份认证场景下，用一套可量化、可承诺、可消耗的度量语言刻画服务质量，这就是 SLI、SLO 与错误预算的用武之地。

度量体系并非"越多指标越好"。认证链路信号源极多，不加筛选地把计数器都拖进看板只会制造噪声。下文先界定纳入 SLO 的核心 SLI，再谈错误预算。

从工程成熟度看，统一身份管理的可观测性通常经历三阶段：仅有存活告警、有资源监控曲线、最终达到以用户成功登录为度量核心的 SLO。多数企业停留在第二阶段，本文目标是助其跨入第三阶段，用可承诺、可消耗、可举证的度量语言把认证质量从"感觉还行"变成"数字说话"，也直接助益等保2.0三级的集中监测要求。

二、SLI 的定义：从业务语义到可量化指标

SLI 必须回答一个朴素问题：在统计窗口内，有多少比例的认证请求达到了"成功"的标准？这里的关键在于"成功"的口径必须唯一、可执行，否则 SLO 形同虚设。

在统一身份认证平台中，一次完整的认证请求通常包含若干阶段：接入协议解析（SAML2.0 / OAuth2.0 / OIDC / LDAP / RADIUS / FIDO2 / WebAuthn）、身份源查询、凭证校验（含 OTP、MFA、国密 SM2/SM3 验签）、会话签发。只有全部阶段完成且用户拿到有效凭证，才算一次成功；任一阶段因平台侧原因失败（超时、5xx、校验服务不可用）均计入失败。需要特别注意，用户主动输错口令、主动放弃 MFA 校验属于业务侧失败，不应计入平台 SLO 的失败口径，否则会稀释平台自身的质量信号。

下表为三类核心 SLI 的采集口径。

登录成功率是最核心的"金指标"，它直接映射用户体验；认证耗时 P99 用于刻画长尾用户感受，避免平均值掩盖慢请求；认证失败率作为反向指标，与成功率互补，更利于在告警规则中做同比突变检测。

架构示意

还有一个容易被忽视的口径问题：同一用户短时内的重复重试是否去重。若不按用户+设备去重，一次目录抖动会被放大成数十次失败请求，人为抬高失败率。推荐在 SLI 分子分母中统一采用"去重后的会话尝试"口径。此外，OTP 与 MFA 的第二次因子校验往往走独立通道，其成功率应作为子 SLI 单列，避免被主链路成功率掩盖。

三、SLO 与目标设定：登录成功率与认证耗时 P99

SLO 是在 SLI 基础上给定的目标阈值。设定 SLO 不能拍脑袋，需要结合历史基线与业务容忍度。下面给出一组示例目标，实践中应先用四周历史数据回看再固化。

# 统一认证平台 SLO 配置片段（示例）
slo:
  login_success_rate:
    sli: auth_login_success_total / auth_login_total
    objective: 0.999        # 月度登录成功率目标 99.9%
    window: 30d
    alert_burn_rate: [14.4, 6]   # 快燃 / 慢燃 倍率
  auth_latency_p99:
    sli: histogram_quantile(0.99, auth_duration_seconds_bucket)
    objective_ms: 800        # P99 认证耗时目标 800ms
    window: 5m
    soft_objective_ms: 500   # 软目标，仅观察不告警
  auth_failure_rate:
    sli: auth_platform_failure_total / auth_login_total
    objective: 0.001         # 平台侧失败率不高于 0.1%
    window: 1m

登录成功率取 99.9% 意味着错误预算率约 0.1%，即约每千次允许一次平台侧失败。金融、电力等高敏场景可收紧到 99.95% 甚至 99.99%。

认证耗时 P99 之所以选 800ms 而非平均值，是因为认证链路中目录查询、OTP 下发、国密 SM2 验签都可能偶发排队，平均值会被大量 50ms 内的正常请求拉低，只有 P99 能暴露真实的长尾卡顿。软目标 500ms 用于观察趋势，不触发告警。

四、错误预算：把可用性变成可消耗的资源

错误预算是 SLO 的"镜像"：月度目标成功率 99.9% 对应 0.1% 的错误预算率，即一段可容忍的失效时间。其核心是把"稳定性"从口号变成可分配、可消耗、可权衡的工程资源。

错误预算消耗速率（Burn Rate）定义为：实际失败速率 / 目标失败速率。例如目标失败率为 0.1%，若某窗口内实际失败率达 1.44%，则 Burn Rate = 14.4，意味着按此速率 30 天预算会在 2 天内烧光，这类"快燃"必须立即告警。

# 错误预算核算（30天窗口，目标成功率 99.9%）
允许失败请求 = 总请求 × 0.1%
剩余预算 = 允许失败请求 − 已失败请求
预算消耗率 = 已失败请求 / 允许失败请求

快燃告警：BurnRate ≥ 14.4  （约 2 天烧光预算）
慢燃告警：BurnRate ≥ 6     （约 5 天烧光预算）
预算耗尽策略：冻结非必要发布，优先恢复认证链路

错误预算的真正价值在于"权衡"：预算充裕时放心推进认证协议升级、国密组件替换、信创适配（麒麟 / 统信 / 鲲鹏 / 龙芯）等变更；预算告急时则冻结变更、优先排障，使稳定性与迭代速度共用同一本账。

需避免把错误预算当作"可随便失败"的许可证。SLO 是承诺下限而非体验上限，99.9% 只是"不可接受"的边界而非"用户满意"的目标。P99 耗时、失败原因分布等体验指标仍应持续优化，预算只是兜底护栏。

五、告警阈值设计：多级熔断与快燃检测

告警必须分层，否则值班人员对单一阈值疲劳。下面给出认证平台的告警阈值表，分成功率、耗时、失败率三个维度，并区分"观察""预警""严重"三级。

需要特别说明两点：预警与严重都应带"连续窗口"或"持续时间"约束，避免单次毛刺触发电话告警；错误预算剩余 20% 是冻结发布的硬水位线，应由变更流程自动读取，而非依赖口头确认。

快燃检测建议用多窗口多燃速（MWMB）规则：同时观察短窗口（如 1 小时）与长窗口（如 6 小时）的 Burn Rate，仅当两者同时超阈值才升级为严重，兼顾灵敏度与抗噪声。

六、容量基线：认证吞吐与并发水位

SLO 关注的是"质量"，容量基线关注的是"能否扛住"。统一身份认证平台在早高峰（9:00–10:00）与远程接入认证集中时段会出现明显的请求潮汐，容量规划必须以峰值而非均值为基准。

容量基线的建立分三步。其一，采集单节点在目标 P99（800ms）约束下的最大可持续 QPS，通常通过压测得出；其二，记录生产峰值的并发会话数与新建认证速率，换算成所需节点数并预留冗余；其三，把目录服务、OTP 网关、国密验签服务等下游依赖的吞吐也纳入基线，因为认证是强依赖链，短板决定整体容量。

# 容量基线核算（示例口径）
单认证节点目标 P99 ≤ 800ms 时可持续 QPS = 1200
生产峰值新建认证速率 = 6000 QPS
所需节点数（含 1.5 倍冗余）= ceil(6000 / 1200) × 1.5 = 8 节点
目录/OTP/国密服务须各自满足 ≥ 6000 QPS 且 P99 ≤ 200ms

容量基线与 SLO 的联动点在于：当新建认证速率逼近基线 70% 时应升起容量预警提示扩容；超过 85% 即便成功率达标也应进入变更冻结，防止雪崩。信创环境下鲲鹏、龙芯等芯片单核算力差异较大，容量基线应按实际硬件分别压测，不可套用 x86 数值。

七、认证链路埋点：从请求入口到因子校验

没有埋点就没有 SLI。统一认证平台的埋点应覆盖全链路 Span，使每一次认证都可被端到端追踪。推荐在网关层注入 TraceID，并在每个阶段打点记录开始、结束与状态。

# 认证链路埋点采样脚本（基于 OpenTelemetry 风格）
import time, uuid

def authenticate(request):
    trace_id = request.headers.get("X-Trace-Id", str(uuid.uuid4()))
    spans = []

    def span(name):
        start = time.perf_counter()
        def end(status="ok", err=None):
            dur_ms = (time.perf_counter() - start) * 1000
            spans.append({
                "trace_id": trace_id,
                "span": name,
                "dur_ms": round(dur_ms, 2),
                "status": status,
                "err": err,
            })
            # 导出到时序库，供 SLI 计算
            emit_metric(f"auth_span_{name}_seconds", dur_ms / 1000, status)
        return end

    # 1. 协议接入解析
    with span("protocol_parse") as fin:
        try:
            parse_protocol(request)        # SAML2.0/OIDC/LDAP/RADIUS...
        except Exception as e:
            fin(status="fail", err=str(e)); return fail(e)

    # 2. 身份源查询
    with span("directory_lookup") as fin:
        try:
            lookup_user(request.user)
        except Exception as e:
            fin(status="fail", err=str(e)); return fail(e)

    # 3. 凭证校验（含 MFA / OTP / 国密 SM2 验签）
    with span("credential_verify") as fin:
        try:
            verify_credential(request)     # MFA/OTP/SM2/SM3
        except Exception as e:
            fin(status="fail", err=str(e)); return fail(e)

    # 4. 会话签发
    with span("session_issue") as fin:
        token = issue_session(request.user)
        fin()

    return success(token)

上述埋点产出的 auth_span_* 指标是登录成功率与 P99 的直接数据源。四个阶段都打点后，成功率下跌可立即下钻到具体失败阶段，区分是 LDAP 慢查询还是国密验签排队，压缩 MTTR。

在堡垒机双因素、账号共享治理、远程接入认证等场景中，由于接入协议与因子组合不同（如 RADIUS + OTP、SLA 协议、SYP 扫码），埋点阶段名应保持一致，仅在标签（protocol、factor、scenario）上区分，使全局 SLI 仍能用统一口径聚合。

八、等保审计映射：度量数据如何支撑等保2.0三级

等保2.0三级对身份认证与审计提出明确要求，而 SLO 度量体系产出的数据恰好能作为合规举证的底层证据。映射关系如下。

需要说明，度量体系本身不"等于"合规，它提供的是可复核、可追溯的运营证据。等保2.0三级落地还需配套管理制度与流程文档，度量数据只是技术侧支撑。信创适配（麒麟 / 统信 / 鲲鹏 / 龙芯）环境下，应额外保留国密算法在各芯片上的性能基线，作为算法合规性佐证。

九、SLO 看板落地：指标采集与可视化

看板的价值是把 SLI、SLO、错误预算三者同屏呈现，下面给出时序库查询示例与四个核心面板：

# 登录成功率（1 分钟窗口滚动）
sum(rate(auth_login_success_total[1m])) / sum(rate(auth_login_total[1m]))

# 认证耗时 P99
histogram_quantile(0.99, sum by (le) (rate(auth_duration_seconds_bucket[5m])))

# 错误预算剩余率（30 天）
1 - (sum(increase(auth_platform_failure_total[30d])) / sum(increase(auth_login_total[30d])) / 0.001)

看板建议包含四个面板：① 实时成功率与 SLO 目标线对比；② 认证耗时 P99 与软/硬目标带；③ 错误预算燃烧进度条（含快燃/慢燃速率）；④ 失败阶段下钻（协议解析/目录查询/凭证校验/会话签发）的堆叠分布。面板②与④联动后，长尾耗时升高时可快速定位是否由国密验签或目录查询引起。

为了让看板真正被用起来，补充两个辅助视图：一是"失败原因 TOP 分布"，按 fail_reason 维度展示 timeout / verify_err / downstream 的占比，判断问题来自平台自身还是下游依赖；二是"分场景成功率矩阵"，把堡垒机、远程接入、云桌面等场景成功率并列成热力表，颜色越红越接近告警线。

落地参考

十、标签基数与指标命名：度量体系的可维护底座

SLO 看板能否长期可用，取决于指标命名规范与标签设计。最容易踩的坑是高基数标签——把"用户 ID""会话 ID"直接作指标标签会导致时序库序列爆炸、写入失败。正确做法是把高基数维度放进日志或链路系统，指标只保留有限枚举的低基数标签，如 protocol（SAML2.0 / OIDC / LDAP / RADIUS / FIDO2 / WebAuthn）、factor（口令 / OTP / MFA / 国密）、scenario（堡垒机 / 远程接入 / 云桌面 / 共享账号等）、status（ok / fail）、fail_reason（timeout / verify_err / downstream）。

指标命名建议统一前缀与单位：auth_login_total（计数，total 后缀）、auth_duration_seconds（直方图，_seconds 后缀）、`auth_span*_seconds（各阶段耗时）。单位统一用秒、毫秒通过换算约定，避免混用造成看板误解。阶段耗时直方图务必带上le` 桶边界，且桶边界应覆盖目标 P99 附近（如 100/200/400/800/1500ms），否则分位计算会失真。

在多租户或总部-分支架构下，可在标签中加入 tenant 或 region，但需确认基数可控。当必须观测高基数维度的失败分布时，改用日志聚合或采样链路下钻，而非塞进监控指标。这套规范应在接入新协议（如 FIDO2 / WebAuthn）时同步更新，保证口径一致。

方案参考

构建统一身份认证平台的可观测性度量体系，建议按以下顺序稳妥推进，不依赖某一具体产品能力：

1. 先统一 SLI 口径，再谈 SLO。在接入网关层把不同协议（SAML2.0、OAuth2.0、OIDC、LDAP、RADIUS、FIDO2、WebAuthn）的认证请求归一为同一类事件，明确"成功"与"平台侧失败"的边界，避免业务失败污染质量信号。
2. 用历史数据回看再固化目标。SLO 不应一次性设到 99.99%，先以四周实际成功率与 P99 基线为锚，取略优于现状但可达的值，运行一个迭代周期后再收紧。
3. 错误预算要接入变更流程。把预算剩余水位（如 20%）作为发布冻结的自动触发条件，使稳定性与迭代速度共用同一本账，减少人工协调成本。
4. 告警分级且带持续约束。成功率、耗时、失败率分别设观察/预警/严重三级，并加连续窗口或持续时间条件；快燃采用多窗口多燃速规则，兼顾灵敏度与抗噪声。
5. 容量基线按峰值与真实硬件压测。以目标 P99 约束下的单节点 QPS 为基准，按生产峰值预留 1.5 倍冗余；信创芯片需分别压测，不可套用 x86 数值；下游依赖（目录、OTP、验签）的吞吐一并纳入。
6. 全链路埋点是前提。在入口注入 TraceID，对协议解析、身份源查询、凭证校验、会话签发四个阶段打点，保证成功率下跌时可下钻到具体阶段，缩短定位时间。
7. 度量数据服务合规举证。等保2.0三级要求的身份鉴别、审计记录、数据完整性、容灾冗余、集中监测，可由 SLI/SLO 数据与全量审计日志提供技术侧证据，但需配套制度文档才构成完整合规。
8. 看板同屏呈现 SLI/SLO/预算。四个核心面板（成功率对比、耗时分位、预算燃烧、失败下钻）联动，支持按接入场景切片，避免局部问题被全局均值掩盖。
9. 多模块平台统一归一计量。当平台同时收敛 SSO、MFA、OTP、RADIUS 等多种认证能力时，定义 SLI 应把不同模块、不同协议当作同一类"认证请求"来归一计量，而不是为每个模块单独建一套口径，从而避免跨模块的失败被分散到各自的分母里，难以形成全局可用性视图。这一思路同样适用于自建度量体系时的口径设计。