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

　　在告警服务的设计过程中，首先明确了告警服务的价值，然后通过用户画像描述了告警服务的实际应用场景，接着通过用户体验地图全面梳理了告警服务中用户的触点、痛点、机会点，并以此分析出设计的落地策略，最后通过对告警服务的设计及其迭代演化，逐步完善告警服务的设计方案、提升用户体验。
　　监控，可以拆解为监视控制，监视（monitor）表示用户通过观察获取数据，控制（control）表示数据变化引发的用户行为。
　　作为云产品的一种，监控产品构成数据人行为的闭环，满足用户两层需求：
　　提供准确实时的产品数据
　　产品数据引导正确的用户行为
　　数据是监控的基础，行为是监控的价值变现。本文所述的告警服务就是在用户处于离线状态下，监控产品仍然能构成数据人行为的完整闭环。
　　一、告警服务的价值
　　用户需求
　　对于99的用户，都不能724盯着监控系统，当处于离线状态时（干活、吃饭、睡觉、下班、休假），用户与监控数据之间是隔离的。
　　在这种场景中，如果监控数据发生了异常变化，用户仍希望能够立马获悉，进而采取措施应对、避免造成损失。告警服务应运而生，用户设定一定的规则，当监控数据违反规则时触发告警并发送给用户，打破人和数据的的隔离状态，瞬间构成数据人行为的完整闭环。
　　业务价值
　　告警服务能极大解放用户的注意力。通过对产品的业务数据设定规则，业务人员就可以724的掌握产品数据的健康状态，得以将更多的精力专注于业务本身。
　　告警服务能使用户第一时间获取期望的业务数据。产品的业务数据一旦违反用户设定的规则即可迅速推送至用户，帮助用户过滤99的无效信息，使数据精准触达用户。
　　二、用户画像
　　用户画像A
　　任盈盈，女，25岁，产品经理
　　负责苏宁易购某核心产品线XX产品线的产品工作，日常的工作主要围绕XX产品线的需求、排期、研发、上线开展，工作节奏快、强度高。每天会登录数次监控产品，查看XX产品线的监控数据，以掌握XX产品线的健康状态。
　　由于工作节奏快，每天难以抽出充沛的时间去分析产品监控数据，会遗漏部分关键数据从而留下隐患。希望能通过告警服务获取所有XX产品线相关的关键异常数据，既不用花费大量的时间精力去分析数据，也不会遗漏任何关键数据。
　　用户画像B
　　令狐冲，男，35岁，技术负责人
　　负责苏宁易购某核心研发中心XX研发中心的技术工作，日常的工作主要是XX研发中心的技术保障，工作责任重、压力大。每天一上班就会打开监控产品，随时查看XX研发中心相关的监控数据，保证系统的稳定。
　　由于系统是724小时运行，但自身无法全天候上线查看监控数据，尤其是下班后或节假日，没法做到随时查看监控数据。希望能通过告警服务及时获取XX研发中心相关的异常数据，以便第一时间作出判断、并决定是否安排人员介入。
　　三、用户体验地图
　　通过参考行业相关产品和调研用户需求，可以将告警服务拆分为4个阶段：
　　配置告警策略筛选产品数据推送告警消息接收告警消息
　　以下是告警服务4个阶段的用户体验地图，可以从全局视角审视告警服务的每一个环节。
　　通过洞察用户的行为和心理，梳理用户在不同阶段的情绪点，可以盘点、挖掘告警服务四个阶段设计的机会点，如下：
　　配置告警策略：简单的配置规则、合理的指标、提供默认的阈值
　　筛选产品数据：计算平台处理能力强、计算平台准确性高、计算平台稳定性好
　　推送告警消息：告警平台稳定性好、告警平台对相同告警进行合并
　　接收告警消息：告警内容简单易读、告警消息支持多渠道发送、告警消息支持自定义接收者
　　四、分析与思考
　　用户体验地图给出设计的机会点，接下来需要思考如何将其落地、形成可参考执行的设计策略。
　　首先，需要关注存在哪些用户触点，这是设计落地的切入点，通过用户体验地图，分析如下：
　　1）在配置告警策略阶段，存在1个触点：告警配置模块。
　　结合该阶段的设计机会点，可以推定：在告警配置模块，需要提供简单的配置规则，在配置规则内尽量提供用户最合适的指标或组合，并且在关于阈值的设定上可以提供默认值、或者毋需用户设定。
　　2）在筛选产品数据、推送告警信息两个阶段，均由后台系统自动完成、用户不会直接接触，因此不存在用户触点。
　　但是并不意味着设计不需要关注这两个阶段，在设计的过程中，需要根据目前的技术能力给出合理的设计方案，尽量避免凭空想象。
　　3）在接受告警消息阶段，存在2个触点：终端接收设备、告警内容。
　　结合该阶段的设计机会点，可以推定：
　　针对终端接收设备，用户希望可以选择自己需要的渠道接收告警消息，并且告警消息发送给谁也由用户自己决定，这两项均属于配置阶段的内容。
　　针对告警内容，用户希望能按照重要、紧急两个维度将告警内容从上到下排列，并且尽量减少冗余信息、提升可读性。
　　通过以上分析，可以清晰归纳出，设计的落地点主要由两个：
　　配置告警策略（支持自定义的渠道和接收者）
　　告警消息所推送的内容
　　针对这两项的设计策略如下：
　　五、设计及演化
　　配置告警策略
　　参考行业相关产品，告警配置模块主要分为两个部分：
　　告警策略的展示列表
　　告警策略的添加编辑状态
　　本质上两者都是即围绕告警策略开展设计。
　　针对告警策略，一般由4种内容组成：
　　告警策略的名称
　　告警监控的对象
　　告警针对的指标
　　告警触发的条件
　　在本案例中，由于终端接收设备模块的内容合并至告警配置模块，因此本案例中的告警策略需要再增加一项内容：告警消息的推送。
　　1）告警策略的名称：指本条告警策略的名称，与人的姓名一样，是用户识别告警策略的主要标识。
　　2）告警监控的对象：指本条告警策略是针对哪些对象而配置的，监控这些对象的状态变化。
　　3）告警针对的指标：指针对哪个数据指标设立告警规则，指标可以是单个或一组，需要选择合适的指标才能更好的发挥告警服务的价值。
　　4）告警触发的条件：指选定的数据指标达到什么阈值即触发告警的生成，这个决定告警服务的精确程度。
　　5）告警消息的推送：指告警消息发送的人员，以及发送的方式，也就是解决通知谁、怎么通知的问题。
　　梳理完告警配置模块的元素，就可以根据配置告警策略的设计原则，开展设计：配置规则简单、指标契合、阈值有默认值、自定义接收渠道、自定义接收者
　　当用户进入告警配置模块，未配置任何告警策略，提示、引导用户开始创建。
　　针对添加告警策略，经历了3版设计方案的演变。
　　第一版方案，基本符合上述的设计原则。
　　该方案上线之后用户配置了大量的告警策略，但发生了意想不到的事情：不告警。经过排查定位，最终确认是计算平台产生了非常严重的阻塞，即用户体验地图的第二阶段筛选产品数据出了问题。复盘之后，认定有两方面的原因：
　　一是所选择的告警指标影响用户占比的环比增长率涉及大量的去重计算，严重消耗计算平台的性能；
　　二是监控对象没有做限制，多个筛选条件排列组合之后产生了大量监控对象，远远超过了计算平台的极限。
　　因此，决定从两个方面优化设计方案：
　　使用新的告警指标
　　对监控对象做限制
　　这是第二版方案，在延续第一版所遵循的设计原则基础上，针对性做了优化。
　　监控对象限制了可配置的数目，降低现有计算平台产生阻塞的风险；
　　改用新的告警指标，舍弃了去重计算，提供绝对值、相对值两种指标供用户选择，覆盖面更广；
　　精简了触发条件，减轻现有计算平台的压力；
　　消息推送的渠道默认值只设置豆芽，降低成本（豆芽是苏宁内部员工使用的IM工具）
　　第二版方案上线之后，告警计算平台的阻塞问题解决了，但是用户反馈：监控对象可配置的太少。这个当时已经预料到会有这个问题，但是现有的计算平台性能受限，巧妇难为无米之炊，只能采取这种妥协的方式。
　　随着新的计算平台上线，性能得到极大提升，设计方案也不用畏手畏脚。第三版方案在保留原有优点的基础上，主要针对告警对象做了重点优化。
　　告警名称提供默认值，解决用户对告警名称填写过程中不愿想、不愿写的懒需求；
　　监控对象的来源，提供用户常见的场景作为待选集合，方便用户快速选择告警对象；
　　监控对象的配置，让用户行为从输入变成勾选，并提供批量选择，简化用户的配置步骤；
　　监控对象的数目，限制数放开至200，并可通过后台配置进行动态调整。之所以将数目暂定于200，是方便用户从四个TOP异常的场景中分别选中一类，正好200。
　　添加完告警策略之后，告警模块至少会有一条告警策略。
　　支持用户对告警策略列表进行筛选、搜索
　　支持继续添加告警策略
　　将告警策略的五种主要内容（告警名称、监控对象、告警指标、触发条件、消息推送）显示在列表内
　　支持对单条策略的开关、编辑和删除，其中开关场景是用户暂时需要关闭策略、但不对其进行删除
　　告警消息
　　告警消息指的是当告警发生以后，告警平台将该条告警相关的信息推送至用户，是数据人行为闭环的重要一环，用户通过阅读告警消息获取当前系统的健康状况、从而采取对应的干预措施。
　　根据告警消息的设计原则，开展设计：
　　提供关键数据、精简告警内容、减少冗余信息、提升可读性
　　相比于配置告警策略，告警消息没有出现过较大版本的优化。通过参考行业相关产品和用户需求，择取了9个字段，实际的告警消息有两种模板，分别对应两种告警指标：异常数、绝对值。
　　告警策略的名称：用户第一时间判断和自身的相关程度，是否自己创建、是否是高优先级告警策略。
　　当前产生的告警等级：判断该告警的严重程度，决定了采取何种干预措施。
　　产生告警的监控对象：确认告警是由哪个监控对象引起，如果要采取措施可据此联系责任人。
　　触发告警的数据：查看现场数据，在告警等级的基础上进一步判断该告警的严重程度。
　　告警发生的时间：时间可用于定位告警的原因和判断时效性。
　　告警所属的产品：附属信息，当用户名下有多个产品时据此区分。
　　告警发生的来源：附属信息，当用户使用多种监控系统时据此区分。
　　告警消息的接收者：附属信息，用户用以判断相关干系人是谁。
　　告警策略的创建者：附属信息，用户用以判断该告警策略是否是正常、合法创建。
　　六、总结
　　小结
　　在告警服务的设计过程中，首先明确了告警服务的价值，然后通过用户画像描述了告警服务的实际应用场景，接着通过用户体验地图全面梳理了告警服务中用户的触点、痛点、机会点，并以此分析出设计的落地策略，最后通过对告警服务的设计及其迭代演化，逐步完善告警服务的设计方案、提升用户体验。
　　随着AI和大数据等技术的引入，告警服务会持续进行优化迭代，主要围绕3个方面：
　　更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值，能极大降低用户使用告警服务的成本。
　　更具体的对象。目前的告警策略针对的还是零散的告警对象，未来将会将围绕场景概念为用户提供更加具体的业务告警对象，价值更高。
　　更精准的决策。目前的告警服务仅仅限于将现场数据告知用户，未来将会提供给用户加精准的辅助决策，以达到智能化运维的目标。
　　反思
　　设计师都是理想主义者，设计过程就是一个理想主义者不断与这个世界妥协的过程，与用户妥协、与技术妥协、与时间妥协，但这也体现体验设计的魅力：围绕用户需求进行快速迭代。
　　设计没有好与坏，只有合不合适