mod

极客时间专栏/DevOps实战笔记/基础理论篇/01 | DevOps的“定义”：DevOps究竟要解决什么问题？.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="01 | DevOps的“定义”：DevOps究竟要解决什么问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1b/60/1ba0a9963fd7b9396f09df3a8f6d9360.mp3"></audio>
+
+你好，我是石雪峰。今天我们来聊一聊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的秘密就来源于它的名字所代表的两种角色——**开发和运维**。那么这两种角色之间究竟有什么问题呢？我们从软件工程诞生以来所历经的三个重要发展阶段说起。
+
+## 瀑布式开发模式
+
+<img src="https://static001.geekbang.org/resource/image/85/af/859c32bccda5b8e9aee5b7001fca42af.png" alt="">
+
+瀑布式开发模式将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。
+
+可是，随着市场环境和用户需求变化的不断加速，这种按部就班的方式有一个严重的潜在问题。
+
+软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性，很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即便我们投入了大量资源，却难以达到预期的效果。
+
+从业界巨头IBM的统计数字来看，有34%的新IT项目延期交付，将近一半的应用系统因为缺陷导致线上回滚，这是一件多么令人沮丧的事情。
+
+## 敏捷式开发模式
+
+<img src="https://static001.geekbang.org/resource/image/0f/41/0f337a6b79641b1fb92bc5cf428f0b41.png" alt="">
+
+基于这种问题，敏捷的思潮开始盛行。它的核心理念是，既然我们无法充分了解用户的真实需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。
+
+与此同时，将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。
+
+很显然，敏捷是一种更加灵活的研发模式。经常有人会问，敏捷会直接提升团队的开发速度吗？答案是否定的。试想一下，难道说采用了敏捷方法，研发编码的速度就会提高两倍甚至三倍吗？回想一下很多年前在IT行业广为流传的“人月神话”，我们就能发现正确的认知有多么重要。
+
+**敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工**。关于这一点，我会在敏捷和精益的相关内容中做更加详细的介绍。
+
+说到底，敏捷源于开发实践，敏捷的应用使得开发和测试团队抱团取暖。可是问题又来了，开发和测试团队发现，不管研发的速度变得多快，在软件交付的另一端，始终有一群人在冷冰冰地看着他们，一句“现在没到发布窗口”让多少新开发的功能倒在了上线的门槛上。
+
+毕竟，无论开发了多少“天才”的功能，如果没有经过运维环节的部署上线，并最终发布给真实用户，那么这些功能其实并没有什么用。
+
+## DevOps模式
+
+<img src="https://static001.geekbang.org/resource/image/af/5f/af17eb95cc11a99bec07ca265a9f6a5f.png" alt="">
+
+于是，活在墙的另一端的运维团队成了被拉拢的对象。这些在软件交付最末端的团队始终处于一种“背锅”的状态，他们也有改变的意愿，所以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实战笔记/基础理论篇/02 | DevOps的价值：数字化转型时代，DevOps是必选项？.md

@@ -0,0 +1,94 @@
+<audio id="audio" title="02 | DevOps的价值：数字化转型时代，DevOps是必选项？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c5/4f/c5729ce41c56fa8f5cc7f197f1e3c74f.mp3"></audio>
+
+你好，我是石雪峰。今天我们来聊聊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个结果指标。
+
+1. **部署频率**：指应用和服务向生产环境部署代码的频率。
+1. **变更前置时间**：指代码从提交到成功运行在生产环境的时长。
+1. **服务恢复时间**：指线上应用和服务出现故障到恢复运行的时长。
+1. **变更失败率**：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。
+
+每年，这个报告都会基于这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的价值呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/基础理论篇/03 | DevOps的实施：到底是工具先行还是文化先行？.md

