《凤凰项目》读后感-精选

前言

两年前，读到的是DevOps，是持续交付流水线，是运维自动化。
两年后，读到的是精益/TOC，是云，是价值交付流水线。

过两年如果再读，读到的也许会是教练，如何成为艾瑞克那样的尤达大师。
两年间，业界发生了可以说是翻天覆地的变化，云计算在当时看起来还是个趋势，至少在国内的落地还没有能看的那么清晰，那么成为绝对的趋势，还在讲公有云的安全，还在讲混合云的必要性。
两年前，对广罗大众而言，Docker刚刚兴起，K8s还未见踪影，微服务还在谈概念的阶段。
两年后，Docker、K8s、微服务已经成了DevOps三剑客，国内各家已经基于Docker搭建起CI/CD流水线，DevOps已经是热词，DevOps相关的形形色色的大会不下20场，连架构师峰会也要安排DevOps专场。
两年后，“凤凰项目”已经变成了沙盘游戏，而DevOps Master的认证也如火如荼。
两年前，我谈的是Dev2Ops，End2End。
两年后，我想说的是精益以及三步工作法。

背景

DevOps起源于“一天十次部署”，以提高部署频度为抓手，（如果能成功生存下来）最终达到提升生产环境的可靠性、稳定性、灵敏性和安全性。
书中提到的“三步工作法”，与高德拉特的“目标”一书提到的约束理论TOC五个步骤，异曲同工，“凤凰项目”一书原本就是对“目标”的致敬，而我也才知道“目标”居然是MBA的课程之一，不懂精益的CEO不是好的CIO。
DevOps最终还是要服务与业务的，以最少的资源提供更多的业务价值交付，既保持竞争力，又控制成本，多快好省不是梦想。
DevOps根本上是一条价值流交付管道，一切脱离业务去谈IT效率都是耍流氓。IT的工作是“确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，提供稳定的、可预测的、安全的IT服务。”
”凤凰项目“，包括Gene Kim、Jez Humble等人的新书“DevOps Handbook”，重点是三步工作法。你关注什么就看到什么，再次阅读时看到的就是三步工作法中的精益思想。

三步工作法

第一步：

建立从开发到IT运维再到客户的整个自左向右的工作流。帮助理解在工作从开发移向IT运维时该如何建立快速工作流。为了使流量最大化，需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并且不断为了整体目标（相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标）进行优化。
必要的做法：看板可视化、持续构建、持续集成、持续测试、持续部署，代码分支整合，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。不断降低周期时间，持续不断的降低批量规模，目标是单品流。
可视化价值流图，关键是描述现状，把日常做的事原原本本的写下来，暴露发现问题从而解决问题，而不是相互指责。
可视化一切：可视化工作流，可视化任务，可视化等待时间，可视化依赖，可视化运维监控。
瓶颈，约束点
保护约束点，根据瓶颈资源所能完成工作的速度来安排工作，在瓶颈之外的任何地方做出的改进都是假象，在瓶颈之前做出的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来；在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。
想想道路交通，堵点后面的道路通常是一马平川，而堵点前面都是要截流的，有交警敢敞开了放行么？
约束理论TOC
第一是确认约束点，这是大前提，如果约束点认错了，你懂得，”在瓶颈之外的任何地方做出的改进都是假象“；
第二是利用约束点，高效的利用约束点；利用约束点，并不意味着单纯的提高约束点的资源利用率，资源利用率是局部的优化，局部的思维方式，而精益/TOC，需要的是全局思维，更看重的是系统整体的吞吐率，即流动效率。“在产品开发中，我们的问题几乎从来不是停滞的资源（或不动的工程师），而是停滞的产品需求（用户价值）”，让价值流动起来。
第三是把约束点置于次要位置，Drum-Buffer-Rope，鼓点-缓冲-绳子，从高德拉特的TOC到大卫安德森的看板，同样一脉相传。
构建为运营而设计的系统，把非功能性需求考虑在内，包括要考虑易部署、安全性，并且可测试、可验证、会反馈。
关于”已完成工作“的定义Define of Done，同样的，需要考虑端到端，不只是编码完成、各类测试通过，同样要包括部署、运维完成，正常运行。此外，产生预期的业务价值或是业务反馈，也应该在DOD内。事实上，从一个DOD入手，就能深挖出DevOps的思想精髓。

