走进任何一座大型机场航站楼，你第一眼看到的不是跑道，不是雷达，而是那块巨大的航班信息屏：航班号、目的地、准时还是延误。绝大多数旅客只关心一行字——我的航班会不会准时。但当航班延误时，真正解决问题的人不会盯着那块大屏，而是打开调度系统、天气雷达、塔台通信和地勤清单。同一场飞行，两套画面，各自服务于截然不同的观众。 SLO 仪表盘就是这个道理。工程师想看到每个服务的关键指标曲线，高管只想在 3 秒内知道“现在是不是全绿”。如果你把一张塞满曲线和表格的技术大屏直接甩给高管，那就等于把塔台雷达拆下来挂到候机大厅，谁也看不懂。反过来，如果工程师只有一块写着“一切正常”的大屏，出了事故也毫无下手之处。本篇文章要解决的，正是如何设计一个同时服务这两种观众的 SLO 仪表盘：既要遵循 Wilkinson 可视化原则，让信息层级井井有条；也要设计自动构建流程、Grafana 集成和生产部署方案，让仪表盘像机场航班系统一样自动更新、可靠运行。

岗位关联

掌握 SLO 仪表盘的信息层次与可视化编码，你就能在工程深度与高管可读性之间架起桥梁，让每一次事故被更快定位，让每一次汇报更有说服力。

目录
  1. 可视化演示
  2. 信息层次
  3. 受众定制
  4. 感知编码
  5. 自动化构建
  6. Grafana集成
  7. 故障容错
  8. 生产部署
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

信息层次

机场里，旅客看大屏只关心“我的航班是否准时”，地勤却需要看完整的航班队列、跑道状态和登机口分配。如果让地勤在值机大厅那块屏上操作，效率会崩溃；如果让旅客去看塔台雷达，同样不知所措。SLO 仪表盘的第一课，就是把这两种需求拆成明确的层次，而不是把数据堆到一起自欺欺人。

信息层次可以理解为“三层漏斗”：最上层是高管摘要层，只有少数几个聚合状态块，比如“核心 API 可用性 99.95%”或“支付链路全绿”；中间是工程师证据层，展示每个 SLI 的历史曲线、错误率和延迟分布；最底层是诊断素材层，包含日志、链路追踪和事件流，供故障定位时下钻。

技术实现上，上层向下层提供下钻链接，让读者从“状态灯”一路点到“具体请求日志”。三层数据都应来自同一指标口径：例如都以“请求总数”和“成功请求数”为基准，只是聚合粒度不同。

回看机场大屏：它没有把天气、跑道、航班计划全列出来，而是只给旅客一个清晰的方向。仪表盘同样如此——把正确信息放到正确层次，读者才不会在噪音中寻找答案。

Hierarchy=Summary→Evidence→Raw\mathrm{Hierarchy} = \mathrm{Summary} \rightarrow \mathrm{Evidence} \rightarrow \mathrm{Raw}
信息层次就是一个从“结论”到“证据”再到“原材料”的漏斗，保证读者始终只看到当前决策需要的深度。
  1. 摘要层（Summary）这一层把多个 SLI 聚合成少数状态块，通常只包含健康/不健康、达成/未达成，是高管决策的入口。
    Summary=⋀k=1nStatusk\mathrm{Summary} = \bigwedge_{k=1}^{n} \mathrm{Status}_k
  2. 证据层（Evidence）读者发现摘要异常后，进入这一层查看各 SLI 曲线，判断异常是偶发抖动还是持续恶化。
    Evidence={SLIk(t)}k=1n\mathrm{Evidence} = \{ \mathrm{SLI}_k(t) \}_{k=1}^{n}
  3. 原始层（Raw）最后一层保留请求日志和链路追踪，帮助工程师精确定位到某一次超时或错误。
    Raw={log⁡i,tracej}\mathrm{Raw} = \{ \log_i, \mathrm{trace}_j \}

受众定制

