当我们谈DevOps时，我相信大家无论是团队、部门、公司都已察觉现有的工作模式与能力（组织结构、人员职责与技能、流程、工具、治理、文化）已经无法满足现在或者未来客户对企业要求，无法满足快速变化的市场。

我们都想象有这样的一个世界，业务部门、产品经理、开发人员、QA人员、运维人员和信息安全人员相互帮助，齐心协力，整个公司的业绩蒸蒸日上。他们朝着一个共同的目标而努力奋斗。建立出从想法到产品到客户上线，端到端的快速服务交付流水线，在系统稳定性、可靠性、可用性和安全性方面可以达到世界一流水平。

而在残酷的现实中，我们会碰到各种各样的问题，总结最痛点如下：

（1）公司、部门、团队没有统一的目标，或者对目标的理解与认知不同；

（2）部门、团队之间存在严重隔阂，只关心自己，并不在乎整体目标；

（3）建立太多没有价值的合规管控流程，导致内耗太严重；

（4）并没有形成与养成，自我不断学习、变革的开发、包容的文化；

（5）人员技能与知识都还停留在过去，不想也不敢去探索与实践；

（6）缺少适合自己组织的方法论、工具平台，提升交付能力；

我相信大家碰到的问题几乎大同小异，基本不会超过上面的问题，DevOps最终解决的还是组织的管理问题而已，所以基本逃不过整体框架。（组织结构、人员能力、流程、工具平台、文化、技术债、整体治理等）。

其实最难的是：组织架构与文化，以及企业领导的重视程度，其他都是时间与钱的问题而已。

回到DevOps的主题，我们再把范围缩小一些，随着企业的不断发展，其“债务”也在不断的积累，举个例子，就我们个人而言，如果你整体工作18个小时，你的身体就会积累成为你的债务，及时你达到的一定的高度，但是如果你不注意的你的身体，总有一天你会倒下，这一倒下可能再也站不起来，也可能对你后续的发展造成不可预估的影响，所以我们需要持续关注这些“债务”，平衡发展，并不断的减轻这些债务。债务永远是清除不完的，因为我们一直在平衡中进行取舍，也许有时候债务并没有那么重要，就像“灰犀牛”一样，但是一旦变成了“黑天鹅”，那你必须付出惨痛的代价。

那我们拿大家都比较熟悉的例子吧，在大多数公司，业务/产品的功能肯定大于运维、安全的非功能需求，特别是在中、小公司，企业要快速发展，有时候需要做一些取舍。但是，在某个阶段的平衡，并不能代表我们可以忽略，甚至抵触。因为这些问题，可能会慢慢演化为“黑天鹅”。跟孩子教育一样，除了学习以外，他的身体也一样重要，他的精神发展也更加重要。大家应该听说很多故事，从小很乖巧的小朋友，读书一直很好，老师同学都很喜欢，但是进了社会，完成无法忍受各种挫折，不愿意面对失败，造成最终的悲剧。

那回到IT相关的“技术债”，他们是如何日积月累造成的呢？主要由以下3个原因导致：

（1）有人必须去弥补未兑现的承诺。简单一些来说，整个团队一直处理焦虑状态、加班状态，一直处于一种超负荷的状态；

（2）我们最脆弱的组件正支撑着最重要的业务系统。我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远不会到来；

（3）所有人都越来越忙，工作所消耗的时间越来越多，沟通变得越来越困难，团队需要更长时间的等待与反馈，整体团队的节奏慢慢变慢。

那DevOps跟上述的3个原因有啥关联关系？那我们先了解与学习一下DevOps的发展与基本3个基本原则。让我们聊聊DevOps的发展。那我们先来讲讲一些名词：敏捷-Agile、精益-Lean、丰田方法-TPS、敏捷基础设施（持续集成-CI与持续部署-CD）、价值流-Value Stream（前置时间、处理时间、返工指标-%C/A）。总结来说，DevOps体系的发展，其实是结合上述几门实践发展，从中吸取精华后，在互联网、数字化转型中不断实践与总结的一套综合实践体系。

现在正式进入今天的主题，DevOps的3大原则。

（1）流动原则（效率） - 使得工作能够在价值流中，从左到右快速流动；

（2）反馈原则 （质量）- 使得工作从右到左每个阶段能够快速、持续反馈；

（3）持续学习与实验原则 （PDCA）-建立高度信任文化、不断成长进步；

流动原则（效率）

那我们先聊聊“流动原则”，任何一个组织它的生存价值在于通过一系列的活动，创造出对应的产品与服务给到最终的客户，满足客户的需求，最后客户愿意来买单，而且愿意持续买单，还会介绍他的朋友来使用。

那其中最重要的就是如何来设计、持续优化产出产品和服务的价值流（Value Stream）。相比工厂的实际产品的价值流，IT工作中的技术价值流更加难描述，设计、优化。如：产品团队设计产品，有时候是一个想法，里面有文字、图片，那你如何确保这些产出物可以被业务理解与认同，如何让开发理解可以进行开发等，一个工作到设计了，他们需要几天才能完成，现在到哪个阶段了？那我们就需要把这些工作可以可视化出来。所以在流动原则中，有下面几个分支。

（1）使工作可见 - 在文章的一开始，我们聊过部门、团队之间合作问题，其实更多的是不够透明，大家都不愿意把自己的状态暴露出来，所以透明化是基础，对整个团队的成员可见，大家都知道现在整体的状态，会不会对自己负责的工作有影响，以及如何来帮助有困难的模块一起解决问题等，另外可以从全局进行可视化，方便整个团队知道整体的短板，而后一起努力改进；

（2）限制在制品 - 大家都知道，我们一个人同时可以做多件事情吗？我相信大多数人是不行的，不同的工作类型、目标可能不相关，需要的方法、知识、工具也不相关，特别是知识工作者，如果不断的再进行工作思路的切换，我相信他后面肯定会出问题。对于知识工作者来说，他们可以集中精力做同一类事情，而且数量相对可控，他们的效率会更高，质量会更好；

（3）减小批量大小 - 这个概念应该比较熟悉，但是理论可能比较陌生。这个就是Agile里面的小步快跑，将原则的大项目，如果可以拆分成更小的完整性的产品，快速的交付用户可用的产品，进行市场的考验，然后不断的进行后续的调整、改进、迭代等，这样一方面可以减少等待时间、一方面可以快速响应市场与客户的需求；

（4）减少交接次数 - 大家都知道，人与人直接的交接是最困难的，特别是知识工作者，尤其是技术知识工作者，他们常年跟机器打交道，他们更加相信机器，因为他们不会说谎，不会疲劳，交流方式也标准、统一，但是人与人之间就不一样了，可能同样的一个交付物，不同的人理解是不一样的，减少交接会减少等待、减少出错的概率等；

（5）持续识别和改善约束点 - 这个点更加适合IT的交付，我们需要加快我们的交付效率，我们可以通过标准化、自动化等技术来提高的整体交付效率，如：环境搭建、代码部署、测试的准备和执行、紧密耦合的架构等，我们可以通过持续识别找出约束我们的效率的点，然后做持续的改善与优化；

（6）消除价值流中的困难与浪费 - 这个难度就更大了，更多是引入了TPS的一些理论，如如何消除：格外工序、减少等待等，其实原理很减少，就是不断的优化价值流，减少无效的活动。

反馈原则（质量）

上面我们谈了流动原则，更多关注的是效率，但是另外一个维度也很重要，那就是质量。那如何提高整体质量呢？只是通过测试就行啦？当然不行，我们需要建立持续反馈的机制，以及全面质量管理体系。

（1）在复杂系统中安全地工作 - 首先，我们应该承认，在复杂的系统中，故障的出现是不可避免的，那我们如何尽量的避免故障呢？质量保证也是有需要投入的，有代价，那我们就需要平衡投入与产出，抓大放小，抓主要问题，放次要问题，来保证整体的投入的价值与产出；

（2）及时发现问题 - 不知道大家有没有听说这么一段话：如果你不能度量它，你一直没法管理它。在“价值流”中，很重要的就是“信息流”，那我们必须建立整体的监控与度量机制，确保问题及时的被发现，被暴露。例如，上面我举过的例子，你一天工作16小时，那肯定身体会有一些反应，那如果你自己感觉到，去医院检查，那会帮助你及时发现问题，进而采取相关措施，避免后续更加严重的问题产生，所以持续的进行反馈发现的问题，并采取行动，进行后续的跟进是非常重要的；

（3）群策群力，战胜问题获取新知 - 上面也讲过了，故障是不可避免的，但是每一次出故障与解决故障，都是整个团队一起成长最好的机会，大家一起努力解决问题，然后进行总结与归纳，并沉淀为团队宝贵的经验，形成知识库，并且可以分享给其他团队，让大家一起成长，有一些可以转化为标准、制度等指导团队往更好的方向发展；

（4）在源头保障质量 - 这个大家应该在学习软件工程的时候就听说过，在需求阶段如果理解错了客户的需求进行改进，比项目与产品已经上线后，才发现理解错误的需求要要命的多，如果是后者，我们需要花更多的人力、物力、时间去救火，而如果在源头就知道有问题，将其扼杀在摇篮里，我们会更加经济与实惠，并且不会带来后续未知的影响；

（5）为下游工作中心而优化 - 我们每个岗位都是整个价值流的重要环节，我们都需要对下游负责，如果我每个人都以我的客户是谁？他的要求是什么？什么时候需要我？这样的理念去思考与设计，他们我们整体的效率与质量一起会大大提高，配合也越来越默契。

持续学习与实验原则（文化与学习）

在技术价值流中，最核心的是建立高度信任的文化。它强调每个人都是持续学者，必须在日常工作中承担风险，通过科学的方式改进流程与开发产品，从成功和失败中积累经验教训，从而识别有价值的想法。另外，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术与理念。

（1）建立学习型组织与安全文化 - 这个是任何优秀组织的根本，已经与DevOps无特别大的关系了，但是也是DevOps最重要的，需要组织不断进行自我变革，自我拷问，自我督促，自我成长；

（2）将日常工作的改进制度化 - 养成一种文化，渗入到各个个体、团队、组织的日常工作中，并且形成一种制度文化，不断的进行改进与持续优化；

（3）把局部发现转化为全局优化 - 除了我们自己各自负责部分以外，我们更加应该需要从整体的改进进行思考，哪些是整个团队、组织的短板，不断的优化我们最短的短板；

（4）在日常工作中注入弹性模式 - 建立更加健全的机制，不断提升整体的Antifragile的能力，例如：通过缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时候解耦架构，都属于在系统中引入类似张力的做法，也能够提高开发人员的生产效率与可靠性；

（5）领导层强化学习文化 - 学习文化，都是从领导层面开始的，都是从上到下的，只有领导层重视，愿意投入时间、精力、预算，才能持续的不断的养成文化、并且不断的吸收外部的好的思想、方法、工具、人才等；

预告，接下来我们会探讨，如何在各自企业里面开始实践DevOps，从哪里出发呢？选择什么样的项目、产品呢？