first commit

专栏/DevOps实战笔记/00开篇词从默默无闻到风靡全球，DevOps究竟有什么魔力？.md

@@ -0,0 +1,78 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            00 开篇词 从默默无闻到风靡全球，DevOps究竟有什么魔力？
+                            你好，我是石雪峰，目前在京东商城负责工程效率体系建设和平台研发。从业十多年，我一直在软件行业深耕，尤其是从2015年接触DevOps至今，我一直在企业内部从事DevOps的落地实践工作，也曾帮助多家大型企业进行DevOps的相关能力评估，积累了很多实战经验。
+
+在写开篇词的时候，我才意识到，DevOps从诞生至今已经整整十个年头了。十年之间，DevOps从默默无闻到风靡全球，很多人都在反思和总结DevOps究竟有什么魔力。
+
+十年前的2009年，我在一家日本软件公司工作，长期被外派到日本尼康公司做项目。虽然当时敏捷已经兴起，但在日本，软件开发还是瀑布模式的天下。每当一个新项目来临时，我们经常不分白天黑夜地埋头苦干几个月，完全不敢想象，如果不能顺利交付会怎么样。
+
+可是，怕什么就来什么。有一次，我负责开发一款客户端软件，给客户交付的方式是事先刻录一张光盘，把光盘带去现场，一边部署，一边演示。刚开始还挺顺利的，可是到了生产数据拉取的环节，系统竟然异常退出了。我至今都还记得那位项目负责人不满的表情。
+
+调试后我发现，客户的生产环境使用的是Oracle数据库，而我们使用的是微软的Access数据库，数据访问协议不一致，数据自然会同步失败。
+
+之后的三个月，我总共休息了两天，每天的节奏就是吃饭睡觉写程序，干到搭乘最后一班电车回家，唯一的娱乐活动就是在吃加班餐的时候吐槽老板。
+
+所以，当时我就在想，一定会有一种更好的软件开发方式，在这种方式下，团队间沟通和协作的重要性一点也不亚于写代码、写文档、做测试之类的常规工作。但我不知道的是，远在大洋彼岸，DevOps的旅程才刚刚开始。
+
+十年后，也就是2019年，以移动互联网、云计算、微服务、大数据、人工智能等为代表的技术日新月异，技术的迭代和演进都在以十倍速的方式向前发展，数字化转型浪潮正在席卷各行各业。“软件正在吞噬世界”“每一家企业终将成为软件企业”……行业领袖口中的这些预言，都在慢慢地变成现实。
+
+如今，软件正在深刻地改变着我们的生活方式。前段时间，我去新疆旅行。在旅行途中，我发现即便是在沙漠边缘的小镇，微信支付也是畅通无阻。另外，用户喜新厌旧的成本已经低到可以忽略不计，企业之间的竞争已经升级为软件即服务的竞争。
+
+所以，如何快速地持续交付高质量的软件，满足用户的多样化需求，并借此提升企业的利润和市场占有率，已经成为企业必须要面对的现实问题。
+
+可问题是，现在很多企业采用的软件开发方式，同十年前我所在的公司其实并没有什么区别，甚至由于组织分工的细化，内部沟通的消耗成本更加高昂。
+
+你应该也遇到过这样的场景吧？两个部门为了数据打通，来回拉锯，各种方案和排期一天一个样，还美其名曰“PK”。原本特别简单的一件事情，非要扯上几天甚至几周才能有点眉目。每当这个时候，我都忍不住想说：“嘿，兄弟，我不是来抢你饭碗的，我只是想通过系统间的打通来简化一些工作而已，何必搞得这么复杂呢？”
+
+所以你看，软件开发过程的改进，除了依赖于技术进步，还依赖于流程、理念、文化等全方位的改进，而这正是DevOps带给软件开发方式的一场革命。
+
+从2017年DevOpsDays大会北京站举办以来，DevOps在国内的发展正式驶向了快车道。作为从业者之一，我深刻地感受到DevOps的影响力与日剧增，不仅仅是互联网行业，就连传统的电信、金融，甚至是政府机构，也都把DevOps作为核心能力在快速建设。
+
+现在已经很少有人会问DevOps有什么用、DevOps是否适合我之类的问题了，更多人开始关注要如何落地实践DevOps，并且让DevOps充分发挥它的价值，真正改善软件交付方式，提高IT工程师的幸福指数。
+
+除此之外，越来越多的企业开始招聘DevOps方面的人才，对DevOps的技能和经验背景的要求越来越高，DevOps专家的岗位薪资甚至仅次于高级管理层，一跃成为IT行业的金字塔顶端。
+
+我个人认为，DevOps已经成为了所有IT从业人员应知应会的必备技能。在这些技能中，技术和实践当然非常重要，但文化和理念更是尤为珍贵。如果每个从业者都认同DevOps的文化和理念，认同快速交付价值远胜于部门间的零和博弈，认同我们应该共享一个目标，并从自身做起持续改善上下游的关系，那么，怎么可能还会出现刚刚我提到的PK的例子呢？
+
+也许你从各种渠道了解过DevOps的相关信息，但是因为市场上资料庞杂、个人精力有限等原因，还存在着以下几个困惑：
+
+
+如何梳理出一套清晰的DevOps理念和完整的知识体系？
+如何获得一线大厂的实践经验，让DevOps真正落地？
+如何获得一条渐进式的DevOps学习曲线，让自己在正确的方向上不断增值？
+
+
+这些问题，正是多年来我一直在思考的，也希望在这个专栏中传递给你的核心内容。
+
+学习DevOps的过程，对你来说将会是一场探索之旅。DevOps涉及软件开发的方方面面，因此，你将漫步于需求、开发、测试、运维的完整开发流程，途经管理实践和工程实践的领域，探寻方法论、最佳实践和工具平台的有机结合方式，让自己在全栈工程师和斜杠青年的道路上更进一步。
+
+DevOps涉及的领域如此之广，想在一个专栏中学遍所有内容几乎是不可能的事情，所以我从实战的角度出发，臻选出最重要的内容，帮你梳理出一条DevOps的最佳学习路径。
+
+本专栏主要由4个部分组成。
+
+
+第1部分是“基础知识篇”。我将详细介绍DevOps的定义、价值、实施与衡量，在最开始帮你建立起正确的DevOps体系认知。
+第2部分是“落地实践篇”。这一部分占据整个专栏一半的篇幅，是最核心的部分。我将带你通盘梳理DevOps的转型路径，你一定不要错过。
+第3部分是“平台工具篇”。它涵盖平台建设的3个阶段、产品研发和设计、不可忽视的开源工具等，帮你找到快速搭建平台的钥匙。
+第4部分是“转型案例篇”。我将分享1～2个实际案例，将前面提到的理论、落地实践和工具融入其中，让你能够融会贯通。
+
+
+另外，我还设置了特别放送环节。在这个环节，我会跟你分享一些经典的学习资料、DevOps工程师的必备技能等内容，让你全方位、多层次地掌握DevOps。
+
+
+
+其实，整个专栏的整理和写作，对我来说也是一场修行。毕竟，作为DevOps多年的实践者，我在用它解决问题的同时也发现了更多的问题，好奇心和对效率建设的执着追求让我乐此不疲。现在能够静下心来，把我多年的经验与反思整理出来跟你分享，也是一件非常有意义的事情。
+
+在这个过程中，我也越发地感受到，DevOps的思想和文化的落地依然任重道远。每个时代都会有一群先锋走在时代的前沿，中流击水，鹰击长空，希望通过本专栏的学习，你也可以成为DevOps的思想者和实践者，实现个人价值和企业价值的双赢。
+
+最后，我想请你聊一聊，关于DevOps，你都有哪些困惑？对于专栏，你又有哪些期待？欢迎你写在留言区，我们一起交流，期待你的反馈。
+
+好了，从现在开始，就让我们一起踏上这场DevOps的奇妙旅程，一路同行，不断进步。
+
+                        
+                        
+                            