同样是航班，旅客看登机口，机组人员看配载单，塔台看雷达回波。如果把这三类信息强行塞进同一块屏幕，任何角色都会觉得碍眼。SLO 仪表盘的受众定制，就是为不同角色准备不同“频道”，但所有频道共用同一套底层数据。

这里的核心原则是：指标口径统一，展示语义分离。高管的视图不应该出现“error_budget_remaining 42.3%”这种工程师语言，而应该显示“本月故障预算剩余较多”或“需要关注”。工程师视图则保留原始指标，包括时间窗口、采样粒度和告警阈值。

在工程落地时，可以维护两个仪表盘模板：一个 executive dashboard，只包含聚合状态和趋势大图；一个 engineering dashboard，包含 SLI 明细、燃烧速率和日志入口。它们都读取同一个指标数据源，只是查询和渲染方式不同。

飞机起飞前，乘客、机长、地勤各看各的系统，却都服务于“安全准点起飞”这一共同目标。SLO 仪表盘同样让不同角色各取所需，目标却始终指向服务的可靠交付。

ExecView=min⁡kSLIk,EngView={SLIk(t),logs}k=1n\mathrm{ExecView} = \min_{k} \mathrm{SLI}_k, \quad \mathrm{EngView} = \{ \mathrm{SLI}_k(t), \mathrm{logs} \}_{k=1}^{n}
高管视图关注“最差的那个 SLO”，因为任何一个核心服务失守都可能影响客户；工程师视图则保留全部细节，用来定位原因。
  1. 高管聚合对核心 SLO 取最小值或加权平均，让高管一眼看到“当前最差情况是否能接受”。
    ExecView=min⁡kSLIk\mathrm{ExecView} = \min_k \mathrm{SLI}_k
  2. 工程展开工程师视图保留每个 SLI 的时间序列，并把日志查询链接挂在面板上，点开即查。
    EngView=⋃k{SLIk(t),logs}\mathrm{EngView} = \bigcup_k \{ \mathrm{SLI}_k(t), \mathrm{logs} \}
  3. 口径统一两套视图使用的计数方式必须一致，例如都以“非 5xx 请求 / 全部请求”作为可用性定义，避免高管和工程师对“健康”的认知产生偏差。
    SLI=successtotal\mathrm{SLI} = \frac{\mathrm{success}}{\mathrm{total}}

感知编码

机场大屏会把“延误”涂成醒目的红色，而不是在满屏蓝色表格里加一行小字。为什么？因为人的视觉对颜色变化相对敏感，但对细小文字和形状差异并不敏感。Wilkinson 的可视化原则给出了一个感知通道排序：位置、长度、角度、面积、色相、形状——从强到弱。

在设计 SLO 仪表盘时，应该把最强的通道留给最重要的信息：SLO 状态用“位置 + 长度”表达，例如进度条和坐标位置；错误率变化用“角度/斜率”表达，例如折线图；而次要的标注信息才用颜色或形状区分。

颜色也有语义约定：绿色代表达成 SLO，红色代表违反，黄色代表接近阈值。不能为了美观使用彩虹色。工程师最容易犯的错是把状态灯画成五颜六色，结果高管的注意力被无关装饰吸引。记住：图表不是画作，而是决策工具。

回到机场的例子：为什么所有旅客都能在几秒内找到自己的航班？因为设计者把航班号放在固定位置，用颜色标注状态，而不是让每个航班显示不同的图标。SLO 仪表盘遵循同样的逻辑，才能让信息“一眼可见”。

position>length>angle>area>hue>shape\mathrm{position} > \mathrm{length} > \mathrm{angle} > \mathrm{area} > \mathrm{hue} > \mathrm{shape}
这条不等式是可视化设计的“兵力部署原则”：把最强的视觉通道留给最重要的信息，弱的通道只表达弱信息。
  1. 位置（position）人眼对空间位置的判断最准，所以关键指标应放在大屏左上角或独立显眼的位置。
    position≫hue\mathrm{position} \gg \mathrm{hue}
  2. 长度（length）条形图利用长度比较数值非常高效，适合展示错误预算消耗量。
    length∝value\mathrm{length} \propto \mathrm{value}
  3. 角度（angle）折线图的斜率传递趋势变化，适合展示错误率随时间上升还是下降。
    angle=ΔyΔt\mathrm{angle} = \frac{\Delta y}{\Delta t}
  4. 形状（shape）形状是最弱的通道，只适合区分不重要的类别，不应承载关键状态信息。
    shape→category\mathrm{shape} \to \mathrm{category}