第二步：

建立价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。缩短以及放大反馈环路，从而在源头解决质量问题。这样我们就能在所需支出获取或潜入知识，从源头上保证质量。
必要的做法：在部署管道中的构建和测试失败时“停止生产线”；日复一日的持续改进日常工作；创建快速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和IT运维之间建立共同的目标和共同解决问题的机制；建立普遍的产品遥测技术，让每个人都知道，代码和环境是否在按照设定运行，以及是否达到了客户的目标；A/B Testing，蓝绿部署，滚动升级。
不做什么比做什么更重要，Say No，无论是对人或事。系统中最大的浪费恰恰是开发了没人使用的功能。越快把功能推向市场接受考验，就越能获取反馈，消除不必要的浪费。
精益要求对用户的响应速度要快，用户的需求从进去到出来的时间要短，绝对速度要高，要有明确的衡量指标。同时，更要拼相对速度，相对于市场，相对于竞争对手。
精益的核心在于消除浪费，交付价值。如何消除浪费，很关键的就是需要从反馈中汲取经验，锻炼浪费以后能够快速识别出浪费的能力，同“反脆弱”一样的“反浪费”，不是不浪费，而是能从浪费中获益的能力。
关于“停止生产线”，借鉴精益生产中的Andon Cord 按灯拉绳系统，一旦发现质量问题，每个人都可以拉绳，也应该拉绳。按灯拉绳，不只是一个系统而已，背后是员工的责任感，主人翁精神，客户至尚的理念，以及安全感（知道任何拉绳造成的损失都不会被追究，反而被鼓励拉绳）。按灯拉绳不只是对外部客户，也同样适用于合作伙伴，以及内部团队之间，我们在亚马逊的领导力准则中也可以看到同样的思想。

第三步：

创造公司文化，带动两种风气的形成：不断创世，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。
建立文化，技能鼓励探索，从失败中吸取教训，又能理解反复的时间是精通工作的先决条件。
必要的做法：营造一种勇于创新、敢于保险以及高信任度的文化，把至少20%的开发和IT运维周期规划给非功能性需求，并不断鼓励进行改进。
改进日常工作比开展日常工作更重要。不断给系统施加压力，从而不断强化习惯并加以改进。系统里要经常出些故障，长此以往，再遇到困难就没有原来那么痛苦了。
“计划外工作”
第一，知道计划外工作从哪里来，从而在下一次做好计划；第二，如何看待计划外工作，排斥、恐惧还是坦然或者欣然接受。
计划外工作来临时，可以有两种表现：一种是在计划外工作的冲击下崩溃，就像小说中前2/3部分描述的；一种是经常的演练，从失败中吸取教训，优化改进，从而把计划外工作变成日常的训练过程，痛苦的事情一定要多做。
无论是加压测试也好，Chaos Monkey混世猴子也好，都与”反脆弱“理论不谋而合，从失败中获益。
把反脆弱融入到IT的日常中，把原本最让人头痛的部署日常化、平常话，每天10次部署，是2009年最先进的理念，到两年前亚马逊已经可以做到一天23000次。把每次出现问题当成学习改进的机会，像圣斗士一样，做不死的小强，不被同一个招式打倒两次。
把IT融入公司的日常运行中，融入到公司的业务内容中，最终做到大家意识不到IT的存在，IT无所不在又没有一个具体的IT部门，也许才是真正的境界。就像亚马逊贝佐斯一直强调的，真正好的客户服务，是没有（不需要）客户服务。

思考

你的工作是什么？你所提供的价值是什么？对你而言，什么是美好的一天，什么是糟糕的一天？你的远期目标、近期目标以及评估指标是什么？这些指标与谁以及哪些部门有关，风险有哪些？
同样的，拿着这些问题去问问你身边的人，问问和你工作相关相互协作的部门接口人，问问你做什么能帮到他/她。