背景
旧版概览在设计上过于追求颗粒度，缺乏业务关联性和时效性。随着业务演进，客户日常使用场景覆盖不全，业务模块冗余、零散等问题暴露出来。在“业务导向、技术相辅”的思路下开始整改。
KPI
概览是整个平台的门面，客户查看频率高，开发测试查看频率更高。最重要的是领导、SE查看频率也高，一个“三高”的需求，也是典型KPI衡量点。没UI、没设计只有要求，只能循规蹈矩的按照要求设计一版。
旧概览
客户反馈
- 概览中图表区域占比小，留白大
- 常关注的云主机、物理机信息、指标在概览中无法看到
- 概览中部分卡片展示的内容根本不关注
- 告警柱状图提供的信息无法清晰了解告警全貌和最近告警情况
SE反馈
不好看
API现状
- 独立接口
- 部分指标关联接口
- 部分耦合接口
- 轮询刷新频率不一致，从不刷新 ~ 15s范围都有
接口提供比较自由缺乏设计，数据处理会上移至每个模块组件中
优化改造
深度改造可参见之前文章大屏概览-定制化方案，适应业务灵活度更高，场景更复杂，定制化程度更高的系统。本次优化改造适用于在成熟系统基础上，涉及面相对较小，且很快能出效果。
业务模块
经过和SE讨论确定基本业务框架
卡片改造及整合
针对反馈问题修改
- 放大部分卡片中图表占比，增加采色变化；采用系统状态色，根据水球图比例设定变更水球图颜色
“绿->蓝->橙->红”
- 常关注的云主机相关统计和指标，
增加适配的图标，提升信息直观性 - 常关注的物理机相关统计和指标，
增加适配的图标，提升信息直观性 - 隐藏部分不关注卡片，支持自定义布局，需要查看随时可以放出来
- 参考友商及其它产品在告警统计上的概览设计，结合平台业务
API改造
随着业务模块、卡片改造及整合确定，对于API的设计及数据结构也提出相应的要求。由之前单指标和卡片1:1的设计变更成多指标和卡片n:1，也可以说是指标的组合与合并。
- 云主机：统计指标 + CPU使用率 + 内存使用率
- 主机：统计指标 + CPU使用率 + 内存使用率
- 告警：统计指标 + 最近告警 + 多平台
- 网络：统计指标 + 剩余可用IP数
意味着由技术驱动的指标颗粒度展示方式开始深度结合业务呈现，结合API现状优化如下：
- 刷新频率每个业务模块结合下层接口指标采集频率设定
- 数据处理会上移至每个模块组件中，同类型卡片数据源采用过滤器形式统一数据结构
- 考虑组合指标业务模块场景，针对同类型展示区域，提取子组件及统一数据结构。组合指标业务卡片可随时拆分重组。