自动化构建

机场的航班信息屏从不会有人手写更新——航班计划变动后，后台系统自动把新数据推到所有屏幕。SLO 仪表盘也必须这样。如果每次都靠工程师手动拖拽图表、手工配置，仪表盘迟早会落后于服务架构的演进。

自动化构建的核心是 Dashboard as Code。把仪表盘定义成 JSON 或 YAML 文件，放进 Git 仓库，用模板渲染出最终配置。服务上线时，只要注册元数据（服务名、SLO 目标、负责人），自动构建脚本就能生成对应的面板。

模板的好处是“一变全变”：当所有服务的错误预算口径统一调整时，只需要修改模板中的公式，重新渲染即可。相比手动维护几十个仪表盘，自动化方案把维护成本从 O(n) 降到 O(1)。

自动化意味着仪表盘的每一次变更都可审查、可回溯。就像机场航班的每一班变更都有系统记录一样，DaaS（Dashboard as Code）让仪表盘的状态和线上服务保持一致，而不是靠记忆和口口相传。

Dashboard=Render(Template,Env,SLOs)\mathrm{Dashboard} = \mathrm{Render}(\mathrm{Template}, \mathrm{Env}, \mathrm{SLOs})
自动化构建的公式本质是“模板 + 环境变量 + SLO 清单”三者的确定性组合，输入相同，输出永远一致。
  1. 模板（Template）定义图表布局、查询语句和视觉通道，是所有仪表盘通用的骨架。
    Template={panels,vars,annotations}\mathrm{Template} = \{ \mathrm{panels}, \mathrm{vars}, \mathrm{annotations} \}
  2. 环境（Env）区分 staging、prod 等环境，查询地址和权限各有不同。
    Env={datasource,namespace}\mathrm{Env} = \{ \mathrm{datasource}, \mathrm{namespace} \}
  3. 渲染（Render）将模板变量用真实的服务名和指标替换，输出最终可导入的 JSON。
    Render:(T,E,S)↦JSON\mathrm{Render}: (T, E, S) \mapsto \mathrm{JSON}

Grafana集成

机场的信息屏自己并不知道飞机在哪，它从机场运营数据库读取航班状态；Grafana 仪表盘同样不产生数据，它从 Prometheus、CloudWatch 或 Loki 等数据源拉取指标，再把查询结果渲染成面板。

在 Grafana 中集成 SLO 仪表盘有三个关键点：数据源接入、模板变量和权限控制。数据源接入就是配置 Prometheus 地址和认证信息；模板变量让一个面板同时服务多个服务，例如用 $service 下拉框切换不同服务的 SLO；权限控制则决定谁能看到高管视图，谁能编辑面板。

一个典型的配置是：数据源使用 Prometheus；面板查询语句写作 slo:error_rate:ratio{service="$service"}；把服务列表做成变量，由前端下拉选择。这样一套面板可以复用给所有服务，而不必复制几十份。

通过 Grafana 的集成能力，SLO 仪表盘不再是孤岛，而是整个可观测性体系中的一个标准界面。高管看到宏观状态，工程师点进明细，SRE 维护面板版本，职责边界清晰。

