解读

在国内互联网与金融级客户场景下，CouchDB 集群常被用作离线优先 App 的同步中枢或微服务配置中心，其可用性 SLO 一般设定为 99.9% 或 99.95%。一旦触发 SLO 违规，意味着业务已产生可量化的用户损失或合规风险，必须启动 Postmortem（事故复盘）机制。面试官想考察的是：

1. 你能否把可观测性数据 → SLO 判断 → 复盘触发做成自动化、可审计的闭环；
2. 你能否在多人跨部门场景下，用最小行政成本把关键角色拉到同一张桌子上；
3. 你能否区分**“触发”与“召开”，并给出国内可落地的模板**（含责任认定、整改跟踪、合规归档）。

知识点

1. SLO 四大件：SLI（指标）、阈值（目标+警戒）、窗口期（滚动/固定）、错误预算（Error Budget）。
2. CouchDB 侧典型 SLI：
   • 集群 HTTP 200 成功率（排除 4xx）
   • P99 同步延迟（replication lag）
   • 数据丢失量（missing_revs + doc_conflicts）
3. 告警分级：P1（SLO 突破）、P2（预算烧完 80%）、P3（单节点故障但 SLO 未破）。
4. 国内合规要求：
   • 金融类需24 h 内向央行报备重大事件；
   • 等保 2.0 要求留存日志≥6 个月；
   • 工信部**“双清单”对 SaaS 厂商的“服务中断”**有强制披露窗口。
5. Postmortem 触发条件（满足其一即可）：
   • 连续 5 min SLI 低于目标；
   • 任意 30 min 内错误预算耗尽；
   • 人工升级（客户投诉+舆情）。
6. 会议角色：
   • Incident Commander（当日值班 SRE）
   • CouchDB Owner（内核研发）
   • 业务方代表（App 产品经理）
   • QA/合规（负责出具**“事件级别认定书”**）
7. 产出物：“五件套”——时间线、根因图、影响面、整改 Action（含 Owner+Deadline）、**“是否追责”**结论。

答案

给出一套可在国内中型互联网公司（200–1000 台 CouchDB 节点）落地的自动化触发流程，分三层：采集层、决策层、执行层。

1. 采集层
   使用Prometheus + Exporter拉取 CouchDB 原生指标：

   • couchdb_httpd_200: 200 响应数
   • couchdb_replication_last_update: 各节点时间戳
     计算 SLI：

   success_rate = increase(couchdb_httpd_200[5m]) / increase(couchdb_httpd_request[5m])
   replication_lag = time() - couchdb_replication_last_update
   

   写入Thanos做 30 天滚动窗口聚合，确保审计可追溯。

2. 决策层
   在阿里 SLS 告警中心（或腾讯云 CLS）配置多条件组合告警：

   • 条件 A：success_rate < 99.9% 持续 5 min
   • 条件 B：replication_lag > 60 s 且 success_rate < 99.9%
     满足 A 或 B 即生成P1 告警事件，并调用函数计算（FC） webhook。

3. 执行层
   FC 脚本完成三件事：
   a) 自动创建飞书多维表格记录事件编号、SLI 值、预算剩余；
   b) 调用飞书日历 API，预定次日 10:00 的 Postmortem 会议，强制邀请Incident Commander、CouchDB Owner、业务方、QA、合规；
   c) 在Jira创建**“Problem Ticket”，类型=SLO-Breach，优先级=Critical，标签=couchdb-slo-<日期>，并@Owner**。

4. 会议召开
   会议前 1 h，SRE 值班需把**“事件时间线”初稿贴进飞书群；QA 提前出具级别认定书（模板含“是否属于重大事件”复选框）。
   会议中严格按照“30-30-30”**节奏：

   • 30 min 还原时间线；
   • 30 min 根因分析（用5 Whys+Fishbone）；
   • 30 min 制定**≤3 条可量化的 Action**（必须含完成时间+验证指标）。
     会议结论当场录入 Jira，并由合规同学在24 h 内完成央行报备模板（若属金融类）。

5. 关闭条件
   所有 Action Done 且连续 7 天 SLI 回绿，由CouchDB Owner在 Jira 提交**“关闭申请”，经SRE 主管+QA 双人审批**后归档，错误预算自动重置。

拓展思考

1. 灰度场景：若 CouchDB 集群处于灰度发布阶段，SLO 违规是否触发 Postmortem？
   建议：引入**“灰度权重”标签，只对全量流量生效的 SLO 违规触发正式复盘；灰度阶段违规仅触发“轻量复盘”（不追责、不报备），但需烧双倍错误预算**，防止**“灰度逃避”**。

2. 多活架构：在异地双活场景下，区域级灾难导致单区 CouchDB 不可用但全局 SLO 未破，是否开会？
   建议：把 SLO 拆成**“全局 SLO”与“区域 SLO”，后者违规同样触发“区域 Postmortem”，但不消耗全局错误预算**，确保**“局部问题局部复盘”**。

3. Serverless 化：当 CouchDB 以Kubernetes CRD形式交付，Pod 频繁弹性导致 SLI 抖动，如何避免**“误触发”？
   可在 Prometheus 记录规则里加入“最小样本数”阈值，例如 5 min 内总请求量 < 1000** 时自动抑制告警，防止**“样本过少”造成的“假阳性”**复盘。