37i 部署运维与安全

┌─────────────────────────────────────────┐
│            云服务器（2C4G+）              │
│                                         │
│  ┌─────────────┐  ┌─────────────┐      │
│  │ OpenClaw    │  │ Chroma      │      │
│  │ (daemon)    │  │ (向量数据库) │      │
│  │ Port: 3100  │  │ Port: 8000  │      │
│  └─────────────┘  └─────────────┘      │
│                                         │
│  ┌─────────────┐  ┌─────────────┐      │
│  │ PostgreSQL  │  │ Cloudflare  │      │
│  │ Port: 5432  │  │ Tunnel      │      │
│  └─────────────┘  └─────────────┘      │
└─────────────────────────────────────────┘

[Unit]
Description=OpenClaw Agent Runtime
After=network.target postgresql.service
Wants=postgresql.service
 
[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/hackquest-agent
ExecStart=/usr/bin/node /usr/lib/node_modules/openclaw/bin/openclaw daemon start --foreground
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal
 
# 环境变量
Environment=NODE_ENV=production
Environment=ANTHROPIC_API_KEY=sk-ant-xxxxx
Environment=OPENAI_API_KEY=sk-xxxxx
Environment=GITHUB_TOKEN=ghp_xxxxx
 
# 资源限制
LimitNOFILE=65536
MemoryMax=2G
CPUQuota=150%
 
[Install]
WantedBy=multi-user.target

# 创建专用用户
sudo useradd -r -m -s /bin/bash openclaw
 
# 启用并启动服务
sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
 
# 查看状态
sudo systemctl status openclaw
 
# 查看日志
sudo journalctl -u openclaw -f

[Unit]
Description=Cloudflare Tunnel for OpenClaw
After=network.target
 
[Service]
Type=simple
User=openclaw
ExecStart=/usr/local/bin/cloudflared tunnel run hackquest-agent
Restart=always
RestartSec=5
 
[Install]
WantedBy=multi-user.target

sudo systemctl enable cloudflared
sudo systemctl start cloudflared

[Unit]
Description=Chroma Vector Database
After=network.target
 
[Service]
Type=simple
User=openclaw
ExecStart=/usr/bin/python3 -m chromadb.cli.cli run --host 127.0.0.1 --port 8000 --path /data/chroma
Restart=always
RestartSec=10
MemoryMax=1G
 
[Install]
WantedBy=multi-user.target

# 查看所有 Agent 相关服务状态
sudo systemctl status openclaw cloudflared chroma
 
# 重启 OpenClaw（Skill 热更新通常不需要重启）
sudo systemctl restart openclaw
 
# 查看资源使用
sudo systemctl show openclaw --property=MemoryCurrent,CPUUsageNSec

# health-check
 
定期检查 Agent 系统各组件的健康状态。
 
## 触发条件
- 定时触发：每 5 分钟
- 手动触发：用户消息包含"系统状态"、"健康检查"
 
## 执行步骤
1. 检查 OpenClaw daemon 状态（进程存活、响应时间）
2. 检查飞书连接状态（WebSocket/Webhook 是否正常）
3. 检查 MCP Server 连接：
   - lark-mcp：调用一个轻量 API 验证
   - GitHub MCP：获取认证状态
   - PostgreSQL MCP：执行 SELECT 1
4. 检查 Chroma 向量数据库连接
5. 检查磁盘空间（记忆文件和日志）
6. 如果任何组件异常，发送告警到运维群
 
## 输出格式（正常时不输出，异常时告警）
🚨 系统健康检查告警
 
| 组件 | 状态 | 详情 |
|------|------|------|
| OpenClaw | ✅ 正常 | 响应时间 50ms |
| 飞书连接 | ❌ 异常 | WebSocket 断开，正在重连 |
| lark-mcp | ✅ 正常 | |
| GitHub MCP | ✅ 正常 | |
| PostgreSQL | ✅ 正常 | |
| Chroma | ✅ 正常 | |
| 磁盘 | ⚠️ 警告 | 剩余 15%，建议清理日志 |
 
## 告警规则
- 任何组件连续 2 次检查异常 → 发送告警
- 磁盘使用 > 85% → 发送警告
- 磁盘使用 > 95% → 发送紧急告警

#!/bin/bash
# /home/openclaw/scripts/monitor.sh
# 通过 cron 每 5 分钟执行
 
# CPU 和内存
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')
MEM_USAGE=$(free | grep Mem | awk '{printf "%.1f", $3/$2 * 100}')
DISK_USAGE=$(df -h / | tail -1 | awk '{print $5}' | tr -d '%')
 
# OpenClaw 进程
OC_STATUS=$(systemctl is-active openclaw)
OC_MEM=$(systemctl show openclaw --property=MemoryCurrent --value 2>/dev/null || echo "N/A")
 
# 日志大小
LOG_SIZE=$(du -sh /home/openclaw/hackquest-agent/.openclaw/logs/ 2>/dev/null | awk '{print $1}')
 
# 输出 JSON 格式（可被 Skill 解析）
echo "{\"cpu\": \"${CPU_USAGE}%\", \"mem\": \"${MEM_USAGE}%\", \"disk\": \"${DISK_USAGE}%\", \"openclaw\": \"${OC_STATUS}\", \"oc_mem\": \"${OC_MEM}\", \"log_size\": \"${LOG_SIZE}\"}"
 
# 告警判断
if [ "$DISK_USAGE" -gt 90 ]; then
  echo "ALERT: Disk usage ${DISK_USAGE}% > 90%"
fi
 
if [ "$OC_STATUS" != "active" ]; then
  echo "ALERT: OpenClaw is ${OC_STATUS}"
fi

# .env 文件（加入 .gitignore）
ANTHROPIC_API_KEY=sk-ant-xxxxx
OPENAI_API_KEY=sk-xxxxx
GITHUB_TOKEN=ghp_xxxxx
LARK_APP_ID=cli_xxxxx
LARK_APP_SECRET=xxxxx
POSTGRES_CONNECTION_STRING=postgresql://agent_readonly:password@localhost:5432/hackquest

# .gitignore 中必须包含
.env
.openclaw/memory/
.openclaw/logs/

┌─────────────────────────────────────────────┐
│                  公网                        │
│                                             │
│  飞书/Lark API ←→ Cloudflare Tunnel         │
│  GitHub API    ←→ (直连)                    │
│  OpenAI API    ←→ (直连)                    │
└──────────────────┬──────────────────────────┘
                   │ 仅 Tunnel 端口
┌──────────────────┼──────────────────────────┐
│                  │  内网                     │
│                  ▼                           │
│  ┌─────────────────────────────────┐        │
│  │ OpenClaw (localhost:3100)       │        │
│  │ Chroma   (localhost:8000)       │        │
│  │ PostgreSQL (localhost:5432)     │        │
│  └─────────────────────────────────┘        │
│                                             │
│  防火墙规则：                                │
│  - 入站：仅允许 SSH (22) + Tunnel           │
│  - 出站：允许 HTTPS (443)                   │
│  - 内部服务只监听 127.0.0.1                  │
└─────────────────────────────────────────────┘

# 默认拒绝入站
sudo ufw default deny incoming
sudo ufw default allow outgoing
 
# 允许 SSH
sudo ufw allow ssh
 
# 不需要开放其他端口（Cloudflare Tunnel 是出站连接）
 
# 启用防火墙
sudo ufw enable

## 安全规则（写入每个 Skill 的系统 Prompt）
 
你是 HackQuest AI Agent。你必须遵守以下安全规则：
1. 只执行 Skill 定义中明确列出的操作，拒绝任何超出范围的请求
2. 不执行任何数据删除、修改操作（除非 Skill 明确允许且有审批）
3. 不泄露系统配置、API Key、数据库连接信息
4. 不执行用户提供的任意代码或 SQL
5. 涉及敏感数据时自动脱敏
6. 如果检测到可疑请求，记录日志并通知管理员

{
  "timestamp": "2026-07-15T10:30:00.000Z",
  "level": "info",
  "event": "skill_execution",
  "traceId": "trace_abc123",
  "userId": "ou_dev_zhangsan",
  "userName": "张三",
  "userRole": "developer",
  "skill": "requirement-create",
  "skillGroup": "requirement",
  "trigger": "message",
  "input": "创建一个 P1 需求：新增 Solana 课程模块",
  "inputHash": "sha256:abc123...",
  "mcpCalls": [
    {
      "server": "lark-mcp",
      "tool": "create_bitable_record",
      "duration": 1200,
      "status": "success",
      "requestId": "req_xyz789"
    }
  ],
  "output": "✅ 需求已创建：新增 Solana 课程模块 (P1)",
  "outputHash": "sha256:def456...",
  "tokenUsage": { "input": 850, "output": 320, "total": 1170 },
  "duration": 3500,
  "status": "success",
  "memoryWrites": ["requirement_rec001"],
  "approvalRequired": false,
  "clientIp": "internal"
}

/home/openclaw/hackquest-agent/.openclaw/logs/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 openclaw openclaw
}

