运营和→管理AI操作员助理

操作员的AI助手

1）为什么需要它

运算符沉没在Alert，Logs和分散的人工制品中。AI助手将异构信号转换为易于理解的推荐和现成的动作：三合会更快，手动例程更少，SLO的可预测性更高。

• 降低MTTD/MTTR和Alert噪音。
• 提高风险管理和事后文件的质量。
• 自动化"繁重例程"（搜索上下文、摘要、字幕）。
• 提交统一的响应/通信标准。

2）应用方桉（Top-12）

1.事件三重性：分组Alert →原因假设→优先级/影响。
2.动作指南（Action Hints）："现在该怎么做"（runbook链接和启动按钮）。
3.自动摘要（Incident TL；DR）：事件通道/堆积器的简短挤压。
4.知识搜索（RAG）：对runbook/SOP/后验表/升级矩阵的快速响应。
5.Ticket/Update生成：Jira/Status Update草稿按模板。
6.Alert分析：识别"嘈杂规则"，调音建议。
7.Observability Q&A："在1小时内显示p99 bets-api" →完成的图形/查询。
8.供应商上下文：供应商摘要（配额，SLA，窗口，事件）。

9.谓词提示： "burn-rate↑+lag↑ →准备一个PSP feilover。"

10.Handover Copilot：从dashbords/tiket收集更换包。
11.Postmortem Copilot：来自log/treds的年表+Corrective/Preventive Actions草稿。
12.消息本地化/音调：正确、一致的客户端升级。

3）解决方桉架构（高级）

资料来源：度量/logi/traces（观察力），滴答声/事件，configi/ficheflagi，提供者状态，SLO/OLA目录，runbook/SOP。
RAG层（知识搜索）：标记文档索引（域、版本、日期、所有者）。Vyuhi"用于操作员"。
工具（工具/行动）：安全操作："scale-up HPA"，"暂停金丝雀"，"启用安全模式"，"切换PSP"，"创建滴答声"，"组装图形"。所有活动均通过经纪人/编曲员进行审核。
Policy-guardrails：角色权利，HITL确认，限制，干跑（干跑），日志。
安全性：KMS/Secrets，PII掩码，mTLS，数据访问审核。
接口：NOC中的聊天/面板，dashbords中的小部件，slack slash命令。

4）UX模式（操作员可以看到）

事件卡： "症状→假设（排名）→ 3个建议的步骤→指向数据→动作按钮。"

单个prompt字段： "在Payments的最后4小时内形成一个包裹。"

放心/来源突出显示："基于：Grafana，Postgres logs，Runbook v3"。
"Dry-Run"按钮：显示将做什么以及风险在哪里。
决策历史：谁确认了步骤，结果，回滚/成功。

5）集成和操作（examples）

Observability：现成的PromQL/LogsQL/Trace过滤器,按下图形。
Feature Flags：启用安全模式/回滚标志（带确认）。
Release-canareica：暂停/回滚；将注释添加到图形。
K8s：HPA提前，可重启，PDB/Spread检查。
提供商：将PSP-X → PSP-Y路由切换；配额检查。
通讯：升级到事件通道/状态页的草稿。
Tickets：创建带有预填充部分的Jira。

6）安全和隐私政策

按角色/域进行访问：操作员仅看到"自己的"系统和最低限度的足够数据。
行动日志：谁/何时确认，结果，回滚。
PII/秘密：在答复/记录中伪装；无法获得"原始"秘密。
内容存储：带有TTL和标签的检索工件（RAG）版本。
禁止"推理"作为人工制品：我们保留结论和对来源的引用，而不是模型的内部反思。
供应商边界：离开周边的数据的清晰列表（默认为零）。

7）质量与绩效指标

• MTTD/MTTR ↓, Pre-Incident Detect Rate ↑, Change Failure Rate ↓, Handoff Quality Score ↑.
• 警报Fatigue ↓（每个操作员/班次的变量），直到第一个更新↓。

AI-KPI:

接受率（接受建议），时间保存/案例，按类（例如P1）进行精制/恢复，万事达率（无源错误陈述），安全事件=0。

• Recall(P1) ≥ 0.7, Precision ≥ 0.6, Acceptance ≥ 0.5、Time Saved ≥ 25%，Hallucination ≤ 2%，强制参考来源。

8）Prompt工程和知识管理

查询模板：标准化表述（以下为示例）。
上下文层：（a）系统规则（安全性、响应样式）、（b）轮换/域的简短上下文,（b）根据最新文档/图表搜索RAG。
知识验证：每个runbook/SOP都有'id@version'和日期，AI提供链接和版本。
确认答复：我们要求为所有实际指控提供数据来源/dashborda的链接。