专栏/DevOps实战笔记/01DevOps的“定义”：DevOps究竟要解决什么问题？.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            01 DevOps的“定义”：DevOps究竟要解决什么问题？
+                            你好，我是石雪峰。今天我们来聊一聊DevOps的“定义”。
+
+近些年来，DevOps在我们身边出现的频率越来越高了。各种大会上经常出现DevOps专场，行业内的公司纷纷在都招聘DevOps工程师，企业的DevOps转型看起来迫在眉睫，公司内部也要设计和开发DevOps平台……这么看来，DevOps似乎无处不在。
+
+可回过头来想想，关于DevOps，很多问题我们真的想清楚了吗？所谓的DevOps平台，是否等同于自动化运维平台，或持续交付平台呢？DevOps工程师的岗位描述中又需要写哪些技能要求呢？另外，该如何证明企业已经实现了DevOps转型呢？这些问题真是难倒了一众英雄好汉。说到底，听了这么久的DevOps，它的“定义”到底是什么，好像从来没有人能说清楚。
+
+现在，我们先来看看维基百科对DevOps的定义。不过，估计也没谁能看懂这到底是在说什么。
+
+
+DevOps（开发Development与运维Operations的组合词）是一种文化、一场运动或实践，强调在自动化软件交付流程及基础设施变更过程中，软件开发人员与其他信息技术（IT）专业人员彼此之间的协作与沟通。它旨在建立一种文化与环境，使构建、测试、软件发布得以快速、频繁以及更加稳定地进行。
+
+
+于是乎，每当提及DevOps是什么的时候，最常出现的比喻就是“盲人摸象”。有意思的是，DevOps之父Patrick第一次参加DevOpsDays中国站活动的时候，也使用了这个比喻，看来在这一点上，中西方文化是共通的。毕竟每个人的视角都不相同，看到的DevOps自然也是千差万别。
+
+DevOps大潮汹涌而来，很多人都被裹挟着去探索和实践DevOps，甚至有一种极端的看法认为一切好的实践都属于DevOps，而一切不好的实践都是DevOps的反模式。
+
+当年敏捷开始流行的时候，似乎也是相同的论调，但这种笼统的定义并不能帮助我们理清思路，甚至会带来很多负面的声音，比如DevOps就是开发干掉运维，又或者，DevOps就是要让运维抛弃老本行，开始全面转型做开发。这让很多IT从业人员一度很焦虑。
+
+客观来说，从DevOps运动诞生开始，那些先行者们就从来没有试图给DevOps下一个官方的定义。当然，这样做的好处很明显，由于不限定人群和范围，每个人都能从自己的立场来为DevOps做贡献，从而使DevOps所涵盖的范围越发宽广。
+
+但是，坏处也是显而易见的。随着DevOps的不断发展，刚开始接触DevOps的人往往不得要领，只见树木不见森林，认知的偏差使得DevOps越发地神秘起来。
+
+与其纠结于DevOps的定义，不如让我们一起回归原始，来看看DevOps究竟要解决的是什么问题。
+
+其实，DevOps的秘密就来源于它的名字所代表的两种角色——开发和运维。那么这两种角色之间究竟有什么问题呢？我们从软件工程诞生以来所历经的三个重要发展阶段说起。
+
+瀑布式开发模式
+
+
+
+瀑布式开发模式将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。
+
+可是，随着市场环境和用户需求变化的不断加速，这种按部就班的方式有一个严重的潜在问题。
+
+软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性，很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即便我们投入了大量资源，却难以达到预期的效果。
+
+从业界巨头IBM的统计数字来看，有34%的新IT项目延期交付，将近一半的应用系统因为缺陷导致线上回滚，这是一件多么令人沮丧的事情。
+
+敏捷式开发模式
+
+
+
+基于这种问题，敏捷的思潮开始盛行。它的核心理念是，既然我们无法充分了解用户的真实需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。
+
+与此同时，将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。
+
+很显然，敏捷是一种更加灵活的研发模式。经常有人会问，敏捷会直接提升团队的开发速度吗？答案是否定的。试想一下，难道说采用了敏捷方法，研发编码的速度就会提高两倍甚至三倍吗？回想一下很多年前在IT行业广为流传的“人月神话”，我们就能发现正确的认知有多么重要。
+
+敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工。关于这一点，我会在敏捷和精益的相关内容中做更加详细的介绍。
+
+说到底，敏捷源于开发实践，敏捷的应用使得开发和测试团队抱团取暖。可是问题又来了，开发和测试团队发现，不管研发的速度变得多快，在软件交付的另一端，始终有一群人在冷冰冰地看着他们，一句“现在没到发布窗口”让多少新开发的功能倒在了上线的门槛上。
+
+毕竟，无论开发了多少“天才”的功能，如果没有经过运维环节的部署上线，并最终发布给真实用户，那么这些功能其实并没有什么用。
+
+DevOps模式
+
+
+
+于是，活在墙的另一端的运维团队成了被拉拢的对象。这些在软件交付最末端的团队始终处于一种“背锅”的状态，他们也有改变的意愿，所以DevOps应运而生，也就是说，DevOps最开始想要打破的就是开发和运维之间的对立和隔阂。
+
+在传统模式下，度量开发团队效率的途径就是看开发完成了多少需求。于是，开发为了达成绩效目标，当然也是为了满足业务需求，不断地堆砌新功能，却很少有时间认真思考这些功能的可运维性和可测试性，只要需求状态流转到开发完成就万事大吉了。
+
+而对于运维团队而言，他们的考核指标却是系统的稳定性、可用性和安全性。但现代IT系统是如此复杂，以至于每一次的上线发布都是一场战役，整个团队如临大敌，上线失败的焦虑始终如影随形。
+
+很多时候，我们并不知道上线之后会发生什么，只能按照部署手册一步步操作，完成之后就听天由命。所以，每逢大促活动，就会有各种“拜服务器教”的照片广为流传。
+
+另一方面，在无数次被开发不靠谱的功能缺陷蹂躏得体无完肤之后，运维团队意识到，变更才是影响他们绩效目标的最大敌人。于是，预先设立的上线窗口就成了运维团队的自留地，不断抬高的上线门槛也使得开发团队的交付变成了不可能完成的任务，最后，“互相伤害”就成了这个故事注定的结局。
+
+即便到了今天，部署上线在大多数公司依然是一件很神圣的事。我给你讲一件有趣的事情。
+
+去年我在欧洲拜访DevOps之父Patrick的时候，曾经去过他的公司。那天风雪交加，比利时根特显得非常冷清。我们停好车后，刚要推门进入他们公司，恰好碰到Patrick和他的一个同事下楼抽烟。
+
+简单寒暄之后，我们才知道，原来Patrick公司负责的一个系统要在15分钟后上线，他们趁这个间歇出来换换脑子，然后再回去大干一场。所以你看，连DevOps之父在面临上线的时候都如此正式，可见，DevOps的发展之路依然任重而道远啊。
+
+从一开始想要促进开发和运维的协作，团队慢慢发现，其实在整个软件交付过程中，不仅只有开发和运维，业务也是重要的一环。
+
+比方说，如果业务制定了一个不靠谱的需求，那么无论开发和运维怎样协作，得到的终究是一个不靠谱的结果，以及对人力的浪费。可是业务并不清楚用户的真实情况，于是运维团队慢慢转向运营团队，他们需要持续不断地把线上的真实数据和用户行为及时地反馈给需求团队，来帮助需求团队客观评估需求的价值，并及时作出有利于产品发展的调整，这样一来，业务也被引入到了DevOps之中，甚至诞生了BizDevOps这样一个专门的词汇。
+
+那么，既然沟通协作放之四海皆准，安全也开始积极地参与进来。安全不再是系统上线发布之后的“定时炸弹”，而是介入到整个软件开发过程中，在每个过程中注入安全反馈机制，来帮助团队在第一时间应对安全风险，那么，对于安全团队来说，DevSecOps就成了他们眼中的DevOps。
+
+这样的例子比比皆是，包括职能部门、战略部门等，都纷纷加入其中，使得DevOps由最开始的点，扩展为线，再到面，不断发展壮大。每个人都参与其中，这使得DevOps成了每一个IT从业人员都需要学习和了解的知识和技能体系。
+
+说到最后，我还是希望基于我对DevOps的理解，给出一个我自己的“定义”：
+
+DevOps是通过平台（Platform）、流程（Process）和人（People）的有机整合，以C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化IT组织。
+
+总结
+
+今天，我带你一起梳理了DevOps的发展历程，以及软件开发模式的变迁。有人说，DevOps是软件工程发展至今的第三次革命，可见它带给整个行业的影响是很深远的。人云亦云并不能帮助我们更好地理解DevOps，建立正确的认知才是体系化学习的第一步，希望你能通过今天的课程，建立起你自己对于DevOps的独特认知。
+
+思考题
+
+最后，给你提一个问题：我给出的定义符合你心目中对DevOps的预期吗？DevOps具有与生俱来的开放性，你能谈一谈你对DevOps的理解和定义吗？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+                        
+                        
+                            

专栏/DevOps实战笔记/02DevOps的价值：数字化转型时代，DevOps是必选项？.md

@@ -0,0 +1,102 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            02 DevOps的价值：数字化转型时代，DevOps是必选项？
+                            你好，我是石雪峰。今天我们来聊聊DevOps的价值。
+
+前段时间，因为工作的缘故，我参访了一家在国内数一数二的金融企业。在跟他们科技处的同事交流的过程中，有一件事情让我非常吃惊，想跟大家分享一下。
+
+虽然在一般人眼中，这家企业是典型的传统企业，但他们的绩效目标采用的却是OKR模式。
+
+我简单介绍一下OKR。OKR也就是目标与关键成果法，是在硅谷互联网公司很流行的绩效制定方法。简单来说，O代表目标，也就是我们要做什么，KR代表关键结果，用于验证我们是否已经达到了目标。
+
+这家金融企业的大老板，也就是科技处的老大，给全体员工制定的众多OKR中，有且只有一条属于愿景指标。说出来你可能不相信，这个愿景指标就是，到今年年底，让DevOps在全行的三个试点项目中成功落地。
+
+而且，这并不是简单的说说而已，如果最终达成了这个愿景指标，所有员工的年终奖将在原有的基础上上浮10%～20%。由此可见，关于实施DevOps，他们是在玩真的了。
+
+全行的核心系统改造都没能成为愿景指标，那为啥DevOps会有如此大的魔力，让大老板都为之着迷，并且成为愿望清单列表中的第一名呢？这就是我今天要跟大家讨论的话题：DevOps的价值以及它对现代企业的意义。
+
+如果要选一个近年来在各大企业战略中曝光率最高的关键词，数字化转型绝对是排名最高的，没有之一。
+
+比如，传统汽车巨头大众公司今年宣布启动全面数字化转型，计划到2023年年底投资约40亿美元，实现管理和生产的数字化。而且，预计到2025年，大众集团的软件研发的比例将从目前的不到10%增长到60%。
+
+为什么软件如此重要？
+
+对于软件从业人员来说，这绝对是令人欢欣鼓舞的事情。同时，这也再一次印证了那句流传已久的名言，每一家公司都将成为软件公司。那么问题来了，在数字化转型时代，为什么软件会如此重要呢？
+
+互联网的普及和移动通讯技术的发展所带来的移动互动网的兴起，深刻地影响了我们每个人的生活方式。
+
+举个最简单的例子，几年前如果我们要办理银行业务，我们首先要找到附近的营业厅，抽空跑过去排号，经过很长时间的等待，才能坐到柜台前，同银行的柜员面对面地完成业务办理。当然这还是在顺利的情况下，如果忘记带证件或者排队人太多，可能还要再跑一次，办事成本相当高。
+
+现在呢，大多数情况下，我们只要掏出手机，打开银行的APP，点击几下屏幕，业务就办好了，完全不用受时间和空间的限制。用户对银行服务的体验直接来源于手机应用本身。如果哪家银行的应用界面很丑，操作还总是出现各种问题，就会直接影响用户对这家银行的印象，甚至会在潜意识里觉得这家银行不靠谱。显然，没有任何一家银行愿意给人留下这样的印象。
+
+所以，软件慢慢从企业内部的支撑系统和成本中心，变成了企业服务的直接载体和利润中心。企业通过软件降低运营成本，提升服务水平，而用户在获得便利的同时，也加强了同企业之间的联系。
+
+这本是一件双赢的事情，可问题是，我们所身处的是一个VUCA的时代，VUCA是指易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity），它代表了这个时代的典型特征。比如共享单车这个行业从冉冉兴起炙手可热，到逐渐归于平静，前后不过短短几年的时间。
+
+企业能快速满足用户的需求，在行业大势之下灵活转身，在跨界打击越发普遍的情况下脱颖而出，已经不仅仅是good to have的能力，而是must have的能力。
+
+可以说，软件交付的效率和质量成了当今企业的核心价值和核心竞争力，所以，任何一家企业，无论是行业巨头还是初创公司，无论是互联网行业还是传统行业，无论是领先者还是颠覆者，都有强烈的意愿去改善自身的软件交付能力，而这恰恰和DevOps的理念和诞生背景不谋而合。这么看来，DevOps能够成为企业愿望清单中的第一名也就不足为奇了吧。
+
+可是，即便软件如此重要，却依然有很多公司在用一种手工作坊的方式开发软件，引用国家智库的某位领导的话来说，“工业革命消灭了绝大多数的手工业群体，却催生了程序员这个现存最大的手工业群体”。这句话看似危言耸听，但这种开发软件的方式的确存在，其中伴随着大量的效率浪费。企业内部的软件开发交付效率已经成了一座值得探索挖掘的金矿，效率经济可能成为新的业绩增长点。
+
+DevOps的价值
+
+那么，实施DevOps带给企业的价值究竟是什么呢？要回答这个问题，我们就不得不提到DevOps业内非常著名的现状调查报告了。
+
+高效的软件交付方式
+
+从2014年至今，这个报告每年都会发布一份，由业内大咖和行业领袖基于科学的分析方法，通过大量的数据分析得出，可以说是业内最具权威性的报告，其中的很多数据和理念都被广为传播。我发现，在这洋洋洒洒大几十页的报告中，被引用频率或者说出镜率最高的，就是DevOps的4个结果指标。
+
+
+部署频率：指应用和服务向生产环境部署代码的频率。
+变更前置时间：指代码从提交到成功运行在生产环境的时长。
+服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
+变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
+
+
+每年，这个报告都会基于这4个核心指标统计行业内高效能团队和低效能团队之间的差距。从去年的数据来看，与低效能团队相比，高效能团队的部署频率高了46倍，变更前置时间快了2500多倍，服务恢复时间也快了2600多倍，失败率低了7倍。
+
+我们先不管这份数据是怎么计算出来的，当你第一次看到这个数据的时候，它带给你的冲击是不是很强大呢？用具体的数字形式来呈现企业之间效率的差距，是很有震撼力的。
+
+而世界上最令人“绝望”的事情，就是那些比你优秀的人，实际上比你还要更加努力。当你仔细查看这份报告的时候，你会发现，那些常年被人提及的明星公司，很多都在践行DevOps，甚至很多来源于这些公司的实践案例，都成为了DevOps行业的经典案例。
+
+另一方面，DevOps状态报告中提到的四项结果指标，分别代表了软件交付的两个最重要的方面，也就是交付效率和交付质量。而且，从数据结果中，我们还能得到一个惊人的发现，那就是高效能的组织不仅做到了高效率，还实现了高质量，由此可见，鱼与熊掌可以兼得。
+
+可是，这就颠覆了很多人心目中的“慢工出细活”的传统软件开发理念。因为按照传统软件开发的V模式来说，软件开发完成后，需要经过单元测试、集成测试、系统测试和验收测试等层层关卡，以此来保证软件的质量符合预期。但是，对于现代软件开发而言，如此重的流程和管控显然有点跟不上时代的节奏。
+
+我们在不断提高软件交付效率时，往往是以牺牲质量为代价的，结果做得越多，错得越多，从而陷入进退两难的境地。
+
+DevOps却反其道而行之，它试图通过体系化的研发实践导入、软件架构的整体革新、组织管理理念的不断升级和企业文化的影响塑造，来帮助企业改善整个软件交付过程，在实现高吞吐量的同时保证服务的总体稳定性，从而真正实现又快又好的软件交付目标。
+
+激发团队的创造力
+
+我们刚刚谈到的这些内容，当然是DevOps带给企业的重要价值，但并非全部。在专栏中，我不仅希望能跟你分享知识，还希望能跟你分享一些不同的观点，我们一起思考和讨论，获取灵感和新知。
+
+之前，我在跟Jenkins创始人KK聊天的时候，他提出过这样一个问题：熟悉云计算的同学可能或多或少地了解过容器编排领域的事实标准Kubernetes以及它背后的CNCF基金会，那么，企业为什么热衷于加入这样的基金会呢？即使要付出一笔不菲的费用也在所不惜，企业这么做的收益究竟是什么？
+
+不可否认，CNCF是一个非常成功的运营案例，成为会员还能享受白纸黑字上的福利，但是，对于很多中小企业而言，他们的诉求可能不止如此。
+
+很多时候，企业加入这样的组织，也是为了向内部员工表态，我们正和世界上最著名的公司站在同一条起跑线上，关注着同样的问题。这对他们的员工来说，既能起到激励作用，也能增强对企业自身的信心。
+
+对于DevOps而言，道理也是同样的，因为说到底，企业的问题都是人的问题，最核心的价值最终都会归结到人身上，所以，单纯关注软件交付的能力而忽视人的感受，结果往往都是片面的。
+
+在企业内部建设DevOps工具平台的时候，我也经常在思考这个问题，我们费尽心思通过平台能力建设提升了5%的交付效率，即便节省下来的时间只是让员工多休息了一会儿，也是非常有意义的事情。因为DevOps本身也包含了改善软件从业人员的生存状态，提升他们的幸福水平的理念。
+
+这么看来，实施DevOps，一方面可以通过种种流程优化和自动化能力，改善软件开发团队的工作节奏，另一方面，也可以让大家关注同一个目标，彼此信任，高效协作，调动员工的积极性和创新能力，从而让整个团队进入一种积极创造价值的状态，而这所带来的影响远非建设一两个工具平台可比拟的。
+
+总结
+
+DevOps作为软件工程的第三次革命，在数字化转型的大潮之下，几乎成了所有通过交付软件来提供服务的企业的必选项。因为，DevOps不仅可以改善企业的软件交付过程，实现高质量和高效率兼得，同时也可以持续改善企业内部的工程师文化，提升员工信心，激发员工的活力和价值创造，从而帮助企业在VUCA时代占得先机，获得更大的成功。如果一家企业真的可以通过DevOps落地达到以上目标，而只需要多付出10%～20%的年终奖，岂不是大大赚到了吗？
+
+思考题
+
+最后，给你留一个思考题：如果你觉得DevOps可以解决公司现有的问题，想要跟领导申请立项的话，你会如何说明DevOps的价值呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+                        
+                        
+