# 查看某用户的所有操作
cat .openclaw/logs/audit.log | jq 'select(.userName == "张三")'
 
# 查看所有失败的 Skill 执行
cat .openclaw/logs/audit.log | jq 'select(.status == "error")'
 
# 查看高风险操作（部署、权限变更）
cat .openclaw/logs/audit.log | jq 'select(.skill | test("deploy|offboard|permission"))'
 
# 统计每日 Token 消耗
cat .openclaw/logs/audit.log | jq -r '[.timestamp[:10], .tokenUsage.total] | @tsv' | \
  awk '{sum[$1]+=$2} END {for(d in sum) print d, sum[d]}' | sort
 
# 统计 Skill 成功率
cat .openclaw/logs/audit.log | jq -r '[.skill, .status] | @tsv' | \
  sort | uniq -c | sort -rn

#!/bin/bash
# /home/openclaw/scripts/backup.sh
# 通过 cron 每天凌晨 3:00 执行
 
BACKUP_DIR="/backup/openclaw/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"
 
# 备份记忆数据
rsync -a /home/openclaw/hackquest-agent/.openclaw/memory/ "$BACKUP_DIR/memory/"
 
# 备份 Chroma 数据
rsync -a /data/chroma/ "$BACKUP_DIR/chroma/"
 
