跳到主要内容

模式 D · 稳态运维项目接入

适用判定：项目已运行 1 年+,不再做大迭代,只维护和小优化。聚焦运维,不求完整。

为什么你属于这个模式​

符合以下任一项：

  • ✅ 产品已稳定运行,用户基本固定
  • ✅ 不再有"版本发布"节奏,只是 Bug Fix + 小优化
  • ✅ 研发资源已转移到新产品
  • ✅ 只有 1-2 人维护
  • ✅ 只关心"不出事 + 出事了能救"

核心策略：只要运维篇 + 最小开发规范​

这个模式不强求：

  • ❌ 完整的 PRD（项目已无大需求）
  • ❌ 详细的用户故事
  • ❌ 可测性评审流程
  • ❌ 复杂的分支策略
  • ❌ 测试策略和覆盖度度量

这个模式只要求：

  • ✅ Runbook（最重要,出事能救）
  • ✅ 故障响应流程（谁上、怎么升级、怎么复盘）
  • ✅ 复盘机制（每次故障都要 5 Why）
  • ✅ 基础 commit 规范（纯粹为了可追溯）
  • ✅ Bug 报告模板（内部流转用）

上车清单（4 步）​

Step 1 · 初始化精简目录（15 分钟）​

cd your-project
epcode init --mode=maintenance

# 或手动（只建运维相关）:
mkdir -p ops/{runbooks,incidents,postmortems,releases}

不需要建 docs/prd/、tests/cases/ 等（用不到）。

Step 2 · 写最关键的 Runbook（0.5-1 天）​

列出本项目最高频的 5-10 个线上告警，每个写 1 份 Runbook：

# Runbook: <告警名>

## 现象
[告警内容 + 用户表现]

## 快速定位（5 分钟内）
1. [查什么命令/日志]

## 处置方案
方案 A: 重启（最快）
方案 B: 扩容
方案 C: 回滚

## 常见根因 Top 3
...

用 Runbook 模板。

优先级排序（先写哪个）：

  1. 数据库相关（最高影响）
  2. 核心业务接口 5xx
  3. 登录/认证
  4. 定时任务
  5. 第三方依赖

Step 3 · 定义故障响应 SOP（1 小时）​

把这些贴在内部 Wiki / 钉钉群公告：

# 【XX 项目】故障响应 SOP

## 告警收到后
1. 5 分钟内确认（值班人）
2. 级别判定:
   - P0: 核心业务不可用 → 立即处理 + 通知全员
   - P1: 部分用户受影响 → 15 分钟响应
   - P2: 非核心异常 → 工作时间处理
3. 找对应 Runbook 执行
4. 找不到 Runbook 或 10 分钟没恢复 → 升级到 @张三 / @李四

## 事后必做
1. 24 小时内补故障报告（用模板）
2. 48 小时内复盘（用 5 Why）
3. 更新 Runbook 补上学到的

Step 4 · 建立最简提交规范（30 分钟）​

告诉团队：

Commit 格式（只要求 type）：

fix: 修复登录失败
fix(auth): 修复登录重复请求
chore: 升级依赖
hotfix: 紧急修复数据库慢查询

PR 规则：

  • 主干分支保护（只能通过 PR）
  • 至少 1 人 approve
  • 关键改动（DB/配置/安全）必须 2 人 approve

Bug 用模板（bug-report-template.md）:

  • 内部跟踪用,不必 100% 填所有字段

最小可用集​

如果连上面的 4 步都嫌多,这 2 件事绝对必做：

#必做代价
1至少 3 份核心 Runbook0.5 天
2故障复盘用模板写每次故障多 30 分钟

这两件做到,就比"啥都没有"强 10 倍。

运维日常工作流​

日常（无事）​

  • 监控大盘观察
  • 告警按 Runbook 处理
  • 小 Bug 按模板记录

有故障时​

收告警 → 按 Runbook 定位 → 处置 → 恢复 → 发故障报告 → 48h 内复盘

所有模板见 templates/operations/。

周度​

  • 看上周告警统计
  • 评估是否需要补 Runbook
  • 复盘中的改进项跟进

月度​

  • 看月度故障分类
  • MTTR / 故障率趋势
  • 是否有系统性问题要向上反馈

运维度量（轻量）​

只盯 3 个指标：

指标定义目标
MTTR故障平均恢复时间< 30 min
故障数/月总数月对月持平或下降
重复故障率同类问题再次发生的占比< 10%

不要追求：

  • 代码覆盖率
  • PR 评审时长
  • 需求变更率

这些是迭代阶段的指标,稳态不适用。

不适合稳态的规范（明确忽略）​

告诉团队明确可以跳过的：

规范为什么跳过
完整 PRD没新需求
可测性评审没新需求要评审
故事地图不做新功能
测试策略测试的都是 bug fix 的小范围
多层审批团队小,直接做
完整 ADR架构已定,只记录关键变更
Sprint 规划不做 Sprint
Release Note可选,小改动不发

稳态项目的"最怕什么"​

怕 1: 值班人员流动后知识丢失​

对策：

  • Runbook 必须详细到新人也能照着做
  • 不要写"张三知道怎么处理" → 写具体步骤

怕 2: 没人维护,代码腐烂​

对策：

  • 至少保持 Conventional Commits 便于追溯
  • 每季度跑一次依赖升级（Dependabot）
  • 定期（季度）安全扫描

怕 3: 突然要做大改动​

对策：

  • 触发条件：如加新功能 > 5 人天
  • 升级到 模式 C 运行一个版本

怕 4: 文档没人看​

对策：

  • Runbook 写在遇到问题会直接翻的地方（内部 Wiki / 仓库 README）
  • 文件命名用"告警名",便于搜索

稳态的"最小健康度"​

每季度自检：

  • 最高频告警都有 Runbook
  • 最近 3 个月的故障都有复盘
  • 值班 SOP 有文档且近期更新过
  • 依赖有定期升级（无高危 CVE）
  • 有人能接班（知识不依赖单人）

从稳态退出​

稳态不是终点。什么时候脱离模式 D：

  • 项目又要做大迭代（加新功能、重写模块） → 升级到 模式 C 或 模式 A
  • 项目要下线 → 走下线 SOP（不在本框架范围）

相关资源​