mod

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/01 | 为什么Netflix没有运维岗位？.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="01 | 为什么Netflix没有运维岗位？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7d/69/7df51b36e81dbf2e7ed459dcfea66f69.mp3"></audio>
+
+众所周知，Netflix是业界微服务架构的最佳实践者，其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可遵从的原则和实践经验。
+
+Netflix超前提出某些理念并付诸实践，以至于在国内众多互联网公司的技术架构上也可以看到似曾相识的影子。当然殊途同归也好，经验借鉴也罢，这都不影响Netflix业界最佳实践者的地位。
+
+同样，在运维这个细分领域，Netflix仍然是最佳实践的典范。所以专栏的开始，就让我们一起看看世界顶级的互联网公司是如何定义运维以及如何开展运维工作的。
+
+## Netflix运维现状
+
+准确一点说，Netflix是没有运维岗位的，和运维对应的岗位其实是我们熟知的SRE（Site Reliability Engineer）。但我们知道SRE≠运维，**SRE理念的核心是：用软件工程的方法重新设计和定义运维工作**。
+
+也就是要改变之前靠人去做运维的方式，转而通过工具体系、团队协作、组织机制和文化氛围等方式去改变，同时将之前处于研发体系最末端的运维，拉回到与开发肩并肩的同一起跑线上。
+
+但是Netflix的神奇和强大之处在于，连Google都非常重视和大力发展的SRE岗位，在Netflix却没有几个。按照Netflix一位技术主管（Katharina Probst）在今年9月份更新的博客中所描述，在1亿用户，每天1.2亿播放时长、万级微服务实例的业务体量下，SRE人数竟然不超过10个，他们称这样的角色为Core SRE。描述具体如下：
+
+> 
+<p>100+ Million members. 125+ Million hours watched per day. Hundreds of<br />
+microservices. Hundreds of thousands of instances. Less than 10 Core<br />
+SREs.</p>
+
+
+不可否认，Netflix拥有强大的技术实力和全球最优秀的工程师团队。按照SRE的理念，完全可以打造出这一系列的工具产品来取代运维和SRE的工作。但是能够做到如此极致，就不得不让人惊叹和好奇，Netflix到底是怎么做到的？
+
+## 为什么Netflix会做得如此极致？
+
+这确实是一个很有意思的问题，带着这样的疑问，阅读了大量的Netflix技术文章和公开的演讲内容之后，我想这个问题可以从Netflix的技术架构、组织架构、企业文化等几个方面来看。
+
+### 1.海量业务规模下的技术架构和挑战
+
+前面我也提到，Netflix在业务高速发展以及超大规模业务体量的驱动下，引入了更为灵活的微服务架构，而且已经成为业界的最佳实践典范。
+
+引入微服务架构后，软件架构的细化拆分和灵活多变，大大提升了开发人员的开发效率，继而也就提升了业务需求的响应和迭代速度，我想这也正是微服务思想在业界能够被广泛接受和采用的根本原因。
+
+但是这也并不是说没有一点代价和成本，随之而来的便是架构复杂度大大增加，而且这种复杂度已经远远超出人的认知能力，也就是我们已经无法靠人力去掌控了，这也就为后续的交付和线上运维带来了极大的难度和挑战。<br />
+<br />
+这时，微服务架构下的运维就必须要靠软件工程思路去打造工具支撑体系来支持了，也就是要求微服务架构既要能够支持业务功能，还要能够提供和暴露更多的在后期交付和线上运维阶段所需的基础维护能力。
+
+简单举几个例子，比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问ACL控制、异常熔断和旁路、调用关系和服务质量日志输出等等，要在这些能力之上去建设我们的运维工具和服务平台。
+
+讲到这里，我们可以看到，微服务架构模式下，运维已经成为整体技术架构体系中必不可少的一部分，而且与微服务架构相关的体系是紧密相连不可拆分的。
+
+我们现在看到很多跟SRE相关的文章或内容，对于SRE产生原因的解释，大多是说为了缓解开发和运维之间的矛盾，树立共同的目标，让双方能够更好地协作配合。这样理解也没有太大的问题，但是我认为不够充分，或者说以上这些只能算是结果，但不是背后的根本原因。
+
+我理解的这背后最根本的原因是，微服务架构复杂度到了一定程度，已经远远超出单纯的开发和单纯的运维职责范畴，也远远超出了单纯人力的认知掌控范围，所以必须寻求在此架构之上的更为有效和统一的技术解决方案来解决复杂度认知的问题。**进而，在这一套统一的技术解决方案之上，开发和运维产生了新的职责分工和协作方式**。
+
+目前业界火热的DevOps理念及衍生出来的一系列话题，我们可以仔细思考一下，其实也是同样的背景和逻辑。DevOps想要解决的开发和运维之间日益严重的矛盾，究其根本，还是微服务架构背后带来的技术复杂度在不断提升的问题。
+
+> 
+**Netflix带给我们的启示一**：微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
+
+
+### 2.更加合理的组织架构和先进的工具体系及理念
+
+我上面提到，在微服务架构模式下，运维已经成为整体技术架构和体系中不可分割的一部分，两者脱节就会带来后续一系列的严重问题。
+
+从这一点上，不得不说Netflix的前瞻性和技术架构能力还是很强的。因为早在2012年，甚至更早之前，Netflix就已经意识到了这个问题。在组织架构上，将中间件、SRE、DBA、交付和自动化工具、基础架构等团队都放在统一的云平台工程（Cloud and Platform Engineering）这个大团队下，在产品层面统一规划和建设，从而能够最大程度地发挥组织能力，避免了开发和运维的脱节。
+
+当然，这个团队不仅没让大家失望，还给我们带来了太多惊喜。业界大名鼎鼎的NetflixOSS开源产品体系里，绝大部分的产品都是这个团队贡献的。
+
+比如持续交付系统Spinnaker；稳定性保障工具体系Chaos Engineering，这里面最著名的就是那只不安分的猴子，也正是这套稳定性理念和产品最大程度地保障了Netflix系统的稳定运行；被Spring Cloud引入并得以更广泛传播的Common Runtime Service&amp;Libraries，而且大家选用Spring Cloud基本就是冲着Spring Cloud Netflix这个子项目去的。当然还有很多其它优秀的开源产品，这里我就不一一介绍了。
+
+> 
+**Netflix带给我们的启示二**：合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
+
+
+### 3.自由与责任并存的企业文化
+
+上面讲了这么多，看上去好像就是SRE常见的理念和套路，只不过Netflix在开源和分享上更加开放和透明，让我们有机会更多地了解到一些细节。但是为什么Netflix会做的如此极致呢？好像我们一直没有回答到这个问题，那这里就不得不提Netflix的企业文化了。
+
+Netflix的企业文化是 **Freedom &amp; Responsibility**，也就是自由和责任并存，高度自由的同时，也需要员工具备更强的责任心和Owner意识。
+
+体现在技术团队中就是，You Build It，You Run It。工程师可以随时向生产环境提交代码或者发布新的服务，但是同时你作为Owner，要对你发布的代码和线上服务的稳定运行负责。
+
+在这种文化的驱使下，技术团队自然会考虑从开发设计阶段到交付和线上运维阶段的端到端整体解决方案，而不会是开发就只管需求开发，后期交付和维护应该是一个叫运维的角色去考虑。No，文化使然，在Netflix是绝对不允许这种情况存在的，你是开发，你就是Owner，你就要端到端负责。
+
+所以，短短两个英文单词，Freedom &amp; Responsibility，却从源头上就决定了团队和员工的做事方式。
+
+> 
+**Netflix带给我们的启示三**：Owner意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。
+
+
+## 总结
+
+通过上面的分析，我们可以看到，Netflix在其技术架构、组织架构和企业文化等方面的独到之处，造就了其优秀的技术理念和最佳实践。从运维的角度来说，无论是SRE也好，还是DevOps也罢，都被Netflix发挥到了极致。
+
+当然，Netflix能做到这一点，是需要非常强大的技术实力和人才储备的。当前我们虽然没法直接套用，但是这并不妨碍我们在某些经验和思路上去借鉴和学习。
+
+比如，现在很多公司在采用了微服务架构后，就没有充分考虑到后续基于微服务架构的运维问题。而且在运维团队设置上，仍然是脱离整个技术团队，更不用说将其与中间件和架构设计等团队整合拉通去建设，自然也就谈不上在产品层面的合理规划和建设了。
+
+因此导致的问题就是运维效率低下，完全靠人工，线上故障频发，但是处理效率又极低，开发和运维都处于非常痛苦的状态之中，运维团队和成员也会遭遇到转型和成长的障碍。
+
+以上这些问题都很棘手，亟待解决。
+
+通过今天的分享，我们了解了Netflix的技术团队运作模式和思路，不知道给你带来了哪些启示呢？
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友。
+
+欢迎你留言与我一起讨论。
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？.md

