mod

极客时间专栏/DevOps实战笔记/特别放送/特别放送（一）| 成为DevOps工程师的必备技能（上）.md

@@ -0,0 +1,127 @@
+<audio id="audio" title="特别放送（一）| 成为DevOps工程师的必备技能（上）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f3/b0/f355c5af97c63158c38fb57b222031b0.mp3"></audio>
+
+你好，我是石雪峰，今天到了“特别放送”环节。有很多留言问道：“DevOps专家这个岗位，需要的技能和技术栈有哪些？成长路径是怎样的呢？”
+
+我相信这应该是很多刚开始接触DevOps的同学最关心的问题。毕竟，从实用的角度出发，每个人都希望能够尽快上手实践。所以今天，我来跟你聊聊，我认为的DevOps工程师的必备技能以及学习路径。不过在此之前，我们要先了解DevOps工程师的岗位职责。
+
+全球最大职业社交网站LinkedIn（领英）2018年发布的一份[报告](https://business.linkedin.com/content/dam/me/business/en-us/talent-solutions/cx/2018/pdf/33-most-recruited-jobs.pdf)显示，当今全球最热门的招聘职位分别是**DevOps工程师、企业客户经理和前端开发工程师**。其中，排名第一的就是DevOps工程师。
+
+无独有偶，2019年全球最大知识共享平台Stack Overflow的[开发者调查报告](https://insights.stackoverflow.com/survey/2019)显示，在薪资排行榜上，DevOps工程师排名第三，仅次于技术经理和SRE（网站可靠性工程师）。而在去年的调查报告中，DevOps工程师的收入甚至排名第二。
+
+无论是人才市场需求，还是收入薪资水平，这种种迹象都表明，DevOps工程师已经成为了当今最炙手可热的岗位，收入也攀升至IT行业的金字塔顶端。难怪有越来越多的人开始接触和学习DevOps。
+
+但是，DevOps这样一个刚刚诞生10年的“新兴事物”，并不像一门专业技术那样，有一条相对清晰的学习路径，以及经典的学习资料，比如你要学习Java，就可以从《Java编程思想》看起。
+
+除此之外，DevOps似乎又跟软件工程的方方面面有着说不清的关系。我跟你分享一幅DevOps技能发展路线图，根据这幅路线图，你要从编程语言入手，理解操作系统原理、系统性能、网络安全、基础设施即代码、CI/CD、运维监控和云技术等等。
+
+<img src="https://static001.geekbang.org/resource/image/df/b3/df028795541ad1758d13004acd68fcb3.png" alt="">
+
+> 
+图片来源：[https://roadmap.sh/devops](https://roadmap.sh/devops)
+
+
+怎么样，是不是看到这么一堆名词就瞬间头大了吧？如果要把这些所有的技术全部精通，那至少得是CTO级别的岗位。对普通人来说，这并不太现实。毕竟，**啥都懂点儿，但是啥都不精通，本身就是IT从业者在职业发展道路上的大忌**。
+
+如果要说清楚这个岗位，核心就是要回答3个问题：
+
+1. DevOps工程师在公司内承担的主要职责是什么？
+1. 为了更好地承担这种职责，需要哪些核心技能？尤其是从我接触过的这些公司来看，有哪些技能是当前最为紧俏的呢？
+1. 学习和掌握这些技能，是否存在一条可参考的路径呢？
+
+接下来，我们就重点聊一聊这些内容。
+
+## DevOps工程师的岗位职责
+
+关于DevOps工程师这个岗位，一直以来都存在着很大的争议。很多人认为DevOps应该是一种文化或者实践，而不应该成为一个全新的职位或者部门，因为这样会增加公司内部的协作壁垒。
+
+其实，我倒觉得没有必要纠结于这个Title，因为很多时候，DevOps跟公司内部已有的角色存在着重叠。比如，开发变成了DevOps开发，运维变成了DevOps运维。另外，在不同的公司里面，类似角色的岗位名称也大不相同。比如，在DevOps状态报告中，DevOps就和SRE被归为一类进行统计。而在公司中实际负责推行DevOps的部门，至少我见过的就有工程效能团队、运维团队、配管团队，甚至还有项目管理团队。可见，不同公司对于DevOps工程师的职责定义也同样存在着差异。
+
+但不管怎样，我觉得谈到DevOps工程师职责的时候，除了本职工作的内容以外，至少还应该额外关注3个方面：
+
+**1.工具平台开发**
+
+关于工具平台开发，争议应该是最小的，而且这也是很多公司推行DevOps的起点。**因为工具是自动化的载体，而自动化可以说是DevOps的灵魂**。随着公司规模越来越大，研发内部的协作成本也随之水涨船高，那么工具平台的能力水平就决定了公司交付能力的上限。
+
+但问题是，因为种种原因，很多公司只有大大小小的分散工具，并没有一套完整的研发协同工作平台，这本身就制约了协作效率的提升。你可以想象一下，研发每天要在大大小小的系统里面“跳来跳去”，很多功能甚至还是重复的，这显然是很浪费时间的。
+
+比如，你明明已经在代码托管平台上做了代码评审，结果提测平台上面还有个必填项是“你是否做过了评审？”是不是很让人抓狂呢？这背后的主要原因，就是缺乏顶层设计，或者压根就没有专人或者团队负责这个事情。这样一来，团队各自为战，发现一个痛点就开发一个工具，发现一个场景就引入一个系统，再加上考核指标偏爱从0到1的创造性工作，也难怪每个高T升级都要有自己的系统加持了。但如果任由这种趋势发展下去，内部的重复建设就难以避免了。
+
+所以，对于DevOps工程师而言，除了要关注原有的工具重构、新功能的开发之外，更要聚焦于整个软件交付流程，将现有的工具全面打通，以实现可控的全流程自动化。也就是说，不仅仅要追求点状的工具，还要包括整条线上的工具链，从而形成覆盖软件交付完整流程的工具体系。
+
+另外，工具平台同样是标准化流程的载体，同时也是DevOps实践的载体，所以在设计实现时，需要考虑这些实践的支持。举个例子，在配置管理领域，将一切纳入版本控制是不二法则。那么，在建设工具平台的时候，就需要始终有这样的意识，比如记录流水线的每一次配置变更的版本，并且能够支持快速的对比回溯。
+
+**2.流程实践落地**
+
+其次，无论是工具平台的推广落地，还是结合平台的流程改进，都需要有人来做。毕竟，即便是完全相同的工具，在不同人的手里，发挥的作用也千差万别，把好好的敏捷管理工具用成了瀑布模式的人也不是少数。而针对流程本身的优化，也是提升协作效率的有效手段。
+
+比如在有的公司里，单元测试需要手动执行，那么当工具平台具备自动化执行的能力，并且能够输出相应的报告时，这部分的操作流程就应该线上化完成。再比如，以往申请环境需要走严格的线上审批流程，当环境实现自动化管理之后，这些流程都可以变为自服务，通过工具平台进行跨领域角色的交叉赋能，从而实现流程优化的目标。
+
+另外，我接触过的一些公司倾向于在不改变流程的前提下，推动DevOps落地。坦率地说，这种想法是不现实的。如果流程上没有约束开发和测试共同为结果负责，那开发为什么要跟测试共同承担责任呢？出了问题又怎么可能不扯皮呢？因此，**如果你在公司内部负责流程改进，遇到问题就应该多问几个为什么，找到问题的本源，然后将流程和工具相结合，双管齐下地进行改进。**
+
+所以，**理念和实践的宣导，内部员工的培训，持续探索和发现流程的潜在优化点，这些也都是DevOps工程师要考虑的事情**。
+
+**3.技术预研试点**
+
+最后，各种新技术新工具层出不穷，哪些适用于公司现有的业务，哪些是个大坑呢？如果适合的话，要如何结合公司的实际情况，评估潜在的工具和解决方案，而不是盲目地跟随业界最佳实践呢？类似技术债务的识别和偿还这种重要不紧急的事情，到底什么时候做合适呢？
+
+另外，如果公司决定开始推行单元测试，那么，选用什么样的框架，制定什么样的标准，选择什么样的指标，如何循序渐进地推进呢？这些同样非常考验团队的功底。如果步子一下子跨得太大了，到最后就可能成为形式主义了。
+
+你可能会觉得，我就是一个小开发、小运维，怎么能推动这么大的事情呢？但实际上，DevOps从来都不是某一个人，或者某一个角色的职责，而是整个研发交付团队所共享的职责。在你力所能及的范围内，比如在你所在的部门内部，开展DevOps的理念宣导和技术培训，鼓动领导参加行业的大会，在和上下游团队协作的时候向前一步，这些都是DevOps所倡导的自服务团队应该具备的能力。
+
+## DevOps工程师的主要技能
+
+说完了DevOps工程师主要负责的事情，接下来我们就来看看DevOps工程师所要具备的能力。我从实用的角度出发，总结了DevOps工程师的核心能力模型。
+
+其中，**能力模型分为两个方面：专业能力和通用能力**。专业能力也就是常说的硬实力，是IT从业人员身上的特有能力，比如软件工程师会写代码，就跟导演会拍电影，司机会开车一样。而通用能力，更加接近于软实力，这些能力并不局限于某一个岗位或者职业，是所有人都应该努力培养的能力。很多时候，当硬实力到达天花板之后，软实力的差异将决定一个人未来的高度，这一点非常重要。
+
+### 软实力
+
+我们今天先从软实力说起。在讲具体的软实力之前，我先跟你分享一个小故事。
+
+我在国外听过这样一种说法：在企业中，印度裔的工程师往往比华裔工程师的岗位职级要高。为什么会这样呢？我曾经做过一个跨中美印三地的工程团队的负责人，我发现，每次我跟印度工程师交代一个事情，他们总能又快又好地做出一个特别清晰漂亮的PPT。我特意问过他们是怎么做到的。原来，他们在上学时受过这方面的训练，还专门练习过表达、演讲等技能，可见，事出必有因，软实力对个人的发展至关重要。
+
+那么，作为一名DevOps工程师，需要具备什么软实力呢？
+
+**1.沟通能力**
+
+DevOps倡导的核心理念就是沟通和协作，所以，难怪沟通能力会排在软实力的第一名。
+
+**在推动DevOps落地的过程中，你需要同时具备向上沟通、向下沟通和横向沟通的能力**。提炼DevOps实施框架和落地价值，寻求领导层的支持，需要**向上沟通**；打破组织间的边界，建立跨团队的协同，需要**横向沟通**；引导团队快速完善平台工具能力，表明工作的意义和价值，提升大家的主动性，需要**向下沟通**。所以你看，其实每天的工作中都充满了大量的沟通。
+
+需要注意的是，**沟通能力不仅限于语言能力，很多时候，开发运维的沟通是基于代码完成的**。所以，良好的注释风格、清晰结构化的描述方式……这些细节往往也能提升沟通的效率。
+
+比如有一种很DevOps的方式，就是ChatOps，是以GitHub的Hubot为代表的对话式运维，慢慢扩展为人机交互的一种形式。通过建立一种通用的沟通语言，打破开发和运维之间的隔阂。
+
+**2.同理心**
+
+DevOps希望团队可以共享目标，共担责任，但是实际上，哪个团队不想更加自动化、更加高效地工作呢？所以，DevOps工程师要能够站在对方的角度来看问题，设身处地地想想他们的困难是什么，我能做些什么来帮助他们。这种同理心也是弥合团队分歧，建立良好的协作文化所必需的能力。
+
+除此之外，**培养团队以用户为中心的思想，也是很好的方式**。这里的用户，不是外部用户，而是在交付流程中存在交付关系的上下游部门。在交付一个版本的时候，要尽力做到最好，而不是不管三七二十一，先丢过去再说。
+
+我还是要再强调一下，**同理心只有在流程和机制的保证之下才能生根发芽**。
+
+**3.学习能力**
+
+DevOps工程师需要了解的东西真得很多，因此，能够在有限的时间里快速学习新的技能，并且有意愿主动地改进提升，也是一种能力。
+
+在DevOps工程师的眼里，从来没有“完美”二字。比如完美的流程、完美的技术实现、完美的软件架构等。他们似乎天生就有一种能力，那就是能发现问题并时刻想着可以做到更好。但实际上，如果没有日积月累的思考，没有外部优秀实践的学习，没有开放的沟通和交流，是没有办法知道，原来还有一种更好的工作方式的。引用质量管理大师戴明博士的一句话：
+
+> 
+Don’t just do the same things better – find better things to do.
+
+
+很多时候，我们都在等待一个完美的时机，比方说，你打算学习一个新的知识点，但要等到工作都完成了，没人来打扰，有大段的时间投入才开始学习。**但实际上，哪来这么多准备就绪的时候呢？真正的学习者都是在没有条件来创造条件的过程中学习的。所以，如果想开始学习DevOps，我信奉的原则只有一个，那就是先干再说**。
+
+## 总结
+
+今天，我给你介绍了DevOps工程师的前景，可以说，现在是这个岗位的黄金时期。我还给你介绍了DevOps工程师的主要职责，包括工具平台开发，流程实践落地和技术预研试点，这些都是在完成本职工作的基础上需要额外考虑的。在个人技能要求方面，我重点提到了3项软实力，希望你始终记得，软实力不等于玩虚的，这对未来个人的发展高度至关重要。
+
+在下一讲中，我会跟你分享DevOps工程师必备的硬技能，以及成长路径，敬请期待。
+
+## 思考题
+
+你所在的公司是否有DevOps工程师的岗位呢？他们的职责要求是怎样的呢？你觉得还有哪些软实力是DevOps工程师所必备的呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/特别放送/特别放送（三）| 学习DevOps不得不了解的经典资料.md

@@ -0,0 +1,183 @@
+<audio id="audio" title="特别放送（三）| 学习DevOps不得不了解的经典资料" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3f/f7/3fcf422d8f32b70500096cd9630ceef7.mp3"></audio>
+
+你好，我是石雪峰。
+
+今天又到了特别放送的环节，在学习交流DevOps的过程中，经常有人会问这样的问题：
+
+- 我想学习DevOps，可以推荐一些好的书和资源吗？
+- DevOps相关的最新行业案例，我可以在哪里获取呢？
+- 你是怎么知道这么多有趣的故事的呢？
+
+这些问题的“出镜率”特别高，所以，我今天专门来跟你聊聊有关DevOps学习资料的事情。
+
+你应该也有感觉，在这个信息爆炸的时代，如果想要了解一个新的事物，相关的信息不是太少，而是太多了。像DevOps这种热门话题，相关的资料网上一搜就一大把。各种新书也像“采用了DevOps实践”一样，发布频率越来越快。信息一多，我们就很容易焦虑，这么多资料，什么时候才能看完啊？
+
+更何况，如果单单只是臻选有用的资料，就要花费大量的时间，按照精益的理论来说，这也是不增值的活动呀。在这个时间稀缺的时代，想要花大段的时间投入到一件事情上，找到一个靠谱和有价值的信息，就成了很多人开始学习的第一步，
+
+所以，为了让你在专栏之余可以更加有效地持续学习，我特意整理了一份我认为DevOps从业人员需要了解和关注的资料，你可以参考一下。
+
+需要强调的是，有针对性地精读一本好书的一部分内容，要比泛泛地读好几本书要更有收获一些，也就是“**贵精不贵多”，先定下一个小目标，然后沉下心来反复地学习实践，这个道理在大多数领域都是适用的**。
+
+## 一份报告
+
+如果说，DevOps领域有行业公认的权威资料的话，DevOps状态报告自然是不二之选。
+
+从2014年开始，这份报告每年发布一次，主要编写方也经历了好几次变迁，从最开始的Puppet实验室、IT Revolution到DORA（DevOps Research &amp; Assessment）的加入，再到去年，DORA和Puppet分家，两边各自推出了自己的DevOps状态报告。
+
+但从影响力来说，我更推荐DORA的这份报告，从去年开始，这份报告正式改名为：加速度，DevOps状态报告。
+
+提到DORA，你可能不太熟悉，但是如果说到DORA的两位核心创始人Nicole博士和Jez Humble，相信你一定有所耳闻，他们也是我今天推荐的一些书的作者。
+
+有意思的是，去年DORA宣布加入谷歌，其主要成员也被谷歌云收编，比如Jez Humble，目前就是谷歌云的技术布道师。
+
+回到报告本身，我在2017年就开始进行报告的本地化工作。从近两年来看，报告的体量在持续扩大，比如，今年的报告洋洋洒洒有80页内容，而且是全英文的。
+
+那么，关于这份报告，重点是要看什么呢？纵观过去几年的报告模式，我给你画个重点：**核心是看趋势、看模型和看实践**。
+
+**首先看趋势**。
+
+每年的报告都会有一些核心发现，这些发现代表了DevOps行业的发展趋势。比如，今年的报告就指出，云计算能力的使用依然是高效能组织和中低效能组织的分水岭，所以，如果公司还在纠结是否要上云，不妨从DevOps的角度思考一下，使用云计算能力带给交付能力的提升可以有多明显。
+
+另外，公司内的DevOps组织比例也从2014年的14%提升到了今年的27%。由此可见，越来越多的公司在拥抱DevOps，至少从组织层面可以看到，越来越多带有DevOps职责，或者是以DevOps命名的团队出现。这对于公司内部职责的划分和团队架构演进，具有一定的指导意义。
+
+当然，不得不提的，还有衡量DevOps实施效果的4个核心指标，也就是**变更前置时间、部署频率、变更失败率和故障修复时长**。
+
+从2014年的第一份报告开始，每年的报告都在对比这4个核心指标在不同效能团队之间的变化和差异。实际上，就我观察，国内很多公司的DevOps度量体系，都深受这些指标的影响，或多或少都有它们的影子。
+
+可以说，这4个指标已经成为了衡量DevOps效果的事实标准，甚至有人直接把指标拿给老板看，说：“你看，高效能组织比低效能组织的故障恢复时长要快2000倍，由此可以证明，DevOps是势在必行的。”
+
+我个人觉得，没有必要纠结于数字本身，这东西吧，看看就好，更多的还是要透过数据看趋势。
+
+比如，去年的指标数据就显示，在交付能力方面，不同组织间的差距在缩小，相应的质量维度的指标差异却在拉大。这就说明，通过初期的自动化能力建设，团队可以快速地提升交付水平。但是，由于缺少质量能力的配套，很容易产生更多的问题，这就带来一个警示，在快速提升交付能力的同时，质量建设也不能落在后面。
+
+<img src="https://static001.geekbang.org/resource/image/79/ac/79665c64da0a9ccab7f0244c5e59eeac.png" alt="">
+
+**关于报告，其次是看模型**。
+
+我在[第4讲](https://time.geekbang.org/column/article/148878)中提到过一个观点：**任何技术的走向成熟，都是以模型和框架的稳定为标志的**。因为当技术跨越初期的鸿沟，在面对广大的受众时，如果没有一套模型和框架来帮助大众快速跟上节奏，找准方向，是难以大规模推广和健康发展的。
+
+在软件开发领域是这样，在其他行业也是如此，要不然，为啥会有那么多国标存在呢？所以说，模型和框架的建立是从无序到有序的分水岭。
+
+在今年的状态报告中，研发效能模型进一步细化为软件交付运维模型和生产力模型。今天我不会深入解析模型本身，但我会在专栏后面的内容中结合实际案例进行详细解释，从而帮助你更好地理解。
+
+但是，从过往的报告可以看出，每一年关于模型的进化是整个报告的核心内容，报告也在不断覆盖新的领域，试图更加全面地揭示影响软件开发效能的核心要素。在实践DevOps的时候，你可以参考这个能力模型，识别当前的瓶颈点，在遇到拿捏不准的决策时，也可以参考模型中要素的影响关系。
+
+比如，公司内部经常会争论是否需要更加严格的审批流程，希望借助严格的审批流程，促使软件交付更加有序和可靠。很多系统和需求在提出的时候，都是以这种思想为指导的。我一直对这种流程的有效性抱有怀疑，加入更多的领导审批环节，除了出问题的时候大家一起“背锅”之外，并没有带来什么增值活动。
+
+在今年的模型中，这种观点得到了印证。**重流程管控不利于软件交付效能的提升，轻流程管控也不会影响软件交付质量，关键要看公司是否选择一种“更好”的做法来实现管控的目的**。
+
+<img src="https://static001.geekbang.org/resource/image/c8/63/c87bd960e6743511dae31617f99e0c63.png" alt="">
+
+最后，我们要重点关注**实践**。
+
+在实施DevOps的时候，经常会有这样的困扰：道理都懂，却仍然做不好DevOps。所以，DevOps落地的核心无外乎实践和文化，而实践又是看得见摸得着的，这一点当然值得关注。在状态报告中，有很大篇幅都在介绍实践部分，这些实践都是在大多数公司实施总结出来的，并且得到了实际的验证，具有很强的参考性。
+
+比如，今年的报告重点介绍了技术债务、灾难恢复测试和变更管理流程这几个方面的实践，这些都是企业实施DevOps时的必经之路。
+
+比如灾难恢复测试，很多公司都有非常详尽的文档，但是如果找他们要操作记录，他们却又很难拿出来。
+
+我之前就见过一家国内Top的公司，说是在做关键数据的备份，但实际去看才发现，这个备份任务已经很长时间处于失败状态了。
+
+如果有定期的灾难恢复测试，类似的这种问题是一定可以发现的。而**往往在灾难发生的时候，才能体现一家公司的工程能力水平**。
+
+比如，Netflix正是因为混沌工程，才没有受到AWS云服务down机的影响，这和日常的演练是密不可分的。
+
+从2014年至今的DevOps状态报告的中英文版本，我已经收集并整理好了，你可以点击[网盘](https://pan.baidu.com/s/1W7-_et-wulD7AueBU2KTow)链接获取，提取码是mgl1。
+
+## 几本好书
+
+讲完了报告，接下来，我再给你推荐几本好书。
+
+**1.《[持续交付](https://item.jd.com/1027475074.html)》&amp;《[持续交付2.0](https://item.jd.com/12512514.html)》**
+
+谈到DevOps里面的工程实践，持续交付可以说是软件工程实践的终极目标。对于在企业内部推进DevOps工程能力建设的人来说，这两本书可以说是案头必备，常看常新。
+
+对我自己来说，因为2011年机缘巧合地拿到了第一版第一次印刷的《持续交付》这本书，我的职业生涯彻底改变了。因为我第一次发现，原来软件交付领域有这么多门道。帮助组织提升交付效率这个事情，真是大有可为。
+
+《持续交付》围绕着软件交付的原则，给出了一系列的思想、方法和实践，核心在于：**以一种可持续的方式，安全快速地把你的变更（特性、配置、缺陷、试验），交付到生产环境上，让用户使用**。你可以参考一下软件交付的8大原则。
+
+- 为软件交付创建一个可重复且可靠的过程
+- 将几乎所有事情自动化
+- 将一切纳入版本控制
+- 频繁地做痛苦的事情
+- 内建质量
+- DONE意味着已发布
+- 交付过程是每个成员的责任
+- 持续改进
+
+很多人都有《持续交付》这本书，但我敢打赌，真正能沉下心来把这本书看透的人并不多，因为这本书里面通篇都是文字，而且有些难懂，如果没有相关的实践背景，基本上就跟看天书差不多了。
+
+所以，通读《持续交付》并不是一个好的选择，我建议你**尽量带着问题有选择性地去读**。
+
+到了《持续交付2.0》，乔梁老师创新性地将精益创业的思想和《持续交付》结合起来，更加强调IT和业务间的快速闭环，也更加适应当今DevOps的发展潮流。
+
+另外，乔梁老师的文笔更加流畅，读起来更加轻松，他会结合案例进行说明，对于实际操作的指导性也更强。毫无疑问，他是国内软件工程领域的集大成者。
+
+如果你对软件开发流程的工程实践不太了解，你可以读一读这两本书。
+
+当然，对于开发、测试、运维人员这些软件交付过程中必不可少的角色来说，也可以用来拓展知识领域。
+
+**2.《[精益创业](https://item.jd.com/11055746.html)》&amp;《[Scrum精髓](https://item.jd.com/11462889.html)》&amp;《[精益产品开发](https://item.jd.com/12132997.html)》&amp;《[精益开发与看板方法](https://item.jd.com/11862173.html)》**
+
+关于管理实践和精益方面，我给你推荐4本书。
+
+《精益创业》提出的MVP（最小可行产品）思想已经被很多的企业奉为圭臬。它的核心是，只有经过真实市场和用户的验证，想法才是真正有效的，产品需要在不断的验证和反馈过程中持续学习，持续迭代，而不是试图一步到位，耗尽所有资源，从而失去了回旋的余地。
+
+《Scrum精髓》适合于使用Scrum框架的敏捷团队学习和实践，以避免Scrum实施过程中形似而不神似的问题。同时，这也是立志成为Scrum Master的同学的红宝书。
+
+《精益产品开发》是何勉老师在2017年出版的一本基于精益思想和精益看板方法的著作。在精益软件开发领域，这本书和李智桦老师的《精益看板方法》，都是看一本就够了的好书。
+
+这几本书比较适合想要了解敏捷，或者是在实际工作中践行敏捷开发方法的同学阅读。另外，精益思想可以说是DevOps的理论源泉，很多的文化导向，以及持续改进类工作都跟精益思想有密切的关系。
+
+**3.《[DevOps实践指南](https://item.jd.com/12350780.html)》&amp;《[Accelerate：加速](https://item.jd.com/29263749137.html)》**
+
+如果你想了解DevOps的全貌以及核心理论体系和实践，《DevOps实践指南》和《Accelerate：加速》就是最好的选择了。这两本书的作者都是DevOps行业内的领军人物，作为Thought Leader，他们引领的DevOps的体系在不断向前演进。
+
+其中，《DevOps实践指南》，也就是俗称的Handbook，重点介绍了DevOps实践的三步工作法，还包含了大量DevOps实施过程中的参考案例。而《Accelerate：加速》的作者就是DevOps状态报告的作者。他在这本书中揭示了状态报告背后的科学方法，并提出了DevOps能力成长模型，以帮助你全面提升软件交付能力。
+
+**4.《[凤凰项目](https://item.jd.com/11789836.html)》&amp;《[人月神话](https://item.jd.com/12401749.html)》&amp;《[目标](https://item.jd.com/12610010.html)》**
+
+最后，我想再推荐三本小说，这也是我读过的非常耐看的几本书了。
+
+其中，《凤凰项目》提出的DevOps三步工作法和《DevOps实践指南》一脉相承；《人月神话》是IT行业非常经典的图书，畅销40余年；《目标》则是约束理论的提出者高德拉特的经典著作，他所提出的改进五步法构成了现代持续改进的基础。
+
+## 大会，网站和博客
+
+当然，报告和书只是DevOps资源中的一小部分，还有很多信息来源于大会、网站和博客，我挑选了一些优质资源，分享给你。
+
+- [DEOS](https://events.itrevolution.com) ：DevOps国际峰会，以案例总结著称；
+- [DevOpsDays](https://devopsdays.org/)：大名鼎鼎的DevOpsDays社区；
+- [TheNewStack](https://thenewstack.io/) ：综合性网站，盛产高质量的电子书；
+- [DevOps.com](https://devops.com/) ：综合性网站；
+- [DZone](https://dzone.com) ： 综合性网站，盛产高质量的电子书；
+- [Azure DevOps](https://devblogs.microsoft.com/devops/)：综合性网站，盛产高质量的电子书；
+- [Martin Fowler](https://www.martinfowler.com/bliki/) ：Martin Fowler的博客；
+- [CloudBees Devops](https://www.cloudbees.com/devops) ：Jenkins背后的公司的博客。
+
+在这些资源中，有一些值得你重点关注一下。
+
+比如，Gene Kim发起的DOES（DevOps企业峰会）就是获取实践案例的绝佳场地；而DZone和NewStack经常会推出免费的电子书和报告，也值得订阅；Martin Fowler的博客，每一篇内容都是精品，对于很多技术细节可以说是起到了正本清源的作用，值得好好品味。
+
+说了这么多，最后我还想再花一点点时间，跟你聊聊学习这个事情。我跟你分享一幅美国学者爱德加·戴尔提出的学习金字塔模型图，这个模型也是目前比较有参考性的模型之一。
+
+<img src="https://static001.geekbang.org/resource/image/f2/d6/f2de4f052d1c4e90d5caf3e5f863bfd6.jpeg" alt="">
+
+> 
+图片来源：[https://www.businessdirect.bt.com/](https://www.businessdirect.bt.com/)
+
+
+在这个模型中，学习的方式分为两种，一种是主动学习，一种是被动学习。其实，无论是读书，看视频，还是听专栏，都属于是被动式的学习，最终收获的知识可能只有输入信息的一半儿，这还是在记性比较好的情况下。大多数时候，看得越多，忘得越多，这并不是一种特别有效的学习方式。
+
+实际上，对于DevOps这种理念实践、技术文化、硬技能、软实力交织在一起的内容来说，主动学习的方式是不可或缺的，比如**案例讨论，线下交流，在实践中学习**等。
+
+所以，希望你能多思考，多总结，结合工作中的实际问题，摸索着给出答案，并积极分享，跟大家讨论。只有主动思考，才能消化吸收，最终总结沉淀出一套自己的DevOps体系认知。
+
+## 总结讨论
+
+好了，今天我跟你聊了DevOps的学习资料，包括状态报告、书籍和大会、网站、博客。不过，对于DevOps来说，这些也仅仅是点到为止。
+
+我想请你来聊一聊，你自己在学习和实践DevOps的过程中，有没有私藏的干货和渠道呢？如果有的话，希望你可以分享出来，我们共建一个DevOps相关的资源库，并在GitHub上进行开源维护，从而帮助更多人了解和学习DevOps。
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/特别放送/特别放送（二）| 成为DevOps工程师的必备技能（下）.md

@@ -0,0 +1,120 @@
+<audio id="audio" title="特别放送（二）| 成为DevOps工程师的必备技能（下）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/64/51/648ba3c530957179fd48d8275be09751.mp3"></audio>
+
+你好，我是石雪峰。在上一讲，我介绍了DevOps工程师的具体职责以及DevOps工程师必备的3项软实力，分别是沟通能力、同理心和学习能力。有了这些认知之后，我们今天来看看“重头戏”：DevOps工程师必备的硬实力以及学习路径。
+
+## DevOps工程师必备的硬实力
+
+所谓硬实力，说白了就是指一个人的技术能力。软实力通常是“只可意会不可言传”的，但技术本身就具体多了，重要的是，技术水平的高低相对来说也更好衡量。在公司里面，技术人员要想获得晋升，重点就是依靠技术能力。
+
+IT行业覆盖的技术领域非常广，而且近些年的新技术也是层出不穷的，从入门到精通任何一门技术，都需要大量时间和精力的投入。那么，在面对这么多技术的时候，究竟要选择从哪个开始入手，真是一个难题。对于希望成为DevOps工程师，甚至是DevOps专家的你来说，究竟有哪些必须掌握的核心技术呢？
+
+**1.代码能力**
+
+现在这个时代，代码能力可以说是最重要的硬实力了。IT行业自然不用说，像运维有运维开发，测试也有测试开发，就连产品经理都要懂代码，不然可能都没办法跟开发同学顺畅交流。
+
+对于工具平台自身的建设而言，代码能力自然是重中之重。这不仅仅在于通过写代码来实现工具平台本身，还在于你能了解开发的完整过程。这些平台的用户每天跟代码打交道的时间可能比跟人打交道的时间还多，如果你不能理解他们的日常工作方式，那么你做出来的工具平台，又怎么能真正解决团队的问题呢？
+
+这里提到的**代码能力包含两个方面，分别是脚本语言能力和高级语言编程能力**。
+
+- **脚本语言能力**。这对于运维工程师来说自然是驾轻就熟，各种VIM、Emacs手到擒来，Shell和Python也是轻车熟路。而对于开发人员来说，难点不在于语法本身，而在于对关联操作系统和命令的理解上。毕竟，脚本语言是一种快速的自动化手段，追求的是高效开发，简单易用。
+- **高级语言编程能力**。你需要至少掌握一门高级语言，无论是Java、Python还是Ruby和PHP。**其实语言只是工具，你不用过度纠结于选择哪门语言，要求只有一个，就是你能用它来解决实际问题**，比如能够支持你实现面向移动端或者Web端的工具平台开发。**为了写出好代码，而不仅仅是写出能用的代码，你也需要对于一些常见的开发框架和开发模式有所了解**。这是一个相对漫长的过程，绝对不是什么“21天精通XX语言”就够了。因为看得懂和写得好，完全是两码事。
+
+好的代码是需要不断打磨和推敲的。**与其说写好代码是一门技术，不如说是一种信仰**。我们团队的内部沟通群名叫作“WBC团队”，“WBC”也就是“Write Better Code”的缩写，这其实也是我们团队对自己的一种激励。在日常的开发过程中，我们会不断发现和总结更好的实现方式，在内部分享，互相学习，从而持续提升代码能力。我截取了一部分我们最近优化流水线脚本的经验总结，你可以参考一下。其实，每个人都能总结出自己的代码心经。
+
+<img src="https://static001.geekbang.org/resource/image/91/0b/9124fd4c7ef664ba04af700faca06e0b.jpg" alt="">
+
+**2.自动化能力**
+
+在自动化方面，你首先需要对CI/CD，也就是持续集成和持续交付，建立起比较全面的认知。因为CI/CD可以说是DevOps工程领域的核心实践，目前大部分公司都在集中建设软件的持续交付能力，尤其是以流水线为代表的持续交付平台，很多时候就同DevOps平台划上了等号。
+
+接下来，为了实现全流程的自动化，你需要能够熟练使用CI/CD各个关键节点上的典型工具，并且了解它们的设计思路。
+
+一方面，目前很多公司都在拥抱开源，参与开源，开源工具自身的成熟度也非常高，并且逐渐取代商业工具，成为了主流方案。通过直接使用开源工具，或者基于开源工具进行二次开发，也是自动化领域投入产出比最高的方式。所以，像版本控制工具Git、代码托管平台Gitlab、CI工具Jenkins、代码扫描工具Sonar、自动化配置管理Ansible、容器领域的Docker、K8S等等，这些高频使用的工具都是你优先学习的目标。
+
+另一方面，**无论是开源工具，还是自研工具，工具与工具之间的链路打通也是自动化的重要因素**。所以，在理解开源工具的实现方式的基础上，就要能做到进可攻，退可守。无论是封装，还是自研，有了工具的加持，CI/CD也会更加游刃有余。
+
+关于DevOps的工具图谱，我跟你分享一个信通院的DevOps能力成熟度模型版本，供你参考。值得注意的是，**工具不在多，而在精**。其实，工具的设计思路和理念有共通之处，只要精通单个节点上的工具，就可以做到以点带面。
+
+<img src="https://static001.geekbang.org/resource/image/91/bd/91b7d3327892002d68029c7817fe06bd.png" alt="">
+
+**3.IT基础能力**
+
+我始终认为，运维是个特别值得尊敬的工种，也是DevOps诞生的原点。如果你不是运维出身，那你要重点掌握运维的基础概念，最起码要了解**Linux操作系统方面的基础知识**，包括一些**常用的系统命令使用**，以及**网络基础和路由协议**等。毕竟，对于开发者来说，他们通常习惯基于IDE（集成开发环境）图形界面工作。比如，如果问一个iOS开发同学怎么通过命令行的方式进行构建调试，或者如何用代码的方式实现工程的自动化配置，他可能就答不上来了。
+
+另外，随着基础设施即代码的技术不断成熟，你还要能看懂环境的配置信息，应用自动化构建、运行和部署的方式等，甚至可以自行修改环境和应用配置，这样才能实现所谓的开发自运维。虽然在大多数公司，运维的专业能力一般都会通过运维平台对外提供服务，但对于基础概念，还是需要既知其然，也知其所以然。
+
+**4.容器云能力**
+
+云计算对于软件开发和部署所带来的变化是革命性的。未来企业上云，或者基于云平台的软件开发会慢慢成为主流。而容器技术又天生适合DevOps，Kubernetes可以说是云时代的Linux，基于它所建立的一整套生态环境，为应用云化带来了极大的便利。
+
+所以，无论是容器技术的代表Docker，还是实际上的容器编排标准Kubernetes，你也同样需要熟悉和掌握。尤其是在云时代，基于容器技术的应用开发和部署方式，都是DevOps工程师必须了解的。
+
+**5.业务和流程能力**
+
+在任何时候，DevOps的目标都是服务于业务目标，DevOps本身也从来不是墨守成规的方式，而是代表了一种变革的力量。所以，加强对业务的理解，有助于识别出DevOps改进的重点方向，而流程化的思维建设，有助于突破单点，放眼全局。
+
+很多时候，**企业需要的不仅仅是一个工具，而是工具所关联的一整套解决方案，其中最重要的就是业务流程**。
+
+对于DevOps工程师来说，**要有能力发现当前流程中的瓶颈点，并且知道一个更加优化的流程应该是怎样的**，这一点也是制约工程师进一步拓展能力的瓶颈之一。
+
+举个例子，对于开发DevOps平台工具来说，你可能认为最合适承担的团队就是开发团队，因为他们的代码能力最强。但是实际上，DevOps平台的设计，很多时候都是由最熟悉企业内部研发流程的团队来主导的。正因为DevOps工程师的工作应该同业务紧密联系，更加关注于全局交付视角，所以很多时候，配置管理、质量管理、项目管理和技术运维团队更多地在承担相近的角色。**毕竟，只有方向正确，所做的一切才是加法。**
+
+<img src="https://static001.geekbang.org/resource/image/df/d2/df7819fcd4372b837317754a4c72c9d2.png" alt="">
+
+## 学习路径
+
+那么，要想成为DevOps工程师，是否有一条普适性的学习路径呢？实际上，这个问题就跟我们要在公司推行DevOps，是否存在一条通用的改进路径一样，并不是一个容易回答的问题。
+
+从前面的能力模型可以看出，DevOps工程师特别符合现在这个时代的要求，他具备多重复合能力，是典型的全栈工程师，或者“梳子型”人才。因为只有这样，才能充分弥合不同角色之间的认知鸿沟，堪称团队内部的万金油。
+
+基于过往在公司内部推行DevOps的经验，以及当前行业的发展趋势，我有几条建议送给你：
+
+**1.集中强化代码能力**
+
+**未来的世界是软件驱动的世界**。我们以前总说的必备能力，比如外语、开车等，未来都可以被软件所取代。而编程能力即将成为下一个必备能力，甚至连国务院发布的《新一代人工智能发展规划》中都提到，要在中小学普及推广编程教育。
+
+**而写可以用的代码，和写好的代码之间，距离绝不只是一点点而已**。你可能会说，以后都用人工智能来编程了，可问题是人工智能从何而来？又是谁来训练和标注人工智能的呢？所以，越是基础的能力，越不会过时，比如数学、核心的编程思想、数据结构，以及基于代码构建对世界的认知和建模能力。
+
+所以，如果你现在只是刚开始接触代码，我建议你给自己定一个目标，专门强化自己的代码能力，至少花1年时间，从新手变成熟手，这对于你未来在IT行业的发展，至关重要。
+
+跟你分享一个小技巧。你可以基于成熟的开源软件来边学习边应用，比如像Adminset这种轻量级的自动化运维平台，已经可以解决大多数中小公司的问题了。其实，代码能力不仅仅是掌握语法和框架，更重要的是基于场景，整体设计数据和业务流程，并通过代码实现出来。毕竟，只有结合实际的应用场景进行学习，才是最有效率的。
+
+**2.培养跨职能领域核心能力**
+
+相信经过几年的工作，你已经具备了当前岗位所需要的基本能力，这是你当前赖以为生的根本。那么在这些能力的基础上，逐步发展跨领域跨界的能力，尤其是那些核心能力，就成了投入产出比最高的事情。
+
+举个例子，如果你是软件开发工程师，那么恭喜你，你已经走在了代码的道路上，接下来，运维能力就是你要尝试攻克的下一个目标。而在这些目标中，比如操作系统、自动化部署以及云能力，就是你要最优先发展的跨界能力，因为它们是运维的核心，也是了解运维最好的出发点。反过来说，如果你从事的是运维行业，那么除了常用的脚本以外，核心代码能力就是你的目标。
+
+其实，我们每天的工作其实都离不开跨界，比如，运维每天部署的应用，为什么要部署这么多实例？每个实例之间的调用关系又是怎样的？**多问几个为什么，往往就有新的收获。**
+
+不仅如此，在接触跨领域的时候，除了基础核心技能，那些最常见的工具，你也要花时间来了解。现在网上的资料足够多，快速入门应该并不困难。
+
+**3.DevOps核心理念和业务思维**
+
+如果你不理解DevOps到底是什么，那何谈成为DevOps工程师呢？因此，像DevOps中的核心理念，比如精益敏捷、持续交付，以及很多实践，你都要有所了解。当然，如果你订阅了这个专栏，我将带你走过前面的这段路，你可以快速地进入下一阶段，在实战中练习。
+
+DevOps在公司的落地是大势所趋，也许你所在的团队也会参与其中，那么除了做好自己的本职工作外，你也可以多参与，多思考，看看推进的过程是怎样的，涉及到的角色又在做些什么，项目的整体进展和计划是什么。在实战中练习和补齐短板，对于积累经验来说，是不可或缺的。**很多时候，不是没有学习的机会，只是我们自己不想看到罢了。**
+
+另外，可能你现在距离业务还比较远，那么你可以尝试了解一些大的业务目标，多跟你所在团队的上下游进行沟通，看看他们现在的关注点在什么地方。既然业务的目标需要整个团队紧密协作才能完成，那么每个团队都是其中的一份子，所以他们身上也同样体现了业务的目标。
+
+**4.潜移默化的软实力建设**
+
+类似沟通能力、同理心、自驱力、学习能力、主动性等，无论从事任何职业，都是你身上的闪光点。很多天生或者从小养成的习惯，需要长时间潜移默化的训练才能有效果。
+
+很多时候，IT从业人员给人的印象都是不善表达，再加上东方文化的影响，本身就比较含蓄，这对很多沟通和表达来说，都是潜在的障碍。这个时候，就要尽量把握已有的机会，比如多参加团队内部的读书分享、公司内部的讲师培训报名等。即便刚开始分享的内容还不足你脑中的1%，但至少也是一个好的起点。我的建议就是6个字：**勤练习，多总结**。就像DevOps一样，持续改进和持续反馈，培养自己的自信心。
+
+## 总结
+
+总结一下，我在这两讲给你介绍了DevOps工程师要重点关注的3大职责，分别是工具平台开发、流程实践落地和技术预研试点。另外，我还基于实用角度提炼了8大核心能力模型，分为3条软实力和5条实力，并给出了4条提升DevOps核心能力的建议。为了方便你复习和理解，我画了一张脑图，把这两讲内容进行了汇总，你可以参考一下。
+
+<img src="https://static001.geekbang.org/resource/image/48/07/48de933119e78f7f94cd2abe91073d07.png" alt="">
+
+最后，我想强调的是，就像DevOps没有明确的定义一样，DevOps工程师的技能也没有明确的限定，所以，你要时刻保持好奇心，持续学习，总结出自己的能力体系，并在实践积累经验，这样才能在激烈的竞争中占得先机。
+
+## 思考题
+
+针对我们这两讲的内容，你觉得自己需要提升哪方面的能力呢？你有哪些快速提升能力的小窍门吗？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/特别放送/特别放送（五）| 关于DevOps组织和文化的那些趣事儿.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="特别放送（五）| 关于DevOps组织和文化的那些趣事儿" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d8/ee/d81e325d77022ec265531c388f549fee.mp3"></audio>
+
+你好，我是石雪峰，今天又到了特别放送环节。写到这儿，专栏已经接近尾声了，我想再跟你聊聊DevOps的组织和文化。
+
+DevOps文化好像是一个矛盾结合体：一方面，文化这种东西似乎只可意会不可言传；另一方面，文化对DevOps实践的重要性又是毋庸置疑的。
+
+在各种行业大会上，关于文化的议题总是屈指可数。原因也很简单，关于文化，一般都说不明白，即便能说明白，也改变不了什么。因为文化的改变可不是像引入一个工具那么简单，很多时候都需要思想上的转变。
+
+谈到DevOps文化，我想到去年我和几个朋友一起组织《DevOps实践指南》的拆书帮活动。这个活动就是，通过连续几周的线上分享，我们帮助大家总结提炼书中的核心知识。
+
+在分享的过程中，有这样一件事，我印象特别深刻。事情的起源是原书的第14章中有这样一段描述：
+
+> 
+团队在客户面前没有任何需要隐藏的，对自己也同样如此。与其把影响线上系统的问题视为一种秘密，不如尽可能地将它透明化，主动将内部的问题广而告之给外部用户。
+
+
+某大型公司的IT负责人刚好负责分享这个章节，他表示，为了尊重原文，他保留了这段描述，但是在国内的环境下，这并不现实。即便是他自己，一个坚定的DevOps实践者，也很难做到这种程度。因为如果把公司内部的问题通通开放给客户，那估计转天就可以收拾东西回家了。
+
+也正因为公司一般不会在第一时间对外公布故障，所以也难怪，这些事情基本都是通过“云头条”这类公众号第一时间公布出来的。
+
+但是，似乎大家的记忆力也都不太好，很多时候，这些事情过去了也就不了了之了，除了听说“谁又背锅了，谁又被牵连了“之类的流言蜚语之外，也没有什么特别之处。
+
+这也可以理解，毕竟家丑不可外扬，内部吐吐槽也就罢了，如果凡事都到外面去宣传，那公司岂不是形象全无？更有甚者，还会影响用户对公司的信心。你想，如果天天就你问题最多，那谁还敢用你的服务呢？
+
+我们都知道DevOps文化的几个关键词：**协作**、**分享共担**、**无指责文化**、**在错误中学习**……这些道理大家都懂，但真正遇到问题、需要平衡不同部门利益的时候，是否还能以这些文化为准则，来指导行为模式，就是另外一码事了。
+
+说白了，如果想看团队是否具备DevOps文化，与嘴上说说相比，更重要的是看怎么做。所以，今天我给你分享几个故事，看看在面对同样的问题时，其他公司是怎么做的，并思考一下，为什么这样是一种更好的做法？
+
+## GitLab删库的故事
+
+时间回到2017年1月31日，全球最大的代码托管协作平台之一的GitLab出现了一次长达18小时的停机事故，原因居然是一个IT工程师把生产数据库的数据给清空了。
+
+由于遇到了爬虫攻击，主备数据库之间的同步延迟已经超过了WAL的记录上限，导致数据同步无法完成。当时，遇到这种问题的操作就是移除所有备份数据库上的数据记录，然后全量触发一次新的同步。但是，由于数据库配置并发数和连接数等一系列的配置问题，导致数据库的数据备份一直失败。
+
+这个时候，时间已经来到了标准国际时间的晚上11点半。由于时差的关系，对于身在荷兰的工程师来说，这时已经是深夜1点半了。当值工程师认为有可能是之前失败的同步遗留的数据导致的数据库备份失败，所以决定再一次手动清空备份服务器的数据。
+
+但是，也许是由于疏忽，他并没有意识到，当时他操作的是**生产数据库**。几秒钟后，当他回过神来取消操作的时候，一切都已经来不及了。最终的结果是，总共有超过300G的线上数据丢失，直接导致了服务进入恢复模式。
+
+按道理说，这种事情虽然难以接受，但其实并不少见。更加严重的是，当GitLab尝试恢复数据的时候才发现，他们所谓的“精心设计”的多重备份机制，竟然都无法拯救被删除的数据。
+
+最夸张的是，直到这会儿，他们才发现，由于升级后工具版本不匹配，数据库的定时备份一直处于失败状态。他们原以为邮件会告警这个问题，但巧合再一次出现，针对自动任务的报警也没有生效。
+
+事已至此，要么是隐藏事实，然后给外界一个不疼不痒的解释，要么就是把问题完全公开，甚至是具体到每一个细节，你会选择怎么处理呢？
+
+GitLab公司的选择是后者。他们第一时间将系统离线，并将事件的所有细节和分析过程记录在一个公开的谷歌文档中。不仅如此，他们还在世界上最大的视频网站YouTube上对恢复过程进行全程直播。
+
+考虑到有些用户不看YouTube，他们还在Twitter上同步更新问题状态，硬生生地将一场事故变成了一个热门话题。当时，同时在线观看直播的用户超过5000人，甚至一度冲到了热门榜的第二位。
+
+除此之外，在几天后，公司的CEO亲自给出了一篇长达4000字的问题回溯记录，包含问题发生的背景、时间线、核心原因分析，针对每一种备份机制的说明，以及将近20条后续改进事项，由此获取了用户的信任和认可。可以说，在这一点上，他们真的做到了透明、公开和坦诚相待，并且做到了极致。
+
+> 
+问题回溯的资料： [https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/](https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/)
+
+
+至于那位倒霉的工程师的结果，估计你也听说了，对他的惩罚就是强迫他看了几十分钟的《彩虹猫》动画。说实话，这个动画有点无聊。但是，如果这种事情发生在咱们身边，估计直接就被开掉了。我知道你肯定好奇这个《彩虹猫》到底是个啥动画片，我也特别无聊地找来看了下，如下所示：
+
+<img src="https://static001.geekbang.org/resource/image/86/c1/86a033098638db7244c2ec6f661808c1.png" alt="">
+
+从此以后，GitLab的开放越发“变本加厉”。现在你可以在任何时间去查看服务的实时状态，包括每一次过往的事故分析。同时，名叫“GitLab状态”的Twitter账号实时更新当前的问题，目标就是在任何用户发现问题之前，尽量主动地将问题暴露出来，至今已经发布了将近6000条问题。
+
+同时，你还可以查看GitLab服务的详细监控视图和监控数据，包括GitLab的运维标准手册、备份脚本。这些通通都是对外开放的。只要你想用，你就可以直接拿来使用；如果你觉得哪里不靠谱，也可以直接提交改动给他们。我提取了一些截图和地址，你可以参考一下。
+
+1.GitLab状态Twitter：[https://twitter.com/gitlabstatus](https://twitter.com/gitlabstatus%5Breference_end%5D)
+
+<img src="https://static001.geekbang.org/resource/image/cb/7f/cba011cebb4cdf8318772bf04bd95d7f.png" alt="">
+
+2.GitLab状态网页：[https://status.gitlab.com/](https://status.gitlab.com/%5Breference_end%5D)
+
+<img src="https://static001.geekbang.org/resource/image/7d/50/7d5909f0a8c2c6e7903aa0a7fddfcf50.png" alt="">
+
+3.GitLab内部监控大屏：[https://dashboards.gitlab.com/](https://dashboards.gitlab.com/%5Breference_end%5D)
+
+> 
+<img src="https://static001.geekbang.org/resource/image/4c/6c/4c79b3a2c797cc0e2651dd9a53216a6c.png" alt="">
+
+
+这并不是GitLab公司发疯了，实际上，开放已经成为了主流公司的标配。比如，在GitHub上，你同样可以看到类似的信息。
+
+<img src="https://static001.geekbang.org/resource/image/69/fc/69c4413d897ca9bd82747580c51092fc.png" alt="">
+
+故事讲到这儿，就可以告一段落了。**面对事故的态度，很大程度上体现了公司的文化**。
+
+首先，就是**在错误中学习**。
+
+GitLab的分析报告不仅是对问题本身的描述，很大程度上也是希望把他们的经验，尤其是修复过程中的经验分享出来，通过错误来积累经验，改善现有的流程和工具，从而彻底地避免类似问题的出现。
+
+每个人、每个公司都会犯错，**对错误的态度和重视程度，决定了成长的高度**。所以，假如说我要去一家公司面试，面试官问我有没有问题，那我非常关心的一定是他们公司对错误的态度，以及具体的实际行动。
+
+另外，就是**建立信任和及时反馈，公开透明是关键**。这不仅是对外部用户而言的，对内部协作的部门和组织来说，也是这样。因为只有充分的透明，才能赢得对方的信任，很多事情才有得聊，否则，建立协作、责任共担的文化，就成了一句空谈。
+
+在开始建立DevOps文化的时候，你首先要明白，上下游所需要的信息是否能够自主简单、随时地获取到，如果不能的话，这就是一个很好的潜在改进事项。
+
+## Etsy三只袖子毛衣的故事
+
+Etsy是美国的一家手工艺电商平台，从2015年上市以来，它的市值一度接近80亿美元。当然，除了快速增长的市值以外，最为人称道的就是它们的DevOps能力，而它们的案例也大量出现在了《DevOps实践指南》一书中。
+
+那么，为什么这个名不见经传的公司能够做到这种程度呢？实际上，通过一件小事，我们就能看出来原因。
+
+你可能不知道的是，一家在线电子商务公司每日浏览频率最高的单体页面不是首页，也不是具体哪个商品的页面，而是**网站的不可用页面**，也就是我们习惯说的502页面。有些公司甚至为了提升502页面的用户体验，利用好这部分流量，在502页面做了很多文章，比如把502页面作为一个产品推广的阵地等。
+
+当Etsy的网站不可用的时候，你看到的是一个小姑娘在织毛衣的画面，而这个毛衣竟然有三只袖子。
+
+<img src="https://static001.geekbang.org/resource/image/48/51/48b597fce55138868119d2fb55dea751.png" alt="">
+
+实际上，“三只袖子的毛衣”代表了Etsy对于错误的态度。我们都知道，一件毛衣应该只有两只袖子，这是常识。如果有人真的织出来第三只袖子，我们的第一反应就是觉得这很可笑，这只是个人的问题，却很少去想他为什么会做这种反常识的事情，背后的根因是什么。
+
+但是，Etsy公司却不是这样的。在每年的年终总结大会上，公司都会颁发各种奖项，其中一个奖项的奖品就是“三只袖子的毛衣”，获奖者是公司年度引入最大问题的个人。
+
+这是因为，在他们看来，**犯错误并不是什么大不了的事情。错误本身并不是个人的问题，而是公司系统和制度的问题，正因为有了这样的错误，才给了公司改进和成长的空间**。从某种意义上说，这也是一种贡献。
+
+当然，除了制造噱头之外，通过这种行为，其实公司想表达的是它们对文化的偏好，也就是要**建立一种心理安全**、**快速变化**、**及时反馈**、**鼓励创新的文化**，由此来激发整个团队的士气和战斗力。
+
+无独有偶，2019年的DevOps状态报告也特别指出，**心理安全的文化氛围，有助于团队生产力的提升**。更重要的是，状态报告还把它作为一条重要能力，放入了DevOps能力模型之中。
+
+因为，只有当员工感受到心理安全时，才会把注意力集中在解决问题和快速完成工作上，而不是花费大量的时间用于互相攻击和部门政治。在跨部门寻求合作的时候，才会思考如何让组织的价值最大化，而不是想“谁过来动了我的奶酪，我要如何制造更高的门槛来保护自己的利益”。对于DevOps这种注重协作的研发模式来说，这一点真的太重要了。
+
+## Netflix招聘成年人的故事
+
+美国硅谷聚集了世界上大多数精英的IT公司，但是精英中的精英，就是FAANG，也就是Facebook、Apple、Amazon、Netflix和Google这五家公司的首字母简称，这五家公司基本引领了硅谷技术的风向标。大多数人对其中的4家公司都非常熟悉，但是对Netflix却知之甚少。那么，这家公司凭啥能跻身为精英中的精英呢？
+
+如果我告诉你，在Netflix，每个工程师不仅拿着数一数二的薪水，还可以自己决定什么时候休假，爱休多长时间就休多长时间，而且报销不需要经过审批，填多少就报多少。另外，即便只加入公司一天就离职了，公司给予的补偿也足够他们活上一年半载。
+
+看到这里，你是不是觉得这家公司的老板疯了呢？
+
+这个叫作里德·哈斯廷斯的人还真没疯。我所说的这一切，背后的原因都被记录在了《奈飞文化手册》一书中，这也是号称硅谷最重要的文件的作者在离开Netflix之后写的一本阐述Netflix文化的书。
+
+Netflix认为，**与其建立种种流程来约束员工，不如砍掉所有不必要的流程，给员工一个自由发挥自我价值的空间**。因为，把所有员工都视为一个成年人是他们的行为准则。**作为一个成年人，你应该能够为自己的行为负责，同时为公司的发展负责，由此做出最好的选择，并付出最大的努力**。
+
+正是这种开放的氛围，使得Netflix至今开源了171个项目和插件。其中，像混沌工程的鼻祖混乱猴子（[Chaos Monkey](https://github.com/Netflix/chaosmonkey)）、断路器工具[Hystrix](https://github.com/Netflix/Hystrix)、服务注册工具[Eureka](https://github.com/Netflix/eureka)、部署工具[Spinnaker](https://www.spinnaker.io/) ，都是DevOps领域最为著名的开源工具。
+
+**开源为先的共享精神**正在成为越来越多的公司重视开源的动力之一。让真正优秀的人做有价值的事情，而不是让他们整日为复杂的流程、公司的内部政治和无意义的工作所影响，他们才能发挥最大的价值。对DevOps来说，也是如此。
+
+## 总结
+
+说到这儿，三个故事已经讲完了。我们来总结一下在DevOps文化中最为知名的几点内容：
+
+1. 建立免责的文化，并在错误中学习；
+1. 通过对外开放透明，建立信任，促进协作；
+1. 打造心理安全的氛围，鼓励创新；
+1. 开源为先的共享精神。
+
+改变企业文化，绝不是一个人、一句话的事情，管理层的认同和导向非常重要。但是，我们并不能期望每家公司都能成为FAANG一样的硅谷巨头。所以，从我做起，从力所能及的范围做起，别觉得文化跟自己没有关系，这才是最重要的。
+
+最后，希望你看完这一讲以后，可以重新审视一下，团队内部是否建立了正向的错误回溯机制？是否鼓励内部分享和创新？是否和上下游之间做到了开放和协作为先？是否在身体力行地减少重复建设？
+
+## 思考题
+
+你对今天的哪些内容印象最深刻呢？你又有哪些跟DevOps文化相关的故事可以拿来分享呢？
+
+欢迎在留言区写下你的思考和答案，我们一起讨论，共同学习进步。如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。
+
+

极客时间专栏/DevOps实战笔记/特别放送/特别放送（四）| Jenkins产品经理是如何设计产品的？.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="特别放送（四）| Jenkins产品经理是如何设计产品的？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f4/ca/f413fa247e11f3545a5ed38cc92d65ca.mp3"></audio>
+
+你好，我是石雪峰。这是一期临时增加的特别放送。
+
+前两天，我去葡萄牙里斯本参加了2019年的DevOps World | Jenkins World大会。这是一年一度的社区聚会，参会人会围绕Jenkins和DevOps展开为期3天的密集交流，信息量非常大。很多新技术、行业趋势、产品设计思路都在大会上涌现了出来，我觉得非常有价值，也很有必要整理出来，分享给你。
+
+2019年是Jenkins诞生15周年，对于任何一个软件来说，15年都不是一个短暂的时间。在这个时间点，社区也在展望过去15年来的Jenkins发展历程，并憧憬下一个15年Jenkins的变化。
+
+可以说，从DevOps产品的角度来说，Jenkins本身就是一个非常出色的典型案例。
+
+最开始，这是一个由于Jenkins创始人KK无法忍受同事天天导致编译失败而开发的一个人项目。到今天，这个项目已经有将近900名或全职、或兼职的贡献者，26万多个Master节点，超过3000万个任务了。这些数字还仅仅是官方可以统计到的部分，如果再加上企业内网、个人电脑上的实例，那就更加不计其数了。
+
+今年，我印象最深刻的是，Jenkins创始人KK并没有在主会场上讲太多的产品细节、设计思路、发展方向等，而是仅仅用了10多分钟回顾了自己的心路历程。在演讲的最后，他将舞台交给了一位Jenkins产品经理。这位产品经理是何方神圣呢？为什么是一位产品经理来讲这些内容呢？这激起了我极大的好奇心。
+
+一直以来，KK都被视为Jenkins的头号产品经理。的确，技术专家兼产品经理是比较普遍的一个现象。这是因为，与普通面向用户的产品相比，DevOps产品有几个非常鲜明的特征。
+
+- **技术背景要求高**。因为DevOps产品要解决的很多问题都是一线的技术问题；
+- **面向的用户是开发人员**。这就意味着，如果你不了解开发的真实工作方式，就很难设计出开发友好的产品；
+- **专业工具繁多**。产品引用到的开源组件和工具都是专业领域的内容，比如Jenkins就是一个典型的持续集成系统，如果你不了解Jenkins，又怎么设计Jenkins呢？
+
+在几天的会议过程中，针对DevOps产品经理面对的这些挑战，我专门跟这位神奇的Jenkins产品经理进行了沟通。他就是Jeremy Hartley，一个来自荷兰的大哥。
+
+我先给你介绍下社区的运作方式。以Jenkins这个产品为例，它背后的主要贡献者都来自于CloudBees公司。虽然这些人都属于同一个公司，但实际上，他们大多各自分散在家办公，一年到头也见不了几次面。
+
+比如，产品经理Jeremy在荷兰，创始人KK在加州，基础设施的负责人Oliver在比利时，K8S的插件维护者在西班牙。因此，每年的FOSDEM（年初的欧洲最大的开源软件大会），以及年末的Jenkins World大会，就成了这些世界各地的开发者汇聚到一起的难得机会。
+
+言归正传，与产品经理的积极外向、滔滔不绝的一般形象不同，Jeremy可以说是一个异类。他从始至终都给人一种温文尔雅的感觉，甚至在公开演讲的时候，他的语气也非常平和，没有太多的情绪表达，只是把他和他的产品的故事娓娓道来。
+
+Jeremy早先在一家互联网在线视频公司干了10年。他半开玩笑地说，即便干了10年，也不如跟腾讯合作一个项目来得出名。后来，他加入XebiaLabs。这是一家专门做DevOps平台产品的公司，在国内可能不是特别出名，但如果提到DevOps工具元素周期图，相信你肯定听说过，这就是这家公司迭代更新的。
+
+<img src="https://static001.geekbang.org/resource/image/fa/bc/fa1f9db00986532b0acc1790043178bc.png" alt="">
+
+> 
+图片来源：[https://xebialabs.com/periodic-table-of-devops-tools/](https://xebialabs.com/periodic-table-of-devops-tools/)
+
+
+在今年的4月份，他加入了CloudBees，成为了主管开源和商业版本Jenkins的高级产品经理。在跟他交流的过程中，我对产品经理这部分内容的印象非常深刻。我梳理了一些要点，分享给你。如果你已经是DevOps产品经理，或者是立志要成为DevOps产品经理的话，你一定要认真看一下。
+
+## 一、自我颠覆
+
+什么叫自我颠覆呢？我给你举个例子。比如，Jenkins的用户UI项目Blue Ocean，很多人应该都知道，目前这个项目的主要开发已经停止了。社区仍然会修复缺陷和安全漏洞，也会接受开发者共享的PR，但是不会再投入专职工程师进行开发工作了，新需求也都处于无限暂停的状态。
+
+实际上，不仅仅是Blue Ocean，去年Jenkins大会上星光闪耀的项目，比如Five super power、Jolt in Jenkins、Evergreen等项目，也都因为方向调整和人员变动而处于半终止、暂缓开发的状态。那么，为什么在短短一年的时间内，会有这么大的颠覆性变化呢？我把这个问题抛给了Jeremy。
+
+他的观点是，这些项目并非没有意义，但是确实没有达到项目原本的预期。对于产品经理来说，**管理预期是一项非常重要的能力**。当需求走到产品经理的时候，做哪个、不做哪个经常是个问题。团队往往会进行协商，挑选出来最有希望的项目，但这并不代表这些项目注定会成功。相反，很多想法只有做了才知道是不是靠谱，用户是不是买单。**如果使用场景有限，又没有很好的增长性，及时叫停反而是一种好的选择**。
+
+Blue Ocean项目诞生之初，可以说是让人眼前一亮，充满期待，甚至一度和Jenkins流水线一起被视为2.0版本的最大功能。但是几年之后，由于产品性能、插件扩展支持等种种原因，真正在企业中大规模使用的机会并不多。正因为项目没有达到预期，产品团队就决定停止这个项目。
+
+但是与此同时，全新的Jenkins用户界面项目已经被提到了日程表中。这个全新的用户界面大量借鉴了Blue Ocean的设计思路，并最终通过一套用户界面，取代了现有的Blue Ocean。我想，正是这种不断的自我颠覆，才让一个15年的软件始终保持着活力和创新力。
+
+## 二、化繁为简
+
+对于Jenkins这样的产品来说，很多插件都是开发者提供的，但是开发者往往倾向于追求功能的全面性，这从很多插件的设计中就能看出来。
+
+开发者不加筛选地把所有功能都罗列在用户面前，自然是得心应手。但是，对普通用户来说，当他第一眼看到这个复杂产品的时候，他的使用意愿就会大打折扣。
+
+另外，面对这么多的插件，从表面上看，用户好像有很多选择，但是，有些插件的名字长得差不多，你并不知道哪个能用。或者，有些插件适用于当前的Jenkins版本，但是一旦Jenkins升级，它们就无法正常使用了。但是，用户在升级之前并不知道是否适配，往往是在升级完成之后才会发现问题，只能再进行版本回滚。类似这些插件使用中的问题，都给用户带来了很大的使用障碍。
+
+在探讨这个问题的时候，Jeremy也认为，**系统过于复杂有悖于产品设计的初衷**，但是，作为一个公开的平台，他们并不能约束开发者的行为，所以就需要一种方法来平衡功能的全面性和功能的易用性。
+
+比如，在重新考虑Jenkins插件生态的时候，一方面，产品团队会针对全新的业务场景提供官方的插件支持。举个例子，在云原生开发场景下，通过和云服务商深度合作，提供更多的官方插件，来满足典型的云服务商的使用场景。无论是对亚马逊的AWS、微软的Azure，还是未来国内的主流云服务商，他们都会通过这种方式来进行合作。无论你使用的开源产品，还是商业产品，都能通过这个项目来获得收益。
+
+另一方面，产品团队也会进一步对现有的1600多款插件进行分类，并将其中的一部分插件纳入CloudBees的保障项目之下。这就意味着，将由CloudBees公司来保证这类插件的兼容性和可用性。对于专业用户来说，他们依然可以按照自己的方式自由地选择和开发插件，而对于普通用户来说，官方推荐的插件集合就足够了。
+
+不仅仅是插件，产品的易用性体现在产品设计的方方面面。凡是阻塞用户使用的问题，都是需要优先解决的。
+
+比如，对于一个10多年的产品来说，历史积累的文档数量巨大，很多时候，用户都无法找到真正有用的信息。所以，Jenkins产品团队启动了一个文档治理的项目，会重新梳理所有文档，并把它们迁移到GitHub平台上。另外，他们还会结合新的产品功能，整理出最佳实践。比如，对于流水线使用来说，官方也总结了很多[最佳实践](https://support.cloudbees.com/hc/en-us/articles/230922208-Pipeline-Best-Practices)供入门者参考，你可以结合前面两讲的内容一起学习。
+
+**要始终记得，不要让你的产品只有专家才会使用。将复杂的问题简单化，是产品经理不论何时都要思考的问题。**
+
+## 三、退后一步
+
+DevOps的产品经理大多是技术人员出身，因此会特别容易一上来就深入细节，甚至是代码实现的细节。
+
+Jeremy同样也是程序员出身，他做过很长一段时间的前端开发。当我问他“**一个好的产品应该如何平衡用户视角和实现视角**”的时候，他给我的回答是，**要尽量退后一步来看问题**。
+
+**退后一步，就是说不要把关注点只聚焦在问题表面，而是要尽量站在旁边，以第三方的视角来全面审视问题**。
+
+他举了个Jenkins的流水线即代码的例子。在实际使用的时候，流水线文件中经常会有大量的代码，有时候，流水线代码甚至会有上千行。代码越多，系统的不稳定因素就越多，测试起来也越麻烦。同时，按照现有的运行机制来说，很多代码都是运行在master节点上的，这就给集群的master节点带来了很大压力。
+
+要想解决这个问题，从实现的角度出发，就是提供一种标准化、结构化的语法格式，也就是声明式流水线语法，以此来降低流水线的编写难度，减少流水线代码量，并且让这个代码结构更加清晰。但是，这些优化依然不能解决集群master节点压力过大的问题，这就相当于问题只看了一部分。
+
+退后一步来看，这就需要一种全新的视角，来提升流水线整体的隔离性。所以，产品团队目前就在设计一种新的流水线组件 **building block**，也就是构建块。
+
+**所谓构建块，是指一整块的代码片段，而不是一条条独立的指令**。这些构建块结合到一起，就可以满足一个具体场景的问题。比如Maven打包构建的场景，构建块可以帮你解决环境、工具、构建命令等一系列问题。这些构建块以代码形式在子节点上运行，既降低了流水线的编写难度，也缓解了master节点上的压力。对用户来说，使用构建块也更为简单，可以直接把它放在自定义的步骤中执行。
+
+对于产品经理来说，找到方案、解决问题自然是职责所在，但与此同时，他们往往需要同时保有两种思维，即**用户思维和实现思维**。能够在这两种思维之间自由切换，是产品经理走向成熟的标志。
+
+## 总结
+
+说到这儿，我来回答一下最开始的那个问题，也就是“为什么是产品经理来分享产品的规划呢？”这是因为，无论要开发一个多大还是多小的产品，都需要有这样一拨人来退后一步，找到用户的真实问题，化繁为简，实现这个功能，并不断颠覆自己，持续打磨和改进。这对于任何一个想要解决更多人问题的产品来说，都是至关重要的。
+
+## 思考讨论
+
+关于这次Jenkins World大会，你还有什么希望进一步了解的内容吗？欢迎你积极提问，我会知无不言。
+
+如果你觉得这篇文章对你有所帮助，也欢迎你把文章分享给你的朋友。
+
+