运营

将出口管制与多厂商路由整理为规划清单：记录主/备路（含 Helicone、LiteLLM Router）、量化区域封锁敞口，并在管理层对某市场「零预期」时与财务口径一致；含法务会签、故障演练与上线前证据。

将 LiteLLM 路由文档转化为上线前清单：核对主/备部署、重试与负载策略；经 Proxy 时验证虚拟密钥与费用；通过可控主路故障演练确认回退触发；若用 MCP Gateway 则检查 store_model_in_db 与 SEP-986 命名。

依据 Google SRE Workbook「附录 C - Results of Postmortem Analysis」，说明为何需在组织内统一事故的「触发维度」与「根因类目」两组标签：附录基于大量历史复盘样本列出常见 outage 触发因素占比——如二进制推送约 37%、配置推送约 31%，以及用户行为、管线、提供商变更、性能衰退、容量、硬件等分项；并就根因给出软件缺陷约 41.35%、研发流程失效约 20.23%、复杂系统行为约 16.90%、部署计划约 6.74%、网络故障约 2.75%等分布（均为附录所述统计区间内的汇总）。落地时应沿用其分类颗粒度并结合自身事故库重算权重，而非照搬数字。

依据 Google SRE Workbook 附录《Example SLO Document》，把示范性「游戏服务 API / HTTP / 分数管道」的写法抽象为可落地的文档模板：先写清用户旅程与数据来源，再选定滚动观测窗口（示例为四周），为每一条 SLI（可用性剔除 5xx、延迟阈值、读取新鲜度、探针正确性、批任务完整性等）写清分子与分母的统计口径并给出目标百分比，解释目标选取与取整惯例，分项计算误差预算并与《示例错误预算策略》联动，最后用 clarifications/caveats 记录 ELB/SYN 探测等盲点。套用模板时需替换为你们自己的业务指标与数据来源。

依据 Google SRE Workbook 附录示例，把错误预算写成可执行的治理文档：界定目标与非目标、滚动窗口内的冻结与放行规则、事故占用预算阈值对应的复盘与整改要求，以及预算口径争议时的升级路径，便于产品与研发对「可靠性 vs 迭代速度」达成共识。

从检测到解决的生产故障处理结构化流程——涵盖严重性评估、团队协调、沟通模板和事后分析要求。

通过自动化爬取、Lighthouse 检查和结构化输出诊断整个网站的索引、可抓取性和页面 SEO 问题——在人工审核之前呈现带有优先级排序的可操作发现。

构建评测套件：带基准答案的自动化评分与回归检测，让团队在模型或提示词变更上线前就知道效果有没有提升，而不是靠感觉。

审计 Token 用量、模型选择、缓存策略与提示压缩，让团队在大规模 AI 功能下不失控——对高流量 Agent 流水线尤其关键。

在让 Agent 接管发布前，先约定黄金信号、SLO 窗口与面板检查项——助手才知道何谓「健康」，而不是从嘈杂日志里猜。

在故障后沉淀时间线、影响面、促成因素与可跟踪的后续项，让团队从事故里学习，而不是重复同一种意外。

先把一小部分流量打到新构建，看错误预算与延迟，再扩面或回滚；Agent 动发布链路时，意外也更可控。

约定少量日志字段（请求 ID、用户 ID、功能开关、延迟分桶），让线上排障不靠 grep 一堆格式不一的 printf。

结合链路追踪、火焰图与系统指标先定位真实瓶颈，再动代码，避免凭感觉做微优化却测不到收益。

定期扫一遍旧工具、MCP、技能和资讯条目，处理过期价格、失效文档链接与弱摘要，不让目录慢慢变旧。

发布内容批次前检查 sitemap、canonical、hreflang、robots 和 Search Console 信号，尤其适合现在这种双语静态站。

用额外 worktree 承载并行实验或长任务，减轻主工作区 stash 堆积与上下文切换成本。

用假设—验证—最小复现替代拍脑袋，适合线上事故、构建抖动和难以复现的行为回归。

在开发完成后统一处理验证、提交粒度、推送与分支生命周期，明确合并、压缩或后续工单。

在宣称「完成」之前先跑测试、构建或约定的人工检查，让「完成」等于在真实环境里验证过。