运维

从请求到响应

按一个可重复闭环发布应用、理解太一看到的信号、调查可疑流量,并做范围最小且可验证的变更。

1. 发布应用

先启动后端并创建站点,在修改公网 DNS 前验证路由。新站点创建后立即生效;一步式命令会创建上游池并使用内置 Standard 策略。

tiyi site create \
  --name shop \
  --host shop.example.com \
  --upstream-url http://10.0.0.20:9000 \
  --tls none

curl -i -H 'Host: shop.example.com' http://127.0.0.1/

应用交付 → 站点管理 TLS、路径路由、健康状态与站点安全覆盖。同一域名承载多个应用时,使用 `/api/`、`/static/` 等最长前缀路由,保留 fallback,并在保存后逐条探测。

2. 建立基线

总览选择站点和时间范围,检查请求率、拦截率、状态码、延迟与 Top 攻击源。通过监控 → 遥测探索器查看 Top-K 与 API Inventory;通过监控 → 日志管道检查消费者健康。

真相平面回答的问题隔离边界
精确计数通过或拦截了多少流量?不被明细策略采样。
Finding/证据发生了什么,哪些请求能证明?紧凑并为调查保留。
明细 + SIEM什么需要导出或深入检查?独立重试,不能阻塞代理。

3. 调查告警

  1. 打开检测与响应 → 活跃告警并跟随证据 URL。
  2. 固定站点和时间范围,复制 X-Request-Id
  3. 把 Security Finding 与访问、错误证据关联起来。
  4. 查看 Incident 生命周期、来源/目标、Geo/ASN 限制与 MITRE 投影。
  5. 多个 Incident 形成更大来源/目标/TTP 模式时,调查持久化 Attack Campaign 的 revision、图与时间线。
  6. 确认、分派并记录;缓解措施验证后再解决。

AI 仅提供建议。 Enrichment 可选且默认关闭。应用建议前必须核对保留证据与编译后策略。

4. 安全调优

  1. 复现并确定规则、站点、路径与客户端类别。
  2. 预览有效策略或 UI 差异。
  3. 可用时先用 log-only/canary。
  4. 把排除限制到准确规则与路径。
  5. 同时发送恶意与合法回归请求。
  6. 应用后监控拦截率、状态码与新 Finding。

IP allow list 不是规则排除。WAF bypass 会跳过后续检查,必须比普通单规则 pass 限制得更严格。

5. 运维 Agent

tiyi agents issue-token --tag edge --ttl 1h
tiyi agents list

使用 Agent Group 做稳定目标选择。发布前检查 bundle diff,发布后核对在线状态、applied revision/hash、apply 结果与代理健康。“离线”和“在线但停留在旧 revision”是两类故障。

6. 日常与变更检查

每天

健康、磁盘、证书到期、Agent、管道积压、firing 告警、开放 Incident、Campaign 变化、API Inventory、SIEM/通道失败与审计链。

每次变更

tiyi doctortiyi diff → 应用 → health → 功能请求 → tiyi audit verify

备份 state.db、KEK、上传证书源文件、license 与声明式清单。必须测试恢复,不能只测试备份生成。