监控产品中“告警服务”的设计及演化

在“告警服务”的设计过程中，首先明确了“告警服务”的价值，然后通过用户画像描述了“告警服务”的实际应用场景，接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点，并以此分析出设计的落地策略，最后通过对“告警服务”的设计及其迭代演化，逐步完善“告警服务”的设计方案、提升用户体验。

监控，可以拆解为“监视+控制”，监视（monitor）表示用户通过观察获取数据，控制（control）表示数据变化引发的用户行为。

作为云产品的一种，监控产品构成“数据—人—行为”的闭环，满足用户两层需求：

1. 提供准确实时的产品数据
2. 产品数据引导正确的用户行为

数据是监控的基础，行为是监控的价值变现。本文所述的“告警服务”就是在用户处于离线状态下，监控产品仍然能构成“数据—人—行为”的完整闭环。

一、告警服务的价值

用户需求

对于99%的用户，都不能7*24盯着监控系统，当处于离线状态时（干活、吃饭、睡觉、下班、休假…），用户与监控数据之间是隔离的。

在这种场景中，如果监控数据发生了异常变化，用户仍希望能够立马获悉，进而采取措施应对、避免造成损失。“告警服务”应运而生，用户设定一定的规则，当监控数据违反规则时触发告警并发送给用户，打破“人”和“数据”的的隔离状态，瞬间构成“数据—人—行为”的完整闭环。

业务价值

“告警服务”能极大解放用户的注意力。通过对产品的业务数据设定规则，业务人员就可以7*24的掌握产品数据的健康状态，得以将更多的精力专注于业务本身。

“告警服务”能使用户第一时间获取期望的业务数据。产品的业务数据一旦违反用户设定的规则即可迅速推送至用户，帮助用户过滤99%的无效信息，使数据精准触达用户。

二、用户画像

用户画像A

任盈盈，女，25岁，产品经理

负责苏宁易购某核心产品线- XX产品线的产品工作，日常的工作主要围绕XX产品线的需求、排期、研发、上线开展，工作节奏快、强度高。每天会登录数次监控产品，查看XX产品线的监控数据，以掌握XX产品线的健康状态。

由于工作节奏快，每天难以抽出充沛的时间去分析产品监控数据，会遗漏部分关键数据从而留下隐患。希望能通过告警服务获取所有XX产品线相关的关键异常数据，既不用花费大量的时间精力去分析数据，也不会遗漏任何关键数据。

用户画像B

令狐冲，男，35岁，技术负责人

负责苏宁易购某核心研发中心- XX研发中心的技术工作，日常的工作主要是XX研发中心的技术保障，工作责任重、压力大。每天一上班就会打开监控产品，随时查看XX研发中心相关的监控数据，保证系统的稳定。

由于系统是7*24小时运行，但自身无法全天候上线查看监控数据，尤其是下班后或节假日，没法做到随时查看监控数据。希望能通过告警服务及时获取XX研发中心相关的异常数据，以便第一时间作出判断、并决定是否安排人员介入。

三、用户体验地图

通过参考行业相关产品和调研用户需求，可以将“告警服务”拆分为4个阶段：

“配置告警策略——筛选产品数据——推送告警消息——接收告警消息”

以下是“告警服务”4个阶段的用户体验地图，可以从全局视角审视“告警服务”的每一个环节。

通过洞察用户的行为和心理，梳理用户在不同阶段的情绪点，可以盘点、挖掘“告警服务”四个阶段设计的机会点，如下：

1. 配置告警策略：简单的配置规则、合理的指标、提供默认的阈值
2. 筛选产品数据：计算平台处理能力强、计算平台准确性高、计算平台稳定性好
3. 推送告警消息：告警平台稳定性好、告警平台对相同告警进行合并
4. 接收告警消息：告警内容简单易读、告警消息支持多渠道发送、告警消息支持自定义接收者

四、分析与思考

用户体验地图给出设计的“机会点”，接下来需要思考如何将其落地、形成可参考执行的设计策略。

首先，需要关注存在哪些用户触点，这是设计落地的切入点，通过用户体验地图，分析如下：

