【知识联动】端到端DevOps持续交付

背景

今天有幸听了王立杰老师的DevOps培训，收获颇丰，并且项目上也计划往DevOps发展，下面想分享的一方面为心得，不过多涉及培训内容本身，而更注重于实践补充，所谓联动。

触动

DevOps字面上是Development和Operations的组合，但不限于开发和运维之间的协作。广义是覆盖端到端全价值链的，涉及所有业务相关部门协同来达成目标。

这个确实打破了我之前的固定思维（当然万物都在发展，也包括理论）
行动项1：扩大学习DevOps理论知识。
2022.5.8：阅读《持续交付2.0：业务引领的DevOPS精要》，很有意思，在此之前有个前作《持续交付》，而两者的区别作者也做了类似的诠释，即从DevOps1.0的涉及需求/产品，开发，测试，运维基础上在2.0扩大到了业务、市场。这本书把DevOps概括成了两个环，分别是“探索环”和“验证环”，前者思后者做，一起组成∞持续运行。目前读了10%，感觉挺不错，后续实践时会借鉴其中的一些经验。
2022.7.10：“探索环”顾名思义，通过探索识别出问题，识别出满足客户真实需求的方案，这一部分更偏向业务、市场，相对陌生，但是如果要做好一个PO（对，我是想做好），必须对这块很熟，因为产品需求的输入来源于此，且只有这样才能做出接地气、有意义的需求。当然“探索”二字以及DevOps的基因决定了这个过程也是需要从茫茫数据中找到像样的几条路，然后每条路摸索/判断一下（常用方法demo）选择最合适的出来，切忌过快进入“验证环”。

持续反馈与优化，交给用户使用不代表任务完成。

”持续“二字，就是反一次性的（现实中也很难做到），强化了”迭代“，并和”敏捷“紧密关联，是DevOps的精髓，有点无限进化的感觉。
DevOps运转强调数据驱动，这个数据从哪来？就是从使用产品的用户那来，所以交付给客户恰恰才是运转刚刚开始，接下来要不断地根据客户输入来改进，一个环接一个环地运转下去。现在业内开始出现一种预见性的观点：未来软件定义汽车，意味着汽车增值体现将从单纯制造变为“制造+服务”，因为制造出来是一次性行为（硬件，制造工艺升级，具备的功能在出厂时刻是固定的），只有靠后续服务，持续发布新的功能给到客户，客户反馈更多数据行成闭环，才能源源不断产生新的价值。

Netflix案例：Simian Army团队。

Simian Army从Chaos Monkey开始发展的，这是一个捣乱的岗位/程序？反正人家上班是coding，他是搞破坏，比如随机关闭一些服务，来看看系统的鲁棒性（抵抗混乱的能力）。最后类似的角色越来越多，情景越来越丰富就变成了一支Army（让我想到了猩球崛起。。）。刚听到网飞这么玩眼前一亮，喔，有点小牛逼，还可以这样。后来知道原来这个也是有相关领域的，就是混沌工程。不过还是觉得这个得在沙盒或者镜像里搞，就像持续部署并不意味着同步发布。
行动项2：学习混沌工程。

马斯克：把一件事改进10倍比改进10%更容易。

虽然不知道是不是他本人原话，但说法很有他的style（第一性原理），也是让我亮了一下的金句。本质就是要对成熟的几乎难以再改进的进行颠覆，创新。如果做不到，那就像《持续交付2.0》里说的那样加入“探索环”，多去定义问题。

像管理球队一样去管理员工。

因为不算球迷，开始不太理解这句话，请教了同事，原来球队最关注的是比赛胜利，也就是目标一致，另外打比赛都有先发阵容以及替补机制，这就讲究把合适的人在合适的时机放到合适的位置上了，并且要如何让大家配合无间，共同达成赢球的目标，另外也要考虑出售不合格队员以及引入新星来换血，持续维持一个有战斗力的球队。这里面既有对队员（人）自身素质的要求，也有团队精神氛围（文化）培养的要求，还有需要教练/球队经理有超强的识别力和决断力（决策），再多想一步，球队的训练条件及供给（工具链）也得跟上。基本全套了。

人>流程>工具

了解敏捷的知道，对人的要求很高。类似地，DevOps必须要人有很强的业务分析和执行能力，以及目标导向，流程工具反而是锦上添花。就像传统V流程也是可以应用DevOps的，自动化集成/测试工具也是早就大规模应用了（和传统流程并不冲突），人的意识和能力到位了，都可以拿起现成的来实现DevOps化。

精益看板和Scrum只是敏捷朝DevOps发展的初级阶段适用方法，用于中小型产品。

这个观点比较好接受些，之前学习敏捷时了解精益看板是一个从传统开发到敏捷过渡的良好方法。所以在实际项目运行中也在用。现在方法在进步，敏捷之上又多了DevOps加持（我的理解DevOps并不是敏捷的高级形式，而是一种方法论，结合敏捷这种开发模式可以发挥最大效果），也会多一个转变过程。庆幸现在也已经开始实施Scrum，而且目前所负责项目规模也就中小型（10-20人），路线还是走得对的。
2022.06.02：其实实践后发现10人以上规模的项目对于刚实施敏捷或者从传统转型来说还是太过臃肿了，主要原因在于缺乏基因，所以播种到发芽结果还有较长的过程，规模大了沟通成本，管理成本都会非线性上升。比如说目前所带的主力团队已经算是业务能力，执行力，团队默契等都比较足了（承包各类pilot试点），但尝试下来大概2个多月，离期望的还有不少差距：有时问题未能及时透明公开，公开了问题无人追踪，晨会太长（本质是Issue没有公开透明并及时处理），sense of ownership不够。这些都是人多了的弊端，当然也在不断改进：在个人的小范围责任里实施得还不错，有些互相提醒纠错的case，部分人能够主动记录wiki了，完整的Issue处理机制建立。总体来说就是Project Owner的活还是很重，但是有盼头的。不过现实是随着项目增多，团队规模可能还会上升，于是分拆几个小敏捷团队或者是另觅其他小项目来试行可能会更快落地和得出经验。

后记

笔者所从事的是传统汽车工程业务，历史原因推崇的为V模型，但现在由于新势力的崛起，特别是Tesla高分开卷，抄答案者甚众，所以给业内带来了新活力，推动了相应方法论和技术发展。那回到实际，要如何从原本传统的项目往DevOps上转变，开始探索。