记得刚上大学的时候，热门专业叫软件工程。这个专业用的是国外课程，学费比一般专业贵很多，大约是1.5倍。一直是一件非常复杂，甚至是高大上的事情。待会再看《人月神话》，说实话，我会记住一句话。软件开发没有灵丹妙药，再次证明做软件不容易。（题外话，这本书对于在读大学或者刚搞开发的同学来说其实有点高，太抽象了，只有参与过一些比较大的项目才会越来越明白。）看了这么多年，经历过CMM模型、敏捷开发、devops，参与过几千人开发的项目，也做过几个人的小项目，担任过开发、项目管理、产品、业务负责人等各种角色等等，经验多了一些，我来说说最流行的devops是怎么做的。可能我对工程效率不是很专业，这篇文章不是讨论如何做软件工程或如何做devops的教程。核心是讨论devops的价值，一些关键的前置因素，以及背后的一些逻辑。我们来看看devops实施带来的直接价值：（1）对客户的价值：更快的响应通过发布功能发布，功能发布可以更快地响应客户每天的需求（2）产品的价值：提高质量以减少每次发布范围，降低出错概率，提高质量，及时响应；通过回滚或快速修复，提高产品质量（3）对团队的价值：激活组织，简化管理，提高效率可以通过合理拆解降低耦合度，通过分田入户提高团队的积极性；降低吃大食堂、互相等待、上下文切换带来的效率。对于团队成员的快速成长和承担责任也很有帮助。对于管理者来说，可以释放低效的组织协作，专注于更高层次的商业机会和项目机会。打通开发与运维边界，减少上下文切换。另外，通过合理的微服务拆分，单个任务的难度变低。事实上，实现软件变更并不是一个简单的需求。是一个系统工程。devops有一些关键的先决条件：服务架构拆分CI/CD工具灰度环境团队文化转型：观念的认同，工作方式转变的认同，T型人才的持续培养。很多团队都面临着发展模式转型的问题。我的建议是：(1)早实施好于晚实施：早实施对客户和业务的负担更小，带宽详细预估的价值要小得多；计划是必要的，但是业务瞬息万变，敏捷的组织更有价值，所以比起事无巨细地计划一切，马上做一个宏观的整体计划更有价值必要的，或者缺乏方向感的（3）考虑从一个/多个模块，逐步实践和积累经验，最重要的是团队文化的转变，大家对新模式的理解和接受。之前讲了很多野蛮的实践方式，学术上回归DevOps定义本质。《CALMS》有一个主题：Culture（文化）——指拥抱变化，促进协作和沟通Automation（自动化）——指人为干预Links从价值链中淘汰Lean——指运用精益原则促进高频循环次数指标——指通过数据衡量每个环节，改进循环公开与他人分享成功和失败的经验，并从错误中不断学习和改进。你会发现你上面说的可以映射到CALMS。和它相比，你的理解其实会更深刻。除了上面提到的各种价值，我觉得devops更大的价值在于对人性的激发。与传统的Agile和CMM模型最大的区别在于管理逻辑的不同。如果用数据库中的经典锁来解释这个区别，其实就是乐观锁和悲观锁的区别。除了各种工具和套路，devops的核心是能够激活个体团队成员的主动所有者意识。让他们敢打敢干。那么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