@@ -0,0 +1,106 @@
+<audio id="audio" title="02 | 微服务架构时代，运维体系建设为什么要以“应用”为核心？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9a/b4/9af49704b2e22ba7a1d80ffa700b85b4.mp3"></audio>
+
+今天我来讲一下微服务架构模式下的一个核心概念：**应用**。
+
+我会从这几个方面来讲：应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望，**在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要从应用的角度来分析和看待问题**。
+
+## 应用的起源
+
+我们知道，微服务架构一般都是从单体架构或分层架构演进过来的。软件架构服务化的过程，就是我们根据业务模型进行细化的过程，在这个过程中切分出一个个具备不同职责的业务逻辑模块，然后每个微服务模块都会提供相对应业务逻辑的服务化接口。
+
+如果解释得简单点，就一个字，**拆**！如下图，从一个单体工程，拆分出N个独立模块。
+
+<img src="https://static001.geekbang.org/resource/image/7e/cc/7e4da0c4778c834bfa67aa402c7613cc.png" alt="" />
+
+这些模块可以独立部署和运行，并提供对应的业务能力。拆分后的模块数量与业务体量和复杂度相关，少则几个、十几个，多则几十、几百个，所以为了统一概念，我们通常称这些模块为**应用**。
+
+为了确保每个应用的唯一性，我们给每个应用定义一个**唯一的标识符**，如上图的APP-1、APP-2等，这个唯一标识符我们称之为应用名。
+
+接下来，这个定义为应用的概念，将成为我们后续一系列微服务架构管理的核心概念。
+
+## 应用模型及关系模型的建立
+
+上面我们定义出来的一个个应用，都是从业务角度入手进行拆分细化出来的业务逻辑单元。它虽然可以独立部署和运行，但是每一个应用都只具备相对单一的业务职能。如果要完成整体的业务流程和目标，就需要和周边其它的服务化应用交互。同时，这个过程中还需要依赖各种与业务无直接关系、相对独立的基础设施和组件，比如机器资源、域名、DB、缓存、消息队列等等。
+
+所以，除了应用这个实体之外，还会存在其他各类基础组件实体。同时，在应用运行过程中，还需要不断地与它们产生和建立各种各样复杂的关联关系，这也为我们后续的运维带来很多困难。
+
+那接下来，我们要做的就是应用模型以及各种关系模型的梳理和建立，因为只有模型和关系梳理清楚了，才能为我们后面一系列的运维自动化、持续交付以及稳定性保障打下一个良好的基础。
+
+**1.应用业务模型**
+
+应用业务模型，也就是每个应用对外提供的业务服务能力，并以API的方式暴露给外部，如下图商品的应用业务模型示例：
+
+<img src="https://static001.geekbang.org/resource/image/bc/0c/bc986fb73a5632e560ba7d3be981810c.png" alt="" />
+
+这个业务模型通常都是业务架构师在进行业务需求分析和拆解时进行设计，更多的是聚焦在业务逻辑上，所以从运维的角度，我们一般不会关注太多。
+
+而接下来的几部分，将是运维要重点关注的内容。
+
+**2.应用管理模型**
+
+应用管理模型，也就是应用自身的各种属性，如应用名、应用功能信息、责任人、Git地址、部署结构（代码路径、日志路径以及各类配置文件路径等）、启停方式、健康检测方式等等。这其中，应用名是应用的唯一标识，我们用AppName来表示。
+
+这里我们可以把应用想象成一个人，通常一个人会具备身份证号码、姓名、性别、家庭住址、联系方式等等属性，这里身份证号码，就是一个人的唯一标识。
+
+**3.应用运行时所依赖的基础设施和组件**
+
+- **资源层面**：应用运行所必需的资源载体有物理机、虚拟机或容器等，如果对外提供HTTP服务，就需要虚IP和DNS域名服务；
+- **基础组件**：这一部分其实就是我们所说的中间件体系，比如应用运行过程中必然要存储和访问数据，这就需要有数据库和数据库中间件；想要更快地访问数据，同时减轻DB的访问压力，就需要缓存；应用之间如果需要数据交互或同步，就需要消息队列；如果进行文件存储和访问，就需要存储系统等等。
+
+从这里我们可以挖掘出一条规律，那就是**这些基础设施和组件都是为上层的一个个业务应用所服务的**。也正是因为业务和应用上的需求，才开启了它们各自的生命周期。如果脱离了这些业务应用，它们自己并没有单纯存在的意义。所以，**从始至终基础设施和组件都跟应用这个概念保持着紧密的联系**。
+
+理清了这个思路，我们再去梳理它们之间的关系就会顺畅很多，分为两步。
+
+**第一步，建立各个基础设施和组件的数据模型，同时识别出它们的唯一标识**。这个套路跟应用管理模型的梳理类似，以典型的缓存为例，每当我们申请一个缓存空间时，通常会以NameSpace来标识唯一命名，同时这个缓存空间会有空间容量和Partition分区等信息。
+
+**第二步，也是最关键的一步，就是识别出基础设施及组件可以与应用名AppName建立关联关系的属性，或者在基础组件的数据模型中增加所属应用这样的字段**。
+
+还是以上面的缓存为例，既然是应用申请的缓存空间，并且是一对一的关联关系，既可以直接将NameSpace字段取值设置为AppName，也可以再增加一个所属应用这样的字段，通过外键关联模式建立起应用与缓存空间的关联关系。
+
+相应地，对于消息队列、DB、存储空间等，都可以参考上面这个思路去做。
+
+通过上面的梳理，我们就可以建立出类似下图这样的以应用为核心的应用模型和关联关系模型了，基于这个统一的应用概念，系统中原本分散杂乱的信息，最终都被串联了起来，应用也将成为整个运维信息管理及流转的纽带。
+
+<img src="https://static001.geekbang.org/resource/image/9a/74/9a926d2829eed2524ba0f6af6475a174.png" alt="" />
+
+## 真实的情况是怎么样的？
+
+上面讲了这么多理论和道理，但是我们业界真实的现状是怎样的呢？
+
+从我个人实际观察和经历的场景来看，大部分公司在这块的统筹规划是不够的，或者说是不成熟的。也就是软件架构上引入了微服务，但是后续的一系列运维措施和管理手段没跟上，**主要还是思路没有转变过来**。虽然说要做DevOps，但实际的执行还是把开发和运维分裂了去对待，不信你看下面两个常见的场景。
+
+- **场景一**
+
+这个场景是关于线上的缓存和消息队列的。
+
+开发使用的时候就去申请一下，一开始还能记住自己使用了哪些，但是时间一长，或者申请得多了，就记不住了。久而久之，线上就存在一堆无用的NameSpace和Topic，但是集群的维护者又不敢随意清理，因为早就搞不清楚是谁用的，甚至申请人已经离职，以后会不会再用也已经没人讲得清楚了，越往后就越难维护。
+
+根本原因，就是前面我们讲到的，太片面地对待基础组件，没有与应用的访问建立起关联关系，没有任何的生命周期管理措施。
+
+- **场景二**
+
+这个典型场景就体现了应用名不统一的问题。
+
+按照我们前面讲的，按说应用名应该在架构拆分出一个个独立应用的时候就明确下来，并贯穿整个应用生命周期才对。
+
+但是大多数情况下，我们的业务架构师或开发在早期只考虑应用开发，并不会过多地考虑整个应用的生命周期问题，会下意识地默认后面的事情是运维负责的，所以开发期间，只要将应用开发完和将服务注册到服务配置中心上就OK了。
+
+而到了运维这里，也只从软件维护的角度，为了便于资源和应用配置的管理，会独立定义一套应用名体系出来，方便自己的管理。
+
+这时不统一的问题就出现了，如果持续交付和监控系统这些运维平台也是独立去开发的，脱节问题就会更严重。
+
+如下图所示，一个个的孤岛，无法成为体系，当这些系统需要对接时，就会发现需要做大量的应用名转化适配工作，带来非常多无谓的工作量，所谓的效率提升就是一句空话。
+
+<img src="https://static001.geekbang.org/resource/image/8f/ed/8f0601d91a1d6d795d31fb62d6c038ed.png" alt="" />
+
+所以，今天一开头我就提到，**微服务架构模式下的运维思路一定要转变，一定要将视角转换到应用这个维度，从一开始就要统一规划，从一开始就要将架构、开发和运维的工作拉通了去看，这一点是与传统运维的思路完全不同的**。
+
+当然，这里面也有一个经验的问题。虽然微服务在国内被大量应用，但是我们绝大多数技术团队的经验还集中在开发设计层面。微服务架构下的运维经验，确实还需要一个总结积累的过程。我自己也是痛苦地经历了上面这些反模式，才总结积累下这些经验教训。
+
+这也是为什么我今天分享了这样一个思路，**我们要转换视角，规划以应用为核心的运维管理体系**。
+
+不知道你目前是否也遇到了类似的问题，如果今天的内容对你有帮助，也请你分享给身边的朋友。
+
+欢迎你留言与我一起讨论。
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？.md

@@ -0,0 +1,118 @@
+<audio id="audio" title="03 | 标准化体系建设（上）：如何建立应用标准化体系和模型？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b5/7c/b5688940143ff6847f9305bb46dd997c.mp3"></audio>
+
+今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的，但也是最容易被忽视的一个环节。
+
+我做过多次公开演讲，每次讲到这个环节，通常会有单独的一页PPT，就放四个字，字号加大加粗，重复三遍，这四个字就是“**标准先行**”，然后演讲过程中会大声说出“**标准先行，标准先行，标准先行**”，重要的事情说三遍，目的就是想反复强调这件事情的重要程度，一定不要忽视。
+
+<img src="https://static001.geekbang.org/resource/image/0c/13/0cfd49cae5cf02689bb7167aae972c13.jpg" alt="" />
+
+**我们运维工作的开展常常不知从何下手，或者上来就冲着工具和自动化去了，却始终不得章法，工具做了一堆，效率却并没有提升。其实绝大多数情况下，问题和原因就是标准化这个基础工作没做扎实。**
+
+首先，让我们来看看为什么标准化这个事情如此重要。
+
+## 为什么要做标准化？
+
+**标准化的过程实际上就是对运维对象的识别和建模过程**。形成统一的对象模型后，各方在统一的认识下展开有效协作，然后针对不同的运维对象，再抽取出它们所对应的运维场景，接下来才是运维场景的自动化实现。
+
+这有点像我们学的面向对象编程的思想，其实我们就是需要遵循这样一个思路，我们面对的就是一个个实体和逻辑运维对象。
+
+在标准化的过程中，先识别出各个运维对象，然后我们日常做的所有运维工作，都应该是针对这些对象的运维。如果运维操作脱离了对象，那就没有任何意义。同样，没有理清楚对象，运维自然不得章法。
+
+比如我们说扩容，那就要先确定这里到底是服务器的扩容，还是应用的扩容，还是其它对象的扩容。你会发现，对象不同，扩容这个场景所实施的动作是完全不一样的。
+
+如果把服务器的扩容套用到应用的扩容上去，必然会导致流程错乱。同时对于对象理解上的不一致，也会徒增无谓的沟通成本，造成效率低下。自然地，这种情况下的运维自动化不但不能提升效率，还会越自动越混乱。
+
+这就是为什么我每次都会连续强调三遍“标准先行”的原因。虽然这个事情比较枯燥和繁琐，但是**于纷繁复杂中抽象出标准规范的东西，是我们后续一系列自动化和稳定性保障的基础**。万丈高楼平地起，所以请你一定不要忽略这个工作。
+
+好，总结一下标准化的套路：
+
+- 第一步，**识别对象**；
+- 第二步，**识别对象属性**；
+- 第三步，**识别对象关系**；
+- 第四步，**识别对象场景**。
+
+接下来我们就按照上面这个思路，一起来分析从基础设施层面和应用层面应该识别出哪些运维对象。
+
+## 基础设施层面的标准化
+
+基础设施层面的运维对象应该不难识别，因为都是一个个物理存在的实体，我们可以进行如下分析。
+
+- 第一步，识别实体对象，主要有服务器、网络、IDC、机柜、存储、配件等。
+- 第二步，识别对象的属性，比如服务器就会有SN序列号、IP地址、厂商、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等；网络设备如交换机也会有厂商、型号、带宽等信息。
+- 第三步，识别对象之间的关联关系，比如服务器所在的机柜，虚拟机所在的宿主机、机柜所在IDC等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系等，这些相对复杂一些，也就是我们常说的**网络拓扑关系**。
+
+把以上信息梳理清楚，通过ER建模工具进行数据建模，再将以上的信息固化到DB中，一个资源层面的信息管理平台就基本成型了。
+
+以服务器为例简单展示一下，我们的视角就是下面这样的：
+
+<img src="https://static001.geekbang.org/resource/image/a7/1d/a7726de2cea0e957dabfa28ecdfa7a1d.jpg" alt="" />
+
+但是，信息固化不是目的，也没有价值，只有信息动态流转起来才有价值。接下来我们需要做的事情，就是识别出针对运维对象所实施的日常运维操作有哪些，也就是**识别出运维场景是什么**。
+
+- 第四步，还是以服务器为例，我们针对服务器的日常操作有采购、入库、安装、配置、上线、下线、维修等等。另外，可能还会有可视化和查询的场景，如拓扑关系的可视化和动态展示，交换机与服务器之间的级联关系、状态（正常or故障）的展示等，这样可以很直观地关注到资源节点的状态。
+
+完成了这些工作，接下来才是对上述运维场景的自动化开发。所以你看，在真正执行去做工具和自动化平台之前，其实是需要先做好大量的基础准备工作的。我要再次强调这一点，一定不能忽视。
+
+## 应用层面的标准化
+
+下面我们再一起看一个逻辑上的对象，就是我们前面经常提到的运维的核心：**应用**。对这个逻辑对象的建模会相对复杂一些，不过我们依然可以按照上面的套路来。
+
+- 第一步，识别对象。
+
+我们前面讲过，这个识别过程是在做微服务架构设计或拆分的时候就确定下来的。所以严格地讲，它不应该是运维阶段才被识别出来的，而是在之前设计阶段就被识别和确认下来，然后延伸到运维这里才对。
+
+- 第二步，识别对象属性。
+
+一个应用是业务的抽象逻辑，所以会有业务和运维两个维度的属性。业务属性在业务架构时确定，这主要是需要业务架构师去识别的，但是它的运维属性就应该由运维来识别了。
+
+下面我们一起来看一下，一个应用应该具备哪些基本的运维属性。
+
+***应用的元数据属性**，也就是简单直接地描述一个应用的信息，如应用名、应用Owner、所属业务、是否核心链路应用以及应用功能说明等，这里的关键是应用名；
+
+***应用代码属性**，主要是编程语言及版本（决定了后续的构建方式），GitLab地址；
+
+***应用部署模式**，涉及到基础软件包，如语言包Java、C++、Go等；容器如Tomcat、JBoss等；
+
+***应用目录信息**，如运维脚本目录、日志目录、应用包目录、临时目录等；
+
+***应用运行脚本**，如启停脚本、健康监测脚本；
+
+***应用运行时的参数配置**，如运行端口、Java的JVM参数GC方式、新生代、老生代、永生代的堆内存大小配置等。
+
+从应用属性的视角，应该是下面这样一个视图（简单示例，不完整）：
+
+<img src="https://static001.geekbang.org/resource/image/b5/74/b583b0e3224229f6e0fb3f3350edbe74.jpg" alt="" />
+
+- 第三步，识别对象关系。
+
+也就是应用与外部的关系，概括起来有三大类：
+
+**第一类是应用与基础设施的关系**，包括应用与资源、应用与VIP、应用与DNS等等的关系；
+
+**第二类是平行层面的应用与应用之间的关系**，这里再细分下去就是应用服务或API与其它应用服务和API的依赖关系。如果你有相关的经验，应该会联想到全链路这样的工具平台了，没错，这样的平台就是用来处理应用间关系管理的。
+
+**第三类是应用与各类基础组件之间的关系**，比如应用与缓存，应用与消息、应用与DB等等之间的关系。
+
+- 第四步，识别应用的运维场景。
+
+这个就会比较多了，比如应用创建、持续集成、持续发布、扩容、缩容、监控等；再复杂点的比如容量评估、压测、限流降级等。
+
+好，这里我们先收一下，聚焦到标准化的层面，通过基础设施和应用层面标准化的示例，我想你应该可以掌握基本的建模思路了，这样的思路可以应用到其它的运维对象上 。
+
+同时，通过上面这些内容，你应该可以比较清晰地看到，我们的每一个运维操作都是针对某个运维对象的，这一点在规划运维体系时非常重要。
+
+**而在这些对象中，应用又是重中之重，是微服务架构下的核心运维对象**。
+
+从应用标准化的过程中我们也可以看到，针对应用的识别和建模，明显复杂很多。所以，后面我还会从理论和实践的角度来继续强化和分析这个概念。
+
+最后，给你留两个小问题。
+
+1.标准化部分我们提到，在规划和设计一个运维技术方案时，一定要找到对象主体，那请你思考以下问题：我们现在经常听到一些高大上的词汇，如水平扩展、弹性伸缩和自动化扩缩容等，你能否说一说这些技术手段的主体是谁，也就是是谁的水平扩展？弹性伸缩的是什么？同时，这些名词之间又有什么关系？
+
+2.在对象属性识别过程中，我们进行了一些关键项的举例，但是如果换一个对象，有没有好的方法论来指导我们进行准确和全面的识别，而不至于遗漏？从我们今天的内容中，你有没有发现一些规律呢？
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友。
+
+欢迎你留言与我一起讨论。
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？.md

@@ -0,0 +1,105 @@
+<audio id="audio" title="04 | 标准化体系建设（下）：如何建立基础架构标准化及服务化体系？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bc/68/bc1526161fb5a97094d974d5348e8f68.mp3"></audio>
+
+前面我们一起讨论了为什么要做标准化，标准化的套路是什么，并按照套路进行了基础设施和应用的标准化示例。我想这些内容可以帮助我们举一反三，尝试着应用到实际工作中了。
+
+今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进行架构标准化的细节，而是想强调一下基础架构标准化的重要性，因为从我个人的经历和我实际观察到的情况来看，这块的问题会更普遍一些，而这一部分又影响着后续一系列效率和稳定性平台的建设方案。
+
+同时，如果说上次我们讲的基础设施和应用标准化是运维团队职责的话，那今天的内容就是架构、开发和运维共同的职责。
+
+## 常见的分布式基础架构组件
+
+让我们先一起列一下，微服务的分布式架构下，涉及到的主要基础架构组件有哪些。
+
+- **分布式服务化框架**，业界开源产品比如Dubbo、Spring Cloud这样的框架；
+- **分布式缓存及框架**，业界如Redis、Memcached，框架如Codis和Redis Cluster；
+- **数据库及分布式数据库框架**，这两者是密不可分的，数据库如MySQL、MariaDB等，中间件如淘宝TDDL（现在叫DRDS）、Sharding-JDBC等。当前非常火热的TiDB，就直接实现了分布式数据库的功能，不再额外选择中间件框架；
+- **分布式的消息中间件**，业界如Kafka、RabbitMQ、ActiveMQ以及RocketMQ等；
+- **前端接入层部分**，如四层负载LVS，七层负载Nginx或Apache，再比如硬件负载F5等。
+
+上面是几类主要的基础架构组件，为了便于理解我以开源产品举例。但在实际场景中，很多公司为了满足业务上的个性化需求，会自己研发一些基础组件，比如服务化框架、消息中间件等，这个情况在有一定技术实力的公司里比较常见。不过大部分情况下，我们会基于这些开源产品做一些封装或局部的改造，以适应我们的业务。
+
+## 基础架构组件的选型问题
+
+关于基础架构组件，业界可供我们选择的解决方案和产品非常多，但是选择多了就容易挑花眼，反而不知道从何入手。我们大概都会遇到同样的问题，**是自研还是选择开源产品？有这么多的开源产品到底该选哪一个？**
+
+按正常的思路，一定是先组织选型调研，然后进行方案验证和对比，最后确认统一的解决方案。
+
+但是，由于开源产品的便利性，以及开发同学对技术探索的好奇心，实际情况往往是，整个大的技术团队中，不同的开发团队，甚至不同的开发人员，会根据开发的需要或个人喜好，选择不同的开源产品，在没有严格限制的情况下，甚至会尝试去自研。
+
+按照我的观察，这个问题特别容易出现在微服务架构引入初期。在这个阶段，团队组织架构按照业务领域进行切分，产生一个个与业务架构匹配的小规模技术团队。
+
+每个小团队所负责的业务相对独立，自主权就会变大，如果这个时候整个团队中没有一个强有力的架构师角色去做端到端的约束，就极其容易出现上面的这个问题，并且会一直扩散蔓延下去。
+
+相比之下，成规模的大公司在这一点上做得就相对严格一些，当然也可能是因为之前尝过苦头，所以后来变得越来越规范了。所以这一点也是每个技术团队在引入微服务架构时要提前关注的。
+
+我们以分布式服务化框架为例，我之前遇到的一个实际情况就是，整个大的技术团队选型时以Java技术栈为主，毕竟这块有很多的业界经验和产品可以借鉴参考。但是有的团队对PHP特别精通熟悉，就想用PHP去做微服务，有的团队对Go感兴趣，就想尝试Go的微服务。
+
+从单纯的技术选型上来看，选择什么语言并没有严格的标准。而且在技术团队中，我们也应该鼓励技术多样性和尝试新技术。不过这里要有个度，我暂时先不细说这个度在哪里，我们先来看看，假设没有统一标准的约束会带来什么问题。
+
+技术的应用，一般都会随着应用场景的逐步深入和业务体量的增长，逐步暴露出各种各样的问题，我们分两个层面来看。
+
+1.**开发层面**
+
+业务开发同学将大量的精力投入到基础组件和开源产品的研究、研发以及规模化之后的运维上，再加上产品形态的不统一，导致需要在技术层面的协作上做大量适配工作，而且经验还无法互通。
+
+好不容易在一个产品上摸索了很长时间，踩了很多坑，积累了宝贵的经验，结果发现另外一个产品也要经历同样的一个过程，积累的经验依然不能互通和传递。
+
+2.**运维层面**
+
+当我们考虑建设一个统一的效率和稳定体系时，发现基础组件不统一，这个时候就需要做大量的针对不同组件的适配工作。
+
+比如我们要在发布系统中做服务上下线处理，就要针对多个微服务化框架做适配。再举个稳定性上全链路跟踪的例子，为了在分布式复杂调用场景下的链路跟踪和问题定位，我们会在服务化框架中统一做打点功能，这样才不需要侵入业务逻辑。
+
+就这样一个工作，如果服务化框架不统一，就需要到每个框架里都去开发一遍。不过现实中遇到的实际问题是，整个链路就是会有这样那样的情况而串联不起来。
+
+如果你有过类似的经历，一定深有感受。其实各种各样奇葩的问题还远不止这些，继续演化下去，就是我们所说的架构失控了。
+
+当我们把业务开发资源消耗在与业务开发无关的事情上，业务开发就很难聚焦于业务架构，并能够更快、更多、更好地完成业务需求，这就与公司对业务开发的诉求背道而驰了。
+
+同时还会出现维护投入不足，那就必然导致故障频发等一系列问题，团队内部也会因为问题定位不清楚而形成扯皮推诿的不良氛围。
+
+所以，这个时候我们需要做的，就是**对基础架构有统一的规划和建设**。原则上，每种基础组件只允许一种选型，至少就能满足90%甚至更多的应用场景。
+
+比如数据库就只允许使用MySQL，然后版本统一，同时配套的中间件也必须统一，其它的关系型数据库没有特殊情况坚决不允许使用，如果遇到特殊情况具体分析。
+
+这里就举个特殊的小例子。
+
+为了更好地满足业务个性化需求，我们的消息中间件在早期选择了自研，业务上也要求各个应用使用我们统一的服务。但是对于大数据的业务来说，很多开源产品如Spark，都是原生与Kafka配套的，同时很多的新特性也都是基于Kafka去做的，在这种情况下就不能很生硬地要求大数据业务必须按照我们的标准来，这里还是得遵守大数据生态本身的标准才可以。
+
+**所以选型问题还是要看具体的业务和应用场景**，这里只介绍大致的原则，至于具体应该如何标准化，你可以参考我们前面讲到的标准化套路去尝试梳理，先看看你梳理出来的标准化体系是什么样的，后面我也会针对案例进行分享。
+
+## 基础架构的服务化
+
+我们对基础架构组件做了统一标准之后，下一步要做的就是服务化。因为这些组件都只提供了简单的维护功能，还有很多都是命令行层面的维护，这时我们要做的就是把这些组件提供的维护API进行封装，以提供更加便捷的运维能力。
+
+这里以Redis缓存为例。
+
+- 创建和容量申请；
+- 容量的扩容和缩容，新增分片的服务发现及访问路由配置；
+- 运行指标监控，如QPS、TPS、存储数据数量等等；
+- 主备切换能力等等。
+
+以上这些，假设都依赖Redis提供的原生能力来做，基本是不可维护的。所以必须要**基于这些原生能力进行封装，结合运维场景，将能力服务化，这样就大大提升了使用方的便利性**。
+
+同时，我们也可以看到，这个服务化的过程其实就是PaaS化的过程。换言之，**如果我们能把基础架构组件服务化完成，我们的PaaS平台也就基本成型了**。
+
+## 运维的职责是什么？
+
+总结上面的过程，我们要做的事情，可以归纳为两步：**第一步是基础架构标准化，第二步是基础架构服务化**。
+
+所以这个时候，运维必须要有意识去做的两件事情。
+
+<li>
+**参与制定基础架构标准，并强势地约束**。在这里运维作为线上稳定的Owner，发挥约束作用有可能会比业务架构师这样的角色更为有效。另外，由于历史原因或其他种种因素造成的已有架构标准不统一的问题，是需要开发和运维共同合作去改造的。这里面如何保持良好的协作，制定统一的路线图也是非常重要的。所以这里强制约束是一方面，同时也要提供工具化的手段来支持开发的改造，也就是下面这个动作。
+</li>
+<li>
+**基础架构的服务化平台开发，目标是平台自助化，让开发依赖平台的能力自助完成对基础组件的需求，而不是依赖运维的人**。这个事情是驱动运维转型和改进的动力，也是运维能够深入了解架构组件细节的有效途径。同时，要注意到，如果不朝着服务化方向发展，运维将始终被拖累在这些基础组件的运维操作上。
+</li>
+
+今天我们讨论的这个话题，我也和很多同行、专家交流过，发现大家都有相同的痛点，但是业界的架构资料和图书中很少涉及到这一部分的内容。我觉得根本上还是经验意识上的缺失，所以结合自己的经验专门整理出来，也很期待听到你的经验和想法。
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友。
+
+欢迎你留言与我一起讨论。
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/05 | 如何从生命周期的视角看待应用运维体系建设？.md

@@ -0,0 +1,97 @@
+<audio id="audio" title="05 | 如何从生命周期的视角看待应用运维体系建设？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ef/02/ef3e4f9151e7d05d82a9efdca9ce8b02.mp3"></audio>
+
+还记得上周我们在讲标准化体系建设（上）的最后，我留了两个小问题，其中一个是这样的：
+
+在对象属性识别过程中，我们进行了一些关键项的举例，但是如果换一个对象，我们有没有好的方法论来指导我们进行准确和全面的识别，而不至于遗漏？从我们今天的内容中，你有没有发现些规律呢？
+
+这个问题的答案其实就是我们今天要讨论的内容，那就是从“**应用生命周期管理**”的角度分阶段去梳理。
+
+简单理解下来就是，对于一个对象，既然有生命周期，就会有不同的生命周期阶段，那这个对象在不同的阶段，可能就会具备不同的属性、关系和场景。只要我们把一个对象的生命周期阶段理清楚了，顺着这条主线分阶段进行分解，就可以分析得更加清晰、明确和具体了。
+
+## 怎样理解生命周期
+
+谈到生命，首先就会联想到我们自己，所以这里以人做一个简单的类比。我们人类从出生到死亡，就是一个生命周期，在这个周期的每一个阶段，我们都会有不同的属性、关系和所要面对的场景。
+
+比如从人的学生时代开始，作为学生，我们就会具备学生的属性，会有所属学校、所属年级、所属班级、所属学号等等。这个时候我们周边的关系更多的是同学关系和师生关系。我们面临的场景可能就是读书、做作业和考试。当然学生时代细分下去还会有小学生、中学生、大学生以及研究生等阶段，每个阶段里面又会有不同的细分属性以及所要面临的场景，比如大学生毕业，就面对求职的场景等。
+
+当一个学生毕业走入职场之后，这个时候就开启了生命周期里的另一个阶段，那就是职场生涯。这个时候我们身上的属性又发生了变化，具备所属公司、所谓职位、所谓层级等。这个时候的关系也更为复杂，如同事关系、上下级关系以及各种各样的社会关系。我们所面临的场景也变得复杂，要完成工作、晋升考核、领取薪酬以及离职跳槽、再次面试等等。
+
+再往后，我们到了一定年纪，成为老年人，又会有老年人的属性、关系和场景，这里就不详细列举了。
+
+围绕着人类的生命周期，我们国家和社会提供的解决方案，就必须要有一系列对应的教育体系、职业体系、医疗体系、养老体系等。目的就是针对人生的不同阶段，提供不同形式的保障和支持，让每个人在社会体系下都够正常生存并发挥出自己的价值。
+
+从上面的分析我们可以看到，人这个对象，在不同的生命周期阶段中，会有不同的角色属性和外部关系，同时要面对的社会和生存场景也不一样。所以，当我们谈论人这个对象的时候，一定是把这个对象放到具体的某个生命周期阶段中，才会有意义。
+
+## 应用的生命周期分析
+
+回到我们运维对象的生命周期上来，我们所面对的这些对象就相对规范、标准很多。
+
+当一个场景下有多个对象时，就一定要找到那个核心的运维对象，这个核心对象的生命周期就会涵盖其它附属运维对象的子生命周期。结合我们前面讲过的内容，微服务架构下，一切要以应用核心。因此，我们就找到了整个运维体系，或者说软件运行阶段的核心对象，那就是应用。
+
+应用就类似于我们社会中的人，凡事都会以人为本，这里就是要以应用为本。那接下来按照上面我们对一个人的生命周期的阶段分解，我们也可以**对应用的生命周期阶段进行分解，大致分为五个部分，应用的创建阶段、研发阶段、上线阶段、运行阶段和销毁阶段**。我们依次来分析看一下。
+
+**1.应用的创建阶段**
+
+**这个阶段，最重要的工作，是确认应用的基础信息和与基础服务的关系，要同时固化下来，从应用创建之初，就将应用与各类基础服务的生命周期进行挂钩**。
+
+应用的基础信息，可以参考之前我们讲标准化的部分，基本上已经涵盖了比较全的信息，你可以按照生命周期的思路，再理解一下并做梳理。
+
+对于同一类的应用，只需要做一次标准化即可，后续完全可以形成模板固化到工具平台上。
+
+同时，**另外一个很重要的工作，就是要开启与应用相关的各类基础服务的生命周期**。比如这个应用需要用到缓存、消息队列和DB等，也可能需要域名DNS服务、VIP配置等，这些就要从应用创建这个动作延伸出去，启动这些关联基础服务的创建，比如需要缓存就去申请容量空间，需要消息队列要申请创建新的Topic等等。
+
+当然一个应用使用到哪些基础服务，应该是在架构设计和编码阶段就确定下来的，这里做的事情，就是把这些信息通过应用关联起来，与应用的生命周期挂钩。
+
+**2.应用的研发阶段**
+
+应用的研发阶段主要是业务逻辑实现和验证的阶段。针对业务逻辑层面的场景就是开发代码和质量保证，但是这个过程中就会涉及到代码的提交合并、编译打包以及在不同环境下的发布部署过程。同时，开发和测试在不同的环境下进行各种类型的测试，比如单元测试、集成测试以及系统测试等等，这整个过程就是我们常说的持续集成。
+
+所以，这个阶段，我们要做的最重要的一个事情，就是为研发团队打造完善的持续集成体系和工具链支持，在后面我们会有专门一个部分讲解这个过程。
+
+**3.应用的上线阶段**
+
+这是个过渡阶段，从应用创建过渡到线上运行。创建阶段，应用的基础信息和基础服务都已经到位，接下来就是申请到应用运行的服务器资源，然后将应用软件包发布上线运行，这个动作在下面的运行阶段也会持续迭代，我们直接看下面这个阶段。
+
+**4.应用的运行阶段**
+
+**这是应用生命周期中最重要、最核心的阶段**。
+
+**从运维角度来看**，应用在线上运行起来之后就已经变成一个线上运行的进程，那这个进程形态的应用应该有什么样的属性呢？你可能已经联想到，这个时候需要应用线上运行的各种指标的输出。所以这个阶段，应用最重要的属性就是应用本身以及相关联的基础服务的各项运行指标。
+
+这里，我们就需要制定每个运维对象的SLI、SLO和SLA，同时要建设能够对这些指标进行监控和报警的监控体系。
+
+**从业务角度看**，应用是线上业务逻辑的执行载体，但是我们的业务需求是在不断变化和迭代的，所以就需要不断地去迭代更新我们的线上应用，这里仍然会依赖到上述应用研发阶段的持续集成过程，并最终与线上发布形成持续交付这样一个闭环体系。
+
+**从运行阶段应用的关系看**，除了它跟基础服务之间相对固化的关系外，应用跟应用、以及应用包含的服务之间的调用关系也非常重要，而且这个关系可能随时都在变化，这个时候，我们应用之间依赖管理和链路跟踪的场景就出现了。
+
+**同时，应用线上运行还会面临外部业务量的各种异常变化，以及应用自身所依赖的基础设施、基础服务以及应用服务的各种异常状况**。比如“双11”大促，外部流量激增；微博上热点事件带来的访问量剧增；或者服务器故障、IDC故障，DB故障；再或者服务层面API的报错等等。这时就出现了线上稳定性保障的场景，比如流量激增时的限流降级、大促前的容量规划、异常时的容灾、服务层面的熔断等等。
+
+通过上面的这个分析过程，我们可以看到，**日常接触到的各种技术解决方案，都是在解决应用生命周期不同阶段中应用自身或者应用与周边关系的问题，或者是所面对的场景问题**。
+
+**5.应用的销毁阶段**
+
+这一部分就不难理解了。如果应用的业务职责不存在了，应用就可以下线销毁了。但是这里不仅仅是应用自身要销毁，我们说应用是整个运维体系的核心，所以围绕着某个应用所产生出来的基础设施、基础服务以及关联关系都要一并清理，否则将会给系统中造成许多无源（源头）的资源浪费。
+
+我们在日常工作中，经常见到的缓存系统中，很多NameSpace不知道是谁的，消息系统中有很多Topic不知道是谁的，但是又不敢随意乱动，就只能让它无端占用着系统资源。
+
+**执行应用的销毁这一步动作，其实是取决于最前面应用与基础服务的关系模型分析和建设是否做得足够到位**。
+
+## 总结
+
+今天我们分析了应用的生命周期，再结合之前讲的标准化内容，我们就找到了**做运维架构的切入点**，套路也就有了，总结一下就是：
+
+**从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景**。
+
+同理，这个思路还可以运用到基础设施和基础服务对象的生命周期管理中，虽然它们只是子生命周期，但是具体到每个基础服务上面，同样需要这个管理手段和过程。
+
+我已经介绍了很多和应用相关的内容，很大一部分的原因是希望能够帮助你梳理好思路，在思考问题和设计解决方案的时候，一定要从实际出发、从问题出发、从基础出发，理清自己的需求和痛点，然后再去寻求解决方案。
+
+借鉴业界思路，千万不要一上来就去套用别人的解决方案。因为别人的思路和解决方案往往是建立在一个非常稳固的基础之上的，而这些基础，往往又因为太基础、太枯燥、太不够酷炫，所以常常是一带而过，甚至是略去不讲的。一旦忽略了这一点，再优秀的解决方案也是无源之水，无本之木，是实现不了的。
+
+独立思考非常重要，共勉！
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友。
+
+欢迎你留言与我一起讨论。
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/06 | 聊聊CMDB的前世今生.md

