一整墙的图表没人看

仪表板不是图表集合，而是回答一个问题的工具。增加面板与更快得到答案，往往朝着相反方向发展。

概念图: 回答一个问题的工具 · 单向增长 · 比例 · 四个黄金信号

发生故障时打开仪表板只有一个目的：在 30 秒内知道“当前哪里不正常”。但大多数仪表板回答不了这个问题。屏幕上有 40 个面板，其中 38 个和平时一样，值班人员必须亲自从中找出异常项。凌晨 3 点做这件事的人，最终往往会关闭仪表板，转而查看日志。

面板的增加方式也很固定。有人说“如果还能看到这个就更好了”，于是加上一个。却没有人删除面板，因为删除需要证明“没有人看这个”，而仪表板无法提供这种证据。因此，仪表板只会单向增长。

先写下问题，就能打断这种趋势。如果无法用一句话说明每个面板“在回答什么问题”，这个面板就可以删除。让删除有据可依，才是写下问题的真正原因。

应按“问题 → 面板”的顺序创建。反过来就会变成“既然有这个指标，那就画出来看看”，而这样添加的面板最终无人能够解读。

问题	面板	为什么选择该指标
当前是否正在向用户返回失败	5xx 比例	请求量增加时，错误数量也会增加；比例才表示用户遇到错误的概率
是否变慢	p95 响应时间	平均值会掩盖较慢的那部分请求
当前有多少流量进入	每秒请求数	即使错误率下降，如果流量为 0，也不代表系统正常
资源是否即将耗尽	磁盘、连接使用率	只有具有明确上限的数值才适合放在这里

这四项就是 Google SRE 书中所说的四个黄金信号（延迟、流量、错误、饱和度）。为新服务创建仪表板时，从这四项开始通常不会错。

有三类仪表板不能混在一起，否则三种目的都无法实现。

类型	回答的问题	查看者	面板数量
状态（health）	当前是否正常	接到告警的人	4～6 个
诊断（diagnosis）	为什么出现问题	查找原因的人	多一些也可以
容量（capacity）	何时需要扩容	负责规划的人	按周查看

一旦把诊断面板混入状态仪表板，它就无法在 30 秒内给出答案。应把诊断面板移到另一张仪表板，再通过链接连接起来。

“展示得越多越安全。” 实际恰恰相反。屏幕上的信号越多，漏掉唯一异常信号的概率越高。如果状态仪表板超过六个面板，通常意味着混入了诊断用途的内容。

“先放 CPU 指标。” CPU 使用率为 80%，对用户本身没有任何意义。首先应该展示用户实际经历的结果（错误、延迟），然后才是资源。CPU 是诊断仪表板中用于回答“为什么”的材料。

即使数据相同，绘制方式不同，也可能让人 30 秒内看懂，或盯很久仍不明所以。状态仪表板中的面板至少应具备以下四项要素。

同时显示基线。 只有当前值，就无法判断它是好是坏。可以用水平线标出目标值，或叠加上周同一时刻的数据。尤其对于流量这种日周期明显的指标，与昨天或上周的数据叠加比较，远比查看绝对值有用。

单位和范围必须真实。 坐标轴不从 0 开始，会让微小变化看起来像悬崖；范围过宽，又会把真正的变化压平。比例用百分比表示，时间用毫秒或秒表示，大小用字节单位表示，避免让人临场心算。

颜色代表状态。 把多条曲线涂成彩虹色没有任何意义。正常状态使用平静的颜色，只让问题状态使用醒目的颜色。而且，只有真正糟糕时才使用红色。 如果平时就有某项一直显示红色，整张仪表板都会逐渐对红色失去敏感度。

时间范围应匹配问题。 如果用于判断当前是否正常的页面默认显示 30 天，最近几分钟的变化会被压缩成一个点。状态仪表板应使用较短范围（约一小时），容量仪表板则应使用较长范围。

还建议再增加一项：为面板写说明。 用一两行说明该值统计什么、数据来自哪里、出现异常时应去哪里查看。这样，第一次看到面板的人不必询问创建者。创建仪表板的人不会永远都在现场。而且，如果写说明时发现某个面板无法用一句话说明，那么连创建者自己也不清楚它在观察什么，它就是应当删除的候选项。

仪表板建成后，应进行一次事件测试。假设凌晨 3 点接到告警，打开这张仪表板后，能否在 30 秒内判断“正常或异常”？如果不能，问题通常不是面板太少，而是面板太多。

还应直接把仪表板要回答的问题写进标题。与“shop-api 概览”相比，“shop-api——当前是否正在向用户返回失败”更好。标题本身是问题时，不回答该问题的面板就会格外显眼。