# 备份 PostgreSQL
pg_dump -U postgres hackquest | gzip > "$BACKUP_DIR/hackquest.sql.gz"
 
# 备份 OpenClaw 配置（不含 .env）
rsync -a --exclude='.env' --exclude='node_modules' \
  /home/openclaw/hackquest-agent/ "$BACKUP_DIR/config/"
 
# 清理 30 天前的备份
find /backup/openclaw/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
 
echo "$(date): Backup completed to $BACKUP_DIR"

# crontab -u openclaw -e
0 3 * * * /home/openclaw/scripts/backup.sh >> /home/openclaw/scripts/backup.log 2>&1

故障发生
    │
    ▼
评估故障范围
    │
    ├─→ OpenClaw 进程崩溃 → systemd 自动重启（10s 内恢复）
    │
    ├─→ 服务器宕机 → 新服务器部署（RTO: 1 小时）
    │   1. 启动新服务器
    │   2. git clone Skill 仓库
    │   3. 恢复 .env 配置
    │   4. 恢复记忆数据（rsync 备份）
    │   5. 恢复 Chroma 数据
    │   6. 恢复 PostgreSQL（pg_restore）
    │   7. 启动所有服务
    │   8. 验证飞书连接
    │
    ├─→ 数据损坏 → 从备份恢复（RTO: 30 分钟）
    │
    └─→ API Key 泄露 → 立即轮换所有 Key（RTO: 15 分钟）

                    ┌─────────────┐
                    │ 负载均衡器   │
                    │ (Nginx)     │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
        │ OpenClaw  │ │OpenClaw│ │ OpenClaw  │
        │ 实例 1    │ │实例 2  │ │ 实例 3    │
        │ (需求/代码)│ │(分析)  │ │(团队/运营) │
        └─────┬─────┘ └───┬───┘ └─────┬─────┘
              │            │            │
              └────────────┼────────────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌─────┴─────┐
        │ PostgreSQL│ │Chroma │ │ Redis     │
        │ (主库)    │ │(向量) │ │ (缓存/队列)│
        └───────────┘ └───────┘ └───────────┘

# ops-log-query
 
查询应用日志，帮助开发者快速定位线上问题。
 
## 触发条件
- 用户消息包含"查日志"、"日志查询"、"报错日志"、"线上错误"
- 用户消息包含"最近有什么错误"、"500 错误"
 
## 执行步骤
1. 从用户消息中提取查询条件：
   - 服务名（如 course-api, user-service, payment-service）
   - 时间范围（默认最近 1 小时）
   - 日志级别（默认 ERROR）
   - 关键词（可选）
