快好知 kuaihz

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

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

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

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

提供准确实时的产品数据

产品数据引导正确的用户行为

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

一、告警服务的价值

用户需求

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

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

业务价值

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

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

二、用户画像

用户画像A

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

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

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

用户画像B

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

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

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

三、用户体验地图

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

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

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

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

配置告警策略:简单的配置规则、合理的指标、提供默认的阈值

筛选产品数据:计算平台处理能力强、计算平台准确性高、计算平台稳定性好

推送告警消息:告警平台稳定性好、告警平台对相同告警进行合并

接收告警消息:告警内容简单易读、告警消息支持多渠道发送、告警消息支持自定义接收者

四、分析与思考

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

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

1)在“配置告警策略”阶段,存在1个触点:告警配置模块。

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

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

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

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

结合该阶段的设计机会点,可以推定:

针对“终端接收设备”,用户希望可以选择自己需要的渠道接收告警消息,并且告警消息发送给谁也由用户自己决定,这两项均属于配置阶段的内容。

针对“告警内容”,用户希望能按照重要、紧急两个维度将告警内容从上到下排列,并且尽量减少冗余信息、提升可读性。

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

配置告警策略(支持自定义的渠道和接收者)

告警消息所推送的内容

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

五、设计及演化

配置告警策略

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

告警策略的展示列表

告警策略的添加/编辑状态

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

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

告警策略的名称

告警监控的对象

告警针对的指标

告警触发的条件

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

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

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

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

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

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

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

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

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

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

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

一是所选择的告警指标“影响用户占比的环比增长率”涉及大量的“去重”计算,严重消耗计算平台的性能;

二是监控对象没有做限制,多个筛选条件排列组合之后产生了大量监控对象,远远超过了计算平台的极限。

因此,决定从两个方面优化设计方案:

使用新的告警指标

对监控对象做限制

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

监控对象限制了可配置的数目,降低现有计算平台产生阻塞的风险;

改用新的告警指标,舍弃了“去重”计算,提供“绝对值”、“相对值”两种指标供用户选择,覆盖面更广;

精简了触发条件,减轻现有计算平台的压力;

消息推送的渠道默认值只设置“豆芽”,降低成本(豆芽是苏宁内部员工使用的IM工具)

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

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

告警名称提供默认值,解决用户告警名称填写过程中“不愿想、不愿写”的”懒“需求;

监控对象的来源,提供用户常见的场景作为待选集合,方便用户快速选择告警对象;

监控对象的配置,让用户行为从“输入”变成“勾选”,并提供批量选择,简化用户的配置步骤;

监控对象的数目,限制数放开至200,并可通过后台配置进行动态调整。之所以将数目暂定于200,是方便用户从四个TOP异常的场景中分别选中一类,正好200。

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

支持用户告警策略列表进行筛选、搜索

支持继续添加告警策略

告警策略的五种主要内容(告警名称、监控对象、告警指标、触发条件、消息推送)显示在列表内

支持对单条策略的开关、编辑和删除,其中“开关”场景是用户暂时需要关闭策略、但不对其进行删除

告警消息

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

根据“告警消息”的设计原则,开展设计:

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

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

告警策略的名称:用户第一时间判断和自身的相关程度,是否自己创建、是否是高优先级告警策略。

当前产生的告警等级:判断该告警的严重程度,决定了采取何种干预措施。

产生告警的监控对象:确认告警是由哪个监控对象引起,如果要采取措施可据此联系责任人。

触发告警的数据:查看现场数据,在告警等级的基础上进一步判断该告警的严重程度。

告警发生的时间:时间可用于定位告警的原因和判断时效性。

告警所属的产品:附属信息,当用户名下有多个产品时据此区分。

告警发生的来源:附属信息,当用户使用多种监控系统时据此区分。

告警消息的接收者:附属信息,用户用以判断相关干系人是谁。

告警策略的创建者:附属信息,用户用以判断该告警策略是否是正常、合法创建。

六、总结

小结

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

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

更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值,能极大降低用户使用“告警服务”的成本。

更具体的对象。目前的告警策略针对的还是零散的告警对象,未来将会将围绕“场景”概念为用户提供更加具体的业务告警对象,价值更高。

更精准的决策。目前的告警服务仅仅限于将现场数据告知用户,未来将会提供给用户加精准的辅助决策,以达到智能化运维的目标。

反思

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

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

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:告警  告警词条  监控产品  监控产品词条  演化  演化词条  设计  设计词条  服务  服务词条  
设计

 产品设计师必备的模态体验知识

我在Medium上看到这篇讲解关于模态与非模态的差别,以及如何根据产品流程选择适合的类型的文章;觉得写的非常不错,所以翻译给大家看看,希望对大家有帮助~很多设计...(展开)

设计

 浅谈网页UI之Banner篇

关于网页UI,UE之类的论点文章网上太多了,更多大师将这些大师分析到极致,无论是开发领域还是设计领域,这些真正的大师所发表的文章都从不卖弄自己,更多的分析而无私...(展开)