Data Monitor and Alarm Platform
在这个项目中，我们对 Data Monitor and Alarm Platform 进行了从后台服务到前端体验的整体重构。项目范围涵盖后台服务的部署与配置、监控和告警逻辑，以及面向用户的操作页面，目标是让复杂的数据监控和告警流程更容易理解、配置和使用。
随着平台功能和接入规模不断扩大，产品逐渐出现了新的问题。不同模块之间的导航、筛选、状态和操作方式缺少一致性，用户需要反复学习不同系统的使用逻辑。根据用户调研，用户反馈较集中的问题包括入口难以寻找、界面复杂、操作流程不清晰、学习成本较高，以及权限和性能问题。
同时，平台本身也面临较大的业务复杂度：目前接入服务超过 1,100 个，每天处理数千亿条数据点，每月产生大量 P0 和 P1 告警。如何让用户在复杂的数据和告警环境中快速找到信息、理解问题并采取行动，成为产品设计需要解决的核心问题。
我的工作范围覆盖平台菜单、Dashboard、服务管理、监控和告警流程、Onboarding，以及 Smart Cube 相关功能的界面优化。在项目推进过程中，我与前端开发和各产品模块负责人一起讨论需求，将“重构平台体验”“降低使用成本”“加入 AI 能力”等比较抽象的目标，进一步拆解成具体的用户任务和设计问题。
- 接入与配置：用户如何接入服务、配置数据源和绑定监控对象；
- 监控与告警：用户如何创建监控规则、设置阈值、配置通知和管理告警；
- 查看与分析：用户如何通过 Dashboard、Metrics、Tracing 和 Logs 了解服务状态；
- 故障处理与协作：用户如何确认异常、查看事件、进行下钻分析并完成后续处理；
- 智能辅助：用户如何通过 Smart RCA、Cube Companion 和 AI Summary 等功能减少查询和分析成本。
在此基础上，我进一步将问题归类为三个层面：
- 平台结构问题：功能入口过多，菜单层级复杂，用户难以判断功能属于哪个模块；
- 任务流程问题：创建、配置、审批、查看和处理等流程之间缺少连续性；
- 交互和反馈问题：状态、权限、告警级别、加载过程和错误信息的表达不够清晰。
在确定优化顺序时，我并不是按照页面数量或视觉问题的明显程度来排序，而是综合判断几个因素：问题出现的频率、涉及的用户范围、对核心任务的影响、操作错误可能带来的风险，以及它是否会在不同模块中重复出现。
如果一个问题只影响单个页面，我会结合具体场景进行局部调整；如果问题同时出现在导航、权限、状态或任务流程等多个模块中，则会优先将其抽象为平台级的设计问题，通过统一规则或公共组件解决。这样可以避免反复修改相似页面，也能让一次设计优化在多个产品模块中产生作用。
针对这一问题，我参与梳理了 Dashboard 的访问和审批流程，将权限申请统一到明确的入口中，并根据用户当前权限决定功能是否展示。例如，当用户没有创建权限时，隐藏 Add Folder 和 Add Card 等操作，而不是让用户点击后才看到错误提示。
同时，在 Dashboard 中增加 Team、Service、Folder 等筛选方式，并支持全局搜索和快速切换，让用户能够从“寻找页面”转向“直接定位服务或业务对象”。
在告警管理和安全相关场景中，我参与的并不只是按钮或状态标签的视觉调整，而是对告警从产生、识别、通知、查看到处置的完整流程进行梳理。由于平台每天会产生大量 P0、P1 告警，用户需要快速判断告警级别、当前状态、是否属于误报、是否已经被处理，以及自己是否具备相应的查看和配置权限。
基于这些问题，我参与统一了 P0–P3 告警级别，以及 Active、Resolved、Muted、False Alarm 等状态的表达方式，并重新检查告警列表、详情页、通知消息和操作入口之间的信息关系。例如，将含义不明确的 “Mark” 调整为 “Mark False Alarm”，让用户明确这是对告警结果进行标记，而不是修改告警规则本身。对于告警静默、时间段配置和通知规则，则需要清楚展示规则的生效时间、影响范围和恢复方式，避免用户修改配置后忘记恢复，或因配置不清导致重要告警未被及时通知。
在涉及 PII 数据时，设计还需要同时考虑信息展示和权限控制。对于包含敏感字段的 Dashboard 或告警链接，需要区分不同角色的访问范围，并通过明确的字段标识、权限校验和安全跳转限制数据暴露。没有权限的用户不应看到无法执行的操作；具备权限的用户也需要清楚知道当前内容包含敏感信息，以及自己的操作可能影响哪些数据。
通过这些调整，告警级别、处置状态、通知规则、用户权限和数据安全被纳入同一套产品逻辑中，帮助用户在高压排查场景下更快理解问题、判断风险并采取正确操作。
筛选器、表格、分页和数据详情页单独看都可以使用，但组合在一起时，如果信息层级和操作逻辑不一致，用户仍然难以完成任务。因此，我重点梳理了以下公共场景：
- 服务和 Dashboard 的搜索、筛选与分组；
- Metrics、Logs 和 Tracing 的数据查看与下钻；
- 创建、编辑、部署和删除等常见任务；
- 告警规则配置、时间段设置、静默和通知；
- 数据加载、空状态、错误状态和执行中的反馈。
在服务接入、监控规则和告警配置等流程中，用户通常需要完成多个连续步骤，任何一个配置错误都可能影响后续的数据展示或通知结果。因此，我将复杂流程按照用户任务进行拆分，并通过步骤引导、字段校验和配置预览，帮助用户明确当前进度、检查输入内容，并在提交前确认最终结果。
对于删除、禁用、修改告警阈值或调整通知范围等可能影响系统运行的操作，我会重点说明当前操作对象、影响范围、是否可以恢复以及操作完成后的状态，而不是只增加一个通用的“是否确认”弹窗。设计判断主要基于用户在当前任务中需要了解的信息、需要承担的风险，以及完成操作后还需要进行什么后续处理。
在产品设计中，AI 并不是单独增加一个聊天入口，而是与用户已有的监控任务结合起来：
- 在 Cube Companion 中，用户可以通过自然语言查询告警、日志和运行数据；
- 在 Smart RCA 中，系统将告警、服务拓扑、时序数据和日志关联起来，辅助用户分析可能的根因；
- 在 AI Summary Card 中，系统对多个数据卡片进行汇总和异常分析；
- 在 Intelligent Inspection 中，用户可以配置巡检任务并接收分析结果；
- 在 AI Workflow 中，进一步支持通过不同节点组合查询、分析和通知流程。
在引入 AI 能力时，我先从用户正在完成的监控任务出发，而不是先设计一个独立的 AI 入口。例如，用户发现服务异常后，通常需要依次查询运行数据、对比时间趋势、关联告警和日志，再进一步定位可能的根因。针对这些过程中重复查询、跨数据源比对和信息整理成本较高的环节，我们分别引入了自然语言查询、AI 摘要和 Smart RCA 等能力，让 AI 介入具体任务并提供辅助。
这样设计的重点是让 AI 成为原有工作流程中的一部分，帮助用户减少重复操作、缩短信息分析路径，同时保留数据来源和判断依据，而不是为了增加 AI 功能而让用户重新学习一套独立的交互方式。
- 将平台一级菜单从 29 个精简至 12 个，菜单项从约 115 个减少至约 60 个；
- 重构 Dashboard 的搜索、筛选、权限和审批流程；
- 梳理服务、指标、告警、Dashboard 和事件之间的关联关系；
- 统一常见组件、状态反馈和任务流程的使用方式；
- 参与 Smart Cube 多项 AI 能力在监控、分析和故障排查场景中的落地；
- 建立持续收集用户问题并反馈到产品迭代中的工作方式。
目前，Cube Monitor 已支持超过 1,100 个服务接入，每天处理数千亿条数据点，99.7% 的告警规则采用流式机制。对我而言，这个项目的重点并不是单纯重新设计页面，而是在一个复杂且持续增长的平台中，建立用户能够理解、团队能够复用的产品结构和交互规则。