1）在“配置告警策略”阶段，存在1个触点：告警配置模块。

结合该阶段的设计机会点，可以推定：在告警配置模块，需要提供简单的配置规则，在配置规则内尽量提供用户最合适的指标或组合，并且在关于阈值的设定上可以提供默认值、或者毋需用户设定。

2）在“筛选产品数据”、“推送告警信息”两个阶段，均由后台系统自动完成、用户不会直接接触，因此不存在用户触点。

但是并不意味着设计不需要关注这两个阶段，在设计的过程中，需要根据目前的技术能力给出合理的设计方案，尽量避免凭空想象。

3）在“接受告警消息”阶段，存在2个触点：终端接收设备、告警内容。

结合该阶段的设计机会点，可以推定：

• 针对“终端接收设备”， 用户希望可以选择自己需要的渠道接收告警消息，并且告警消息发送给谁也由用户自己决定，这两项均属于配置阶段的内容。
• 针对“告警内容”， 用户希望能按照重要、紧急两个维度将告警内容从上到下排列，并且尽量减少冗余信息、提升可读性。

通过以上分析，可以清晰归纳出，设计的落地点主要由两个：

1. 配置告警策略（支持自定义的渠道和接收者）
2. 告警消息所推送的内容

针对这两项的设计策略如下：

五、设计及演化

配置告警策略

参考行业相关产品，告警配置模块主要分为两个部分：

1. 告警策略的展示列表
2. 告警策略的添加/编辑状态

本质上两者都是即围绕“告警策略”开展设计。

针对“告警策略”，一般由4种内容组成：

1. 告警策略的名称
2. 告警监控的对象
3. 告警针对的指标
4. 告警触发的条件

在本案例中，由于“终端接收设备”模块的内容合并至“告警配置模块”，因此本案例中的告警策略需要再增加一项内容：告警消息的推送。

1）告警策略的名称： 指本条告警策略的名称，与人的姓名一样，是用户识别告警策略的主要标识。

2）告警监控的对象： 指本条告警策略是针对哪些对象而配置的，监控这些对象的状态变化。

3）告警针对的指标： 指针对哪个数据指标设立告警规则，指标可以是单个或一组，需要选择合适的指标才能更好的发挥告警服务的价值。

4）告警触发的条件： 指选定的数据指标达到什么阈值即触发告警的生成，这个决定告警服务的精确程度。

5）告警消息的推送： 指告警消息发送的人员，以及发送的方式，也就是解决“通知谁、怎么通知”的问题。

梳理完告警配置模块的元素，就可以根据“配置告警策略”的设计原则，开展设计：“配置规则简单、指标契合、阈值有默认值、自定义接收渠道、自定义接收者”

当用户进入告警配置模块，未配置任何告警策略，提示、引导用户开始创建。

针对“添加告警策略”，经历了3版设计方案的演变。

第一版方案，基本符合上述的设计原则。

该方案上线之后用户配置了大量的告警策略，但发生了意想不到的事情：不告警。经过排查定位，最终确认是计算平台产生了非常严重的阻塞，即“用户体验地图”的第二阶段“筛选产品数据”出了问题。复盘之后，认定有两方面的原因：

1. 一是所选择的告警指标“影响用户占比的环比增长率”涉及大量的“去重”计算，严重消耗计算平台的性能；
2. 二是监控对象没有做限制，多个筛选条件排列组合之后产生了大量监控对象，远远超过了计算平台的极限。

因此，决定从两个方面优化设计方案：

1. 使用新的告警指标
2. 对监控对象做限制

这是第二版方案，在延续第一版所遵循的设计原则基础上，针对性做了优化。

1. 监控对象限制了可配置的数目，降低现有计算平台产生阻塞的风险；
2. 改用新的告警指标，舍弃了“去重”计算，提供“绝对值”、“相对值”两种指标供用户选择，覆盖面更广；
3. 精简了触发条件，减轻现有计算平台的压力；
4. 消息推送的渠道默认值只设置“豆芽”，降低成本（豆芽是苏宁内部员工使用的IM工具）