@@ -0,0 +1,121 @@
+<audio id="audio" title="03 | DevOps的实施：到底是工具先行还是文化先行？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/33/d7c4bfed08f7de2e2de88d268c3e8333.mp3"></audio>
+
+你好，我是石雪峰。
+
+当一家企业好不容易接纳了DevOps的思想，并下定决心开始实施的时候，总会面临这样一个两难的选择：**工具和文化，到底应该哪个先行？**
+
+的确，在DevOps的理论体系之中，工具和文化分别占据了半壁江山。在跟别人讨论这个话题的时候，我们往往会划分为两个不同的“阵营”，争论不休，每一方都有自己的道理，难以说服彼此。在DevOps的世界中，工具和文化哪个先行的问题，就好比豆浆应该是甜的还是咸的一样，一直没有一个定论。
+
+可是，对于很多刚刚接触DevOps的人来说，如果不把这个问题弄清楚，后续的DevOps实践之路难免会跑偏。所以无论如何，这碗豆浆我先干为敬，今天我们就先来聊聊这个话题。
+
+## DevOps工具
+
+随着DevOps理念的深入人心，各种以DevOps命名的工具如雨后春笋般出现在我们身边，甚至有很多老牌工具，为了顺应DevOps时代的发展，主动将产品名称改为DevOps。最具代表性的，就是去年9月份微软研发协作平台VSTS（Visual Studio Team Services）正式更名为Azure DevOps，这也进一步地印证，DevOps已经成为了各类工具平台建设的核心理念。
+
+在上一讲中，我提到高效率和高质量是DevOps的核心价值，而工具和自动化就是提升效率最直接的手段，让一切都自动化可以说是DevOps的行为准则。
+
+**一切软件交付过程中的手动环节，都是未来可以尝试进行优化的方向**。即便在运维圈里面，ITIL（IT基础架构库)一直是运维赖以生存的基石，也并不妨碍自动化的理念逐步深入到ITIL流程之中，从而在受控的基础上不断优化流程流转效率。
+
+另外，正因为所有人都认可自动化的价值，工具平台的引入和建设就成为了DevOps打动人的关键因素之一。
+
+同时，现在业界的很多开源工具已经相当成熟，以Netflix、Amazon、Etsy等为代表的优秀公司也在不断将内部的工具平台进行对外开放，各方面的参考资料和使用案例比比皆是。
+
+无论是单纯使用，还是基于这些工具进行二次开发，成本都已经没那么高了，一个稍微成熟点的小团队可以在很短的时间内完成一款工具的开发。以我之前所在的团队为例，从0开始组建到第一款产品落地推广，前后不过两个多月的时间，而且与业内的同类产品相比较，毫不逊色。
+
+不过，这也带来一个副作用，那就是企业内部的工具平台泛滥，很多同质化的工具在完成从0到1的过程后就停滞不前，陷入重复的怪圈，显然也是一种资源浪费。
+
+当然，对于工具决定论的支持者来说，这并不是什么大问题，因为引入工具就是DevOps的最佳实施路径。
+
+有时候，当你问别人“你们公司的DevOps做得怎么样啦？”你可能会得到这样的回答：“我们的所有团队都已经开始使用Jenkins了。”听起来感觉怪怪的。如果只是使用了最新最强大的DevOps工具，就能实现软件交付效率的腾飞，那么世界500强的公司早就实现DevOps了。
+
+很多公司引入了完整的敏捷项目管理工具，但是却以传统项目管理的方式来使用这套工具，效率跟以前相比并没有明显的提升。对于自研平台来说，也是同样的道理。如果仅仅是把线下的审批流程搬到线上执行，固然能提升一部分执行效率，但是对于企业期望的质变来说，却是相距甚远。
+
+说到底，工具没法解决人的问题，这样一条看似取巧的路径，却没法解决企业的根本问题。这时候，就需要文化闪亮登场了。
+
+## DevOps文化
+
+在谈论DevOps文化之前，我先跟你分享一个故事。
+
+上世纪80年代，美国加州有一家汽车制造公司，叫作NUMMI。当时这家公司隶属于通用公司，但是由于劳资关系紧张，这家公司一直以来都是通用旗下效益最差的公司。员工整天上班喝酒，赌博，整个工厂乌烟瘴气，旷工率甚至一度达到了20%。通用公司忍无可忍，最后关闭了这家公司。
+
+后来，日本丰田公司想在美国联合建厂，于是跟通用达成了合资协议。美国联合汽车工会（UAW）希望新公司可以重新雇佣之前遭到解雇的员工，通用公司本来不想接受，但是令人惊讶的是，丰田公司却同意了。因为他们认为，NUMMI工厂之前的情况更多是系统的原因，而不是人的原因。
+
+接下来，丰田公司将新招募的员工送到日本进行培训。短短三个月后，整个公司的面貌焕然一新，半年后，一跃成为整个通用集团效益最好的公司。
+
+**由此可见，在不同的文化制度下，相同的人发挥出来的生产力也会有天壤之别。**
+
+类似的故事并非个例，曾经有一群美国专家到日本参观和学习生产流水线，他们发现了一件有趣的事情。
+
+在美国公司的生产线里面，总有一个人拿着橡胶的锤子在敲打车门，目的是检查车门是否安装完好。但即便如此，车门的质量依然很差。可是，在日本公司的工厂里面，却没有这样的角色。
+
+他们就好奇地问道：“你们如何保障车门没有问题呢？”日方的专家回复说：“我们在设计车门的时候，就已经保证它不会出问题了。”你看，同样是采用流水线技术的两家公司，结果却大不相同。
+
+类比DevOps，如果在我们的软件交付过程中，始终依靠这个拿锤子的人来保障产品的质量，出了问题总是抱怨没有会使用锤子的优秀人才，或许这个流程本身就出了问题。
+
+回到文化本身，良好的文化不仅可以让流程和工具发挥更大的作用，更重要的是，它能够诱发人们思考当前的流程和工具哪里是有问题的，从而引出更多有关流程和工具的优化需求，促使流程和工具向更加有力的支持业务发展的方向持续改进。
+
+可是，企业内部的DevOps文化本身就是虚无缥缈的事情，你很难去量化团队的文化水平，进而改变企业的文化。盲目地空谈文化，对组织也是一种伤害。因为脱离实践，文化就会变成无根之水。当组织迟迟无法看到DevOps带来的实际收益时，就会丧失转型的热情和信心。
+
+所以，我们需要先改变行为，再通过行为来改变文化。而改变行为最关键的，就是要建立一种有效的机制。就像我一直强调的那样，机制就是人们愿意做，而且做了有好处的事情。
+
+回想之前提到的某金融公司的案例，如果他们的老板只是喊了句口号“我们要在年底完成DevOps试点落地”，那么年底即便项目成功，本质上也不会有什么改变。相反，他们在内部建立了一种机制，包括OKR指标的设定、关键指标达成后的激励、成立专项的工作小组、引入外部的咨询顾问，以及一套客观的评判标准，这一切都保证了团队走在正确的道路上。而承载这套客观标准的就是一套通用的度量平台，说到底，还是**需要将规则内建于工具之中，并通过工具来指导实践**。
+
+这样一来，当团队通过DevOps获得了实实在在的改变，那么DevOps所倡导的**职责共担**、**持续改进**的文化自然也会生根发芽。
+
+所以你看，DevOps中的文化和工具，本身就是一体两面，我们既不能盲目地奉行工具决定论，上来就大干快干地采购和建设工具，也不能盲目地空谈文化，在内部形成一种脱离实际的风气。
+
+## DevOps的3个支柱
+
+对工具和文化的体系化认知，可以归纳到DevOps的3个支柱之中，即人（People）、流程（Process）和平台（Platform）。3个支柱之间两两组合，构成了我们实施DevOps的“正确姿势”，只强调其中一个维度的重要性，明显是很片面的。
+
+<img src="https://static001.geekbang.org/resource/image/14/42/1444f92a5a0a5e8fb131c7373415a742.png" alt="">
+
+### 人  +  流程 = 文化
+
+在具体的流程之下，人会形成一套行为准则，而这套行为准则会潜移默化地影响软件交付效率和质量的方方面面。这些行为准则组合到一起，就构成了企业内部的文化。
+
+一种正向的文化可以弥合流程和平台方面的缺失，推动二者的持续改进，同时可以让相同的流程和平台在不同的人手中产生迥异的效果。就好像《一代宗师》里面的那句经典台词：“真正的高手，比拼的不是武功，而是思想。”而**指导DevOps落地发展的思想，就是DevOps的文化了**。
+
+举个例子，在谷歌SRE的实践中，研发交付的应用需要自运维一段时间，并且要在达到一定的质量指标之后才会交接给SRE进行运维。但是，为了避免出现“研发一走，运维背锅”的情况，他们还建立了“打回”的流程，也就是当SRE运维一段时间后，如果发现应用稳定性不达标，就会重新交还给开发自己负责维护，这样一来，研发就会主动地保障线上应用的质量。而且在这个过程，SRE也会给予技术和平台方面的支持，从而形成了**责任共担**和**质量导向**的文化。
+
+类似的，有些公司设有**线上安全点数**的机制，在一定的额度范围内，允许团队出现问题，并且不追究责任。这就可以激励团队更加主动地完成交付活动，不必每一次都战战兢兢，生怕出错。通过流程和行为的改变，团队的文化也在慢慢地改进。
+
+由此看来，虽然我们很难直接改变文化，但是却可以定义期望文化下的行为表现，并通过流程的改进来改变大家的行为，从而让文化得以生根发芽，茁壮成长。
+
+### 流程 + 平台 = 工具
+
+企业内部流程的标准化，是构成自动化的前提。试想一下，如果没有一套标准的规则，每一项工作都需要人介入进行判断和分析，那么结果势必会受到人的因素的影响，这样的话，又如何做到自动化呢？
+
+**而平台的最大意义，就是承载企业内部的标准化流程**。当这些标准化流程被固化在平台之中时，所有人都能够按照一套规则沟通，沟通效率显然会大幅提升。
+
+**平台上固化的每一种流程，其实都是可以用来解决实际问题的工具**。很多人分不清工具和平台的关系，好像只要引入或者开发了一个工具，都可以称之为平台，也正因为这样，企业内部的平台比比皆是。
+
+实际上，平台除了有用户量、认可度、老板加持等因素之外，还会有3个显著特征。
+
+1. **吸附效应**：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
+1. **规模效应**：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
+1. **积木效应**：平台具备基础通用共享能力，能够快速搭建新的业务实现。
+
+简单来说，平台就是搭台子，工具来唱戏。平台提供场所，进行宣传，吸引用户，同时还能提供演出的道具，以及数据方面的分析。观众的喜好各不相同，但是平台将各种戏汇集在一起，就能满足大多数人的需求。如果平台把唱戏的事情做了，难以聚焦“台子”的质量，就离倒闭不远了。同样，如果唱戏的整天琢磨着建平台，那么戏本身的品质就难以不断精进。所以是做平台，还是做工具，无关好坏，只关乎选择。
+
+### 平台 + 人 = 培训赋能
+
+平台是标准化流程的载体，一方面可以规范和约束员工的行为，另一方面，通过平台赋能，所有人都能以相同的操作，获得相同的结果。这样一来，跨领域之间的交接和专家就被平台所取代，当一件事情不再依赖于个人的时候，等待的浪费就会大大降低，平台就成了组织内部的能力集合体。
+
+但与此同时，当我们定义了期望达到的目标，并提供了平台工具，那么对人的培训就变得至关重要，因为只有这样，才能让工具平台发挥最大的效用。更加重要的是，通过最终的用户使用验证，可以发现大量的可改进空间，进一步推动平台能力的提升，从而带动组织整体的飞轮效应，加速组织的进化。
+
+所以你看，文化、工具和培训作为DevOps建设的3个重心，折射出来的是对组织流程、平台和人的关注，三位一体，缺一不可。
+
+最后，跟你分享一个关于美国第一资本的例子。他们最初在实施DevOps时，采用的是外包方式，修改一个很小的问题都需要走复杂的变更流程，需要几天的时间。后来，他们决定采用“**开源为先**”的策略，并且严格审查原本的商业采购流程。除此之外，他们还基于开源工具搭建自己的平台，并在公司内部进行跨领域角色的交叉培养，交付效率大幅提升，实现了从每天迭代一次到每天多次的线上部署。
+
+## 总结
+
+讲到这里，我们今天的专栏内容就到尾声了。在这一讲中，我跟你讨论了DevOps中的工具和文化的实际价值，以及潜在的问题和挑战，最终推导出DevOps的3个支柱，也就是人、流程和平台，这3个支柱缺一不可。只有通过人、流程和平台的有机结合，在文化、工具和人员培训赋能领域共同推进，才能实现DevOps的真正落地实施。
+
+## 思考题
+
+最后，给你留一个思考题：你们公司的哪些文化是非常吸引你的？这些文化对于DevOps的实施又有哪些帮助呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/基础理论篇/04 | DevOps的衡量：你是否找到了DevOps的实施路线图？.md