Query=render(expr,vars),expr=rate(errors[5m])\mathrm{Query} = \mathrm{render}(\mathrm{expr}, \mathrm{vars}), \quad \mathrm{expr} = \mathrm{rate}(\mathrm{errors}[5m])
Grafana 的“变量 + 查询渲染”机制，相当于让同一块航班大屏根据航站楼自动切换显示内容，无需为每个登机口单做一块屏。
  1. 数据源datasource 决定指标从哪来，必须配置 type 和 url，并保证网络可达。
    DS={type,url,auth}\mathrm{DS} = \{ \mathrm{type}, \mathrm{url}, \mathrm{auth} \}
  2. 变量（vars）templating.list 定义 $service 等变量，面板查询中通过正则转义引用。
    vars={service:api∣web∣pay}\mathrm{vars} = \{ \mathrm{service}: \mathrm{api}| \mathrm{web}| \mathrm{pay} \}
  3. 渲染（render）Grafana 在查询时把模板中的变量替换成实际选中值，完成一次动态查询。
    Query=expr[ vars ]\mathrm{Query} = \mathrm{expr}[\, \mathrm{vars}\,]

故障容错

机场大屏偶尔也会故障，但机场不可能因此停摆——备用显示系统、广播通报、手写板预案都会顶上。SLO 仪表盘作为“故障指挥中心”，它自己反而最不能成为故障盲点。

容错设计包括三方面：数据缺失时的回退、告警风暴的收敛、以及故障演练的常态化。数据缺失时，面板要显示“无数据”，而不是画出一条平稳直线误导读者；告警收敛则避免 10 条相似告警同时轰炸，而是聚合成一条带聚合信息的通知。

在 Prometheus 查询中，可以使用 absent() 或 last_over_time() 处理数据缺口，例如当数据源断开时显示红色“NODATA”而非默默归零。同时还要为仪表盘本身配置存活探针，确保它本身挂了会被发现。

就像机场的容错系统从不让旅客面对“一片黑屏”，SLO 仪表盘也要在数据管道异常时给出明确信号。这样工程师才敢在故障期间放心依赖它，而不是越忙越乱。

MTTR=1N∑i=1NTi\mathrm{MTTR} = \frac{1}{N} \sum_{i=1}^{N} T_i
MTTR（平均修复时间）衡量从故障发生到恢复的耗时。仪表盘容错的目标，就是让这个时间尽量短。
  1. 缺失检测当指标消失时用 absent(metric) 返回 1，并在面板上渲染为异常色，防止把“无数据”误读为“零错误”。
    absent↔NaN\mathrm{absent} \leftrightarrow \mathrm{NaN}
  2. 回退展示last_over_time 会保留最后一个已知值，让折线不至于断裂，但必须标注“有效期已过”。
    last_over_time(x,5m)\mathrm{last\_over\_time}(x, 5m)
  3. 修复时间把每次故障的修复时长求平均，得到 MTTR，用于复盘和持续改进。
    MTTR=∑TiN\mathrm{MTTR} = \frac{\sum T_i}{N}

生产部署

机场要启用一套新的航班显示系统，绝不可能直接替换生产环境——它要经过测试、双人复核、灰度切换、回滚演练，最后才全量上线。SLO 仪表盘的部署也应照此办理。

生产部署检查清单至少包含以下内容：一是权限安全，仪表盘应该只读给围观者，只有负责人才有编辑权限；二是数据质量，确认指标口径、时间范围和标签选择与 SLO 定义一致；三是回滚预案，所有仪表盘变更都通过 Git 版本管理，出错时可以一键回滚到上一版本；四是发布节奏，先在 staging 环境渲染预览，再同步到生产环境。

还要确认时间时区统一、刷新频率合理（例如 1 分钟自动刷新），防止所有团队同时刷新导致数据源压力过大。发布后需要保留一段观察期，盯住面板加载时间和查询错误率。

部署清单的意义就像机场的“双人复核制度”：它把风险前置到上线之前，让每一次变更都稳妥落地。SLO 仪表盘作为衡量可靠性的工具，自己也要始终可靠。