Triage:
"You are an SRE operator. Based on [Grafana: payments, Logs:psp_x, Incidents: last 24h]
group alerts into 3-5 hypotheses with probability, effect on SLO, and brief validation steps.
Answer: hypothesis cards + links"

Handover:
"Collect handover packet in last 4h for Payments domain:
SLO, incidents (ETA), releases/canaries, providers/quotas, risks/observations, action items.
Add links to panels and tickets"

9）嵌入过程（SOP）

事件：AI发布TL；DR每N分钟，准备下一个ETA，提供步骤。
发行版本：前期和后期摘要；在谓词风险下自动驾驶。
班次：打包成型，通过支票单验证。
Postmortems：时间线草稿+Corrective/Preventive Actions列表。
报告：为期一周的噪音和调音建议摘要。

10）Dashbords和Widgets（最低）

AI Ops Overview：接受的建议、节省的时间、成功/回滚行动。
Triaging Quality：按年级、有争议的桉例、顶级错误。
知识健康：runbook/SOP覆盖范围，过时版本，空白。
警报Hygiene：噪音源，调音候选规则。
Safety&Audit：操作日志、失败尝试、干运行报告。

11）反模式

"魔术盒将决定一切"-没有RAG和链接，带有"猜测"事实。
在没有HITL/角色/限制的情况下自动执行不可逆转的活动。
在搜索中混合散文/堆栈文物。
响应和助手日志中的秘密/PII。
缺乏质量指标和后期效益评估。
"对所有任务进行一次聊天"-没有卡，状态和动作按钮。

12）实施支票

• 定义了域和脚本（triage,摘要,handover, tikets）。
• 配置了RAG： runbook/SOP/后验表/升级矩阵索引（带版本）。
• 集成：Observability, Flags, Release, Tickets, Providers-通过安全工具。
• 政治：角色，HITL，杂志，干跑，伪装PII/秘密。
• UX：事件卡、动作按钮、信心和链接。
• 度量标准：AI-KPI和Ops-KPI+dashbords。
• 过程：涉及AI的事件/释放/轮班/验尸的SOP。
• 操作员培训计划以及与助手的"沟通规则"。

13）"安全"自动辅助示例

TL出版；DR/ETA进入事件频道。
创建/更新tiket,绑定工件。
生成/开始读取指标和逻辑（不更改系统）。
图表上的版本/标志注释。
准备干跑花花公子（确认后将完成）。

14）角色和责任

Ops Owner：业务结果（MTTR,噪音）,SOP批准。
Observability/SRE：RAG，集成，安全性和质量指标。
域领导：建议的验证，运行手册/SOP的相关性。
培训/实施：提倡操作员，"如何与AI沟通"，考试。
Compliance/Security：数据策略、审核和日志存储。

15）30/60/90-启动计划

• 一个域上的飞行员（例如Payments）：三合会，TL；DR，滴答作响。
• 知识索引（RAG）和事件卡，干跑动作。
• 基本指标：Acceptance/Time Saved/Precision/Recall。

• 添加handover/postmortem copilot,与Flags/Release集成。
• 包括谓词提示（burn-rate，lag）和alerts调谐子句。
• 使用助手进行两个游戏日。

• 扩展到Bets/Games/KYC，统一模式。
• 将SOP与AI正式化，将KPI引入季度目标。
• 优化经济影响（成本/事件，减少加班时间）。

16）助手答复示例（格式）

Symptom: p99 payments-api ↑ up to 420 ms (+ 35%) in 15 minutes
Hypotheses:
1) PSP-X timeouts (probable 0. 62) - outbound_error_rate growth, quota 88%
2) DB-connections (0. 22) — active/max=0. 82
3) Cash evikshens (0. 16) — evictions>0
Steps:
[Open PSP-X panel] [Check quota] [Enable safe-mode deposit]
[Payments-api canary pause]
References: Grafana (payments p99), Logs (psp-x), Runbook v3

SLO OK/Degraded, incidents: INC-457 ETA 18:30, canary bets-api 10%, PSP-X quota 85%.
Action items: @ squad-payments check out the feilover before 7 p.m.

Impact: deposit conversion − 3. 2% at 5pm-5.25pm
Timeline: 16:58 alert p99; 17:04 canary pause; 17:08 PSP- X→Y
Root cause: slow PSP-X responses when 90% quota is reached
Actions now: breaker tuning, auto-predictor quota> 0. 85, alert hygiene

17) FAQ

问：首先自动化是什么？
答：摘要/提要/知识搜索-安全且立即节省时间。然后是HITL的谓词提示和半自动动作。

问：如何对抗"幻觉"？
答：只有RAG，只有链接响应，禁止无源响应，离线质量评估，有争议的响应标记和分解为复古。

Q：助手有权"咀嚼按钮"吗？
答：是的-用于可逆和低风险步骤（注释，摘要，干跑，预赛），其余的则通过HITL和角色。