2. 如果用户未指定服务名，列出可查询的服务列表让用户选择
3. 构建日志查询命令：
   - GCP: 通过 Cloud Logging API 查询
   - AWS: 通过 CloudWatch Logs API 查询
   - 自建: 通过 SSH 执行 journalctl 或 grep 命令
4. 执行查询，获取匹配的日志条目（最多返回 50 条）
5. 分析日志内容：
   - 识别错误模式（重复错误、错误频率）
   - 提取关键堆栈信息
   - 关联可能的原因
6. 格式化输出，附上分析建议
 
## 安全规则
- 只查询白名单中的服务日志
- 自动脱敏：隐藏日志中的 API Key、密码、用户邮箱等敏感信息
- 查询结果最多返回 50 条，超过时只返回统计摘要
- 禁止执行任何写操作
 
## 输出格式
📋 日志查询结果：{service_name}（{time_range}）
 
共找到 {count} 条 {level} 日志
 
🔴 错误摘要：
| 错误类型 | 出现次数 | 最近一次 |
|---------|---------|---------|
| {error_type} | {count} | {timestamp} |
 
📝 最近 5 条错误日志：

💡 分析建议：
- {suggestion_1}
- {suggestion_2}

## 示例

### 示例 1
**用户**: 查一下 course-api 最近的报错日志
**Agent**:
📋 日志查询结果：course-api（最近 1 小时）

共找到 23 条 ERROR 日志

🔴 错误摘要：
| 错误类型 | 出现次数 | 最近一次 |
|---------|---------|---------|
| Redis ConnectionError | 18 | 10:45:32 |
| TimeoutError | 3 | 10:42:15 |
| ValidationError | 2 | 10:30:08 |

📝 最近 3 条错误日志：

💡 分析建议：
- Redis 连接池耗尽是主要问题（18/23 条错误），建议检查连接池配置和连接泄漏
- TimeoutError 可能是 Redis 连接问题的连锁反应
- 建议查看 Redis 服务器状态：`redis-cli info clients`

## 权限要求
- 云平台日志 API 读取权限（GCP Cloud Logging / AWS CloudWatch）
- 或 SSH 访问权限（自建服务器场景）
- 飞书消息发送权限

## 错误处理
- 日志服务不可达：提示用户检查日志服务状态
- 查询超时：缩小时间范围后重试
- 无匹配日志：明确告知"指定时间范围内无 {level} 级别日志"

# ops-service-status
 
检查各服务的运行状态，包括进程存活、端口可达、响应时间。
 
## 触发条件
- 用户消息包含"服务状态"、"系统状态"、"健康检查"、"服务挂了吗"
- 定时触发：每 10 分钟执行一次（静默模式，异常时才通知）
 
## 执行步骤
1. 从记忆中读取服务列表和健康检查端点
2. 对每个服务执行健康检查：
   - HTTP 服务：GET /health 或 /api/health，检查响应码和响应时间
   - 数据库：执行 SELECT 1，检查连接和响应时间
   - Redis：执行 PING，检查连接
   - 消息队列：检查队列深度
3. 汇总检查结果
4. 如果有异常服务：
   - 查询该服务最近的错误日志（调用 ops-log-query）
   - 检查最近是否有部署变更
5. 生成状态报告
 
## 服务列表（HackQuest）
| 服务 | 健康检查端点 | 超时阈值 |
|------|------------|---------|
| course-api | https://api.hackquest.io/health | 5s |
| user-service | https://api.hackquest.io/user/health | 5s |
| payment-service | https://api.hackquest.io/payment/health | 5s |
| web-frontend | https://www.hackquest.io | 10s |
| PostgreSQL | SELECT 1 | 3s |
| Redis | PING | 2s |
| Chroma | http://localhost:8000/api/v1/heartbeat | 3s |
 
## 输出格式
 
### 手动触发时（完整报告）
🖥️ 服务状态报告（{timestamp}）
 
| 服务 | 状态 | 响应时间 | 详情 |
|------|------|---------|------|
| course-api | ✅ 正常 | 120ms | |
| user-service | ✅ 正常 | 85ms | |
| payment-service | ⚠️ 慢 | 4200ms | 响应时间超过阈值 |
| PostgreSQL | ✅ 正常 | 15ms | |
| Redis | ❌ 异常 | — | Connection refused |
 
⚠️ 异常服务：
- Redis：连接被拒绝，可能进程已停止
  建议：`sudo systemctl status redis` 检查进程状态
- payment-service：响应时间 4200ms，超过 5s 阈值
  建议：检查是否有慢查询或外部依赖超时
 