@@ -0,0 +1,119 @@
+<audio id="audio" title="04 | DevOps的衡量：你是否找到了DevOps的实施路线图？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2a/8b/2a09ac576b94f720de5e9f9f1eb6768b.mp3"></audio>
+
+你好，我是石雪峰。今天我们来聊聊DevOps的实施路线图。
+
+商业领域有一本特别经典的书，叫作《跨越鸿沟》，这本书中提出了一个“**技术采纳生命周期定律**”，对高科技行业来说，它的地位堪比摩尔定律。
+
+<img src="https://static001.geekbang.org/resource/image/e3/f5/e352ad88f8ab68c78192ba8c0c4e24f5.png" alt="">
+
+简单来说，这个定律描述了一项新技术从诞生到普及要经历的5个阶段，这5个阶段分别对应一类特殊人群，即创新者、早期使用者、早期大众、晚期大众和落后者。这个定律表明，技术的发展不是线性的，需要经历一段蛰伏期，才能最终跨越鸿沟为大众所接受，成为业界主流。
+
+当然，DevOps这项所谓的新技术，在企业内部的落地也注定不是一帆风顺的。那么在这种情况下，你是否找到了DevOps的实施路线图呢？
+
+从2017年第一届DevOpsDays大会中国站举办以来，DevOps正式在国内驶入了发展的快车道。从一门鲜为人知的新技术思想，到现在在各个行业的蓬勃发展，各种思想和实践的激烈碰撞，DevOps的理念和价值可谓是深入人心。
+
+这样看来，DevOps已经成功地跨越了技术发展的鸿沟，从早期使用者阶段进入了早期大众的阶段，而这也意味着越来越多的公司开始尝试DevOps。
+
+在2017年底，Forrester的一组[调查数据](https://go.forrester.com/blogs/2018-the-year-of-enterprise-devops/)显示，将近50%的受访公司表示已经引入并正在实施DevOps，30%的公司表示有意向和计划来开启这项工作，而对DevOps完全不感兴趣的仅占1%。可以说，2018年就是企业落地DevOps的元年。
+
+但是，就像你要去往一个未知的目的地时，需要导航帮你规划路径、实时定位，并在出现意外情况时及时提示你是否要重新规划路径一样，企业在实施DevOps的过程中，其实也面临着相似的问题。企业自身难以清晰定位DevOps的现状，客观评估DevOps相关的能力水平，识别当前所面临的最大瓶颈以及实施DevOps的阶段性成果预期……
+
+回顾整个IT行业的发展历程，**新思想和新技术的发展，总是同标准化的模型和框架相伴相生的**。
+
+我认为，**任何技术的成熟，都是以模型和框架的稳定为标志的**。因为当技术跨越初期的鸿沟，面对的是广大受众，如果没有一套模型和框架来帮助大众快速跟上节奏，找准方向，是很难大规模推广并健康发展的。
+
+比如，软件开发领域的CMMI模型（软件能力成熟度模型）、运维行业的ITIL模型等，在各自的领域都久负盛名，甚至一度被各个领域的从业者奉为圭臬和行为准则，成为衡量能力高低的标尺。
+
+我曾经在国内某大型通讯设备公司参与过CMMI评级项目。当时，就算业务压力再大，只要是关于通过评级的事情，所有部门都会高优先级支持。由此可见，整个公司都非常重视这个认证评级项目。
+
+那么问题来了，在DevOps这项新思想和新技术不断走向成熟的过程中，是否也有类似的模型和框架，能够指导企业内部的DevOps转型落地工作呢？
+
+答案是有的，而且有很多。只要你去谷歌上搜一下DevOps框架、模型等关键词，就能看到非常多的结果。尤其是国外的一些知名公司，比如Atlassian、CloudBees、CA等，基本上都有一套自己的模型和框架，来帮助企业识别当前的DevOps能力水平并加以改进。
+
+我之前参与过工信部旗下的中国信息通讯研究院牵头制定的一套DevOps能力成熟度模型。这套模型覆盖了软件交付的方方面面，包括**敏捷开发管理**、**持续交付**和**技术运营**三大部分，同时，也有与应用架构设计、安全和组织结构对应的内容。
+
+不仅如此，对于开发DevOps工具的企业来说，系统和工具模型更加偏向于平台能力，稍加整理就可以作为平台需求输入到开发团队中。目前已经有不少公司在参考这套模型进行DevOps实践。下图展示了这个模型的整体框架，如果你正在企业内部推进DevOps落地的话，可以参考一下。
+
+<img src="https://static001.geekbang.org/resource/image/57/47/572cf00d2db3666801a3b51ccf951847.png" alt="">
+
+## 步骤与原则
+
+业界有这么多模型和框架，是不是随便找一个，直接照着做就行了呢？当然不是。
+
+毕竟，每家企业所处的行业现状、竞争压力、市场竞争态势都不尽相同，组织架构、战略目标、研发能力、资源投入等方面也千差万别，很难有一条标准的路径，让大家齐步走。比如，同样是金融企业，让万人规模的大银行和百人规模的城商行同台竞技，本身就有点强人所难。
+
+所以，在实际参考模型和框架的时候，我认为应该尽量遵循以下步骤和原则：
+
+1.**识别差距**
+
+从“道法术器”的角度来说，DevOps的成熟度模型和框架处于“法”这个层面，也就是一整套实施DevOps的方法论，相当于是一幅战略地图，最重要的就是对DevOps实施所涉及到的领域和能力图谱建立全面的认知。
+
+通过和模型、框架进行对标，可以快速识别出企业当前存在的短板和差距，并建立企业当前的能力状态基线，用于对比改进后所取得的效果。
+
+2.**锚定目标**
+
+数字化转型的核心在于**优化软件交付效率**。通过对标模型框架，企业需要明确什么是影响软件交付效率进一步提升的最大瓶颈，当前存在的最大痛点是什么，哪些能力的改善有助于企业达成预定的目标……同时，要根据企业的现状，甄别对标的差距结果，识别出哪些是真实有效的，哪些可以通过平台能力快速补齐。
+
+比如，对于一家提供CRM软件的公司来说，容器化部署虽然在环境管理、部署发布等领域有非常多的优势，但并非当前的核心瓶颈和亟需解决的问题，那么就不应该纳入近期的改进列表中。
+
+通过现状分析，企业可以把有限的资源聚焦在那些高优先级的任务上，识别出改进目标和改进后要达到的预期效果。这些效果需要尽量**客观**和**可量化**，比如缩短50%的环境准备时长。
+
+3.**关注能力**
+
+**模型和框架是能力和实践的集合**，也就是道法术器的“术”这个层面，所以在应用模型的过程中，核心的关注点应该在能力本身，而不是单纯地比较数字和结果。
+
+比如，亚马逊每天23000次部署的案例经常会被拿来举例子。这个数字的确相当惊人，但反过来想想，所有企业都需要达到这么高的部署频率吗？举个例子，一个客户端应用可以在几分钟内构建完成，但同样是构建，对于大型系统软件来说可能需要几个小时，那么到底多长时间才算达标呢？
+
+我们不能只关注这些明星企业所达到的成就，而忽略了自身的需求。所以，**正确的做法是根据锚定的目标识别所需要的能力，再导入与能力相匹配的实践，不断强化实践，从而使能力本身得到提升**。
+
+4.**持续改进**
+
+模型和框架本身也不是一成不变的，也需要像DevOps一样不断迭代更新，以适应更高的软件交付需要。另外，从今年的DevOps状态报告就可以看出，达到精英级别的比例从2018年的7%快速提升到2019年的20%，也就是说，行业整体的能力也在不断提升，这就对企业的软件交付能力提出了更高的要求。
+
+好了，以上这些就是我总结的企业应用DevOps能力模型和框架的步骤和原则。DevOps作为一个系统性工程，同样需要与之配套的立体化实施方法，只有将方法、实践和工具结合起来，全方位推进，才有可能获得成效。
+
+为了帮助你更好地理解DevOps实施的过程，我贴了一幅经典的部署引力图。
+
+<img src="https://static001.geekbang.org/resource/image/69/4e/6998eeeea55f7695e31f2dc9e6a3e94e.png" alt="">
+
+可以看出，当软件发布的频率从100天1次进化到1天100次的时候，分支策略、测试能力、软件架构、发布策略、基础设施能力，以及数据库能力都要进行相应的改动。比如分支策略要从长线分支变成基于特性的主干开发模式，而架构也要从大的单体应用，不断解耦和服务化。在实际应用中，企业涉及的领域甚至更多，因为这些仅仅是技术层面的问题，而组织文化方面也不可或缺。
+
+## 实践案例
+
+最后，我再跟你分享一个我之前参与改进的一个客户的案例。
+
+刚开始跟这个客户交流的时候，他千头万绪，抓不准重点，甚至由于组织严格划分职责边界，基本上每讲到一块内容，他就要拉相应的人过来聊，在许多人都聊完之后，项目的全貌才被拼凑出来。我相信这并不是个例，很多公司其实都是如此。
+
+于是，我们引入了能力成熟度模型，并基于模型对企业现有的能力水平进行了一次全盘梳理，并初步识别出了100多个问题点和40多个差距项。下面这张图就是汇总的大盘图，当然，部分数据进行了处理。
+
+<img src="https://static001.geekbang.org/resource/image/81/2f/8148a346c26600afcd64c10a75a5fc2f.png" alt="">
+
+接下来，针对识别出来的这些差距点，我逐项跟企业进行了沟通，重点在于锚定一期的改进目标和具体工作事项。在沟通过程中，我发现由于企业所处行业的特殊性，或者客观条件不具备，有些内容并非优先改进事项，于是将改进事项缩减为30个，并识别出这些改进事项的相互依赖和预期目标。比如，这个企业之前初始化一套环境需要2周左右的时间，为了加快整体交付能力，我们将改进目标定到1周以内完成。
+
+好啦，**有了改进目标和预期效果之后，就要分析哪些关键能力制约了交付效率的提升**。还拿刚才那个例子来说，核心问题在于**环境的初始化过程复杂**以及**审批流程冗长**。其中，原有的初始化过程是研发整理一份部署需求文档，来说明应用所依赖的环境和版本信息，并且这个需求还被整合到一个40多页的文档中。运维团队根据这个文档部署，每次都很不顺利，因为软件功能迭代所依赖的环境也在不断更新，但文档写出来就再也没人维护了。所以，很多人说文档即过时，就是这个道理。
+
+识别出核心能力在于**自动化环境管理**之后，团队决定引入基础设施即代码的实践来解决这个问题。关于具体的技术细节，我会在后面的内容中展开，这里你只需要知道，通过将写在文档中的环境配置说明，转变成配置化的信息，并维护在专门的版本控制系统中，从而使得基础环境的初始化可以在分钟级完成。
+
+当然，审批环境的优化属于非技术问题，而是流程和组织方面的问题。当大家认识到这些审批在一定程度上制约了发布频率的提升，就主动改进了现有流程。针对不同的环境进行不同级别的审批，使得单次审批可以在当天完成。
+
+这样优化下来，环境准备的时长大大缩短，从当初的2周缩短到了2天，改进效果非常明显。接下来，团队又识别出新的差距，锚定新的目标和预期效果，并且有针对性地补齐能力建设，走上了持续改进的阶段。
+
+由此可以看出，**DevOps的能力实践和能力框架模型相辅相成**：能力实践定义了企业落地DevOps的路线图和主要建设顺序，能力模型可以指导支撑方法的各类实践的落地建设；能力实践时刻跟随企业价值交付的导向，而能力模型的积累和沉淀，能够让企业游刃有余地面对未来的各种挑战。
+
+至于ITIL和CMMI，这些过往的框架体系自身也在跟随DevOps的大潮在持续演进，比如以**流程合规**为代表的ITIL最近推出了第4个版本。我们引用一下ITIL V4的指导原则，包括：**关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则和关注实践**。
+
+看起来是不是有点DevOps的味道呢？需要注意的是，DevOps不会彻底颠覆ITIL，只会在保证合规的前提下，尽可能地优化现有流程，将流动、反馈和持续学习改进的方法注入ITIL之中，从全局视角持续优化企业的价值交付流程。
+
+## 总结
+
+总结一下，今天我给你介绍了新技术和新思想的发展需要面对的鸿沟，而能力模型和框架是技术和思想走向成熟的标志，对于DevOps而言，也是如此。在面对诸多模型和框架的时候，企业需要立足自身，识别差异，锚定目标，关注能力，并持续改善软件的开发交付效率。DevOps的实施需要立体化的实施框架，通过模型、方法、能力和实践的相互作用，实现全方位的能力提升。
+
+到此为止，我们整体介绍了DevOps的基本概念、核心价值、实施方法和路线图，帮助你建立了一套有关DevOps的宏观概念。接下来我们就会开始深入细节，尤其是针对每一项核心实践，我会介绍其背后的理念、实施步骤，以及所依赖的能力模型，手把手地帮助你真正落地DevOps。
+
+## 思考题
+
+最后，给你留一道思考题：关于CMMI、ITIL和DevOps，你觉得它们之间的关系是怎样的呢？企业该如何兼顾多套模型框架呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+