第二版方案上线之后，告警计算平台的阻塞问题解决了，但是用户反馈：监控对象可配置的太少。这个当时已经预料到会有这个问题，但是现有的计算平台性能受限，“巧妇难为无米之炊”，只能采取这种妥协的方式。

随着新的计算平台上线，性能得到极大提升，设计方案也不用“畏手畏脚”。第三版方案在保留原有优点的基础上，主要针对“告警对象”做了重点优化。

1. 告警名称提供默认值，解决用户对告警名称填写过程中“不愿想、不愿写”的”懒“需求；
2. 监控对象的来源，提供用户常见的场景作为待选集合，方便用户快速选择告警对象；
3. 监控对象的配置，让用户行为从“输入”变成“勾选”，并提供批量选择，简化用户的配置步骤；
4. 监控对象的数目，限制数放开至200，并可通过后台配置进行动态调整。之所以将数目暂定于200，是方便用户从四个TOP异常的场景中分别选中一类，正好200。

添加完告警策略之后，告警模块至少会有一条告警策略。

1. 支持用户对告警策略列表进行筛选、搜索
2. 支持继续添加告警策略
3. 将告警策略的五种主要内容（告警名称、监控对象、告警指标、触发条件、消息推送）显示在列表内
4. 支持对单条策略的开关、编辑和删除，其中“开关”场景是用户暂时需要关闭策略、但不对其进行删除

告警消息

告警消息指的是当告警发生以后，告警平台将该条告警相关的信息推送至用户，是“数据—人—行为”闭环的重要一环，用户通过阅读告警消息获取当前系统的健康状况、从而采取对应的干预措施。

根据“告警消息”的设计原则，开展设计：

“提供关键数据、精简告警内容、减少冗余信息、提升可读性”

相比于“配置告警策略”，“告警消息”没有出现过较大版本的优化。通过参考行业相关产品和用户需求，择取了9个字段，实际的告警消息有两种模板，分别对应两种告警指标：异常数、绝对值。

1. 告警策略的名称：用户第一时间判断和自身的相关程度，是否自己创建、是否是高优先级告警策略。
2. 当前产生的告警等级：判断该告警的严重程度，决定了采取何种干预措施。
3. 产生告警的监控对象：确认告警是由哪个监控对象引起，如果要采取措施可据此联系责任人。
4. 触发告警的数据：查看现场数据，在告警等级的基础上进一步判断该告警的严重程度。
5. 告警发生的时间：时间可用于定位告警的原因和判断时效性。
6. 告警所属的产品：附属信息，当用户名下有多个产品时据此区分。
7. 告警发生的来源：附属信息，当用户使用多种监控系统时据此区分。
8. 告警消息的接收者：附属信息，用户用以判断相关干系人是谁。
9. 告警策略的创建者：附属信息，用户用以判断该告警策略是否是正常、合法创建。

六、总结

小结

在“告警服务”的设计过程中，首先明确了“告警服务”的价值，然后通过用户画像描述了“告警服务”的实际应用场景，接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点，并以此分析出设计的落地策略，最后通过对“告警服务”的设计及其迭代演化，逐步完善“告警服务”的设计方案、提升用户体验。

随着AI和大数据等技术的引入，“告警服务”会持续进行优化迭代，主要围绕3个方面：

1. 更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值，能极大降低用户使用“告警服务”的成本。
2. 更具体的对象。目前的告警策略针对的还是零散的告警对象，未来将会将围绕“场景”概念为用户提供更加具体的业务告警对象，价值更高。
3. 更精准的决策。目前的告警服务仅仅限于将现场数据告知用户，未来将会提供给用户加精准的辅助决策，以达到智能化运维的目标。

反思

设计师都是理想主义者，设计过程就是一个理想主义者不断与这个世界妥协的过程，与用户妥协、与技术妥协、与时间妥协，但这也体现体验设计的魅力：围绕用户需求进行快速迭代。

“设计没有好与坏，只有合不合适”

作者：胡欣欣，公众号：吹拉弹唱大师（ID：cltcds）

本文由@吹拉弹唱大师 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: