为什么要说“又”？
两年前的这个时候，读了“凤凰项目”一书，写了一篇“DevOps面面观”，没有做推广，阅读量出乎意料的好。
两年前，读到的是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运维时该如何建立快速工作流。为了使流量最大化，需要小的批量规模和工作间隔，绝不让缺陷流向下游工作重心，并且不断为了整体目标（相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标）进行优化。
必要的做法：看板可视化、持续构建、持续集成、持续测试、持续部署，代码分支整合，按需创建环境，严控半成品，以及构建起能够顺利变更的安全系统和组织。不断降低周期时间，持续不断的降低批量规模，目标是单品流。
可视化价值流图，关键是描述现状，把日常做的事原原本本的写下来，暴露发现问题从而解决问题，而不是相互指责。
可视化一切：可视化工作流，可视化任务，可视化等待时间，可视化依赖，可视化运维监控。
瓶颈，约束点
保护约束点，根据瓶颈资源所能完成工作的速度来安排工作，在瓶颈之外的任何地方做出的改进都是假象，在瓶颈之前做出的任何改进都是徒劳的，因为只能干等着瓶颈把工作传送过来；在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。
想想道路交通，堵点后面的道路通常是一马平川
