尧图网页设计 
作者来自 Elastic Jeffrey Rengifo一个审批关卡会在执行操作之前暂停故障事件响应自动化并为审核人员提供足够的证据让其能够在几秒钟内做出决定。无论后续结果是批准还是拒绝都会记录在一个可审计的记录中。没有证据支撑的 “批准” 按钮并不能算作一种控制手段。人在回路中自动化会将五件事情绑定到一个可检查的记录中你观察到的证据、你提出的操作、做出决定的人、他们拥有的截止时间以及实际执行的操作。在本文中你将使用 Elastic Workflows 构建这个审批关卡并复用配套文章 使用 Agent Builder 和 Workflows 构建 SRE 控制平面 中的控制平面。这一次故障事件足够明确可以采取行动单个 worker 上存在过期的定价缓存并在建议和修复之间设置一个结构化的审批步骤。这里的任何操作都不会触及生产环境因此你可以分别运行批准分支和拒绝分支然后比较每个分支在执行记录中留下的内容。正是通过这份记录故障事件响应自动化才能一次针对一个故障事件类别逐步获得自主性。前提条件Elastic Stack 9.4在添加审批之前SRE 控制平面需要什么本文基于使用 Agent Builder 和 Workflows 构建 SRE 控制平面该文章定义了这里使用的控制平面模式将遥测数据、调查上下文、策略以及一组已知操作连接在一起。Agent Builder 对日志、追踪、指标、警报、运行手册和之前的故障事件案例进行推理。Elastic Workflows 按照定义好的序列执行操作并使用明确的输入和权限。人在回路中即 HITL则在证据转化为操作的关键节点将这两项职责连接起来。建议和修复具有完全不同的故障模式。糟糕的建议只是浪费工程师的时间而糟糕的修复则会改变生产环境。这就是为什么审批关卡应该属于执行模型的一部分。使审批关卡成为可靠性控制机制的五种绑定一个有用的审批关卡需要保留五种属性。缺少其中任何一种审批关卡都会变得更弱。证据绑定审核人员能够看到生成该建议所依据的日志、警报详细信息、补充信息或 agent 推理过程。没有证据的“批准”按钮只是在要求一个人接受自动化系统的判断。操作绑定请求需要明确说明具体且范围受限的操作、目标、参数和预期效果。没有明确目标的请求可能会授权执行远超审核人员预期的操作。身份绑定记录会显示谁批准或拒绝了该请求以及做出决定的时间。没有这些信息你只能知道结果却没有责任归属。时间绑定决策具有截止时间过期的请求会默认失败而不是在失去上下文后继续执行。没有超时机制的审批请求其生命周期可能超过当初证明该操作合理的故障事件证据。结果绑定执行记录会显示实际执行了什么、跳过了什么以及操作后的验证是否通过。表单仍然很重要但表单只是一个更大控制机制中面向人工的部分。审批设计本身就是可靠性工程。从 AI 建议到自动修复的四个阶段应将自主性视为一系列运营状态而不是一个产品开关。自主性阶段系统行为人工职责晋级依据0. 观察搜索日志并收集上下文。人工调查并采取操作。查询能够找到正确的故障事件证据。1. 建议提出一个范围受限的下一步操作并提供理由。决定是否执行并在 workflow 外部执行。建议足够准确可以快速审核。2. 审批在执行操作前暂停并且只有获得结构化输入后才继续执行。批准或拒绝明确的操作建议。对审批质量、执行成功率和回滚行为进行衡量。3. 有限范围自动化针对经过验证的故障事件类别自动执行相同的操作。审核异常情况并审计样本。仍然强制执行范围限制、权限、超时、验证和回滚。最重要的转换是从阶段 1 到阶段 2。正是在这里系统不再只是一个顾问而是获得了执行路径。即使 AI agent 参与了调查这条路径也应该是确定性的agent 负责总结证据并建议操作而 workflow 负责暂停、结构化决策、分支处理和执行记录。在 Elastic Workflows 中构建人在回路中的自动化审批关卡Elastic Workflows 为此提供了 waitForInput step。当执行到达该步骤时workflow 会停止在WAITING_FOR_INPUT状态并等待人工输入。审核人员可以在 Kibana execution view 中填写一个简单的表单或通过 resume API 提交提交的内容随后可以通过steps.step_name.output供后续步骤使用。该 workflow 会获取过去 30 分钟checkout-api的失败日志将这些日志交给 Agent Builder 进行根本原因分析并将分析结果写入一个 Observability case。然后它会暂停并提出一个问题是否应该清除checkout-worker-07上的定价缓存如果你批准workflow 会记录模拟操作运行验证查询并将结果追加到 case 中。如果你拒绝它会记录该决定并且不会执行任何操作。无论哪种情况都不会触及生产环境。name: obs-labs-checkout-control-plane-hitl description: Human approval gate for the OpenTelemetry-grounded checkout control plane. enabled: false tags: - sre-control-plane - agent-builder - human-in-the-loop - workflows - opentelemetry settings: timeout: 30m triggers: - type: manual consts: incident_id: obs-labs-checkout-hitl-20260719 steps: - name: collect_evidence type: elasticsearch.search with: index: logs-* size: 10 query: bool: filter: - range: timestamp: gte: now-30m - term: service.name: checkout-api - term: attributes.incident.id: {{ consts.incident_id }} - match_phrase: body.text: query: checkout failed: stale pricing cache - name: rca_analysis type: ai.agent agent-id: elastic-ai-agent create-conversation: true with: message: | Investigate the checkout-api incident identified by {{ consts.incident_id }}. The workflow evidence query found {{ steps.collect_evidence.output.hits.total.value }} matching OpenTelemetry log events in the last 30 minutes. Search logs, traces, and metrics for service.name checkout-api and incident.id {{ consts.incident_id }}. Identify the affected worker, deployment version, error type, HTTP status, and latency evidence. Return the likely cause, supporting evidence, confidence, and whether the bounded simulated action below is consistent with the evidence. Proposed simulated action: simulate clearing the pricing cache on checkout-worker-07. This workflow must not change production. - name: case_title type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a short case title for this checkout incident. Output only the title. - name: case_description type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a concise case description grounded in the OpenTelemetry evidence. Include the incident ID and say that remediation requires human approval. Output only the description. - name: create_case type: cases.createCase with: title: {{ steps.case_title.output.message }} description: {{ steps.case_description.output.message }} owner: observability severity: medium tags: - sre-control-plane - agent-builder - human-in-the-loop - opentelemetry - name: add_agent_analysis type: cases.addComment with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Agent Builder RCA and proposed action Evidence query matches: {{ steps.collect_evidence.output.hits.total.value }} {{ steps.rca_analysis.output.message }} Proposed simulated action: simulate clearing the pricing cache on checkout-worker-07. No action has run yet. Agent conversation: {{ kibanaUrl }}/app/agent_builder/conversations/{{ steps.rca_analysis.output.conversation_id }} - name: review type: waitForInput with: message: | Approve the bounded checkout response? Incident: {{ consts.incident_id }} Evidence: {{ steps.collect_evidence.output.hits.total.value }} matching checkout failure logs in the last 30 minutes. Target: checkout-worker-07 Action: simulate clearing the pricing cache on this worker only. Expected effect: subsequent checkout requests no longer use the stale cache. Blast radius: one worker. This simulated step does not change production. Review the Agent Builder analysis in case {{ steps.create_case.output.case.id }} before deciding. schema: type: object properties: approved: type: boolean title: Approve the simulated cache clear notes: type: string title: Reviewer notes required: - approved - name: approved_action type: console if: steps.review.output.approved : true with: message: Approved. Simulated cache clear recorded for checkout-worker-07. Reviewer notes: {{ steps.review.output.notes }} - name: verify_after_approval type: elasticsearch.search if: steps.review.output.approved : true with: index: logs-* size: 0 query: bool: filter: - range: timestamp: gte: now-5m - term: service.name: checkout-api - term: attributes.incident.id: {{ consts.incident_id }} - match_phrase: body.text: query: checkout failed: stale pricing cache - name: record_approved type: cases.addComment if: steps.review.output.approved : true with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Human decision: approved Reviewer notes: {{ steps.review.output.notes }} Simulated action target: checkout-worker-07 Verification query matches in the last 5 minutes: {{ steps.verify_after_approval.output.hits.total.value }} This walkthrough did not change production. - name: record_declined type: cases.addComment if: steps.review.output.approved : false with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Human decision: declined Reviewer notes: {{ steps.review.output.notes }} No action ran. - name: declined_console type: console if: steps.review.output.approved : false with: message: Declined. No action executed. Reviewer notes: {{ steps.review.output.notes }}collect_evidence和rca_analysis步骤保持了第一篇文章中相同的“先获取证据、再进行推理”的顺序并且 workflow 会在到达waitForInput边界之前将分析结果写入 case。这样当需要人工做出决定时推理结果已经被持久化并且可以进行关联。审批表单要求提供一个布尔值并接受可选的备注。只有批准分支会记录模拟的缓存清除操作、运行一个范围受限的验证查询并将结果追加到 case 中。拒绝分支只记录决定不执行任何操作。审批请求会将最终的计数带入决策而关联的 case 则保留完整的 Agent Builder 分析结果。应将这个计数视为提供给审核人员的证据而不是根本原因结论或性能指标。将模拟操作替换为实际的自动修复本实践指南将批准分支保留为一个console步骤这样你可以安全地运行两个分支。在生产环境中你只需要将这一个步骤替换为范围严格受限的外部操作而 case、超时、验证和拒绝路径则完全保持不变。根据如何访问目标系统你有两个选择。使用 HTTP connector 调用内部修复 API在 Kibana 中配置一个 HTTP connector设置基础 URL、身份验证信息以及任何加密 headers然后通过connector-id引用它。密钥保留在 connector 中永远不会出现在 workflow YAML 中。- name: clear_pricing_cache type: http connector-id: checkout-remediation-api if: steps.review.output.approved : true with: path: /v1/cache/pricing/purge method: POST body: worker: checkout-worker-07 incident_id: {{ consts.incident_id }}交给 Jira、Slack 或 PagerDutyKibana connectors 可以作为 workflow 步骤使用因此批准分支可以为需要变更管理的操作创建jira工单向值班 channel 发布消息到slack或者通过 PagerDuty 发送页面通知所有这些操作都使用团队已经集中管理的凭证。- name: notify_oncall type: slack connector-id: sre-oncall-channel if: steps.review.output.approved : true with: message: Approved by {{ steps.review.output.notes }}: pricing cache cleared on checkout-worker-07 for {{ consts.incident_id }}.无论你选择哪一种方式都要确保操作与明确的目标绑定。如何设计人在回路中的自动化审批关卡上面的 workflow 展示了具体实现方式。要正确设计这个审批关卡则是一个设计问题暂停应该放在哪里、请求应该向审核人员提供哪些信息、无人响应时应该发生什么以及执行记录必须保留哪些内容。这些问题分别对应前面提到的五种绑定。在故障事件响应 workflow 中审批步骤应该放在哪里waitForInput最适合放在第一个会增加影响范围的步骤之前。不要在收集证据之前暂停因为 workflow 通常可以在不触及受影响服务的情况下完成搜索、补充信息、分类以及创建草稿 case。也不要在修复之后暂停因为那只是让人工去确认一个已经发生的操作。在任何人启用 workflow 之前审核人员都可以检查证据查询、表单 schema、超时设置、分支条件以及具体操作。一个好的审批请求应该告诉审核人员什么值班工程师不应该需要打开另外五个界面重新还原整个调查过程。应该首先明确需要做出的决定并且只提供做出该决定所需的证据。一个好的审批请求应该按照以下顺序回答这些问题我究竟要决定什么哪些遥测数据支持这个建议操作将使用什么目标和参数预期效果和影响范围是什么如果我拒绝或什么都不做会发生什么一个必填的决定加上可选的备注通常就足够了。如果审核人员还必须输入服务名称、主机标识符、环境以及操作参数那么在暂停之前这个建议就还不够具体。暂停的执行会一直保存在历史记录中并且任何获得授权的审核人员都可以恢复执行这就带来了一个排队管理的要求。当团队中存在超过几个暂停的执行时审核人员需要一个收件箱或类似的筛选视图用于显示待处理的决定、等待时长、负责人、严重性和目标。否则一个安全的暂停机制很容易悄悄变成一个无人关注的积压队列。如果没有人在规定时间内批准会发生什么waitForInput没有默认的超时设置执行会无限期地等待。settings.timeout 字段 会限制整个执行过程包括等待输入所花费的时间。在这个 workflow 中30 分钟的设置限制了证据收集完成后该建议保持可执行状态的最长时间。应根据故障事件和操作本身来选择这个值在正在发生的服务中断期间进行流量切换可能需要在几分钟内做出决定。而维护审批可能在数小时内都保持有效。请在你实际运行的 Elastic 版本上确认超时行为如果实际观察到的行为不符合你的“默认拒绝”要求请增加外部升级或取消路径。无论如何都不要将沉默视为批准。审计记录必须记录什么执行历史应该能够回答以下四个问题而无需任何人翻阅聊天记录workflow 收集了哪些证据审核人员提交了什么确切的输入哪个分支被执行了操作和验证步骤返回了什么结果暂停的执行会显示证据步骤而决定仍处于待处理状态。获得批准的执行会在同一个视图中增加操作分支和验证输出。被拒绝的执行会保留相同的证据和相同的决定同时跳过所有操作步骤。让实践指南中的操作保持为模拟操作可以让你检查两个分支而不会改变生产环境。对于生命周期更长的故障事件上下文可以将其写入 case。将证据摘要、审核人员备注、操作结果和验证结果作为评论添加进去这样 case 就会成为一个比执行本身生命周期更长的持久记录。如何判断 workflow 已经可以在无需审批的情况下运行不要因为少数几次运行成功就移除审批关卡。你应该检查足够多的执行以了解正常路径和异常路径并至少衡量以下结果衡量指标它回答的问题建议接受率workflow 能否识别正确的故障事件类别审核人员修改或拒绝的比例哪些证据或操作参数仍然存在问题审批等待时间团队能否在证据过期之前做出响应操作成功率范围受限的操作能否可靠执行验证成功率操作之后服务是否得到改善回滚率响应操作有多少次导致了新的问题只有当故障事件类别、目标选择、操作、验证、权限、超时和回滚路径都足够明确且可重复时才适合进行自主执行。即使如此也应该保留相同的 workflow 结构。自动化应该绕过经过验证路径中的人工等待而不是绕过证据收集、授权、验证或审计记录。任何不确定的情况都应该重新交给人工审核。总结审批关卡只需要少量 YAML但它会改变自动化的性质。waitForInput将决定转换为分支逻辑所依赖的结构化输入因此操作、验证和 case 评论之所以存在都是因为一个明确的人在特定时间回答了一个具体的问题。在第一个会增加影响范围的步骤之前立即暂停并通过settings.timeout设置上限这才使它成为一种可靠性控制机制而不仅仅是一个确认对话框。将其投入生产环境的改动比看起来要小将模拟的console步骤替换为http、slack或jiraconnector 步骤其余部分保持不变。从这里开始你可以一次针对一个故障事件类别逐步获得自主性让接受率、审批等待时间、操作成功率、验证成功率和回滚率告诉你某条路径何时已经经过充分验证可以在无需等待人工审批的情况下运行。从哪里开始使用人在回路中的自动化从一个重复出现的运营信号和一个可逆的响应操作开始。首先构建证据查询然后添加一个明确指定目标和预期效果的建议接着在操作之前立即插入waitForInput并在实验环境或仅操作 case 的模式下运行 workflow。与 SRE、开发人员、支持团队、安全团队以及受影响服务的产品负责人一起检查执行历史。审批关卡不是终点。它是一种机制让团队能够在不放弃证据、责任追踪或控制权的情况下逐步迈向范围受限的自主性。人在回路中的 workflow 指南waitForInput流程控制参考外部系统和应用步骤Kibana connectors 参考Workflow 监控指南原文Human-in-the-loop automation for SRE incident response | Elastic Observability Labs 从建议到修复的 4 个阶段：使用 Elastic Workflows 实现人在回路中的自动化
作者来自 Elastic Jeffrey Rengifo一个审批关卡会在执行操作之前暂停故障事件响应自动化并为审核人员提供足够的证据让其能够在几秒钟内做出决定。无论后续结果是批准还是拒绝都会记录在一个可审计的记录中。没有证据支撑的 “批准” 按钮并不能算作一种控制手段。人在回路中自动化会将五件事情绑定到一个可检查的记录中你观察到的证据、你提出的操作、做出决定的人、他们拥有的截止时间以及实际执行的操作。在本文中你将使用 Elastic Workflows 构建这个审批关卡并复用配套文章 使用 Agent Builder 和 Workflows 构建 SRE 控制平面 中的控制平面。这一次故障事件足够明确可以采取行动单个 worker 上存在过期的定价缓存并在建议和修复之间设置一个结构化的审批步骤。这里的任何操作都不会触及生产环境因此你可以分别运行批准分支和拒绝分支然后比较每个分支在执行记录中留下的内容。正是通过这份记录故障事件响应自动化才能一次针对一个故障事件类别逐步获得自主性。前提条件Elastic Stack 9.4在添加审批之前SRE 控制平面需要什么本文基于使用 Agent Builder 和 Workflows 构建 SRE 控制平面该文章定义了这里使用的控制平面模式将遥测数据、调查上下文、策略以及一组已知操作连接在一起。Agent Builder 对日志、追踪、指标、警报、运行手册和之前的故障事件案例进行推理。Elastic Workflows 按照定义好的序列执行操作并使用明确的输入和权限。人在回路中即 HITL则在证据转化为操作的关键节点将这两项职责连接起来。建议和修复具有完全不同的故障模式。糟糕的建议只是浪费工程师的时间而糟糕的修复则会改变生产环境。这就是为什么审批关卡应该属于执行模型的一部分。使审批关卡成为可靠性控制机制的五种绑定一个有用的审批关卡需要保留五种属性。缺少其中任何一种审批关卡都会变得更弱。证据绑定审核人员能够看到生成该建议所依据的日志、警报详细信息、补充信息或 agent 推理过程。没有证据的“批准”按钮只是在要求一个人接受自动化系统的判断。操作绑定请求需要明确说明具体且范围受限的操作、目标、参数和预期效果。没有明确目标的请求可能会授权执行远超审核人员预期的操作。身份绑定记录会显示谁批准或拒绝了该请求以及做出决定的时间。没有这些信息你只能知道结果却没有责任归属。时间绑定决策具有截止时间过期的请求会默认失败而不是在失去上下文后继续执行。没有超时机制的审批请求其生命周期可能超过当初证明该操作合理的故障事件证据。结果绑定执行记录会显示实际执行了什么、跳过了什么以及操作后的验证是否通过。表单仍然很重要但表单只是一个更大控制机制中面向人工的部分。审批设计本身就是可靠性工程。从 AI 建议到自动修复的四个阶段应将自主性视为一系列运营状态而不是一个产品开关。自主性阶段系统行为人工职责晋级依据0. 观察搜索日志并收集上下文。人工调查并采取操作。查询能够找到正确的故障事件证据。1. 建议提出一个范围受限的下一步操作并提供理由。决定是否执行并在 workflow 外部执行。建议足够准确可以快速审核。2. 审批在执行操作前暂停并且只有获得结构化输入后才继续执行。批准或拒绝明确的操作建议。对审批质量、执行成功率和回滚行为进行衡量。3. 有限范围自动化针对经过验证的故障事件类别自动执行相同的操作。审核异常情况并审计样本。仍然强制执行范围限制、权限、超时、验证和回滚。最重要的转换是从阶段 1 到阶段 2。正是在这里系统不再只是一个顾问而是获得了执行路径。即使 AI agent 参与了调查这条路径也应该是确定性的agent 负责总结证据并建议操作而 workflow 负责暂停、结构化决策、分支处理和执行记录。在 Elastic Workflows 中构建人在回路中的自动化审批关卡Elastic Workflows 为此提供了 waitForInput step。当执行到达该步骤时workflow 会停止在WAITING_FOR_INPUT状态并等待人工输入。审核人员可以在 Kibana execution view 中填写一个简单的表单或通过 resume API 提交提交的内容随后可以通过steps.step_name.output供后续步骤使用。该 workflow 会获取过去 30 分钟checkout-api的失败日志将这些日志交给 Agent Builder 进行根本原因分析并将分析结果写入一个 Observability case。然后它会暂停并提出一个问题是否应该清除checkout-worker-07上的定价缓存如果你批准workflow 会记录模拟操作运行验证查询并将结果追加到 case 中。如果你拒绝它会记录该决定并且不会执行任何操作。无论哪种情况都不会触及生产环境。name: obs-labs-checkout-control-plane-hitl description: Human approval gate for the OpenTelemetry-grounded checkout control plane. enabled: false tags: - sre-control-plane - agent-builder - human-in-the-loop - workflows - opentelemetry settings: timeout: 30m triggers: - type: manual consts: incident_id: obs-labs-checkout-hitl-20260719 steps: - name: collect_evidence type: elasticsearch.search with: index: logs-* size: 10 query: bool: filter: - range: timestamp: gte: now-30m - term: service.name: checkout-api - term: attributes.incident.id: {{ consts.incident_id }} - match_phrase: body.text: query: checkout failed: stale pricing cache - name: rca_analysis type: ai.agent agent-id: elastic-ai-agent create-conversation: true with: message: | Investigate the checkout-api incident identified by {{ consts.incident_id }}. The workflow evidence query found {{ steps.collect_evidence.output.hits.total.value }} matching OpenTelemetry log events in the last 30 minutes. Search logs, traces, and metrics for service.name checkout-api and incident.id {{ consts.incident_id }}. Identify the affected worker, deployment version, error type, HTTP status, and latency evidence. Return the likely cause, supporting evidence, confidence, and whether the bounded simulated action below is consistent with the evidence. Proposed simulated action: simulate clearing the pricing cache on checkout-worker-07. This workflow must not change production. - name: case_title type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a short case title for this checkout incident. Output only the title. - name: case_description type: ai.agent agent-id: elastic-ai-agent with: conversation_id: {{ steps.rca_analysis.output.conversation_id }} message: Produce a concise case description grounded in the OpenTelemetry evidence. Include the incident ID and say that remediation requires human approval. Output only the description. - name: create_case type: cases.createCase with: title: {{ steps.case_title.output.message }} description: {{ steps.case_description.output.message }} owner: observability severity: medium tags: - sre-control-plane - agent-builder - human-in-the-loop - opentelemetry - name: add_agent_analysis type: cases.addComment with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Agent Builder RCA and proposed action Evidence query matches: {{ steps.collect_evidence.output.hits.total.value }} {{ steps.rca_analysis.output.message }} Proposed simulated action: simulate clearing the pricing cache on checkout-worker-07. No action has run yet. Agent conversation: {{ kibanaUrl }}/app/agent_builder/conversations/{{ steps.rca_analysis.output.conversation_id }} - name: review type: waitForInput with: message: | Approve the bounded checkout response? Incident: {{ consts.incident_id }} Evidence: {{ steps.collect_evidence.output.hits.total.value }} matching checkout failure logs in the last 30 minutes. Target: checkout-worker-07 Action: simulate clearing the pricing cache on this worker only. Expected effect: subsequent checkout requests no longer use the stale cache. Blast radius: one worker. This simulated step does not change production. Review the Agent Builder analysis in case {{ steps.create_case.output.case.id }} before deciding. schema: type: object properties: approved: type: boolean title: Approve the simulated cache clear notes: type: string title: Reviewer notes required: - approved - name: approved_action type: console if: steps.review.output.approved : true with: message: Approved. Simulated cache clear recorded for checkout-worker-07. Reviewer notes: {{ steps.review.output.notes }} - name: verify_after_approval type: elasticsearch.search if: steps.review.output.approved : true with: index: logs-* size: 0 query: bool: filter: - range: timestamp: gte: now-5m - term: service.name: checkout-api - term: attributes.incident.id: {{ consts.incident_id }} - match_phrase: body.text: query: checkout failed: stale pricing cache - name: record_approved type: cases.addComment if: steps.review.output.approved : true with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Human decision: approved Reviewer notes: {{ steps.review.output.notes }} Simulated action target: checkout-worker-07 Verification query matches in the last 5 minutes: {{ steps.verify_after_approval.output.hits.total.value }} This walkthrough did not change production. - name: record_declined type: cases.addComment if: steps.review.output.approved : false with: case_id: {{ steps.create_case.output.case.id }} comment: | ## Human decision: declined Reviewer notes: {{ steps.review.output.notes }} No action ran. - name: declined_console type: console if: steps.review.output.approved : false with: message: Declined. No action executed. Reviewer notes: {{ steps.review.output.notes }}collect_evidence和rca_analysis步骤保持了第一篇文章中相同的“先获取证据、再进行推理”的顺序并且 workflow 会在到达waitForInput边界之前将分析结果写入 case。这样当需要人工做出决定时推理结果已经被持久化并且可以进行关联。审批表单要求提供一个布尔值并接受可选的备注。只有批准分支会记录模拟的缓存清除操作、运行一个范围受限的验证查询并将结果追加到 case 中。拒绝分支只记录决定不执行任何操作。审批请求会将最终的计数带入决策而关联的 case 则保留完整的 Agent Builder 分析结果。应将这个计数视为提供给审核人员的证据而不是根本原因结论或性能指标。将模拟操作替换为实际的自动修复本实践指南将批准分支保留为一个console步骤这样你可以安全地运行两个分支。在生产环境中你只需要将这一个步骤替换为范围严格受限的外部操作而 case、超时、验证和拒绝路径则完全保持不变。根据如何访问目标系统你有两个选择。使用 HTTP connector 调用内部修复 API在 Kibana 中配置一个 HTTP connector设置基础 URL、身份验证信息以及任何加密 headers然后通过connector-id引用它。密钥保留在 connector 中永远不会出现在 workflow YAML 中。- name: clear_pricing_cache type: http connector-id: checkout-remediation-api if: steps.review.output.approved : true with: path: /v1/cache/pricing/purge method: POST body: worker: checkout-worker-07 incident_id: {{ consts.incident_id }}交给 Jira、Slack 或 PagerDutyKibana connectors 可以作为 workflow 步骤使用因此批准分支可以为需要变更管理的操作创建jira工单向值班 channel 发布消息到slack或者通过 PagerDuty 发送页面通知所有这些操作都使用团队已经集中管理的凭证。- name: notify_oncall type: slack connector-id: sre-oncall-channel if: steps.review.output.approved : true with: message: Approved by {{ steps.review.output.notes }}: pricing cache cleared on checkout-worker-07 for {{ consts.incident_id }}.无论你选择哪一种方式都要确保操作与明确的目标绑定。如何设计人在回路中的自动化审批关卡上面的 workflow 展示了具体实现方式。要正确设计这个审批关卡则是一个设计问题暂停应该放在哪里、请求应该向审核人员提供哪些信息、无人响应时应该发生什么以及执行记录必须保留哪些内容。这些问题分别对应前面提到的五种绑定。在故障事件响应 workflow 中审批步骤应该放在哪里waitForInput最适合放在第一个会增加影响范围的步骤之前。不要在收集证据之前暂停因为 workflow 通常可以在不触及受影响服务的情况下完成搜索、补充信息、分类以及创建草稿 case。也不要在修复之后暂停因为那只是让人工去确认一个已经发生的操作。在任何人启用 workflow 之前审核人员都可以检查证据查询、表单 schema、超时设置、分支条件以及具体操作。一个好的审批请求应该告诉审核人员什么值班工程师不应该需要打开另外五个界面重新还原整个调查过程。应该首先明确需要做出的决定并且只提供做出该决定所需的证据。一个好的审批请求应该按照以下顺序回答这些问题我究竟要决定什么哪些遥测数据支持这个建议操作将使用什么目标和参数预期效果和影响范围是什么如果我拒绝或什么都不做会发生什么一个必填的决定加上可选的备注通常就足够了。如果审核人员还必须输入服务名称、主机标识符、环境以及操作参数那么在暂停之前这个建议就还不够具体。暂停的执行会一直保存在历史记录中并且任何获得授权的审核人员都可以恢复执行这就带来了一个排队管理的要求。当团队中存在超过几个暂停的执行时审核人员需要一个收件箱或类似的筛选视图用于显示待处理的决定、等待时长、负责人、严重性和目标。否则一个安全的暂停机制很容易悄悄变成一个无人关注的积压队列。如果没有人在规定时间内批准会发生什么waitForInput没有默认的超时设置执行会无限期地等待。settings.timeout 字段 会限制整个执行过程包括等待输入所花费的时间。在这个 workflow 中30 分钟的设置限制了证据收集完成后该建议保持可执行状态的最长时间。应根据故障事件和操作本身来选择这个值在正在发生的服务中断期间进行流量切换可能需要在几分钟内做出决定。而维护审批可能在数小时内都保持有效。请在你实际运行的 Elastic 版本上确认超时行为如果实际观察到的行为不符合你的“默认拒绝”要求请增加外部升级或取消路径。无论如何都不要将沉默视为批准。审计记录必须记录什么执行历史应该能够回答以下四个问题而无需任何人翻阅聊天记录workflow 收集了哪些证据审核人员提交了什么确切的输入哪个分支被执行了操作和验证步骤返回了什么结果暂停的执行会显示证据步骤而决定仍处于待处理状态。获得批准的执行会在同一个视图中增加操作分支和验证输出。被拒绝的执行会保留相同的证据和相同的决定同时跳过所有操作步骤。让实践指南中的操作保持为模拟操作可以让你检查两个分支而不会改变生产环境。对于生命周期更长的故障事件上下文可以将其写入 case。将证据摘要、审核人员备注、操作结果和验证结果作为评论添加进去这样 case 就会成为一个比执行本身生命周期更长的持久记录。如何判断 workflow 已经可以在无需审批的情况下运行不要因为少数几次运行成功就移除审批关卡。你应该检查足够多的执行以了解正常路径和异常路径并至少衡量以下结果衡量指标它回答的问题建议接受率workflow 能否识别正确的故障事件类别审核人员修改或拒绝的比例哪些证据或操作参数仍然存在问题审批等待时间团队能否在证据过期之前做出响应操作成功率范围受限的操作能否可靠执行验证成功率操作之后服务是否得到改善回滚率响应操作有多少次导致了新的问题只有当故障事件类别、目标选择、操作、验证、权限、超时和回滚路径都足够明确且可重复时才适合进行自主执行。即使如此也应该保留相同的 workflow 结构。自动化应该绕过经过验证路径中的人工等待而不是绕过证据收集、授权、验证或审计记录。任何不确定的情况都应该重新交给人工审核。总结审批关卡只需要少量 YAML但它会改变自动化的性质。waitForInput将决定转换为分支逻辑所依赖的结构化输入因此操作、验证和 case 评论之所以存在都是因为一个明确的人在特定时间回答了一个具体的问题。在第一个会增加影响范围的步骤之前立即暂停并通过settings.timeout设置上限这才使它成为一种可靠性控制机制而不仅仅是一个确认对话框。将其投入生产环境的改动比看起来要小将模拟的console步骤替换为http、slack或jiraconnector 步骤其余部分保持不变。从这里开始你可以一次针对一个故障事件类别逐步获得自主性让接受率、审批等待时间、操作成功率、验证成功率和回滚率告诉你某条路径何时已经经过充分验证可以在无需等待人工审批的情况下运行。从哪里开始使用人在回路中的自动化从一个重复出现的运营信号和一个可逆的响应操作开始。首先构建证据查询然后添加一个明确指定目标和预期效果的建议接着在操作之前立即插入waitForInput并在实验环境或仅操作 case 的模式下运行 workflow。与 SRE、开发人员、支持团队、安全团队以及受影响服务的产品负责人一起检查执行历史。审批关卡不是终点。它是一种机制让团队能够在不放弃证据、责任追踪或控制权的情况下逐步迈向范围受限的自主性。人在回路中的 workflow 指南waitForInput流程控制参考外部系统和应用步骤Kibana connectors 参考Workflow 监控指南原文Human-in-the-loop automation for SRE incident response | Elastic Observability Labs