@@ -0,0 +1,89 @@
+<audio id="audio" title="06 | 聊聊CMDB的前世今生" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b3/f8/b38883b2425f443f6bdc7680759d03f8.mp3"></audio>
+
+我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分：
+
+- **基础设施层面**：IDC机房、机柜、机架、网络设备、服务器等；
+<li>**应用层面**：应用元信息、代码信息、部署信息、脚本信息、日志信息等。<br />
+这两部分是整个运维架构的基础部分，运维团队是维护的Owner，需要投入较大的精力去好好地规划建设。</li>
+
+当我们识别出运维对象和对象间的关系，并形成了统一的标准之后，接下来要做的事情就是将这些标准固化，固化到某个信息管理平台中，也就是我们常说的**配置管理**，专业一点就叫作  **CMDB**（Configuration Management DataBase）。
+
+其实，如果我们找准了需求和问题在哪里，你会发现技术手段和平台叫什么就真的不重要了，只要是内部能够达成一个统一共识的叫法就好。
+
+关于如何打造CMDB和应用配置管理，我之前有一篇公开的文章《有了CMDB，为什么还需要应用配置管理》，写得已经比较细致了，会在下一期发布出来，但不占用我们专栏的篇幅。
+
+今天我主要来聊一聊CMDB的前世今生，帮助你更加深刻地理解这个运维核心部件，对我们后面开展CMDB的建设大有裨益。
+
+## CMDB源起
+
+CMDB并不是一个新概念，它源于ITIL（Information Technology Infrastructure Library，信息技术基础架构库）。而ITIL这套理论体系在80年代末就已经成型，并在当时和后来的企业IT建设中作为服务管理的指导理论得到广泛推广和实施。但是为什么这个概念近几年才被我们熟知？为什么我们现在才有意识把它作为一个运维的核心部件去建设呢？
+
+我想主要有两个因素，一个起了限制作用，一个起了助推作用。
+
+- CMDB这个概念本身的定义问题，限制了CMDB的实施；
+- 互联网技术的发展驱动了运维技术的发展和演进，进而重新定义了CMDB。
+
+## 传统运维思路下的CMDB
+
+我们先来看下第一个原因，按照ITIL的定义：
+
+> 
+<p>CMDB，Configuration Management<br />
+DataBase，配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。</p>
+
+
+看完上面这个描述，我们能感觉到，这是一个很宽泛的概念描述，实际上并不具备可落地的指导意义。事实上也确实是这样，稍后我们会讲到。
+
+同时，CMDB是与每个企业具体的IT软硬件环境、组织架构和流程强相关的，这就决定了CMDB一定是高度定制化的体系。虽然我们都知道它不仅仅是一个存储信息的数据库那么简单，但是它的具体形态是什么样子的，并没有统一的标准。
+
+**从传统IT运维的角度来看，运维的核心对象是资源层面**，所谓的基础架构也就是网络设备和硬件设备这个层面；各种关联和拓扑关系，基本也是从服务器的视角去看。所以更多地，我们是把CMDB建设成为一个以设备为中心的信息管理平台。
+
+这也是当前绝大多数公司在建设运维平台时最优先的切入点，因为这些运维对象都是实体存在的，是最容易被识别的和管理的；像应用和分布式中间件这种抽象的逻辑对象反而是不容易被识别的。
+
+这种形态，如果是在软件架构变化不大的情况下，比如单体或分层架构，以服务器为中心去建设是没有问题的。因为无论设备数量也好，还是申请回收这些变更也好，都是很有限的，也就是整个IT基础设施的形态变化不大。
+
+我没有专门调研过国外的实施情况，但就国内的情形，谈下我的经历。
+
+早期，大约是在2009~2013年，我接触了一个省级运营商的全国性项目。2012年的时候日PV就到了5亿左右，日订单创建接近2000万。分层的软件架构，不到千台服务器，对于资源的管理，仍然是用Excel表格来记录的。
+
+运维基于这样一个表格去管理和分配各种资源，问题也不算太大。究其根本，就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构。但是发展到后来，这样的软件架构无法满足业务的快速迭代，还是做了架构上的拆分，这就是后话了。
+
+这里我想表达的是，在那个时期，即使是在IT架构相对先进的运营商体系下面，我也没有太多地听说过CMDB这个概念，包括运营商自身，以及为运营商提供整体技术解决方案的厂商，还有来自方方面面的资深架构师和咨询师等，在做系统架构和运维架构设计时，没有人提及过CMDB，也没有人提出把它作为核心部件去建设，更多的都是从ITIL管理服务的流程体系去给出咨询建议；在落地实施的时候，我们最终见到的大多是一条条的流程规范和约束，后来增加的也多是流程和审批，甚至是纸质的签字审批。
+
+这也从一个侧面说明，CMDB在那个时期更多的还是停留在概念阶段，甚至是无概念状态，也没有什么最佳实践经验的传承，CMDB这个概念本身并不具备实践意义，管理的方式方法也就停留在原始的Excel表格中。
+
+**高大上的ITIL体系更多的是被当做流程规范来落地的，真正体现在技术方案和技术产品上的落地并不多。我想这是实施过程中对ITIL理解和运用的一大误区**。
+
+接下来，我们看第二个原因，也就是互联网运维的助推力。
+
+## 互联网运维体系下的CMDB
+
+值得庆幸的是，进入到互联时代，**随着互联网运维力量的崛起，CMDB这个概念也真正地得到了落地实践，从理论概念的方法论阶段过渡到了具备具体技术方案的可实施阶段，而且得到了业界的持续分享和传播**。我们现在能够看到的CMDB经验分享，基本上都是中大型互联网公司的运维最佳实践。
+
+不过，值得注意的是，“此CMDB”已经非“彼CMDB”。我们前面提到，传统运维阶段，我们更多是以设备为核心进行管理，但是到了互联网技术阶段，这个核心就变了，变成了应用这个核心对象。
+
+至于原因，我们前面已经讲过，主要还是互联网技术的快速发展，大大推进了微服务技术架构的落地和实践，这种场景下，应用各维度的管理复杂度、应用的复杂度就逐渐体现出来了，所以我们的很多运维场景就开始围绕着应用来开展。
+
+与此同时，云计算技术也在蓬勃发展，逐步屏蔽了IDC、网络设备以及硬件服务器这样的底层基础设施的复杂度，有公有云或私有云厂商来专注聚焦这些问题，让我们的运维不必再花过多的精力在这些基础设施上面；同时，单纯以硬件为核心的CMDB形态也被逐步弱化。
+
+所以，此时的CMDB，仍然可以叫做配置管理数据库，但是这个配置管理的外延已经发生了很大的变化。之前所指的简单的硬件资源配置管理，只能算是狭义的理解；从广义上讲，当前的应用以及以应用为核心的分布式服务化框架、缓存、消息、DB、接入层等基础组件，都应该纳入这个配置管理的范畴。
+
+所以在这个时期，我们提到的运维自动化，远不是自动化的服务器安装部署交付或网络自动化配置这种单一场景，而是出现了持续交付、DevOps、SRE等更适合这个时代的对运维职责的定义和新的方法论。
+
+到了这个阶段，**传统运维思路下的CMDB，因为管理范围有限，可以定义为狭义上的CMDB；而互联网运维思路下的CMDB外延更广，我们称它为广义的CMDB**。新的时期，对于CMDB的理解也要与时俱进，这个时候，**思路上的转变，远比技术上的实现更重要**。
+
+## CMDB进行时
+
+如果我们仔细观察，会发现一个很有意思的现象。CMDB源于80年代末的ITIL，源于传统IT运维阶段，但真正让它发扬光大的，确是新兴的互联网运维行业，而且现在很多的传统行业也在向互联网学习运维技术。
+
+与此同时，在中大型的互联网公司中，比如阿里和腾讯，也越来越重视流程规范的管控，开始更多地将严格的流程控制与灵活的互联网运维技术结合起来，以避免在过于灵活多变的环境下导致不可控的事件发生。
+
+所以，从这里我们可以看到，**并不是说ITIL的重流程体系就一定是过时老旧的，也不是说互联网运维技术就一定代表着最先进的技术趋势，而是在这个过程中，不同体系相互借鉴、相互学习、共同进步和发展，在碰撞的过程中，催生出更适合这个时代的技术体系**。
+
+这确实是一个充满了机遇和挑战、但又不乏乐趣的新时代。
+
+今天我们讲了CMDB的前世今生，我所讲到的对ITIL以及其定义下的CMDB的理解，更多的是根据我个人的早期经历，还有和业界同行交流的经验所得，我自己并没有完整系统地学习过，所以理解上和见识上会有一定的局限，也期望你能批评指正，我们一起讨论、共同进步。
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/07 | 有了CMDB，为什么还需要应用配置管理？.md

@@ -0,0 +1,78 @@
+<audio id="audio" title="07 | 有了CMDB，为什么还需要应用配置管理？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/04/f5/045555e2ca883367ddd907b63bea0cf5.mp3"></audio>
+
+今天我们分享的主题是：有了CMDB，为什么还需要应用配置管理？
+
+你不妨先停下来，思考一下这个问题。
+
+我抛出的观点是： **CMDB是面向资源的管理，应用配置是面向应用的管理**。
+
+请注意，这里是面向“资源”，不是面向“资产”，资源 ≠资产。
+
+## CMDB是面向资源的管理，是运维的基石
+
+我们一起来梳理一下，在建设运维的基础管理平台时通常要做的事情。
+
+- **第1步**，把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来；
+- **第2步**，把这些硬件的属性确定下来，比如服务器就会有SN序列号、IP地址、厂商、硬件配置（如CPU、内存、硬盘、网卡、PCIE、BIOS）、维保信息等等；网络设备如交换机也会有厂商、型号、带宽等等；
+- **第3步**，梳理以上信息之间的关联关系，或者叫拓扑关系。比如服务器所在机柜，虚拟机所在的宿主机、机柜所在IDC等简单关系；复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系；
+- **第3.5步**，在上面信息的梳理过程中肯定就会遇到一些规划问题，比如，IP地址段的规划，哪个网段用于DB，哪个网段用于大数据、哪个网段用于业务应用等等，再比如同步要做的还有哪些机柜用于做虚拟化宿主机、哪些机柜只放DB机器等。
+
+以上信息梳理清楚，通过ER建模工具进行数据建模，再将以上的信息固化到DB中，一个资源层面的信息管理平台就基本成型了。
+
+但是，**信息固化不是目的，也没有价值，只有信息动态流转起来才有价值**（跟货币一样）。接下来我们可以做的事情：
+
+- **第4步**，基于这些信息进行流程规范的建设，比如服务器的上线、下线、维修、装机等流程。同时，流程过程中状态的变更要同步管理起来；
+- **第5步**，拓扑关系的可视化和动态展示，比如交换机与服务器之间的级联关系、状态（正常or故障）的展示等，这样可以很直观地关注到资源节点的状态。
+
+至此，从资源维度的信息梳理，以及基于这些信息的平台和流程规范建设就算是基本成型了。这个时候，以服务器简单示例，我们的视角是下面这样的：<br />
+
+
+<img src="https://static001.geekbang.org/resource/image/25/e8/25f7203e9ce69c524bac80ea43f523e8.jpeg" alt="" /><br />
+
+
+## 应用配置管理是面向应用的管理，是运维的核心
+
+上面说明了CMDB的基础信息部分，如果从传统的SA运维模式，这些信息已经足够，但是从应用运维的角度，这些就远远不够了。
+
+这时我们就需要一个非常非常重要的句柄：**应用名**，或者叫应用标识。至此，应用运维里面最最重要的一条联系也就产生了：**“应用名-IP“的关联关系**（这里也可以是定义的其它唯一主机标识，如主机名、容器ID等等，因为我们使用的方式是IP，所以这里就以IP示例）。
+
+之所以说“应用名”和“应用名-IP关联关系”非常重要，是因为它的影响力不仅仅在运维内部，而是会一直延伸到整个技术架构上。后面我们会介绍到的所有平台和系统建设，都跟这两个概念有关。
+
+CMDB是IP为标识的资源管理维度，有了应用名之后，就是以应用为视角的管理维度了。首先看一下应用会涉及到的信息：
+
+- 应用基础信息，如应用责任人、应用的Git地址等；
+- 应用部署涉及的基础软件包，如语言包（Java、C++、GO等）、Web容器（Tomcat、JBoss等）、Web服务器（Apache、Nginx等）、基础组件（各种agent，如日志、监控、系统维护类的tsar等）；
+- 应用部署涉及的目录，如运维脚本目录、日志目录、应用包目录、临时目录等；
+- 应用运行涉及的各项脚本和命令，如启停脚本、健康监测脚本；
+- 应用运行时的参数配置，如Java的jvm参数，特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等；
+- 应用运行的端口号；
+- 应用日志的输出规范；
+- 其他。
+
+上面的梳理过程实际就是标准化的过程。我们梳理完上述信息后就会发现，这些信息跟CMDB里面的资源信息完全是两个维度的东西。所以从信息管理维度上讲，把资源配置和应用配置分开会更清晰，解耦之后也更容易管理。
+
+**好了，按照上面CMDB说的套路，梳理完成后，就是要进行信息的建模和数据的固化，这时就有了我们的“应用配置管理”**。再往后，就是基于应用配置管理的流程规范和工具平台的建设，这就涉及到我们经常说的持续集成和发布、持续交付、监控、稳定性平台、成本管理等等。
+
+从应用的视角，我们配置管理，应该是下面这样一个视图（简单示例，不是完整的）：
+
+<img src="https://static001.geekbang.org/resource/image/6e/cd/6ee5e2dc98630d233a3dbd4201f36dcd.jpeg" alt="" /><br />
+<br />
+好了，有了资源配置信息和应用配置信息，这两个信息应该怎么统一管理起来呢。直接看图：
+
+<img src="https://static001.geekbang.org/resource/image/c8/6b/c8243cfbd07d99478a1b6193cb20b56b.jpeg" alt="" />
+
+至此，CMDB和应用配置管理的分层分解就完成了，应用名关联着应用配置信息，IP关联着资源信息，二者通过“应用名-IP”的对应关系，联系到一起。
+
+## 总结
+
+**CMDB是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，所以我们说应用才是运维的核心**。
+
+你可以看到，如果仅仅基于CMDB的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上给业务带来价值了。
+
+但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，做这些事情带来的价值就会大大不同。
+
+以上就是我抛出的观点，CMDB是面向资源的管理，应用配置是面向应用的管理。希望能够抛砖引玉，听到更多你的观点和反馈。
+
+如果今天的内容对你有用，也希望你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/08 | 如何在CMDB中落地应用的概念？.md