### 定时触发时（仅异常通知）
🚨 服务异常告警（{timestamp}）
- Redis：❌ Connection refused
- 已持续异常：2 次检查（10 分钟）
 
## 权限要求
- HTTP 访问各服务健康检查端点
- PostgreSQL MCP（执行 SELECT 1）
- 飞书消息发送权限
 
## 错误处理
- 健康检查端点不可达：标记为"异常"，不重试（等下次定时检查）
- 所有服务都不可达：可能是网络问题，在告警中标注"疑似网络故障"

# ops-alert-handle
 
接收监控系统告警，自动分析告警上下文并通知相关人员。
 
## 触发条件
- 监控系统告警推送到飞书群（Sentry、Grafana、云平台告警）
- 用户消息包含"告警"、"线上问题"、"服务异常"、"紧急"
 
## 执行步骤
1. 解析告警信息：
   - 告警来源（Sentry / Grafana / 云平台 / 用户报告）
   - 告警级别（Critical / Warning / Info）
   - 受影响服务
   - 错误描述
2. 自动关联上下文：
   - 调用 ops-log-query 查询相关日志
   - 调用 ops-service-status 检查服务状态
   - 从记忆中查找是否有类似的历史故障
3. 评估影响范围：
   - 受影响的功能模块
   - 预估受影响用户数（如果可以从日志中统计）
4. 判定严重程度：
   | 条件 | 严重程度 |
   |------|---------|
   | 核心功能不可用（支付、登录、课程） | S0 - 致命 |
   | 核心功能降级（响应慢、部分失败） | S1 - 严重 |
   | 非核心功能异常 | S2 - 一般 |
   | 告警但无用户影响 | S3 - 轻微 |
5. 根据严重程度执行不同操作：
   - S0/S1：立即通知项目群 + @相关负责人 + 写入共享记忆
   - S2：通知运维群
   - S3：记录日志，不主动通知
6. 写入共享记忆 shared/incident_{id}.md，供跨部门协作使用（参考 37d 3.9 节）
 
## 输出格式
 
### S0/S1 告警
🚨 **{severity} 告警**：{alert_title}
 
**受影响服务**：{service_name}
**告警来源**：{source}
**开始时间**：{start_time}
 
**错误详情**：
{error_description}
 
**日志分析**：
最近 {count} 条相关错误，主要错误类型：{error_type}
 
**影响评估**：
- 受影响功能：{affected_feature}
- 预估影响用户：{affected_users}
 
**历史参考**：
{similar_incident_summary}（如果有）
 
**建议操作**：
1. {action_1}
2. {action_2}
 
@{responsible_person} 请尽快处理
 
### S2/S3 告警
⚠️ {severity} 告警：{alert_title}
- 服务：{service_name}
- 详情：{error_description}
- 建议：{suggestion}
 
## 示例
**Sentry 告警**: course-api 500 错误率从 0.1% 飙升到 15%
 
**Agent 回复**:
🚨 **S1 告警**：course-api 500 错误率飙升
 
**受影响服务**：course-api
**告警来源**：Sentry
**开始时间**：2026-07-15 10:15
 
**错误详情**：
500 错误率从 0.1% 飙升到 15%，主要错误：Redis ConnectionError: Connection pool exhausted
 
**日志分析**：
最近 1 小时 156 条 ERROR 日志，其中 Redis ConnectionError 占 82%
 
**影响评估**：
- 受影响功能：课程进度保存、学习记录
- 预估影响用户：约 1,200 人（基于当前在线用户数）
 
**历史参考**：
2026-06-20 发生过类似问题，原因是 Redis 连接池配置过小，通过增大 max_connections 到 50 解决
 
**建议操作**：
1. 检查 Redis 连接池状态：`redis-cli info clients`
2. 如果连接池满，临时增大配置或重启 Redis
3. 排查是否有连接泄漏（未正确释放连接）
 
@张三 请尽快处理
 
## 权限要求
- 飞书消息发送权限
- 调用 ops-log-query 和 ops-service-status 的权限
- 向量数据库读取权限（检索历史故障）
- 共享记忆写入权限
 
## 错误处理
- 日志查询失败：跳过日志分析，直接发送告警基本信息
- 历史故障检索失败：跳过历史参考部分
- 无法判定严重程度：默认为 S1，宁可高估不低估

# ops-deploy-trigger
 
