记得刚读大学的时候，热门的专业叫软件工程，这个专业用国外的教程，学费比一般的专业还要贵很多，大概是 1.5 倍以上，因此搞软件从来都是很复杂甚至感觉高大上的一个事情。

后面去读《人月神话》，说实话就记住了一句话，软件开发没有银弹，再次印证软件不好搞。（题外话是，这本书其实对大学在读或者刚从事开发的同学其实门槛有点高的，过于抽象。只有在亲身参与过一些比较大的项目之后才会越来越体会。）

这么多年走来，经历了 CMM 模型，敏捷开发，devops，参与过几千人一起开发的项目，也搞过几个人的小项目，各种角色也都搞过一遍，开发，项目管理，产品、业务负责人等等，有了一些更多的体会，这里讲讲特别流行 devops 怎么搞合适。

当能我不是专业搞工程效率，这一篇也不是一个说明教程来讨论怎么搞软件工程或者怎么搞 devops。核心是来讨论下 devops 的价值和关键的一些前置要素，以及背后的一些逻辑。

先来看看 devops 实施带来的直接的价值：

• 对客户的价值：响应更快

• 通过按 feature 发布，feature 发布可以到天

• 对客户来说需求的响应速度更快

• 对产品的价值：提升质量

• 每次减少发布范围，降低出错的概率，提升质量

• 出现问题，可以及时响应；通过回退，或者快速修复，提升产品质量

• 对团队的价值：激活组织，简化管理，提升效能

• 通过合理的拆解，降低耦合度，通过 分田到户 提高团队积极性；减少吃大食堂，相互等待，上下文切换导致的效能降低。对团队同学 ，可以快速成长，承担责任也有很大帮助。

• 对管理者可以释放低效的组织协同工作，聚焦到更 high-level 的业务机会和项目机会上。

• 打通开发、运维边界，减少上下文切换。另外通过合理的微服务拆分，单个任务的难度变低

那要实施一个软件变更，其实不是一个简单的要求就能完成的，是一个系统工程，devops 里面是有一些关键的前置要素：

• 微服务架构拆分

• CI / CD 工具

• 灰度环境

• 团队文化转型：对理念的认可，工作方式转变的认可、T 字形人才的持续培养

在很多团队都面向开发模式转型的问题，我的建议是

• 早实施比晚实施好：早实施客户和业务负担小

• 立刻做比详细规划好了做好：

• 个体开发效率相差会比较大，所以带宽估计是非常困难的，所以相比激活组织潜力，详细估计带宽的价值小很多；

• 规划是需要有的，但是业务变化很快，一个敏捷的组织价值更大，所以相比每件事都详细规划，立刻做价值更大

• 宏观的全盘的规划是需要的，要不能会缺乏方向感

• 考虑从一个/多个模块开始，逐渐实践和收获经验，另外最重要的是团队同学文化的转型，大家都理解和接受新的模式。

前面讲了很多实践的野路子，回到 Devops 学术上也定义了精髓，有一个“CALMS” 的主旨：

• Culture（文化）- 是指拥抱变革，促进协作和沟通

• Automation（自动化）- 是指将人为干预的环节从价值链中消除

• Lean（精益）- 是指通过使用精益原则促使高频率循环周期

• Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期

• Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进

你会发现其实前面讲的可以映射到 CALMS 上，对照上去，理解其实会更深入。

除了前面说的各种价值，我觉得 devops 其实更大的价值在人性的激发。和传统的敏捷和 CMM 模型最大的区别在于管理逻辑的区别。这种区别如果用数据库里面的经典的锁来说明，那其实就是 乐观锁和悲观锁的区别，devops 除了要有各种工具和套路之外，核心还是要能激活团队个体成员的主动 owner 意识，让他们敢打敢干。

所以 devops 会是终点吗？我觉得肯定不是，软件工程管理会持续演进和发展，去释放更大的生产率。