我认知的 DevOps 核心价值

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

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

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

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

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

(1) 对客户的价值：响应更快

通过按 feature 发布，feature 发布可以到天对客户来说需求的响应速度更快

(2) 对产品的价值：提升质量

每次减少发布范围，降低出错的概率，提升质量出现问题，可以及时响应;通过回退，或者快速修复，提升产品质量

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

通过合理的香港云服务器拆解，降低耦合度，通过 分田到户 提高团队积极性;减少吃大食堂，相互等待，上下文切换导致的效能降低。对团队同学 ，可以快速成长，承担责任也有很大帮助。对管理者可以释放低效的组织协同工作，聚焦到更 high-level 的业务机会和项目机会上。打通开发、运维边界，减少上下文切换。另外通过合理的微服务拆分，单个任务的难度变低

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

微服务架构拆分CI / CD 工具灰度环境团队文化转型：对理念的认可，工作方式转变的认可、T 字形人才的服务器租用持续培养

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

(1) 早实施比晚实施好：早实施客户和业务负担小

(2) 立刻做比详细规划好了做好：

个体开发效率相差会比较大，所以带宽估计是非常困难的，所以相比激活组织潜力，详细估计带宽的价值小很多;规划是需要有的，但是业务变化很快，一个敏捷的组织价值更大，所以相比每件事都详细规划，立刻做价值更大宏观的全盘的规划是需要的，要不能会缺乏方向感

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

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

Culture(文化)- 是指拥抱变革，促进协作和沟通Automation(自动化)- 是指将人为干预的环节从价值链中消除Lean(精益)- 是指通过使用精益原则促使高频率循环周期Metrics(指标)- 是指衡量每一个环节，并通过数据来改进循环周期Sharing(分享)- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进

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

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

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

来源链接：

http://mp.weixin.qq.com/s?__biz=MzA3ODUxMzQxMA==&mid=2663997949&idx=1&sn=005bde119fa72fbc3ca00605f23032f6&chksm=847c5590b30bdc8643872bf702f50b3a282b3705f047e17f79b031bcc952e1f28c29d2c1f068&mpshare=1&scene=23&srcid=01232RZsxNpaSboNbmj9atAk&sharer_sharetime=1642908755701&sharer_shareid=9603544ecd5d7f3dc66603ae089636f4#rd