触发生产环境部署，必须经过人工确认。这是高风险操作，执行前需要运维或技术负责人在飞书消息卡片上点击确认。
 
## 触发条件
- 用户消息包含"部署"、"上线"、"发布"
- 研发流程状态机中"测试通过"后自动触发（需人工确认）
- 其他 Skill 委派（如 requirement-test-verify 委派部署）
 
## 执行步骤
1. 确认部署信息：
   - 部署环境（生产 / 预发）
   - 部署内容（PR 编号、分支名、或版本号）
   - 关联需求（从共享记忆中读取）
2. 执行部署前检查：
   - CI/CD 是否通过（通过 GitHub MCP 查询 Actions 状态）
   - 是否有未关闭的 S0/S1 缺陷
   - 当前服务状态是否正常（调用 ops-service-status）
3. 生成部署确认卡片，发送到运维群：
   - 部署内容摘要
   - 前置检查结果
   - 确认/取消按钮
4. 等待人工确认（高风险操作，不自动执行）
5. 确认后触发部署：
   - 通过 GitHub MCP 触发 GitHub Actions 部署工作流
   - 或通过云平台 API 触发部署
6. 监控部署过程：
   - 轮询部署状态（最多等待 10 分钟）
   - 部署成功：通知项目群
   - 部署失败：通知运维群，附上失败日志
7. 部署完成后：
   - 写入共享记忆 shared/deploy_{date}.md
   - 委派 PM Agent 更新关联需求状态为"已上线"
 
## 部署前检查清单
| 检查项 | 通过条件 | 阻塞部署 |
|--------|---------|---------|
| CI/CD 状态 | 最新 commit 的 Actions 全部通过 | ✅ 是 |
| S0/S1 缺陷 | 无未关闭的 S0/S1 缺陷 | ✅ 是 |
| 服务状态 | 所有核心服务正常 | ⚠️ 警告（不阻塞） |
| 部署时间窗口 | 工作日 10:00-18:00 | ⚠️ 警告（不阻塞） |
 
## 飞书确认卡片
```json
{
  "msg_type": "interactive",
  "card": {
    "header": {
      "title": { "tag": "plain_text", "content": "🚀 部署确认" },
      "template": "orange"
    },
    "elements": [
      {
        "tag": "div",
        "text": {
          "tag": "lark_md",
          "content": "**环境**：生产\n**内容**：PR #178 fix: increase Redis pool size\n**关联需求**：课程进度接口优化\n\n**前置检查**：\n✅ CI/CD 通过\n✅ 无 S0/S1 缺陷\n✅ 服务状态正常\n⚠️ 当前时间 19:30，不在推荐部署窗口"
        }
      },
      {
        "tag": "action",
        "actions": [
          {
            "tag": "button",
            "text": { "tag": "plain_text", "content": "✅ 确认部署" },
            "type": "primary",
            "value": { "action": "deploy_confirm", "pr": 178, "env": "production" }
          },
          {
            "tag": "button",
            "text": { "tag": "plain_text", "content": "❌ 取消" },
            "type": "danger",
            "value": { "action": "deploy_cancel", "pr": 178 }
          }
        ]
      }
    ]
  }
}

### 9.6 运维 Skill 与跨部门协作

运维 Skill 不是孤立运行的，它们在跨部门协作中扮演关键角色：

| 场景 | 触发 | 运维 Skill 角色 | 协作 Agent |
|------|------|---------------|-----------|
| 线上故障 | 告警事件 | ops-alert-handle 首先响应，分析问题 | → PM Agent 创建缺陷 → Data Agent 分析影响 |
| 需求上线 | 测试通过 | ops-deploy-trigger 执行部署 | ← PM Agent 委派部署请求 |
| 日常巡检 | 定时触发 | ops-service-status 检查状态 | → 异常时通知 Dev Agent |
| 故障排查 | 用户请求 | ops-log-query 查询日志 | → 结果写入共享记忆供 Team Agent 复盘 |

完整的跨部门协作流程（如线上故障全链路）详见 [37d 3.9 节：跨部门 Agent 全链路协作](./37d-Agent管理与Skill体系.md)。

---

> 本章完。回到 [37a 全景架构与决策框架](./37a-全景架构与决策框架.md) 查看整体架构，或从 [37b 飞书机器人与 MCP 搭建](./37b-飞书机器人与MCP搭建.md) 开始动手实践。