Ready=C1∧C2∧C3\mathrm{Ready} = C_1 \land C_2 \land C_3
就绪状态是三个检查项的“与”关系：只要权限、数据、回滚有任何一项不满足，就不应该上线。
  1. 权限检查（C1）确认只有 SRE 和编辑者有写权限，其他角色只有查看权限，避免误操作。
    C1=viewer_ro∧owner_rwC_1 = \mathrm{viewer\_ro} \land \mathrm{owner\_rw}
  2. 数据检查（C2）核对查询语句中的服务名、标签和阈值，与 SLO 定义完全一致。
    C2=metric≡SLOC_2 = \mathrm{metric} \equiv \mathrm{SLO}
  3. 回滚检查（C3）确认仪表盘 JSON 已提交到 Git，并记录上一个可用版本号。
    C3=git_version>prev_versionC_3 = \mathrm{git\_version} > \mathrm{prev\_version}

AI 应用场景

高管可用性汇报

阶段：数据可视化与汇报

解决的问题：传统汇报中，高管面对几十张图表不知所措，只能在“全部绿色”和“某处红色”之间来回猜测。AI 驱动的聚合视图将多个 SLI 压缩成一个健康状态灯，配合自然语言摘要（如“支付链路剩余预算低于 10%，建议关注”），让高管在 10 秒内完成判断。

具体案例：某电商平台每周复盘会上，CTO 不再翻看工程师的 Grafana 大屏，而是打开“高管视图”：顶部显示三个核心 SLO 状态灯，下面附带一句由聚合模型生成的风险摘要。会议决策速度明显加快。

故障定位与降噪

阶段：告警管理

解决的问题：故障发生时，传统仪表盘往往同时弹出几十条告警，工程师无法判断哪条是根因。利用仪表盘的信息层级和历史相关性，系统自动把告警聚合成“故障事件”，并推荐最可能的下钻路径。

具体案例：一次数据库连接池耗尽事件中，工程师从高管视图的红灯点进工程视图，看到连接数曲线异常，再点开日志面板定位到慢查询，全程只用了 4 分钟，而过去平均需要 20 分钟。

季度 SLO 审计报告

阶段：自动化报表生成

解决的问题：传统方式需要手动从多个数据源导出指标、再拼装成周报/月报，耗时且容易口径不一。通过自动化构建的仪表盘快照和模板渲染，按季度导出 SLO 达成率、错误预算消耗和事故复盘摘要，直接生成高管可读的报告。

具体案例：某云计算团队每个季度自动生成《SLO 可靠性报告》，包含每项服务的达成率、趋势图和风险提示，省去了约 8 人/天的整理工作。

Python 演示

python52 行
"""生成SLO仪表盘JSON: 演示仪表盘自动化构建的核心流程"""import jsonimport os  def build_panel(title, expr):    """将一条 PromQL 表达式包装成 Grafana 面板对象"""    return {        "title": title,        "type": "timeseries",        "targets": [{"expr": expr, "legendFormat": "{{service}}"}],        "unit": "percent",    }  def render_dashboard(services, datasource="prometheus"):    """根据服务列表生成 Grafana Dashboard JSON"""    panels = [        build_panel(f"SLO-{svc}", f"slo:error_rate:ratio{{service=\"{svc}\"}}")        for svc in services    ]    return {        "title": "SRE-SLO-Overview",        "uid": "sre-slo-overview",        "panels": panels,        "templating": {            "list": [                {"name": "service", "type": "query",                 "query": "label_values(slo:error_rate:ratio, service)"}            ]        },        "refresh": "1m",        "time": {"from": "now-6h", "to": "now"},    }  def write_dashboard(path, dashboard):    """将仪表盘 JSON 写入目标路径，保持格式稳定"""    with open(path, "w", encoding="utf-8") as f:        json.dump(dashboard, f, ensure_ascii=False, indent=2)  def main():    services = ["api", "web", "pay"]    dashboard = render_dashboard(services)    write_dashboard("slo_dashboard.json", dashboard)    size = os.path.getsize("slo_dashboard.json")    print(f"仪表盘生成完成: slo_dashboard.json ({size} bytes)")  if __name__ == "__main__":    main()
目的：这段代码把“服务清单”渲染成一份完整的 Grafana 仪表盘 JSON，模拟自动化构建流程，是生产环境中 Dashboard as Code 的最小原型。
  1. build_panel(title, expr)定义每个面板的标题和查询语句，保证所有面板使用统一视觉与口径。
  2. slo:error_rate:ratio{service="api"}PromQL 查询表达式，按服务名过滤指标，防止面板间互相污染。
  3. render_dashboard(services, datasource)根据服务列表循环生成面板，未来新增服务时只需要修改名单。
  4. "refresh": "1m"设置自动刷新频率，避免数据源被频繁轮询，同时保证高管看到的数据足够新。
  5. write_dashboard(...)将 JSON 落入磁盘，之后可以提交到 Git，实现版本化回滚。