@@ -0,0 +1,111 @@
+<audio id="audio" title="08 | 如何在CMDB中落地应用的概念？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c8/f7/c82478782d1b0a67f936d07ac55ea8f7.mp3"></audio>
+
+我们前面讲了应用是整个微服务架构体系下运维的核心，而CMDB又是整个运维平台的基石。今天我就讲讲在CMDB中如何落地应用这个核心概念，以及如何建立应用集群分组的思路。
+
+## 如何有效组织和管理应用
+
+微服务架构下会有很多应用产生出来，少则十几、几十个，多则上百甚至上千个。这时我们面临的第一个问题就是如何有效地组织和管理这些应用，而不是让它们在各处散乱，命名方式和层次结构可能还不统一。
+
+你可能接触过“**服务树**”的概念，这个提法是小米在早期互联网运维实践的分享中传播出来的。我第一次听到这个概念是在13年阿里技术嘉年华大会上听小米运维的分享。再往前，这个概念应该是从百度的运维体系中借鉴出来的。
+
+这里的服务实际对应的就是我们前面提到的应用这个概念。据我了解，在阿里和腾讯都是叫作应用，现在业界比较通用的叫法也是应用。其实叫什么并不重要，关键还是要学习到对这个概念的管理方式。
+
+从服务树这个名字中，我们就可以了解到，有效组织和管理应用的方式，就是把它组织成一个树形的层次结构。这种管理模式，无论是在BAT，还是在其它的互联网公司，基本都是一样的思路和模式，所以叫法虽然不同，但是思路上却是相通的，可谓异曲同工。
+
+**基于业务维度的拆分，对应产生了我们的应用拆分原则**。比如对于电商公司，大的维度会有电商、支付、广告、流量和搜索等业务领域；进一步，电商业务领域里最典型的会有用户、会员、商品、交易、商家、店铺以及物流等；这里面还可以再进一步细分，比如商品会有详情、SKU、SPU、库存、评价、标签等。
+
+讲到这里，我们再看一下技术团队的组织架构，基本上是对应着整个业务技术架构的拆分的。也就是**业务架构决定了技术架构，而技术架构又决定了一个研发团队的组织架构**，这个组织架构中不同的团队单元分别承担着对应业务的需求开发和实现职责。
+
+上面这个组织架构建设的逻辑和思路，也是我们在组建团队和职责划分时可以参考的。
+
+这样一个逻辑讲下来，我们的**应用管理思路**其实也就明晰了：**产品线-业务团队-应用**。
+
+这里举个电商商品的例子就是：电商技术-商品团队-商品中心-商品详情等。
+
+<img src="https://static001.geekbang.org/resource/image/51/ab/517948c6d93d9818f4d3bab69ba87bab.jpg" alt="" />
+
+当然因为每个公司对组织架构定义的方式不同，也可以用一、二级部门这样的方式来指代。但是具体团队的分工和职责，一定是来自于业务架构决定的技术架构，只有这样，各业务团队才会职责清晰，配合协作才会顺畅起来。
+
+对于应用名定义，要设定规范，比如：
+
+- 应用名必须以大小写英文字母以及下划线组合；
+- 应用名长度不超过40个字符，尽量简单易懂；
+- 不允许出现机房代号和主机名称这样的信息。
+
+简单举例，商品中心命名为itemcenter，商品详情命名为detail。
+
+这里做个小结：**到了软件运维阶段，运维工作是否可以高效地组织开展，很大程度上，在前面的业务架构拆分阶段就决定了。也就是业务架构拆分得是否合理、职责是否明晰，决定了后续团队组织架构是否合理、团队职责是否明晰。如果这点没做好，到了运维阶段必然就是混乱的**。
+
+这一点我在开篇词中也提到过，**运维能力的体现，一定是整体技术架构能力的体现，割裂两者单独去看，都是没有意义的**。同时，对于当前仍然把运维割裂建设的研发团队，也需要去思考一下在组织架构建设上的合理性了。
+
+## 应用的集群服务分组建设
+
+上述讲到的是应用的组织管理，看上去逻辑思路相对清晰，组织起来也不复杂，但是再往下，应用的集群服务分组建设就会相对复杂了。
+
+为什么会有集群服务分组呢？我们一起来看这么几个需求场景。
+
+**场景一：多环境问题**。
+
+我们常见的环境会有开发联调环境、集成测试环境、预发环境、线上环境等等。后面我们讨论持续交付时会讲到，实际场景下所需要的环境会更多。
+
+**场景二：多IDC问题**。
+
+对于大型互联网业务，会做业务单元化，或者有海外业务拓展需求的场景，我们会在多个IDC机房部署应用，应用代码是相同的，但是配置可能会不同。
+
+**场景三：多服务分组问题**。
+
+这个场景就跟具体业务场景相关了。举个例子，比如商品中心IC这样一个核心应用，对外会有商品详情、交易下单、订单、购物车、评价、广告、秒杀活动、会场活动、商家、店铺等一系列应用依赖它，但是这些依赖它的应用优先级是不一样的。
+
+- **核心应用和非核心应用**：比如交易支付链路上的应用属于核心应用，任何时候都必须要优先保障，但是对于评价、商家和店铺这些应用优先级就低一些。反过来理解就是一个应用出现故障，是不是会影响业务收入，如果影响就属于核心应用，如果不是或者影响非常小，那就属于非核心应用。所以IC这个应用下面，就会有IC的交易分组，IC的广告分组、IC的电商分组等，**这些分组就会相对固定和静态**。
+- **场景因素决定**。这个对于电商就会比较典型，比如大促时的秒杀场景，对于参加秒杀活动的商品，瞬时的访问量就会非常大，而不参加活动的商品就不会有这么大的访问量。所以这时为了隔离较大的流量，就需要有多个不同的秒杀IC分组，从资源层面进行隔离；同时上层秒杀活动的应用在配置中心配置依赖时，就要配置到对应的秒杀IC集群分组上，这样即使秒杀IC出现问题，也不会影响正常的商品IC访问。所以根据场景，不同阶段就会有IC的大促秒杀分组，**这种类型的分组就需要根据实际的业务场景来决定，是个动态调整的过程，需要开发和运维一起来讨论和验证**。
+
+一般情况下，集群服务分组会有以上三个维度中的一个或多个来决定。还是以商品中心IC为例，按照上面的介绍，就会对应如下关系：
+
+<img src="https://static001.geekbang.org/resource/image/03/98/035dfa554ab4799e625f84eb52ab7d98.jpg" alt="" /><br />
+
+
+至此，“**应用-集群服务分组-资源**”的对应关系就建立起来了。这里我们叫它“应用树”或者“服务树”都可以，不管叫什么，这个信息是CMDB中最为关键和核心的信息。为什么是最关键和核心的呢？
+
+## CMDB在基础服务体系中的核心位置
+
+这里我们以应用为核心来看，CMDB中会保存“应用-分组-资源”的对应关系，这个关系对于周边系统来说都是需要的，举例如下。
+
+1.**监控系统**。
+
+我们需要以上的对应关系，监控到每个应用、每个集群以及每台机器上的关键信息。
+
+2.**发布系统**。
+
+我们需要将每个应用对应的代码进行编译打包，然后发布到对应集群的主机上，也需要这个对应关系，这一点我在后面的持续交付中还会讲到。
+
+3.**服务化框架**。
+
+需要依赖应用和集群分组两个信息，其中主要是对应用名和集群分组名的依赖，对于服务化框架来说，更多的是通过其配置管理中心注册的应用名，来实现应用的服务和API管理，这里要做到与CMDB统一。同样，像LVS和Nginx这样的四七层负载，以及ZK这样的开源分布式配置管理，凡是涉及服务注册、服务发现以及服务上下线的基础服务，都是类似思路。
+
+4.**基础服务中**。
+
+如分布式DB、分布式缓存和消息等，就需要应用的应用名，以及应用与资源IP的对应关系，或者集群分组与IP的对应关系。
+
+- **应用名**，是因为要建立应用与分布式服务实例之间的关系。如应用与缓存NameSpace的对应关系，应用与消息Topic的对应关系等，以便于这些基础服务的生命周期管理和自动化开发。
+- **应用与资源的对应关系**，是因为有些核心资源是要做ACL访问控制的。比如对于用户、交易或支付这样非常敏感的数据，它们对应的数据库就不允许随意连接，而应该是仅限于授权过的应用访问。这时就要针对应用对应的IP地址进行白名单配置。一方面，可以通过分布式DB中间件进行配置；另一方面，也可以通过在DB层面进行设置，比如MySQL就可以直接配置白名单策略；同时也可以在机器的iptables上配置，至于如何配置就看具体需求了，但是无论怎样，应用与资源的对应关系是非常重要的。
+
+5.**稳定性保障平台，或者叫服务治理平台**。
+
+针对系统的稳定性，我们会在应用中做很多的降级限流和开关预案策略，这些都是跟应用直接关联的。而且按照我们前面介绍的，不同的集群分组，策略可能会有不同，所以又会跟集群分组相关。同时，这些策略最终下发到具体服务器上运行的应用实例上，所以这里就会需要应用、集群分组以及对应的资源关系。
+
+总结一下，简单示意图如下：
+
+<img src="https://static001.geekbang.org/resource/image/73/fe/7351b5e3b985d76c9e85875472c625fe.jpg" alt="" />
+
+## 总结
+
+通过上述的分析，我们可以看到**基于以应用为核心的CMDB中，又衍生出“应用-集群服务分组-资源”这样一个运维体系中的核心关系**。经过这三部分的分析，我们之前所说的基于应用为核心的运维视图就可以建立出来了，我们再次示意如下：
+
+<br />
+<img src="https://static001.geekbang.org/resource/image/10/6f/1028e2a9fdd0ab316a2893c6ee5d1e6f.jpg" alt="" />
+
+今天我们讨论的内容提到了，监控、发布、基础服务以及稳定性平台会依赖CMDB中“应用、集群服务分组-资源”的对应关系信息，但是当CMDB中的这些关系信息发生变化，比如新增一个IP，或者下线一个IP，这些信息是如何传递到其它平台的呢？这些平台又是如何查询这些关键信息的呢？欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/09 | 如何打造运维组织架构？.md

