一、运维的四类工作

IT 运维部门的所有工作可归入以下四类：

类别 定义
业务项目 业务部门发起的正式项目，如开发新功能、新产品
IT 内部项目 由业务项目衍生的基础架构项目，或内部发起的改进项目
变更 由前两类工作引发的变更请求，应在开发与运维中统一管理
计划外工作 恢复性工作，包括操作事故和问题处理，通常由以上三类工作导致

计划外工作的主要来源是技术债务。未偿还的技术债务会以计划外工作的形式持续产生成本。

二、约束理论（Theory of Constraints, TOC）

系统的产出由其最薄弱环节（约束）决定。优化非瓶颈环节无法提升整体产出。

五步聚焦法

步骤 内容
1. 识别约束 找到限制系统吞吐量的瓶颈资源
2. 利用约束 确保瓶颈资源只处理必须由它处理的工作
3. 服从约束 非瓶颈环节配合瓶颈节奏，避免在瓶颈处形成任务堆积
4. 提升约束 通过知识转移、文档化、培训等方式增加瓶颈产能或降低其负荷
5. 重复循环 当前约束解除后，识别并处理新的约束

三、价值流与可视化工作管理

核心方法

  • 看板可视化：用看板展示工作项的完整流动状态（如：待办 → 开发中 → 测试中 → 已发布）
  • 限制在制品（WIP）：为看板每列设置最大任务数，超限则停止拉入新任务
  • 度量前置时间（Lead Time）：从需求提出到交付的总时间，包含加工时间与等待时间；优化的重点是缩短等待时间

四、技术债务

技术债务是计划外工作的主要来源，表现形式包括：

  • 走捷径的代码与临时补丁
  • 缺乏文档和知识转移
  • 陈旧的依赖与架构
  • 缺乏自动化测试

技术债务需要像财务债务一样主动、持续地偿还。

五、瓶颈资源管理（"布伦特"模型）

书中以"布伦特"作为瓶颈资源的具体案例，其管理方法为：

  1. 识别：找出被最多任务阻塞、名字出现在最多工单中的关键人员
  2. 隔离：配置专人帮助过滤非必须由其处理的任务
  3. 减负：将可通过文档、脚本、培训转移的工作坚决转移
  4. 复制：通过知识转移和文档化，消除对单一人员的依赖

六、三步工作法（The Three Ways）

第一工作法：流动（Flow）

实践 说明
小批量交付 将大需求拆分为可独立交付的小功能，频繁发布
限制在制品 控制并行任务数量，避免多任务并行导致的效率损失
严控半成品 防止"开发完成但未测试"的任务大量堆积
不让缺陷流向下游 发现问题立即修复，不推至下一阶段
可视化价值流 使工作流动状态对所有参与者可见
缩短等待时间 减少任务在各环节之间的等待时间

第二工作法：反馈（Feedback）

实践 说明
自动化测试 每次代码提交自动执行单元测试与集成测试
监控告警 生产环境关键指标异常时即时通知
停止生产线 部署失败或测试不通过时暂停发布，优先修复问题
开发与运维共同目标 两个团队对同一套 SLO/交付指标负责
快速反馈循环 问题发现越早，修复成本越低

第三工作法：持续学习与实验（Continual Learning）

实践 说明
小批量高频发布 降低单次发布风险，便于问题定位
自动化日常任务 将重复操作脚本化或流水线化
无责事后复盘 事故复盘聚焦"系统为何允许错误发生"，而非追究个人责任
持续偿还技术债务 将一定比例的工作时间用于非功能性改进
实验文化 允许可控范围内的失败，从中学习

七、IT 与业务的关系

  • IT 不是成本中心，而是业务竞争力的核心组成部分
  • 开发、运维、安全、业务部门应对同一业务目标负责
  • 需为技术债务偿还预留时间，不能仅追求功能交付速度

八、无责复盘（Blameless Postmortem）

事故复盘的核心问题：

  • 哪些信号在事前被忽略？
  • 哪些工具或流程使错误更容易发生？
  • 如何在更早阶段拦截同类问题？
  • 如何防止类似问题再次发生？

复盘目标是改进系统，而非追究个人责任。