常见误区

误区总担心漏掉指标，于是把延迟、流量、错误、饱和度，甚至数据库连接数、GC 次数全部放在同一页。高管打开后满屏曲线，不知道该看哪里。

正解仪表盘的核心价值是“降低认知负载”。信息层次理论告诉我们，越重要的信息越要放在显眼位置，次要信息应该折叠到下钻层。高管视图只保留 3-5 个核心状态块，其他全部收进明细页，性能往往反而更好。

为何常见：工程师习惯了全天候盯监控，容易把自己的信息需求投射到所有观众身上，忽略了“可读性”才是高管界面的第一需求。

误区给高管看的仪表盘不能有细节，干脆只保留一个大大的“绿/红”灯。结果高管想了解“最近一周是否有波动趋势”时，完全无从下手。

正解高管视图不是“删”，而是“压缩”。保留状态灯之外，也应该保留一条 7 天 SLO 达成率的趋势线，让高管判断方向而非只看到瞬时状态。状态灯回答“现在”，趋势线回答“走向”。

为何常见：把“简洁”误解为“减少信息”，实际应该是“提炼信息”。就像机场大屏不仅有准时/延误，还有登机口和登机状态。

误区用红黄蓝绿紫五种颜色渲染所有图表，认为颜色多就能吸引注意。结果高管的注意力被各种无关色块牵引，寻找真正异常要很久。

正解遵循 Wilkinson 原则，颜色是弱视觉通道，应该只承载“状态”语义，且全图只使用少量颜色。例如：绿色=健康、黄色=注意、红色=故障，其他装饰色一律不要。

为何常见：生活经验中“标识牌都是彩色的”，导致大家默认颜色越多越清晰。但仪表盘不是广告牌，它是决策工具，颜色应该克制。

误区上线时认真配置了仪表盘，之后再也不动，半年后服务架构改了、指标名换了，仪表盘上全是“No Data”，却没人修复。

正解仪表盘是有生命的系统。必须通过自动化构建让仪表盘与架构变更同步更新：服务注册元数据变更，触发 CI 重新渲染仪表盘，并自动提交变更。这样仪表盘不会腐烂。

为何常见：手动维护成本高，团队默认“能用就行”，忽视了配置漂移的累积效应。

误区高管看“可用性 99.95%”，工程师排查时却发现这个指标只统计了 API 网关，没有包含数据库故障。两套数字对不上，决策被误导。

正解所有视图必须共用同一套 SLI 定义与数据源。高管视图的聚合一定要由工程明细层的指标计算而来，不能另起炉灶写一套独立查询。维护一份“指标口径字典”是必要的治理动作。

为何常见：不同团队各自搭建面板时，为了快速实现会复制查询再修改，导致口径漂移。

面试题

Q1. 高管可读性仪表盘的首要设计目标是什么？

单选题 · easy

  • A.展示所有原始数据
  • B.快速感知总体状态← 正确答案
  • C.提供丰富的交互按钮
  • D.防止意外误操作

答案：B。高管没有时间从原始数据中解读信息，仪表盘的首要目标是状态感知——少数几个聚合结果即可回答“现在是否健康”。选项 A 违背信息层次，C 和 D 不是核心目标，只是附加属性。