@@ -0,0 +1,102 @@
+<audio id="audio" title="09 | 如何打造运维组织架构？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/3b/3e06bf6e4303d57288bd9bba32b6a63b.mp3"></audio>
+
+前面几周，我们介绍了Netflix为什么没有运维岗位、应用运维标准化、基础服务标准化以及从应用生命周期的角度如何进行运维建设等内容。这一周我们就来聊聊在组织架构和运维转型方面的话题。
+
+## Netflix给我们的启示
+
+专栏的第一篇我们就介绍了Netflix的云平台组织架构，你应该可以发现，Netflix其实已经给我们提供了一个非常好的思路和方向，就是**在提供基础服务能力的同时，提供对应的自助化运维能力**。也就是说，开发人员可以在这样一个平台上完成自己想要做的任何运维操作，而不再依赖运维的人。
+
+**我们最应该学习和借鉴的，也恰恰是我们绝大多数团队都会忽略的，就是要做好运维和整个技术架构体系的融合，一定不要割裂两者。同时，还要注意不仅仅是促进组织架构层面的融合，最重要的是要促进职能协作上的融合**。
+
+应该怎么理解呢？
+
+我先撇开组织架构，大致说一下我的思路。开篇词中我提到，运维能力的体现，一定是整体技术架构能力的体现。所以，**要想做好运维就一定要跳出运维这个框框**，从全局的角度来看运维，**要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力**。这一点是根本，一定要注意。**如果我们仍然片面地从运维的角度看运维，片面地从运维的角度规划运维，是无法走出运维低价值的困局的**。
+
+## 从价值呈现的角度看运维
+
+当我改变了这个认知后，我的出发点就回归到了效率、稳定和成本这三个对于研发团队来说最重要的目标上来。从运维的角度来说，能够与这三个点契合的事情，我总结了以下五个。
+
+**1. 运维基础平台体系建设**
+
+这块主要包括我们前面提到的标准化体系以及CMDB、应用配置管理、DNS域名管理、资源管理等偏向运维自身体系的建设。**这一部分是运维的基础和核心**，我们前面讲到的标准化以及应用体系建设都属于这个范畴。
+
+**2. 分布式中间件的服务化建设**
+
+**在整个技术架构体系中，分布式中间件基础服务这一块起到了支撑作用**。这一部分的标准化和服务化非常关键，特别是基于开源产品的二次开发或自研的中间件产品，更需要有对应的标准化和服务化建设。这也是我们无意识地割裂运维与技术架构行为的最典型部分，这里容易出现的问题，我们前面讲过，你可以回去再复习一下。
+
+**3. 持续交付体系建设**
+
+**持续交付体系是拉通运维和业务开发的关键纽带，是提升整个研发团队效率的关键部分**。这个部分是整个软件或应用的生命周期的管理体系，包括从应用创建、研发阶段的持续集成，上线阶段的持续部署发布，再到线上运行阶段的各类资源服务扩容缩容等。开发和运维的矛盾往往比较容易在这个过程中爆发出来，但是这个体系建设依赖上面两部分的基础，所以要整体去看。
+
+**4. 稳定性体系建设**
+
+软件系统线上的稳定性保障，包括如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。这里面还会有一些运作机制的建设，比如如何对故障应急响应、如何对故障进行有效管理、如何对故障复盘、如何加强日常演练等等。同样，这个环节的事情也要依赖前两个基础体系的建设。
+
+**5. 技术运营体系建设**
+
+技术运营体系也是偏运作机制方面的建设，最主要的事情就是确保我们制定的标准、指标、规则和流程能够有效落地。这里面有些可以通过技术平台来实现，有些就需要管理流程，有些还需要执行人的沟通协作这些软技能。
+
+最终通过这样一个规划，我把团队以虚拟形式重新规划了不同职责，分别负责基础平台体系、分布式中间件服务化体系、持续交付体系和稳定性体系，基本就是上述的前四件事情。
+
+对于最后一个技术运营体系，这一点作为共性要求提出。我要求团队每个成员都要具备技术运营意识。具体来说，就是要能够有制定输出标准的意识和能力，能够有规范流程制定的能力，同时能够将标准和流程固化到工具平台中，最后能够确保承载了标准和规范的平台落地，也就是平台必须可用，确实能给运维团队或开发团队带来效率和稳定性方面的提升。这些对个人的要求还是比较高的，要有一定的规划、设计和落地能力，能具备一整套能力的人还是少数，目前这块还是靠团队协作来执行。
+
+## 运维协作模式的改变
+
+上面的这几件事情，并不是由运维团队内部封闭来做。还是我们反复强调的那个思路，**要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角，而不仅仅是发挥运维团队的运维能力**。所以这些事情的执行可以理解为是由运维团队发起，与周边技术团队协作配合来完成的。
+
+所以这些事情都需要**跨团队协作**。一方面运维团队要主动出击，去沟通，去推进；另一方面，必须能得到上级主管甚至是更高层技术领导的支持，所以这里**要求技术管理者必须要有这个意识，促进这样的组织协作方式变革**，如果技术管理者意识不到或者支持不到位的话，运维在后续的推进工作中将会遇到非常大的阻力。
+
+下面来分享下我们目前正在尝试的一些调整。
+
+我们运维所在的平台技术部门，包括了分布式中间件、虚拟化技术、稳定性工具平台以及大数据几个子部门。当我们发起并推进上述工作时，就需要与这些团队联合协作，朝着某个目标共同执行。下面我们来看看细分的情况。
+
+**1. 运维基础平台建设**
+
+这块大多数的工作会由运维来完成，因为这是运维的基础，也属于整个技术架构比较关键的基础平台之一，这一点我们在讲应用和集群服务管理时已经介绍过。
+
+**2. 分布式中间件服务化建设**
+
+这个部分我们就需要分布式中间件团队的配合。我们可以一起制定各种使用标准、规范和流程；中间件团队负责提供运维服务能力的接口；运维团队根据用户使用的场景进行场景化需求分析，并最终实现场景，同时负责标准和自助化工具平台的推广和落地。
+
+**3. 持续交付体系建设**
+
+这一部分也会涉及多个团队的协作。在资源使用上，我们前期会用到KVM，那么如何快速交付KVM资源，就需要与虚拟化技术团队协作。现在我们在尝试容器方案，涉及到镜像制作、网络配置以及对象存储这些底层技术，一样会与虚拟化团队配合，在资源交付效率和利用率上都有很大提升。同时，还会与中间件团队协作，因为在应用发布和扩容缩容过程中，就会涉及服务上下线，这就要与服务化框架配合，服务化框架提供底层运维服务能力，而运维要做的就是通过中间件运维能力的封装整合，进而实现用户使用的场景化需求。
+
+**4. 稳定性体系建设**
+
+这里会涉及一些链路埋点、限流降级、以及开关预案等一些技术方案需求，通常会有这样一个专门的稳定性工具团队，对外输出一些稳定性保障能力，比如一些稳定性通用SDK的开发，后台日志采集分析以及数据计算等等，这些事情会对技术能力的要求比较高，需要具备较强开发能力的人来做。所以，运维在这里发挥的作用一个是上述提到的场景化实现能力，再一个就是稳定性能力的落地，或者说是运营能力。稳定性工具提供的多是能力和支持，最终要在业务层面真正执行，就需要运维和业务开发共同来执行。比如一个应用上线，是否具备关键接口的限流降级能力，是否具备熔断能力，是否满足上线的性能及容量要求，这个工作是需要运维深入每个业务，根据不同的业务场景和实现情况，一个个具体落地才行。所以，整体上对运维技术运营能力的要求就会非常高。
+
+**运维在这个过程中要发挥的最关键作用就是通过用户使用场景的分析，将各项基础服务封装并友好地提供出来，并确保最终的落地**。方式上，或者是通过**工具平台的技术方式**，比如分布式中间件基础服务；或者是通过**技术运营能力**，比如稳定性能力在业务层面的落地。
+
+**运维在这个过程中，就好像串起一串珍珠的绳子，将整个平台技术的不同部门，甚至是开发团队给串联起来，朝着发挥出整体技术架构运维能力的方向演进**。
+
+## 运维的组织架构
+
+上面是我们从团队需求和运维价值呈现层面成立的虚拟组织，从实际的人员管理以及技能维度来划分的话，我们和其它互联网公司的运维团队差别不大，基本会分为如下几个岗位：
+
+- **基础运维**，包括IDC运维、硬件运维、系统运维以及网络运维；
+- **应用运维**，主要是业务和基础服务层面的稳定性保障和容量规划等工作；
+- **数据运维**，包括数据库、缓存以及大数据的运维；
+- **运维开发**，主要是提供效率和稳定性层面的工具开发。
+
+这个实体的组织架构，相当于是从技能层面的垂直划分。基础运维更擅长硬件和操作系统层面的运维；应用运维可能更擅长业务稳定性保障、疑难问题攻关以及技术运营等；数据运维就不用多说了，DBA本身就是专业性极高的一个岗位；运维开发则是支持上述几个岗位日常运维需求的，是否能将人力投入转换成工具平台支持，就看这个团队的能力。
+
+而前面所说的从价值呈现层面进行的虚拟团队划分，则是将上述几个实体团队技能上的横向拉通，让他们重新组织，形成技能上的互补，从而发挥出更大的团队能力。
+
+实体组织架构，相当于一个人的骨骼框架，但是价值呈现层面的虚拟组织，就更像是一个人的灵魂，体现着这个人的精神面貌和独特价值。
+
+这个过程中，必然会对**运维的技能模型**有更新、更高的要求。
+
+## 总结
+
+今天我为你介绍了我们正在实践的一些运维组织架构方面的内容。后来当我翻阅《SRE：Google运维解密》这本书时，发现如果按照书中的章节目录进行分类的话，基本上都可以与前面我介绍的部分对应起来，这也更加坚定了我们要按照这套组织模式运作下去的信心。
+
+同时，我们也要明白，**业界没有一劳永逸的组织架构，也没有放之四海而皆准的组织架构标准，更没有万能的可以解决任何问题的组织架构设计，这里的关键是我们如何能够发挥出团队整体的能力和价值，而这一点又需要我们不断地与自己所在团队和业务特点去匹配和契合，这是一个不断变化的过程，也是需要持续调整的过程**。
+
+所以这对技术管理者要求会比较高，应该如何不断地去匹配和契合这个最佳价值点，同时如何统筹调度好团队中不同类型的技术资源并形成合力，是非常重要的。
+
+你的团队在实际过程中遇到过哪些问题，你有怎样的经验和观点，欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/10 | 谷歌SRE运维模式解读.md

@@ -0,0 +1,72 @@
+<audio id="audio" title="10 | 谷歌SRE运维模式解读" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/49/7e/4999e5d4c8426ee422d0e295a1c7bc7e.mp3"></audio>
+
+前面我和你分享了一些关于运维组织架构和协作模式转型的内容，为了便于我们更加全面地了解先进的运维模式，今天我们再来谈一下谷歌的SRE（Site Reliability Engineer）。同时，也期望你能在我们介绍的这些运维模式中找到一些共通点，只有找到这些共通点，才能更深刻地理解，并借鉴到真正对我们有用的东西。
+
+专栏的第一篇文章我们介绍了Netflix的NoOps模式。这个模式并不意味着不存在任何运维工作，只是Netflix将这些事情更紧密地融入到了日常的开发工作中，又做得非常极致，所以并没有很明显地体现出来。
+
+但是，谷歌的SRE却是一个真实具体的岗位，也有明晰的岗位职责。从借鉴意义上来讲，SRE可以给我们提供更好的学习思路和样板。
+
+SRE这个概念，我应该是2014年下半年的时候听到的。当时可接触的资料和信息有限，只知道是谷歌对运维岗位的定义，负责稳定性保障，就没有更多其他的认识了。
+
+后来，有越来越多在谷歌工作或接触过这个岗位的专家开始在公开演讲中分享这个概念。同时，《SRE：Google 运维解密》，这本由多名谷歌SRE亲笔撰写的图书也开始在国内广泛流传，让我们对很多细节有了更加细致的了解。
+
+## SRE岗位的定位
+
+首先，SRE关注的目标不是Operation（运维），而是Engineering（工程），是一个“**通过软件工程的方式开发自动化系统来替代重复和手工操作**”的岗位。我们从SRE这本书的前面几个章节，可以看到谷歌不断强调SRE的工程能力。我简要摘取几段：
+
+> 
+<p>Common to all SREs is the belief in and aptitude for developing<br />
+software systems to solve complex problems.<br />
+所有的SRE团队成员都必须非常愿意，也非常相信用软件工程方法可以解决复杂的运维问题。</p>
+<p>By design, it is crucial that SRE teams are focused on engineering.<br />
+SRE模型成功的关键在于对工程的关注。</p>
+<p>SRE is what happens when you ask a software engineer to design an<br />
+operations team.<br />
+SRE就是让软件工程师来设计一个新型运维团队的结果。</p>
+
+
+与之相对应的，还有一个很有意思的地方，整本书中提到Operation的地方并不多，而且大多以这样的词汇出现：Operation load，Operation overload，Traditional/Manual/Toil/Repetitive Operation Works。你可以仔细体会一下，这些大多就是传统的纯人工操作模式下的一些典型词汇。
+
+我们可以看到，从一开始，谷歌就没把SRE定义为纯操作类运维的岗位，也正是**谷歌换了一个思路，从另外一个维度来解决运维问题，才把运维做到了另一个境界**。
+
+## SRE岗位的职责
+
+书中对SRE的职责定义比较明确，**负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作**。如果站在价值呈现的角度，我觉得可以用两个词来总结，就是“**效率**”和“**稳定**”。
+
+接下来，详细说下我的理解和分析。
+
+SRE的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力，同时还需要良好的沟通协作能力，这个就属于**职场软技能**。
+
+SRE，直译过来是网站稳定性工程师。表面看是做稳定的，但是我觉得更好的一种理解方式是，**以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作**。
+
+分解一下，这里主要有“管理”和“技术”两方面的事情要做。
+
+- **管理体系上**，涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等。
+- **技术体系上**，以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环。
+
+可以看到技术上的平台和系统是用来支撑管理手段的。谷歌的运维其实并没有单独去提自动化、发布、监控等内容，而是通过稳定性这个核心目标，把这些事情全部串联在一起，同时又得到了效率上的提升。
+
+我们来看几个主要的系统。
+
+- **自动化**。是为了减少人为的、频繁的、重复的线上操作，以大大减少因人为失误造成的故障，同时提升效率。比如谷歌内部大名鼎鼎的Borg系统，可以随时随地实现无感知的服务迁移。现在，它的开源版本，已然成为业界容器编排体系标准的Kubernetes。
+- **持续交付**。谷歌非常重视持续交付。由于它的需求迭代速度非常快，再加上是全球最复杂的分布式系统，所以就更加需要完善的发布系统。
+- **问题定位**。这块跟监控相关但又有不同。我看到谷歌SRE这本书中并没有提到太多Tracing的内容，更多的是讲监控和问题管理层面的跟踪机制。其实，关于问题定位，谷歌的Dapper大名鼎鼎，功能很强大，国内外很多跟踪系统和思路都参考了Dapper的理论。这块也是为了能够快速定位问题，保障稳定而产生的，国内分享的大多关于全链路跟踪和分析、限流降级、开关和预案系统、强弱依赖等都属于这个范畴，我认为这块应该更准确地定义为分布式服务治理相关的内容。
+- **各类分布式系统**。如分布式锁、分布式文件、分布式数据库，我们熟知的谷歌三大分布式论文，就是这些分布式系统的优秀代表，也正是这三大论文，开启了业界分布式架构理念的落地。
+
+这些系统大都是以稳定性为导向，同时带动了日常运维效率的大幅度提升，有了监控和全链路这样的问题发现和定位手段，也大大提升了我们对故障处理和问题定位的效率。容量管理，不仅仅可以保障容量充足，还能最大程度地保障资源分配的合理性，尽可能减少浪费，对于成本管控也大有好处。所以，围绕着稳定性这个核心目标，不仅达到了稳定的目的，还获得了高效的运维效率。
+
+所以，SRE的理念通过稳定性这个核心点，将整个运维体系要做的事情非常系统紧密地整合起来，而不是一个个孤立的运维系统。所以，**SRE是一个岗位，但更是一种运维理念和方法论**。
+
+## 如何借鉴和落地
+
+在国外，SRE岗位的薪资，和SWE软件开发工程师相比，要平均高出25%。从实际的岗位要求上看，SRE的技能要求也要比SWE更高、更全面，所以这样的人才是比较紧缺的。即使在国外，除了谷歌、Facebook以及Netflix这样超一流的科技公司能够招聘到，或者内部培养出较多这样的人才，其它公司的SRE、PE或者应用运维也无法完全达到上面的要求。
+
+在国内，就更难一些，那怎么做呢？一个思路就是我们之前讲组织协作模式转型时提到的，就是要依靠团队的力量、发挥团队的力量，如果是单个团队不能完成的事情，就跨团队协调完成。所以，SRE岗位的要求很高，但是我们可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。
+
+最后，还是我反复强调的观点，**要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才可以**。
+
+通过今天的内容，你对于SRE有什么新的理解或者疑问？结合前面的内容，你能够挖掘出哪些共通点呢？欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+

