Skip to content
返回运维与 SRE

减少琐事

识别并消除重复、手动、可自动化的运维工作对工程时间的消耗。

为什么

琐事是重复、手动、可自动化的工作，若不检查会涨到消耗 SRE 一周 50%+ — 重启 pod、拷日志、跑同 SQL 出报告、手动故障转移队列。每小時琐事是未花在减少未来琐事的工程工作上的小时，所以琐事复利：越多越没时间消除所以越涨。SRE 处方是琐事预算（限 <50% 时间）和常设减琐队列：每季选 top 琐事源自动化或消除。这样做的团队报一年内琐事从 60% 降到 20%，余下时间给防宕机的可靠性项目。

何时使用

当运维工作消耗工程师一周 >50%，或同手动任务做过 3+ 次。季度审查。

如何做

1. 测琐事 2 周
   - 记每任务：什么、耗时、手动/重复/可自动
   - 琐事 = 手动 + 重复 + 可自动 + 无持久价值
   - 总琐事时 / 总时 = 琐事百分比

2. 建琐事队列
   - 按（耗时 × 频率）排 — 最大消耗优先
   - 每项标："自动化" / "消除" / "文档并接受"
   - 队列是 backlog 项，冲刺规划审查

3. 选 top 项消除它
   - 自动化：写脚本/runbook 做；从告警或计划触发
   - 消除：任务必要吗？常流程在原因消失后很久仍存在
   - 文档+接受：若真必要且不可自动，使它 5 分钟非 30 分钟

4. 限琐事 <50% 时间
   - 若琐事 >50%，减琐是冲刺最高优先，非功能工作
   - 这是 SRE"琐事预算"— 硬上限非愿望

5. 防新琐事
   - 每新手动流程需"如何自动化此"计划
   - 代码审查：若变更加手动步，要求同时加自动化

示例

# 琐事日志（2 周样本）：
#   restart-pod-orders       15m × 12 次 = 3h   → 自动化（runbook-trigger）
#   generate-weekly-report   45m × 1 次  = 45m  → 自动化（cron + SQL）
#   copy-logs-for-debug      10m × 8 次  = 80m  → 自动化（仪表盘链接）
#   manual-failover-queue    30m × 2 次  = 60m  → 自动化（自动故障转移）
#   总琐事：5h 25m / 80h = 6.8%（健康，但 restart-pod 是最大消耗）

# 自动化 restart-pod-orders（top 项）：
# 前：值班 SSH 到机器，跑 kubectl delete pod，等，确认
# 后：告警自动触发 runbook 删 pod 并验证恢复
#   - runbook：https://rb/restart-orders-pod（可自动执行，见 runbook-trigger）
#   - 每周省 3h 琐事，且 MTTR 降 10m（无人登录时间）

# 琐事预算策略：
#   若 toil_pct > 50：冲刺最高优先 = 减琐（无功能）
#   每季度审查琐事日志，重排，消除 top 项

常见问题

  • ⚠不测琐事 — 无 2 周日志琐事是感觉，工程师无法论证自动化时间超功能工作。
  • ⚠自动化琐事但不维护自动化 — 脚本腐烂坏，回手动并加"修脚本"琐事于上。
  • ⚠把减琐当一次性项目而非常设队列 — 每功能加新琐事，队列须永久。
  • ⚠无琐事预算上限 — 琐事涨到填满可用时间因功能工作总比它造的琐事更可见。

最佳实践

  • ✓记琐事 2 周以量化 — 无数字，减琐在每次冲刺规划对话输给功能工作。
  • ✓保持按耗时×频率排的永久减琐 backlog；每季消除 top 项，非有空才做。
  • ✓把琐事限 <50% 工程时间作硬预算；超时减琐是冲刺最高优先非功能。
  • ✓要求每新手动流程带自动化计划 — 代码审查拒绝加永久手动步的变更。