Q2. 根据 Wilkinson 原则，以下视觉通道中感知最强的是？

单选题 · easy

  • A.颜色色相
  • B.形状差异
  • C.位置差异← 正确答案
  • D.阴影填充

答案：C。Wilkinson 的感知通道排序中，位置、长度、角度都强于颜色和形状。位置差异最容易被人眼捕捉，所以关键指标要放在大屏左上角等固定显著位置。

Q3. SLO 仪表盘中最适合表达“错误预算剩余”的图形是？

单选题 · easy

  • A.饼图
  • B.历史趋势线
  • C.横向条形图← 正确答案
  • D.词语云

答案：C。条形图通过长度直观表达数量，符合“长度”通道强感知的特性。饼图依赖面积和角度，感知较弱；词云则完全不适合精确数值表达。

Q4. 三层漏斗结构从上到下的正确顺序是？

单选题 · mid

  • A.明细层-摘要层-日志层
  • B.摘要层-证据层-素材层← 正确答案
  • C.日志层-摘要层-证据层
  • D.摘要层-素材层-证据层

答案：B。顶层摘要层给结论，中间证据层展示 SLI 曲线，底层素材层保留日志与链路追踪。B 正确，A 和 C 顺序混乱，D 把素材层放在证据层之前，也违背逻辑。

Q5. Grafana 模板变量的主要作用是？

单选题 · mid

  • A.改变图表配色调色板
  • B.一套面板复用多个服务← 正确答案
  • C.压缩历史监控数据
  • D.自动修复故障节点

答案：B。模板变量如 $service 允许一个仪表盘通过下拉框切换服务，从而在同一套面板上复用多套数据。它不负责配色、存储或故障修复。

Q6. 高管视图对多个 SLI 做聚合时，最常用的策略是？

单选题 · mid

  • A.取算术平均
  • B.取最小值← 正确答案
  • C.取最大值
  • D.不聚合直接展示

答案：B。取最小值能让高管看到最差的 SLO，因为任何一个核心服务失守都可能影响客户。平均会掩盖局部风险，最大值则过度乐观。

Q7. “仪表盘自动化构建”的核心收益是？

单选题 · mid

  • A.不需要监控数据
  • B.配置可版本化可回滚← 正确答案
  • C.替代所有告警系统
  • D.自动生成业务日志

答案：B。Dashboard as Code 将配置纳入版本库，变更可审查、出错可回滚。它并不能替代数据源或告警，只是让仪表盘本身的维护流程更可靠。

Q8. 下列哪些元素适合放在高管视图上？

多选题 · hard

  • A.核心 SLO 状态灯← 正确答案
  • B.误码率7天趋势线← 正确答案
  • C.一行原始日志原文
  • D.错误预算剩余占比← 正确答案

答案：ABD。状态灯回答“当下健康吗”，趋势线回答“走向如何”，错误预算剩余占比是业务可感知的语言。原始日志原文是工程师排查时下钻的素材，属于证据层而非摘要层。

Q9. 关于 SLO 仪表盘故障演练，正确的做法包括？

多选题 · hard

  • A.注入错误率并验证告警← 正确答案
  • B.断开数据源测试回退← 正确答案
  • C.禁止所有成员查看仪表盘
  • D.删除历史监控数据

答案：AB。故障演练是为了验证仪表盘在异常条件下仍能给出正确信号：注入错误率可以检验显示逻辑，断开数据源可以检验“无数据”回退机制。C 和 D 不是演练手段，反而会削弱可靠性。

Q10. 生产部署检查清单中必须包含哪些？

多选题 · extreme

  • A.最小权限数据访问← 正确答案
  • B.指标口径与 SLO 一致← 正确答案
  • C.接口响应速度上限
  • D.可回滚的 Git 版本← 正确答案

答案：ABD。权限安全保证只有负责人能编辑，指标口径统一保证高管与工程师的认知一致，Git 版本提供回滚能力。接口响应速度上限是性能要求，不属于部署清单的必备项。