极客时间专栏/赵成的运维体系管理课/应用运维体系建设/11 | 从谷歌CRE谈起，运维如何培养服务意识？.md

@@ -0,0 +1,90 @@
+<audio id="audio" title="11 | 从谷歌CRE谈起，运维如何培养服务意识？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4e/ae/4ed5e1e52bde2bf4fe97695781850cae.mp3"></audio>
+
+2016年10月，谷歌云平台博客（Google Cloud Platform Blog）上更新了一篇文章，谷歌宣布了一个新的专业岗位，CRE（Customer Reliability Engineering），直译过来就是客户稳定性工程师。我看了介绍后，发现还是一个挺有意思的岗位设置，搜索之后发现，针对这个岗位国内还没有太多的解读。下面我们就来尝个鲜，一起来看一看。
+
+## CRE产生的背景
+
+这个岗位出现的主要背景，还是越来越多的用户选择在云上开展自己的业务，很多企业和用户将业务从原来传统的自运维IDC机房迁移到云上。这样做其实就是选择相信公有云平台，但同时也就放弃了对底层基础设施的把控，甚至把企业最为核心的数据也放到了云上。说简单点，就是一个公司的身家性命都交给公有云了。
+
+虽然绝大多数的公有云都宣称自己的稳定性多么高多么好，但是我们知道实际情况并非如此。
+
+其实，我们可以看下Netflix，虽然业务在相对稳定的AWS上，但是自从在AWS上遇到过几次严重故障后，就开始自己做稳定性保障的功能，我们熟知的Chaos Monkey这只猴子就是这么来的，进而发展到后来的Chaos Engineering这样一整套体系。
+
+可以看到，Netflix秉承Design For Faliure，从一开始就选择在变化多端且自己不可控的环境里，加强自己系统的健壮性和容错能力，而不是依赖任何云厂商的承诺。
+
+不过，并不是任何企业都具备Netflix这样的技术能力把自己打造得这么稳定。所以，当云上不稳定的情况发生时，公有云客户通常是手足无措的。因为他并不了解出了什么状况，不知道是自己的问题还是云上基础设施或基础服务的问题，也不知道自己应该从哪里入手恢复业务，所以时间长了必然就会感到非常焦虑，各种不放心。
+
+## CRE岗位的职责
+
+**CRE出现的根本目的，就是消除客户焦虑，真正地站在客户的角度去解决问题，同时对客户进行安抚、陪伴和关怀**。
+
+通常的售后支持，都是你问什么问题，我就回答什么问题，能马上解决的就马上解决，不能解决的就转到后端处理，然后让客户等着，承诺多长时间内给出答复。这种流程标准，严格执行SLA规范，对于一般问题还好，但要是真的出现大问题就不行了。
+
+业务挂了，我都火烧眉毛了，你还跟个机器人一样，我问啥你说啥；或者你排查下对我说跟你没关系，让我自己再检查下，再或者转给后端处理，让我先等着，这个体验就非常差了。
+
+所以，CRE这个角色一定是站在客户角度解决问题。加入客户的“作战室”（War Room），和客户一起排查，问题不解决，自己不撤退；还会随时通报进展，必要的时候会将故障升级到更高的级别，寻求更专业的资源投入以共同解决；同时根据客户的不同反应进行不同方式的安抚。
+
+CRE还会发挥谷歌多年积累下来的非常宝贵的线上运维经验，在日常就跟客户沟通传递一些稳定性保障的知识。CRE可以按照谷歌总结出来的类似SRE的标准规范，对客户线上系统进行稳定性标准评审，并给出专业的建议。如果客户同意遵守这样的标准规范执行，在后续出现故障时，CRE就完全可以按照非常成熟的SRE的运作模式去协作用户处理故障，这样就会大大提升CRE和客户的协作效率，为故障快速处理赢得更多宝贵时间。同时CRE也可以发挥更大的专业作用，而不是之前的对客户系统不熟悉，空有一身绝世武功，却使不上劲。
+
+所以，**CRE这个角色，既具备良好的专业技术能力，又有非常强的问题解决能力，同时还要具有优秀的客户沟通和关怀能力**。背后还有谷歌多年的全球最佳运维实践SRE的经验和方法论支持，让CRE这个角色发挥出更加独特的作用，这一点可能是其它公有云厂商难以达到的。
+
+## 从CRE谈谈做运维为什么要有服务心态
+
+上面花了些篇幅对CRE做了一个整体的介绍。我个人的整体感受，CRE更多的是一个服务性质的岗位，最终是要对客户的满意度负责，所以我们可以看到他的职责里面处处充满了紧贴客户需求和痛点的工作内容。
+
+我们可能一下子达不到CRE这么高大上的水平，但是日常工作中我们要不断提升自己的服务意识还是很有必要的。而且我观察下来，有时候我们日常工作中出现的很多沟通问题、协作问题甚至是技术问题，都是因为服务意识不够而导致的。
+
+我总结了一下，**是不是有服务心态，表现在我们的做事方式上，就是我们是否能够站在对方的角度考虑问题、解决问题**。
+
+具体怎么做，可以有很多方式，这里我给出我个人的几个建议。
+
+**1. 多使用业务术语，少使用技术术语**
+
+与合作部门沟通协作，特别是对于非技术类的业务部门，尽量多使用业务语言来表达。在讨论一个需求时，如果表达的都是API、缓存、数据库、消息队列等等这些专业术语，估计业务部门的同学肯定是跟不上我们的思路的，这样的沟通通常无法正常地进行下去，所以就会经常出现业务同学说业务的事情，技术同学说技术的事情，两边不能达成一致，矛盾就产生了。
+
+这里需要强调的一点是，对于绝大多数的公司来说，业务一定是最重要的，技术是实现业务功能的一种手段和方式，所以一定是从业务角度出发考虑技术解决方案，而不是从技术角度出发让业务来适配技术。
+
+那怎么从业务角度出发呢？就是我刚说的尝试用业务语言去沟通，用对方能够听得懂的表达方式去表达你的技术观点。为了让业务人员理解你的想法，就自然会用业务的思路去思考和解决问题了。这个需要一点点改变，可以先从尝试开始。
+
+**2. 学会挖掘问题背后的真正诉求**
+
+外部提出的一个问题，可能并不一定是真正的问题，而是问题的一个解决方案。
+
+先举个之前我遇到的例子，有个部门给我们提了一个在服务器上安装翻墙软件的需求，结果我们的工程师就照着这个需求去做了，最后发现软件怎么调都启动不了，中间还牵扯到网络同事的配合，需要检查网络上的配置，最后就差动网络设备了。
+
+后来我就去问，为什么要安装翻墙软件呢？一问才知道，有个业务需求是需要爬取Twitter、Instagram和Facebook上一些时尚达人的时间线信息的，需要部署一个这样的应用，然后能够对外访问，但是部署在我们机房内部发现不行（肯定不行啊），所以就建议尝试装一个翻墙软件看看是不是能访问出去。
+
+这么一问，就发现安装翻墙软件不是真正的需求，真正的需求是能够访问到海外站点。看问题的角度不同，解决方案也就不一样了。
+
+因为我们有公有云的海外节点，这样的需求，我们直接将应用部署在海外节点就可以了，然后从申请资源、部署上线到调测通过，30分钟搞定。
+
+这种情况非常常见，也是日常团队协作中最容易出现的问题，很多矛盾都是因为这种原因导致的。如果按照上述不假思索的方式去做，极有可能是没有结果，或者是结果无法让人满意。如果你很努力很认真地做了很多事情，但却无法得到对方的认可，那就太令人沮丧了。
+
+遇到类似问题，可以不着急动手做，先多问自己和对方几个问题，比如：
+
+- 为什么要这样做？
+- 谁要求做这件事情的？
+- 这样做的目的是什么？
+- 这样做是为了解决什么问题？
+
+这一点其实也是站在对方角度去考虑，去思考对方要解决的问题是什么，而不是解决我们的问题。通常情况下，两三个问题后，一般就会暴露出背后最原始的那个需求了。正所谓“磨刀不误砍柴工”，问题和背景搞清楚了，思路和方案就是顺其自然的事情了。
+
+**3. 解决问题的时候关注目标，而不是聚焦困难**
+
+我尝试写了一段话想来分享我的观点，但是读来读去感觉有点太鸡汤。所以还是上一张图，这个是我16年去腾讯交流的时候，在腾讯办公区拍到一张照片，对我启发很大。
+
+两种不同的思考问题的方式，带给人的感受也是完全不一样的。
+
+道理还是需要我们自己悟明白的，所以文字也好，图片也罢，期望对你也有所启发。
+
+<img src="https://static001.geekbang.org/resource/image/73/f6/73ab067884b271e6c6f9198cecc1ecf6.jpg" alt="" />
+
+近些年，随着云计算技术的深入发展，公有云事业也不断拓展，运维领域的分工也在不断地精分细化，而每个细分领域对专业技术的要求也越来越高，专业的服务化程度也越来越高。我想这是一个好现象，让原来非常模糊的运维行业范畴变得越来越清晰、越来越具体。
+
+对于我们运维来说，这样的发展既是机遇，也是挑战。一方面我们要不断提升自己的技术能力，另一方面也要注意自身服务意识的培养，让自己的能力得以发挥，创造更大的价值，获得更好的回报。
+
+对于今天的内容你有怎样的共鸣和思考，欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+