【管理 DevOps】凤凰项目

凤凰项目"/>

【管理 DevOps】凤凰项目

最近入手了一本新书：《凤凰项目-一个IT运维的传奇故事》。翻开看了十分钟后，起码有5次脑中闪过同一个念头：“我去，当时我也是碰到这个情况”，“和我当时的感受一模一样”。大概2天时间就把一本将近400页的书看完了，看完那叫一个酣畅淋漓。看完后再回过头来琢磨琢磨里面的东西，记录一下自己思考的内容。

前阵子写了一篇关于DevOps思考的文章，传送门：

DevOps思考

在读完这本书之后，感觉上次的一些思考不够，只是从日常的工作中感受到了DevOps的必要性，及其收集到的一些零散的知识的汇集，而这本书则是系统性的去描述DevOps的实质方法论，所以又写一点东西为之前的思考做一些补充。

书中的主人公是一个运维部门的负责人，在应付各种工作的过程中，逐步的发现了一些工作方法，从而把自己从四处救火的状态，扭转成了胸有成竹，沉着应对的状态。作为一个沙盘推演的过程，书中是主人公通过应对不同的事件，逐步发现和利用了一些方法，而读完正本书后，我想反过来，先试着用自己的思路去总结一下，然后再展开到日常的工作中。

值得一提的是，这本书已经成为风靡全球的DevOps沙盘演练指导书，但是整本书中的内容没有直接去提DevOps的概念。而是去发现和说明DevOps的背景和实际需要场景，只有理解了这样一些更基本的道理，才能更好的理解DevOps的理论精髓，以便更好的去指导实践。

一. 四种工作

书中将IT工作分成了四个部分：业务项目、内部项目、变更和计划外的工作。

业务项目：这个很好理解，就是支撑公司业务发展的所有项目。

内部项目：用于提升自身效率的工作。如流程建设，基础资源的建设和升级等等。

变更：我自己的理解是计划内的变更。

计划外的工作：各种突发事件，也就是最不可控的一部分。或者更好的说法是团队的“技术债务”或者“业务债务”。而且这种债务是要收“复利”的。团队在很多情况下会造成这种债务，比如团队能力的缺陷，为了进度走捷径等等。这个债务会越滚越大，如果不加理会的话，最终会吞噬掉所有的工作时间，让整个团队完全无法投入到前面的三项工作当中去，最终让团队演变成一个“消防队”，每个成员都成为“救火队员”。

把研发团队看成是一个系统的话，我们的目标就是要提高整个系统的吞吐量，让前三项工作快速地完成，还需要在完成的过程避免产生“债务”。

二. 流水线 & 半成品控制

书中的主人公，比尔-帕尔默的很多疑惑的解决和思考的突破都是在参观工厂的生产车间里出现的，也就是参考流水线的工作方式来解决IT项目研发工作中碰到的问题。就像书中的韦斯和克里斯一样，很多IT从业人员认为IT研发工作是一种高度的脑力工作，其复杂程度绝非流水线的体力工作可比拟。实际上我也是认为不能完全把软件开发工作和流水线作业完全等同，软件开发本身是知识密集型工作，对人员的知识有很高的要求。但是从产品研发和交付角度来看，交付件从客户到产品到开发到测试到运维的流转，也可以视作原材料到成品的过程，而我们的研发系统也是要保证这条流水线的顺利运转。只是流水线上的节点工作性质是不同的。

而流水线运转的过程中，最终要的就是“半成品”的控制。如果“半成品”过多，会阻塞中整个系统的正常运转。

而交付流水线的“半成品”控制，我的理解是有三个控制点可以去控制。

价值工作的输入控制。所有的系统都需要做好源头的控制，源头没有控制好，整个系统就会面临崩溃的风险。就像书中主人公碰到的情况，“凤凰项目”、“审计项目”、“上千个变更”、“各个业务线的副总裁直接下命令的变更”等各种需求未经筛选的一股脑输入到整个系统中，没有统一控制，也没有优先级排序，纯粹靠着谁的嗓门大、谁的职位高、谁和关键开发人员的关系好来处理工作，造成各种工作半成品积压在整个系统中，将整个系统推向崩溃。为了避免这种情况的发生，我们需要在整个系统的源头来控制工作的输入。这样，我们的问题就转变为，如何在大量的工作中来筛选出更有价值的工作，并分出优先级后，分批输入到这样一个流水线系统中呢？书中的主人公比尔在和CFO讨论之后，CFO关心的问题是：

