01 · 续期调度模型
1.1 从"60天规则"到"30+17"模型
90天有效期时代的通行准则是"到期前30天（剩余1/3寿命）续签"，即"60天规则"；SC-081v3将其制度化——47天上限按"30天续签周期+17天缓冲"设计（每月续签一次、失败后有逾两周的修复窗口）。组织应立即按这一模型重构调度，而非等2029年：在200天（2026年3月起）与100天（2027年3月起）阶段即按"剩余1/3"触发。
1.2 ARI驱动的动态调度
静态cron将被ARI取代为协议：客户端按renewalInfo端点的suggestedWindow与Retry-After轮询（Let's Encrypt现行Retry-After约6小时），在窗口内随机落点（防惊群），紧急时窗口被设为过去时间即立即续签。工程要求：续签进程须常驻或高频唤醒——"每天一次cron"的架构在小时级应急窗口下结构性失效；续签请求携带replaces字段。
1.3 抖动与削峰
- 惊群问题：百万级客户端同一时刻续签将压垮CA（这正是ARI要解决的负载尖峰）；组织侧应以台账有效期分布为输入，给续签时刻加确定性抖动；
- 失败退避：遵守Retry-After与指数退避，绝不对速率限制错误（429）重试风暴——失败验证配额（每账户每主机名每小时5次量级）耗尽将锁定数小时；
- staging预演：流水线变更先在CA的staging目录验证（不受生产速率限制约束），再切生产。
02 · 部署闭环：从"签了"到"生效"
自动化事故的高发区不在签发而在部署。完整闭环五环节：
| 环节 | 要求 | 常见失效模式 |
|---|---|---|
| 分发 | 新证书+私钥+全链按目标清单分发（LB/CDN/Ingress/服务），原子更新 | 部分节点漏更新→部分流量仍用旧证书 |
| 热重载 | deploy hook触发服务平滑reload（nginx -s reload等），不依赖进程重启 | 钩子缺失→磁盘是新证书、内存是旧证书（最隐蔽事故） |
| 生效验证 | 从外部多视角握手取证：证书指纹、链完整性、有效期、SNI正确性 | 自验证只看本地文件→"签了没上"长期未察觉 |
| 灰度与回滚 | 关键业务先灰度节点再全量；保留上一版证书与快速回滚路径 | 全量切换后发现问题无退路 |
| 状态回写 | 部署结果回写台账与监测系统（闭环第4页台账） | 台账与实际状态漂移→应急时定界错误 |
03 · 高可用与故障转移
- 多CA策略：关键域名配置主备CA（如Let's Encrypt+另一ACME CA），主CA故障或吊销事件时切换；注意不同CA的验证方法与速率限制差异；
- 验证方法冗余：主DNS-01+备HTTP-01（或反向），单一验证路径故障不转化为过期事故（第3页）；
- 断路器：连续N次续签失败自动熔断并升级人工，避免无效重试耗尽配额；
- 时钟与依赖：续签主机的时钟同步（证书校验对时间敏感）、CRL/OCSP依赖解耦（子课题04）、DNS传播等待的显式探测。
04 · 可观测性指标体系
| 指标 | 定义与目标水位 |
|---|---|
| 续签成功率 | 窗口内首次续签成功比例（目标≥99%；按失败根因分桶：DNS/CA/部署） |
| 续签→生效时延 | 证书签发完成到外部握手验证通过的时长（目标分钟级；暴露部署链路瓶颈） |
| 剩余有效期分布 | 全量证书剩余寿命直方图（P5水位高于告警阈值；47天时代P5应>17天） |
| ARI响应覆盖率 | 支持ARI轮询的证书占比（2024年实测生态短板，应列为硬指标） |
| 部署有效率 | 外部验证证书与台账期望一致的比例（"签了没上"探测） |
| 告警MTTA/MTTR | 过期类告警的响应与恢复时长（对接第5页分级告警） |
指标哲学：把证书运营从"运维杂务"升级为工程体系的关键是可度量——每个指标都必须有 owner、有阈值、有升级路径；可观测性数据同时是应急时（第5页）的定界输入，二者共用一套数据底座。
05 · 证书运营成熟度模型
| 等级 | 名称 | 特征 |
|---|---|---|
| L1 | 人工管理 | 表格台账、日历提醒、人工续签——398天时代勉强存活，2026年3月起失效 |
| L2 | 单点自动化 | ACME客户端+cron续签；无台账、无部署验证、无告警分级——"自动化幻觉"高发区 |
| L3 | 台账化运营 | 三路发现+台账+多级告警+部署验证闭环；具备过期防护纵深 |
| L4 | 韧性运营 | ARI驱动调度、多CA冗余、应急SOP+演练、可观测性指标体系完备 |
| L5 | 敏捷治理 | 短寿命（6天级）默认化、私钥HSM化、机器身份统一治理（与SPIFFE类体系融合）、PQC算法可切换 |
47天时代（2029）的组织水位目标为L4；L5是2026—2029年的演进方向（路线见第8页）。
06 · 短寿命运营专题（6天证书）
- 参数基线：Let's Encrypt短寿命证书有效期160小时（约6天余），2026年1月15日起GA，经ACME profile（shortlived）选择加入；每证约每5天续签一次，年续签次数是90天证书的15倍；
- 适用边界：完全自动化且部署闭环成熟的环境（CDN、云原生、CI/CD）；人工介入空间趋近于零；
- 收益：密钥泄露暴露窗口压缩一个数量级、吊销依赖归零（自然过期）、与replaces字段配合旧证即时清理；
- 代价：DCV频率（第3页复用期10天终态下每5天续签均需新验证）、CA负载、客户端常驻化——任何一环的可靠性短板都被15倍频放大；
- 前置检查清单：ARI支持、失败熔断、多CA冗余、部署验证自动化、外部监测——五项齐备方可试点（呼应第5页"短寿命让过期风险更快兑现"的警示）。
本节参考来源（本页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
IETF RFC 9773（ARI，2025年6月）与Let's Encrypt ARI集成指南（2024年4月25日）：letsencrypt.org/2024/04/25。
CA/B Forum Ballot SC-081v3（2025年4月11日通过，47天=30天续签+17天缓冲的设计说明）：cabforum.org。
Let's Encrypt短寿命证书（160小时，2026年1月15日GA）与证书配置文件文档：letsencrypt.org；速率限制文档（失败验证配额）。
主流客户端ARI支持现状（2025—2026年核实）：Certbot自4.1.0（2025年6月10日发布）起支持ARI，但仅在既有定时任务触发时检查、且暂不发送replaces字段（github.com/certbot/certbot）；acme.sh的完整ARI支持长期缺位（社区功能请求自2024年1月开放，issue #4944）——选型时应逐项验证。
Prometheus blackbox exporter证书探针与Uptime Kuma等开源监测方案的公开文档。