问题发现（Findings）是 STAROps 中将"发现问题"沉淀为可跟踪、可处理、可验证、可闭环对象的核心能力。数字员工（Agent）在巡检、告警分析等任务执行过程中，会自动将发现的各类风险与异常归纳为问题发现（Finding），统一管理其从发现、跟进、处置到验证关闭的完整生命周期，帮助运维团队从被动响应告警转向主动管理问题，实时守护业务系统韧性。
什么是问题发现（Finding）
问题发现（Finding）是数字员工对一组现象形成的、需要被感知、跟进、处理、反馈和关闭的稳定问题判断。
Finding 不是单条告警、单个日志片段、巡检报告中的一个段落，也不是传统工单。与告警相比，Finding 的差异在于：
对比维度 | 告警（Alert） | 问题发现（Finding） |
信息形态 | 单次触发的事件通知 | 对一组相关现象归纳后的稳定判断 |
生命周期 | 触发、恢复 | 发现、跟进、处置、验证、关闭、复发重开的完整闭环 |
重复性 | 同一问题可能反复触发多条告警 | 自动去重，同一问题持续存在时持续更新同一个 Finding |
处置方式 | 依赖人工阅读后自行排查 | 自带影响对象、证据、处置项和验证条件，可跟踪执行结果 |
一个典型的 Finding 包含以下关键信息：
信息 | 说明 |
标题与摘要 | 问题的一句话描述与详细说明，例如"安全组公网暴露 SSH"。 |
类别与严重度 | 问题的分类（如安全风险、资源风险）与严重程度，帮助确定处理优先级。 |
置信度 | 数字员工对该问题判断的置信程度。 |
影响对象 | 问题锚定的 UModel 实体（如安全组、ECS 实例、Service、Pod），以及受影响的其他对象。 |
证据 | 支撑该问题判断的观测数据快照、配置记录等证据引用，可溯源。 |
处理项（Task） | 为闭环该问题需要完成的处理单元，详见下文"处理项与处置执行"。 |
验证条件 | 判断问题是否真正解决的客观标准，在 Finding 创建时即确定。 |
核心概念
问题生命周期
Finding 具有完整的状态生命周期：
打开（Open）：数字员工在任务执行中新发现问题，或同一问题持续存在，Finding 处于打开状态，并持续更新影响范围、证据和发生次数。
处理中：Finding 下的处理项被认领和执行，执行过程全程可观测。
关闭（Closed）：满足以下任一条件时，Finding 关闭：
自动关闭：处置动作执行完毕，且新一轮检查覆盖原检查范围后未再发现该问题，验证通过后自动关闭。
手动关闭：人工确认问题已解决或无需处理后，可手动关闭。
重新打开（Reopen）：已关闭的问题再次出现时，原 Finding 会被重新打开并延续其历史，而不是重复创建新 Finding。
未覆盖原检查范围的证据不会触发 Finding 关闭，避免"没看到"被误判为"已解决"。
问题的状态与关闭类型
除生命周期的宏观阶段外，Finding 在界面上呈现为以下可操作状态：
状态 | 含义 | 可执行操作 |
待处理 | 问题已发现，等待认领与处理 | 可转为「开始处理」或「关闭问题」 |
需要帮助 | 内置的处置 Agent 无法解决该事项，需要产品的使用者提供帮助。该状态由 Agent 在回写状态时使用，表示问题超出 Agent 自身处置能力范围，需要人工介入指导或补充信息 | 人工介入处理，或指导 Agent 继续 |
已关闭 | 问题已按某种关闭类型归档（见下表），复发时可重新打开 | 查看历史、必要时重新打开 |
执行「关闭问题」时，需要选择关闭类型，共 5 个子状态：
关闭类型 | 含义 |
已解决 | 问题经处置并验证通过后关闭（界面默认选中项） |
失败 | 处置执行未成功，按失败原因归档关闭 |
误报 | 经确认该问题并非真实存在的问题，按误报归档关闭 |
已忽略 | 知晓该问题存在，但决定不予处理而关闭 |
已取消 | 主动撤销该问题（如创建错误或不再需要跟踪）而关闭 |
上表状态名称与选项顺序来自产品界面（关闭问题对话框），各关闭类型的文字定义为文档编写组基于产品语义的撰写，便于读者理解。
问题去重与合并
为避免同一问题被重复上报，Finding 在创建前会经过多重校验：
相似度检查：基于规则与模型对历史 Finding 进行相似度判断，命中已有 Finding 时优先更新原 Finding 的影响范围、证据与发生次数，而不是新建。
合并与拆分：同一根因、同一处理动作的多个 Finding 支持合并；不同根因、不同负责人或不同处理方式的问题，支持拆分为多个 Finding 或建立父子关系，保证每个 Finding 都是可独立处理、独立验证的单元。
处理项与处置执行
每个 Finding 可以包含一个或多个处理项（Task），处理项是负责人接收和完成的最小单位，包含：
执行动作：具体的处置步骤，可以是工具调用、通知、审批或人工操作。
负责人（Owner）：处理项可以由人执行，也可以由数字员工在授权范围内自动执行。
验证条件：每个处置动作都附带验证条件，执行完成后需验证通过才算完成。
风险等级：根据处置动作的风险程度划分等级。高风险操作默认需要人工确认（HIL）后才会执行，并提供加强提示；低风险操作可配置为自动执行，无需逐条人工确认。
查看问题
STAROps 提供多个入口查看 Finding：
查看入口 | 说明 |
问题列表 | 控制台提供统一的问题列表页面，展示当前账号下的所有 Finding。 |
数字员工维度 | 支持查看特定数字员工发现的 Finding，按执行主体归口管理。 |
长期任务维度 | 在长期任务（Mission）详情页，支持查看该任务执行过程中产生的 Finding。 |
独立链接 | 每个 Finding 都有独立的 URL，可直接跳转访问，便于在 IM、邮件或工单中引用分享。 |
处理问题
在 Finding 详情页，支持以下操作：
反馈：对 Finding 的准确性进行正向或负向反馈，负反馈可填写原因，帮助数字员工持续提升判断质量。处理项同样支持独立反馈。
再次确认：对 Finding 的结论存疑时，可单击"再次确认"，系统将自动发起对话，由数字员工重新核查该问题是否合理。
关注操作：支持置顶、收藏等关注型操作，便于重点问题的跟踪。
执行处置：按处理项逐步执行处置动作。高风险操作会弹出确认提示，需人工确认后执行。
关闭问题：确认问题已解决后，可手动关闭 Finding；修复验证通过的 Finding 会自动关闭。
典型应用场景
安全风险巡检：定时巡检发现"同一安全组规则导致多台 ECS 暴露 22 端口"，聚合为一个 Finding 并锚定安全组，给出收敛规则的处理项与验证条件。
资源风险预警：巡检发现多块磁盘即将写满，按磁盘拆分为可独立处理、独立验证的 Finding，跟踪扩容或清理结果。
应用稳定性保障：告警事件触发分析发现多个 Pod 属于同一服务、同一崩溃特征，聚合为一个 Finding 并锚定到服务，联动根因分析。
运维缺口管理：诊断过程中发现数据未接入、拓扑缺失、权限不足等缺口时，也会生成对应 Finding，通过处理项明确需要补齐的事项，纳入统一闭环管理。
常见问题
Finding 和告警有什么区别？
告警是单次触发的事件通知，解决的是"让你知道"的问题；Finding 是数字员工对一组相关现象归纳后形成的稳定问题判断，自带影响对象、证据、处置建议和验证条件，并跟踪从发现到关闭的完整生命周期，解决的是"让问题被闭环"的问题。同一问题引发的重复告警，只会持续更新同一个 Finding。
同一个问题会重复创建 Finding 吗？
不会。Finding 创建前会自动进行相似度检查：同一问题持续存在时，数字员工会更新原 Finding 的影响范围、证据和发生次数；已关闭的问题复发时，会重新打开原 Finding，而不是新建。
Finding 会在什么情况下关闭？
两种方式：一是自动关闭——处置动作执行完毕，且新一轮检查覆盖原检查范围后未再发现该问题；二是手动关闭——人工确认后随时可关闭。仅凭"本轮未检查到"的证据不会关闭 Finding。
Finding 的处置动作会自动执行吗？
取决于配置与风险等级。低风险处置动作可配置为自动执行；高风险操作默认进入人工确认（HIL）流程，需通过 IM、控制台或 OpenAPI 确认后才会执行，兼顾效率与安全。
数据或权限不足导致无法诊断的情况会被遗漏吗？
不会。数据缺口、拓扑缺口、授权缺口、操作能力缺口等同样可以生成为 Finding，其处理项会明确说明需要补齐的内容，确保缺口也进入闭环管理。