我们有竞争力吗？

我们能有效地创建产品吗？

我们能尽快把产品推向市场并占有一席之地吗？

我们的产品能带来感兴趣的潜在客户吗？

我们遵守了对客户的承诺吗？

我们是在获得客户，还是在流失客户？

我们可以把销售预测准确率纳入销售计划流程吗？

那么，为了回答这些问题，公司的业务部门又是如何去做的呢？或者说，为公司创造价值的部门对IT系统的需求和抱怨(痛点)是什么呢？

我问了罗恩关于销售渠道流程及其困难的问题，听到的是一顿牢骚。他详细地告诉我们，他收下的经理们想从我们的客户关系管理系统(CRM)中拿到他们需要的报告有多困难，而且要让他收下的全体销售人员都在日常工作中使用这个系统，简直是异常无止境的战争。

糟糕的一天就像是你们负责管理的物料需求计划（MRP）系统和电话系统都崩溃的时候。光是那次物料需求计划服务终中断，客户就为订单延误的事向我们大喊大叫，有两个客户直接取消了25万美元的订单。

我们的数据质量太差，因此无法凭借这些数据来进行各种预测。我们现有的最佳数据，来自于两月一次的门店访谈，以及一年两次的核心用户群访谈。你不能用这种方式经营一家规模数十亿美元的企业，还指望能成功

在我工作的上一家公司，我们每天都收到销售和缺货报告。在这里财务部每月给我们一次销售和缺货报告，但是错误连篇。

产品开发周期越长，公司资本锁定的时间也就越长，资金锁定期间是没有回报的

在竞争的年代，游戏规则就是“快速上市，快速淘汰”

从这样一些谈话中，IT部门的工作重点自然而然就出来了，为客户创造价值的工作才是有价值的工作，我们的研发系统必须要让这样属性的工作首先通过系统并且快速地通过。

还有一部分的工作重点的判断标准是：这部分工作是否能大幅度的提高系统的吞吐量。

每个在系统中工作的人必须将眼光从手里的工作上抬起头了，想象一下走到楼上往下俯瞰整个地面的感觉，去感知整个价值流，就能更好的去理解手里的工作，从而理解工作的优先级排序。

关键节点(约束点)的工作效率。IT从业人员都知道一个好的工程师能顶上10个一般的工程师。所以呢，研发工作中的难点、重活全部流向这样一个工程师。逐步的，团队中就会出现这样一个现象：缺了XXX，这个系统就无法运转了。所有的工作全部阻塞在这样一个节点上，“半成品”也全部积压在这样一个节点上面。一旦这个节点出点什么问题，整个系统就面临崩溃。对于这种问题，一般的思路是：

识别约束点，利用约束点，控制约束点，提升约束点。通过管理流向约束节点的工作来保证约束点处理最有价值的工作，并保护约束点不被打扰进行高质量的工作。同时需要将约束点的工作技能进行复制，引入其他资源来分担约束点的工作，使得约束点的工作流量可以扩大。

而且，在日常工作中，我们通常会注意到这样一个现象，如果一个人被大量的工作占据了，你想和他说句话都比较困难，更加不用说和他去沟通工作的事情了。造成后续的工作大量被积压。而书中给出了一个被约束点控制的等待时间的量化公式：

等待时间 = 忙碌时间 ÷ 空闲时间。比如一个人的50%时间在工作，那么空闲时间就是50%。等待时间就是一个工作单位。如果一个人99%的时间在工作，1%的时间在空闲，那么从这个人那里等待的时间就是99个工作单位。可以看出对某个人的工作量翻倍，但是对于整个系统的吞吐量造成的99倍的下降。

书中给出了这样一个图，很明确的显示了约束点对整个系统造成的阻塞问题。也很好的描述了解决约束点的重要性。

节点到节点之间的工作流转。“半成品”工作向下游交接也是一个问题。从车间流水线上来看，每个工作中心或者是工作环节向下游传递的工作是明确的，有质量要求的输出件。需要尽可能的减少每个输出件的返工，不然，大量的返工也会造成半成品甚至是“废料”的产生，从而导致半成品的堆积。在IT研发过程中，同样的存在这种现象，从需求收集，设计，代码开发，测试，部署。要求每个环节对上下游都有明确的交付规则和质量要求。而不是交付过程中临时去确定规则和反复的澄清和返工。

