小议 Dashboard
最近在参与内部某个系统的设计审核,发现很多人在设计 Dashboard 的思路上存在一定的误区,Dashboard 不等同于那种花里胡哨的界面,并且依托于 Dashboard 还可以做更多事情。综上所述,我打算用漏洞扫描器为示例系统,与大家聊聊我的想法。
Dashboard 分类
我认为 Dashboard 分为 3 种:
- 常规型:告诉我们系统现在是什么状态
- 任务型:告诉我们现在需要去处理什么
- 聚合型:装逼
如果你可以理解,那么我们的想法是一致的,下面的内容就不需要再看了。
(前面的名字都是我瞎取的,各位主要看具体解释就好了)
常规型
常规型的 Dashboard 是最常见的,一提到 Dashboard 大家也往往会想到这种:
这是开源扫描器 —— 巡风的统计界面,上面展示出了各种数据与指标。那么显然,这种类型的 Dashboard,起码要满足,美观
、可读性好
这两个条件,而在他们之间,美观是最容易想到的、最容易看出来、也是最容易做好的地方,所以往往会出现 “花里胡哨的就是好的” 这种印象。那么怎么衡量 “可读性” 呢?我的办法很简单,找个不熟悉这个系统的人,问问他 Dashboard 上的各个图表都是什么意思,看他能不能回答得八九不离十,如果可以的话就过关了。
任务型
这种类型的 Dashboard 其实非常重要,但是很少见人考虑到,它本质上是辅助我们在这个系统上处理事情,我们只需要看一眼这个 Dashboard,就知道现在需要去做什么。例如系统出现异常?哪些漏洞还没被修复且已经超过了 SLA 的限制?哪些漏洞没有找到管理员?通常情况下,这些任务都是系统运维,凭借经验去梳理出来,然后进行处理,实际上梳理的过程是完全可以自动化的。
当然,也有人选择对接第三方的代办系统去追踪这些任务,例如 jira,这样也可以,但是我不喜欢,因为这只不过是前端在哪展示的问题,而与第三方系统做各种交互,还没直接实现这种 Dashboard 简单,因为它最简单的形式是只需要一个表格。
聚合型
某大佬曾经说过,装逼是人类的刚需。作为安全打工人,我们做完一个系统,不仅要好用、自己用的爽,还需要让懂安全的领导、不懂安全的领导都爽,所以在这里,领导关心什么,我们就展示什么,那么不管是自己对系统整体重要指标的把握,还是给领导汇报或者年终总结的时候它都会有很大的帮助。大家可以想想,对于漏洞扫描器来说,领导往往关心什么呢?肯定是较高视角的数据,我举例如下:
- 漏洞修复率或者按时修复率
- 每个部门漏洞数量的排序
- 所有漏洞的数量分布、类型分布
- 资产的变动趋势
- 系统运行的耗时(考察扫描效率)
大家可以结合实际情况,站在领导的角度多想想。其实这种 Dashboard 不仅仅是纯粹为了领导服务,作为项目负责人,我们也可以站在一个更高的视角来观察我们的系统。
Dashboard 的设计
首先,可读性一定是第一位的。如果我们做出了这种 Dashboard,恐怕自己都不想看吧?
解决的方式有很多种,对症下药即可,例如 增加说明,避免太专业或者小众的缩写以减少猜测、数据点不要过于密集、必要时数据拆分做展示,不要挤在一个图里、最重要的信息放在顶部、相关的数据放在接近的位置等等。
第二点,避免 “信息过载”。我们总是有分享收集到的一切数据的冲动,这也想展示,那也想展示。但是各种视图、过滤器、视觉效果都会增加信息密度,并带来认知上的负担。信息太多,Dashboard 就会表现混乱、难以理解。解决的方式嘛,该砍的砍就好了,或者你用一段时间,就会发现有些数据根本没有人关心,那么就可以删了。
第三点,要有重点,每种类型的 Dashboard,主要任务是什么,就展示什么数据,不要互相串。这一点在具体实施的过程中,聚合型的 Dashboard 容易与常规型 的 Dashboard 的重复,我的解决方式很简单,要是一个数据的展示,需要放在聚合型的 Dashboard 里,那么就不放在 常规型 的 Dashboard 里。
加分项:
- 美观,我相信各位审美都是在线的。
- 可交互,主要是筛选,能选择时间范围或者指定某个字段等。
- 实时,会自己异步进行刷新。
- 可自定义,可以参考 Kibana。
上文提到了很多图表绘制过程中易触及的错误,我之前在网上看到过一个较为通用的感知判断标准,分享如下:
最后,祝各位的 Dashboard 都能又实用,又让人赏心悦目~
过完年了
收收心,继续加油!
年前一直在看编译原理相关的知识
后面应该会出系列文章
按照之前说的,写完之后会集中发
敬请期待喔