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

　　在＂告警服务＂的设计过程中，首先明确了＂告警服务＂的价值，然后通过用户画像描述了＂告警服务＂的实际应用场景，接着通过＂用户体验地图＂全面梳理了＂告警服务＂中用户的触点、痛点、机会点，并以此分析出设计的落地策略，最后通过对＂告警服务＂的设计及其迭代演化，逐步完善＂告警服务＂的设计方案、提升用户体验。
　　监控，可以拆解为＂监视+控制＂，监视（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个方面：
　　更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值，能极大降低用户使用＂告警服务＂的成本。
　　更具体的对象。目前的告警策略针对的还是零散的告警对象，未来将会将围绕＂场景＂概念为用户提供更加具体的业务告警对象，价值更高。
　　更精准的决策。目前的告警服务仅仅限于将现场数据告知用户，未来将会提供给用户加精准的辅助决策，以达到智能化运维的目标。
　　反思
　　设计师都是理想主义者，设计过程就是一个理想主义者不断与这个世界妥协的过程，与用户妥协、与技术妥协、与时间妥协，但这也体现体验设计的魅力：围绕用户需求进行快速迭代。
　　＂设计没有好与坏，只有合不合适＂