实际上，我们去观察下研发团队，大量的工作堆积在整个研发系统中，又有很多未经筛选的低价值工作输入整个系统，造成大量半成品的堆积。因此整个团队感觉事情一大堆，但是有没有有效的价值输出。会导致外部对团队的信任度下降，团队内部的成就感也会下降，从而更加导致效率的降低。因此，控制团队内部工作“半成品”的积压就成了提升效率的重中之重。

三. 三步工作法

贯穿全书的三步工作法：

第一工作法是关于从开发到IT运维再到客户的整个自左向右的工作流。为了是流量最大化，我们需要小的批量规模和工作间隔，绝不让缺陷流向下游工作中心，并且不断为了整体目标进行优化。

第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其效益以确保防止问题再次发生，或者更快地发现和修复问题。

第三工作法是关于创造公司文化，该文化可带动两种风气的形成：不断尝试，这需要承担风险并从成功和失败中吸取经验教训；理解重复和练习是熟练掌握的前提。

上述是书中的一个总结性的文字。

我自己对这些话的理解是，第一工作法是要去搭建一套IT生产“流水线”，通过这条“流水线”建立从客户需求到研发再到客户的快速工作流，通过一些技术或者其他手段去解决约束点的问题，扩大这条“流水线”的吞吐量。同时，缩短“流水线”中的每个环节时间，从而做到快速交付，快速修复，快速淘汰。

下面写一些自己对三步工作法的理解，将一些日常的IT研发内容试着归纳到三个方法中去，这个很多是个人的理解，不一定覆盖全了也不一定对，希望能和各位交流。

第一工作法中包含了这样一些工作内容：

建立及时收集客户需求的渠道和机制
需求的准确传递：需求的描述和传递应该是规范的，准确的，无歧义的
建立开发工作量的评估体系：是因为这个对工作流的影响极大，工作量评估不准，造成工作流波动大。
统一的环境规划，环境需求的虚拟化
代码构建自动化，规范的代码编写方法及自动化检查
自动化测试，这一步在我实际的工作中无法完全替代掉人工测试，因此我觉得在有测试人员人工测试的场景中，依照需求准确地提交测试及测试建议的范围是非常重要的。
代码分支管理，多特性的快速构建与部署
过程可视化

而第二工作法包含了下面的一些工作内容：

开发/测试对需求的反馈体系，不要到了代码写的差不多了才发现需求无法实现或者是有无法实现的场景。
测试工作的标准化，不能所有bug都是高优先级，需要制定其评价标准。
做好日志收集体系，日常运行监控，将问题的及时发现和定位责任往现场迁移。
上线演练，提前发现问题，增加反馈流。
A/B测试，灰度测试。
创建知识库，是的重复问题可以快速得到解决。
第三工作法更多的是一些组织上的事项：

创建资源池，做好关键岗位能力复制。当然这又是另外一个完全不同的话题。知识库，书中提到了使用备份工程师，只有备份工程师可以和关键人员沟通，同样的问题不能由关键工程师解决两次以上，否则都需要追责。
避免多头管理，不能让所有的头头们都可以指挥一线工程师，任务的单一入口。
敢于说“不”，但是说“不”或者提出问题的时候，需要有数据支撑，而不是凭直觉。最好是带上解决方案。
培养团队技术风气，敢于尝试而不是安于现状。为新事物的尝试留出空间(包括制度上的引导和时间进度上的预留等)。
持续改进，培养以发现问题为方向的尝试，而不是无的放矢的尝试。

四. 写在最后

DevOps从字面上来看，就是Development & Operations，开发运维。实际上这套方法论远不止包含开发和运维在内，而是试着让一个组织内的从业人员从日常繁杂的工作中脱离出来，站在全局的角度去思考怎样为组织和组织的客户来创造价值，并且是快速创造价值。这需要组织全体人员的参与和配合。

一般认为，DevOps包括了技术和文化两个方面，技术可以是从下往上的，但是文化必须是需要从上往下的贯彻。所以最高管理着对IT系统的认可是至关重要的，想象一下如果组织的管理者对IT系统在组织内部的价值没有足够的认知，开发运维玩的再好也只是空中楼阁。

希望我们每个人都能从这个过程中发现自己更多的可能。