first commit

专栏/赵成的运维体系管理课/18持续交付流水线软件构建难吗？有哪些关键问题？.md

@@ -0,0 +1,108 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            18 持续交付流水线软件构建难吗？有哪些关键问题？
+                            上期文章我们介绍了需求分解与应用对应的管理方式，以及提交环节的开发协作模式，今天我们详细介绍一下提交阶段的构建环节，也就是我们经常提到的代码的编译打包。
+
+构建环节
+
+由于静态语言从过程上要比动态语言复杂一些，代码提交后，对于Java和C++这样的静态语言，我们要进行代码编译和打包。而对于PHP和Python这样的动态语言，就不需要编译，直接打包即可。
+
+同时，编译过程就开始要依赖多环境以及多环境下的配置管理，并根据不同的环境获取不同的配置，然后打包到最终的软件发布包中。
+
+下面我就结合自己的实践经验，以Java为例，对构建环节做下介绍。
+
+构建过程中我们要用到以下4种工具：
+
+
+Gitlab，代码管理工具，也是版本管理工具；
+Maven，依赖管理和自动化构建工具，业界同类型的工具还有Gradle等；
+Docker，用来提供一个干净独立的编译环境；
+自动化脚本和平台，自动化构建的任务我们使用Python脚本来实现代码获取、编译执行、软件包生成等。
+
+
+具体整个构建过程图示如下：
+
+
+
+我们以Java为例描述如下。
+
+1.首先准备好JDK的编译镜像，这个镜像环境与线上运行环境保持一致，比如OS版本、内核参数以及JDK版本等基础环境。当需要启动一个构建任务时，就创建一个对应的Docker实例，作为独立的编译环境。
+
+2.构建任务会根据应用配置管理中的Git地址，将代码克隆下来放到指定的编译目录。Docker实例启动后，将编译目录挂载到Docker实例中。
+
+3.执行mvn package命令进行编译打包，最终会生成一个可发布war的软件包。同样的，对于C++、Go、Node.js，也会准备好类似的编译镜像。不同的是，打包时，对于C++中的cmake和make，Go中的go install等等，最终也会生成一个可发布的软件包。
+
+4.构建完成后，生成软件包放到指定构件库目录，或者直接发布到maven的构件库中管理，然后将Docker实例销毁。
+
+上述就是一个完整的构建过程。在这里，你一定会有一些疑问，那么，我先回答几个比较常见的问题，欢迎你留言和我继续讨论。
+
+几个关键问题
+
+1.配置文件如何打包？
+
+这个问题，我们在前面持续交付的多环境配置管理文章中，已经详细介绍过。这里我们结合构建过程，再介绍一下。
+
+在上述第3个步骤中，我们要进行代码编译。按照持续交付理念，软件只需打包一次就可以各处运行，这对于代码编译是没有问题的，但是对于一些跟环境相关的配置就无法满足。
+
+比如，我们前面讲到，不同的环境会涉及到不同的配置，如DB、缓存。而且，其他公共基础服务在不同环境中也会有不同的地址、域名或其他参数配置。
+
+所以，我们就需要建立环境与配置之间的对应关系，并保存在配置管理平台中，至于如何来做，大家可以参考前面多环境配置管理的文章。
+
+这里我们回到打包过程上来。
+
+在做构建时，我们是可以确认这个软件包是要发布到哪个环境的。比如，按照流程，当前处于线下集成测试环境这个流程环节上，这时只要根据集成测试环境对应的配置项，生成配置文件，然后构建进软件包即可。如果是处于预发环境，那就生成预发环境对应的配置文件。
+
+在我们的实际场景中，多个环境需要多次打包，这与我们持续交付中只构建一次的理念相悖。这并不是有意违背，而是对于Java构建出的交付件，最终无论生成的是war包，还是jar包，上述提到的跟环境相关的配置文件，是要在构建时就打入软件包中的。
+
+而且在后续启动和运行阶段，我们是无法修改已经构建进软件包里的文件及其内容的。这样一来，配置文件无法独立发布，那么就必须跟软件包一起发布。所以，在实际场景下，我们要针对不同环境多次打包。
+
+那么，我们如何确保多次打包的效果能够和“只构建一次”理念的效果相一致呢？
+
+这就还是要依赖我们前面介绍的各个环节的建设过程，主要有以下3个方面：
+
+
+代码提交。通过分支提交管理模式，每次构建都以master为基线，确保合入的代码是以线上运行代码为基础的。且前面的发布分支代码未上线之前，后续分支不允许进入线上发布环节，确保发布分支在多环境下是同一套代码。
+编译环境统一。上述过程已经介绍，编译环境通过全新的Docker容器环境来保证。
+配置管理。前面介绍到的多环境配置管理手段， 通过模板和auto-config的配置管理能力，确保多环境配置项和配置值统一管理。
+
+
+至此，一个完整的软件构建过程就完成了。可以看到，如果充分完善前期的准备工作，在做后期的方案时就会顺畅很多。
+
+2.为什么用Docker做编译环境的工具？
+
+Docker容器很大的一个优势在于其创建和销毁的效率非常高，而且每次新拉起的实例都是全新的，消除了环境共用带来的交叉影响。而且对于并发打包的情况，Docker可以快速创建出多个并行的实例来提供编译环境，所以无论在效率上还是环境隔离上，都有非常好的支持。
+
+你可以尝试一下我的这个建议，确实会非常方便。
+
+3.为什么不直接生成Docker镜像做发布？
+
+在使用Docker容器做编译的过程中，我们最终取得的交付件模式是一个war包，或者是一个jar包，这个也是我们后续发布的对象。
+
+可能有读者会问：为什么不直接生成Docker镜像，后续直接发布镜像？
+
+这确实是一个好问题。如果单纯从发布的维度来看，直接发布镜像会更方便，更高效。不过，在现实场景下，我们应该更全面地看问题。
+
+早期我们曾有一段时间使用OpenStack+Docker的模式进行物理机的虚拟化，以提升资源利用率。这实际上是将容器虚拟机化。
+
+也就是说，虽然Docker是一个容器，但是我们的使用方式仍然是虚拟机模式，要给它配置IP地址，要增加很多常用命令比如top、sar等等，定位问题需要ssh到容器内。
+
+这里一方面是因为基于Docker的运维工具和手段没有跟上，当时也缺少Kubernetes这样优秀的编排工具；另一方面，我们之前所有的运维体系都是基于IP模式建设的，比如监控、发布、稳定性以及服务发现等等，完全容器化的模式是没有办法一步到位的。
+
+所以，这里我们走了个小弯路：容器虚拟机化。那为什么我们不直接使用虚拟机，还能帮我们省去很多为了完善容器功能而做的开发工作？所以一段时间之后，我们还是回归到了KVM虚拟机使用方式上来。
+
+这样也就有了上述我们基于虚拟机，或者更准确地说，是基于IP管理模式下的持续交付体系。
+
+经过这样一个完整的持续交付体系过程后，我们总结出一个规律：
+
+容器也好，虚拟机也罢，这些都是工具，只不过最终交付模式不一样。但是前面我们所讲的不管是标准化、多环境、配置管理等等这些基础工作，无论用不用容器都要去做。而且，容器的高效使用，一定是建立在更加完善和高度标准化的体系之上，否则工具只会是越用越乱。
+
+关于持续交付流水线软件构建方面的内容，我们今天先分享到这里，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/19持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            19 持续交付中流水线构建完成后就大功告成了吗？别忘了质量保障
+                            上期文章我结合自己的实践经验，介绍了持续交付中流水线模式的软件构建，以及在构建过程中的3个关键问题。我们可以看出，流水线的软件构建过程相对精简、独立，只做编译和打包两个动作。
+
+但需要明确的是，在持续交付过程中，我们还要做很多与质量保障相关的工作，比如我们前面提到的各类功能测试和非功能测试。
+
+所以，今天我们聊一聊在流水线构建过程中或构建完成之后，在质量保障和稳定性保障方面，我们还需要做哪些事情。
+
+首先，我们回顾一下之前总结的这张流程图：
+
+
+
+可以看出，在流水线构建过程中，我们尤其要重视以下3个方面的工作内容。
+
+依赖规则限制
+
+主要是对代码依赖的二方包和三方包做一些规则限制。比如，严格限定不允许依赖Snapshot版本；不允许引入有严重漏洞的版本，如Struts2的部分版本；检测JAR包冲突，如我们常用的Netty、Spring相关的包；限定某些软件包的最低版本发布，如内部提供的二方包，以确保版本收敛，降低维护成本。
+
+过滤规则上，通过Maven构建软件包过程中生成的dependency:list文件，将GroupID和ArtifactID作为关键字，与我们设定的版本限制规则进行匹配。
+
+两个示例如下（真实版本信息做了修改）：
+
+检测JAR包冲突：
+
+
+[WARNING] 检测到jar包冲突: io.netty:netty-all, 版本: 4.0.88.Final, 当前使用:
+4.0.22.Final
+
+
+限定最低版本：
+
+
+[WARNING] 检测到 mysql:mysql-connector-java, 版本 5.0.22, 版本不符合要求, 需要大于等于
+5.0.88。旧版存在已知兼容性bug，导致连不上数据库, 请在2018-01-15 00:00:00前升级完成, 否则将被禁止发布，如有疑问，请联系@发布助手
+
+
+JAR包依赖以及维护升级，通常是一件令我们比较头疼的事情，特别是在运行时出现的冲突异常，更是灾难性的。为了从技术角度更好地进行管理，我们需要做好隔离，这一点可以利用JVM类加载机制来实现。
+
+如果你有兴趣，可以在网上参考阿里的潘多拉（Pandora）容器设计资料，这里我们就不作详细介绍了。
+
+功能测试
+
+包括单元测试、接口测试、联调测试和集成测试。这里的每个测试环节起到的作用不同，联调测试和集成测试依赖的主要手段还是手工验证，所以这里我们分享下可以通过自动化手段完成的单元测试和接口测试。
+
+这里主要用到的几个工具：
+
+
+JUnit 和TestNG，分别做单元测试和接口测试；
+Maven插件，maven-surefire-plugin，用来执行JUnit或TestNG用例；
+JaCoCo，分析单元测试和接口测试后的代码覆盖率；
+Jenkins，自动化测试任务执行，报表生成和输出，与Maven、JUnit、GitLab这些工具结合非常好。
+
+
+关于上述这几种工具，我在此就不展开详细介绍了，你可以自行上网查询和学习。
+
+下面，我们分析一下功能测试中的两个重要环节：单元测试和接口测试。
+
+
+单元测试，由开发完成测试用例的开发，对于需要连接DB的用例，可以用DBUnit这样的框架。用例的自动执行，每次代码开发完成，开发执行mvn test在本地进行自测通过，然后提交到GitLab。可以在GitLab中设置hook钩子，和回调地址，提交的时候在commitMsg增加钩子标识，如unitTest，这样提交后就触发回调自动化单元测试用例执行接口，确保提交后的代码是单元测试通过的，最终可以通过JaCoCo工具输出成功率和代码覆盖率情况。
+接口测试，用例编写上使用TestNG，这个测试框架相比JUnit功能更全面，也更灵活一些。但是过程上与单元测试类似，当然也可以不通过hook方式出发，可以通过手工触发进行测试。
+
+
+上述自动化测试环节结束，软件包就可以发布到我们之前说的项目测试环境或集成测试环境进行功能联调和测试了，这时就需要部分人工的介入。
+
+非功能测试
+
+在功能验证的同时，还需要并行进行一些非功能性验证，包括安全审计、性能测试和容量评估 。分别介绍如下：
+
+
+安全审计，由安全团队提供的源代码扫描工具，在构建的同时，对源代码进行安全扫描，支持Java和PHP语言。可以对源代码中的跨站脚本、伪造请求、SQL注入、用户名密码等敏感信息泄露、木马以及各类远程执行等常见漏洞进行识别，对于高危漏洞，一旦发现，是不允许构建出的软件包发布的。而且实际情况是，不审不知道，一审吓一跳，我们前面几次做代码扫描时，各种漏洞触目惊心，但是随着工具的支持和逐步改进，基本已经将这些常见漏洞消灭在萌芽状态。
+
+
+下面是扫描结果的简单示例（目前扫描工具已经开源，请见文末链接）：
+
+
+
+
+性能和容量压测，主要针对核心应用，进行发布前后的性能和容量比对，如果出现性能或容量差异较大，就会终止发布。关于这一点，我在后面稳定性保障的文章中会详细介绍到。这个验证工作，会在预发或Beta环境下进行验证，因为这两个环境是最接近线上真实环境的。
+
+
+下图是一张发布前后的效果比对示意图，正常情况下，性能曲线应该是基本重叠才对，不应该出现较大的偏差。
+
+
+
+最后
+
+到这里，我们稍作一个总结。
+
+关于持续交付中的流水线模式，我们在前面两期文章以及本期的分享中，相对完整地介绍了从需求分解开始，到代码提交、软件构建，再到功能和非功能测试验证的整个过程。这个过程就是我们常说的持续集成。
+
+之所以我没有在一开始引入这个概念，是因为，如果我们将注意力集中到这一过程中具体的动作和问题上，会更有利于我们理解，而不是一开始就被概念性的术语和框架束缚住。
+
+流水线模式功能测试和非功能测试的整个过程可以总结如下：
+
+
+
+同时，我们在上面持续集成的过程中，要基于前面介绍的各类环境和基础配置管理，比如功能验证就需要在线下环境中的开发环境、项目环境以及集成测试环境上进行验收。
+
+而非功能验证的性能和容量评估，就需要在线上环境里的预发或Beta环境中完成。这里就已经涉及到了软件的部署发布。
+
+下一期文章，我将分享线上发布的整个过程，并对整个持续交付体系内容做一个收尾。欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+附：源代码安全审计工具
+https://github.com/wufeifei/cobra
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/20做持续交付概念重要还是场景重要？看笨办法如何找到最佳方案.md

@@ -0,0 +1,112 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            20 做持续交付概念重要还是场景重要？看笨办法如何找到最佳方案
+                            上期文章中我们讲到，在经过严格的依赖规则校验和安全审计之后，构建出的软件包才可以部署发布。
+
+在开发环境、项目环境、集成测试环境以及预发环境下，我们还要进行各类的功能和非功能性测试，最后才能发布到正式的生产环境之上。
+
+通常状况下，做一次软件版本发布，必须经过以下几个环境（如下图所示）。需要明确的是，项目环境和“小蘑菇”（内部叫法）环境，只有特殊版本才会配备，这里我们不做强制。
+
+
+
+上述这些环境我们在之前都介绍过。而历经如此多的环境，高效的自动化持续部署和发布就变得尤为重要。
+
+特别是最后的线上发布环节，还需要确保业务连续稳定、无间断，所以，在复杂的微服务架构环境下，我们对软件的发布策略选择、自动化程度和稳定性要求就更高了。
+
+今天，我们一起看看整个流水线软件部署和发布的细节。
+
+软件的持续部署发布
+
+这里，我们直接以生产环境的发布过程来讲解。软件的部署发布，简单来说就是：
+
+将构建完成和验证通过的应用软件包，发布到该应用对应环境下的IP主机上的指定目录下，并通过应用优雅上下线，来实现软件最新版本对外提供服务的过程。
+
+这个过程会包含的环节，我以图示整理如下：
+
+
+
+我们可以看到，软件部署发布，听上去就是把软件部署一下，然后启动起来。这样的操作方式对于单体架构软件没有问题，但是在微服务架构下就满足不了要求了。
+
+单体架构软件启动起来就可以提供服务，但是对于微服务应用，无论停止还是启动，都需要考虑到对周边其它依赖和被依赖应用的影响才可以，考虑的点也就相对较多。
+
+我们针对单机发布，分环节来看一下：
+
+
+从CMDB中，拿到线上生产环境下的应用主机IP列表去对应关系，目的是要将软件包发布到应用对应的IP主机上。
+
+检查每台机器上的服务是否正常运行，如果是正常服务的，说明可以发布，但是服务本身异常，就要记录或跳过。
+
+下载war包到指定目录。这里要依赖前期我们介绍的应用配置管理，在这一步要获取到该应用的源代码目录。
+
+关闭该应用在这台主机上的监控，以免服务下线和应用终止产生线上错误告警。
+
+优雅下线。RPC服务从软负载下线，如果该应用还提供了http的Web调用，就需要从Nginx这样的七层负载下线，下线动作均通过API接口调用方式实现。
+
+下线后经过短暂静默，重启应用。对于Java应用来说，重启时可以自动解压，启停命令等还是之前从应用配置管理中获取响应路径和命令脚本名称。
+
+优雅上线，进行健康监测，检查进程和应用状态是否正常，如果全部监测通过，则开始上线服务，开启监控。
+
+
+上述是一个应用的单机发布过程，过程比较长，但是可以看出，每个环节并不复杂。这里我们需要注意两个关键点：
+
+
+针对场景，进行细分，这样就可以化整为零，把一个乍看上去很复杂的过程，分解成一个个可执行的步骤。
+与服务化的软负载和注册中心进行交互，确保应用是可以优雅上下线的，而不是简单粗暴地启动和停止。
+
+
+发布策略
+
+上述过程是针对单机的操作步骤。但是，如果我们有上百台主机，甚至一些大的集群有上千台主机，这时应该怎么发布呢？这里就涉及到发布策略问题。
+
+业界常见的几种模式，如蓝绿发布、灰度发布（金丝雀发布）、滚动发布等等，这几种模式网上资料丰富，在这里我们就不逐一展开详细介绍了。
+
+这里，我们主要以灰度发布和滚动发布的组合方式为例，详细分析一下这种发布模式。
+
+前面介绍的线上Beta环境，选择的就是金丝雀发布模式，我们内部称之为灰度发布或Beta发布。后来国外Netflix持续交付经验传播比较广，所以我们经常可以听到金丝雀发布这种方式，而其本质上还是灰度发布模式。
+
+Beta环境下，我们会保留1-2台应用主机，引入较少的线上真实用户流量。发布到这个环境上时，对于核心应用和大规模的集群，我们会静默较长时间，以观察应用的新版本运行状态。
+
+如果没有严重的报错或崩溃，静默期过后，我们认为软件质量和稳定性是没有问题的，接下来就会发布到正式的生产环境上。
+
+因为生产环境上大的集群可能会有上百台甚至上千台主机，如果每台主机逐一单独发布，这样会导致发布效率过低；但是一次性发布数量太多，又会对线上应用容量大幅度缩减，极有可能会导致服务雪崩或业务中断。
+
+所以我们选择的方式就是滚动发布，或者可以理解为分批次发布：即每批次发布10台或20台，升级完成后，再启动下一批次发布。这样每次发布的机器数量可以自行设定，但是必须低于50%。
+
+至此，一个应用的滚动发布流程就结束了。根据我们实践的具体情况，这种灰度加滚动的发布模式，相对平稳和可控。相比于蓝绿发布，不需要额外再独立一个环境出来，且不需要每次发布都要做一次整体的流量切换，避免产生较大的操作风险。
+
+对于回滚，我们会根据上个版本的war包名称记录，在发布过程中或发布后出现严重情况时，直接快速回滚。因为这个操作是在紧急和极端的情况下才执行，所以提供一键操作，过程跟上述的发布过程相似，在此也不再赘述。
+
+持续交付体系的收益
+
+持续交付体系运作起来后，整个流水线过程完全自助发布，运维无需介入，达到了DevOps，或者说是NoOps的效果。如下图所示：
+
+
+
+总结
+
+至此，我们整个持续交付体系的内容就全部介绍完了。对于整个过程的总结，你可以参考本专栏“持续交付”主题的第一篇文章[《持续交付知易行难，想做成这事你要理解这几个关键点》]，我在文中对整个持续交付体系进行了比较完整的梳理。
+
+细心的你应该可以发现，到本期文章为止，我并没有提到太多DevOps相关的内容，而这个恰恰是当前业界非常火热的概念。在写作过程中，我也没有特别强调持续交付是什么，持续集成是什么，而这些又是当前DevOps里面特别强调的部分。
+
+我之所以这样做是因为，概念都是一个个名词或者Buzzword（时髦名词），它们所表达的意思也都非常泛，每个人，每个团队或每个组织对它们的理解以及解读都是不一样的。
+
+就拿DevOps举例，有谁能说清楚它到底是什么，到底代表什么意思？估计一千个人会有一千种理解，不同的团队对它的实践模式也不一样。
+
+所以，如果直接从概念出发，反而容易让我们迷失方向，忘记想要解决的问题，让我们脱离所处的实际场景，把精力都放在了各种所谓的工具和技术上。这一点也恰恰与我所一直强调的，要从实际问题和业务场景出发来考虑解决方案相违背。
+
+在我们“持续交付”主题的分享中，你可以看到，有很多的解决方案并没有标准化的模式，也没有哪一个工具或技术能够直接解决这些问题。
+
+我们所采取的手段，其实都是些笨办法：即找到问题，分析问题，调研解决方案，讨论碰撞，然后慢慢摸索和实践，找出最合适我们的方式。
+
+希望我的分享能够给你带来启发，就像我们开篇词提到的：思路上的转变远比技术上的提升更为重要。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/21极端业务场景下，我们应该如何做好稳定性保障？.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            21 极端业务场景下，我们应该如何做好稳定性保障？
+                            从今天开始，和你分享我对微服务和分布式架构下的稳定性保障的理解。
+
+稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏，以及杨波老师的“微服务架构核心20讲”专栏都有非常详细的介绍。所以在我的专栏里，我会结合特定的场景，并着重从运维和技术运营的角度来分享。
+
+我们所面对的极端业务场景
+
+首先，看一下我们当前所面对的极端业务场景，我把它大致分为两类。
+
+1.可预测性场景
+
+什么是可预测性？简单来说，就像电商每年的大促，如618、双11、双12等等。这类业务场景是可预测的，业务峰值和系统压力峰值会出现在某几个固定的时间点，我们所做的所有准备工作和稳定性应对措施，都是针对这些固定时间点的，比如零点时刻。
+
+峰值压力可预测，就意味着可以提前评估用户访问模型，并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容，调整完成之后，继续压测，继续调整，直至系统容量达到原来设定的目标。由此可见，在可预测的场景下，与后面的不可预测场景相对比，从准备过程上来说会更加从容。
+
+但是，我们的优化或扩容是有限度的，也就是不会无限度地投入成本，来满足零点这个峰值时刻，让所有用户都能够正常访问。从成本和收益角度来说，这样做是不现实的。
+
+所以，在峰值那个时间点上，当用户流量远远大于系统容量时，我们所采取的措施绝不是再去扩容或优化，因为无论是从时效性、系统稳定性还是成本收益上看，这样做都已经无法满足要求了。
+
+那我们该采取什么策略呢？这里我们采取的策略是在系统承诺容量内，保证系统的核心功能能够正常运行。以电商为例，就是要确保整个交易链路是正常的，用户可以正常登陆，访问商品，下单并最终支付。对于非核心功能，就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流，并确保在某些异常状况下能够熔断或旁路，比如缓存故障，就要马上限流并将请求降级到数据库上。
+
+所以，我们在618，双11和双12的零点峰值时刻去访问各大电商网站，很大概率上都会提示系统正忙，请稍后再试，短则2~3分钟，长则5~10分钟，再去访问，网站功能就一切正常了。这并不代表各大电商网站宕机了，而是其在瞬时超大流量访问压力下采取的一种保护措施，这一点反而说明这些电商网站的大促预案非常完善。
+
+2.不可预测性场景
+
+我刚刚提到的电商大促场景，其实已经非常复杂了，没有一定的整体技术能力，想做好从容应对也并非易事。我们这两年做大促模拟压测，动辄上百号人通宵投入，说到底还是在这方面的经验以及各类工具平台的积累不够，体系的完善需要一定的周期和过程。
+
+那不可预测的场景就更为复杂。社交类业务就具有这种明显的特征，比如微博、朋友圈、空间等等。以微博为例，我们知道之前鹿晗公布恋情，王宝强以及乔任梁等的突发事件等等，这些事情什么时候发生，对于平台来说事先可能完全不知道，而且极有可能是大V的即兴发挥。当然，现在因为商业合作上的原因，某些大V的部分营销活动也会与各类社交业务平台提前沟通，确保活动正常执行，但是即使是提前沟通，周期也会非常短。
+
+对于不可预测性的场景，因为不知道什么时候会出现突发热点事件，所以就无法像电商大促一样提前做好准备。社交类业务没法提前准备，就只能随时准备着，我认为这个挑战还是非常大的。
+
+我们要迎接的技术挑战
+
+说完了场景，我们来看看这给技术带来了哪些挑战。
+
+1.运维自动化
+
+这个不难理解，应对极端场景下的系统压力，一定要有资源支持，但是如何才能将这些资源快速扩容上去，以提供业务服务，这一点是需要深入思考的。结合前面我们讲过的内容，标准化覆盖面是否足够广泛，应用体系是否完善，持续交付流水线是否高效，云上资源获得是否足够迅速，这些都是运维自动化的基础。特别是对于不可预测的场景，考验的就是自动化的程度。
+
+2.容量评估和压测
+
+我们要时刻对系统容量水位做到心中有数，特别是核心链路，比如电商的交易支付链路。我们只有对系统容量十分清楚，才能针对特定场景判断出哪些应用和部件需要扩容，扩容多少，扩容顺序如何。同时，系统容量的获取，需要有比较完善的自动化压测系统，针对单接口、单应用、单链路以及全链路进行日常和极端场景下的模拟压测。
+
+3.限流降级
+
+我们前面提到了电商大促的例子，业务在峰值时刻，系统是无论如何也抵御不住全部流量的。这个时候，我们要做的就是保证在承诺容量范围内，系统可用；对于超出容量的请求进行限流，请用户耐心等待一下。如何判断是否需要限流呢？这时我们要看系统的各项指标，常见的指标有CPU、Load、QPS、连接数等等。
+
+同时，对于非核心的功能，在峰值时刻进行降级，以降低系统压力。这里有两种方式，分别是主动降级和被动降级。主动降级就是在峰值时刻，主动把功能关掉，如商品评论和推荐功能等等；我们前面介绍到的静态化，也是一种降级策略。对于被动降级，也就是我们常听到的熔断。某个应用或部件故障，我们要有手段将故障隔离，同时又能够保证业务可用，所以会涉及故障判断和各类流量调度策略。
+
+4.开关预案
+
+上面介绍到的限流降级，也是一类开关，属于业务功能开关；还有一类是系统功能开关，比如当缓存故障时，我们就需要将请求转发到数据库上，目的也只有一个，让系统可用。但是问题来了，数据库的访问效率没有缓存高，所以缓存可以支撑的流量，数据库肯定是支撑不了的，怎么办呢？这时，就要与限流策略结合起来，先限流，限到数据库能够支撑的容量，再做降级。这样几个策略组合在一起，就是应急预案的执行了。当然，预案里面还会有业务预案。
+
+5.故障模拟
+
+上述预案，需要在日常，甚至是从经历过的故障中提炼出场景，制定好策略，然后不断进行模拟演练。只有这样，等到真正出现问题时，我们的预案才可以高效执行。我们知道Netflix的Chaos Engineering，其中的Chaos Monkey，就是专门搞线上破坏，模拟各种故障场景，以此来看各种预案执行是否到位，是否还有可以改进的地方。
+
+所以，类似Chaos Engineering的故障模拟系统，也需要建设起来。我们需要模拟出一些场景，比如最常见的CPU异常，RT响应异常，QPS异常等等，看我们的预案是否能够快速执行，能够保持系统或将系统快速恢复到正常状态。
+
+6.监控体系
+
+最后，我再提一下监控。通过我们前面介绍的内容，监控的重要性就不言而喻了，因为所有的指标采集和统计，异常判断，都需要监控体系的支持。监控体系和前面介绍的运维自动化一样，都是最为基础的支撑平台。
+
+极端业务场景下的不确定因素
+
+上面我们讨论了极端业务场景给技术层面带来的挑战。但是对于稳定性保障而言，我认为最困难的部分，不在技术层面，而是在业务层面，也就是用户的业务访问模型。从技术层面来说，我们还有一些确定的套路可以去遵循，但是访问模型就是个极不确定的因素了。
+
+我们这里还是以电商来举例说明，比如大促时用户下单这个逻辑。一个用户在购物车勾选商品去结算这个场景，用户的访问模型或业务场景就可能会有很多变化，比如是下1个商品的订单，还是同时5个商品的订单？每个商品的购买数量是1个、2个还是3个？商品的购买数量有没有限制？这些商品涉及1个卖家，还是多个卖家？不同卖家又会有不同的优惠折扣，是买二送一，还是满100送20？满一定额度之后是否包邮？全站促销是否有全站优惠，是否有时间段限制？优惠之间是否有优先级和互斥逻辑？支付方式是优先使用支付宝，还是微信，亦或是银行卡等等。
+
+上面这些还只是简单描述，并且是针对单个用户的。当用户数量达到几十万，上百万之后，用户行为可能还有访问首页、详情页以及搜索的情况等等，场景更复杂，整个业务模型中的变量因素就会非常多，且不确定。
+
+往往某个因素的变化，就可能带来容量模型的改变。假设1个商品，1个卖家，1个优惠策略，对DB产生的QPS是20，TPS是10，但是这其中的因素稍微一变化，产生的QPS和TPS就是翻倍的。如果这一点评估不到位，大促时实际的用户场景跟预估的偏差过大，系统可能就会挂掉。
+
+所以，对于稳定性而言，用户访问模型才是关键，这个摸不准，只有技术是没用的，这就更需要我们能够深入业务，理解业务。
+
+我们经常听到的“脱离业务谈架构，谈技术，都是不负责任的”，原因就在于此。希望今天的内容能够让你在学习到知识和技能的同时，也有所启发，切忌脱离业务，空谈技术。
+
+今天我们分享了极端业务场景下，如何做好稳定性保障。关于稳定性保障，你还有哪些问题？有过怎样的经验？欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/22稳定性实践：容量规划之业务场景分析.md

@@ -0,0 +1,63 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            22 稳定性实践：容量规划之业务场景分析
+                            上期文章我们从整体上介绍了极端业务场景下，如何做好稳定性保障工作。今天，我们结合电商大促这个场景，来看一下容量规划这项工作。
+
+稳定性保障的一个难点是我们要面对一个非常复杂的因素，那就是业务模型，或者叫用户访问模型。因为它的不确定性，会衍生出很多不同的业务场景，而不同的场景，就会导致我们的应对策略有所不同。
+
+所以，容量规划，就是对复杂业务场景的分析，通过一定的技术手段（如压力测试），来达到对资源合理扩容、有效规划的过程。
+
+容量规划的场景分析
+
+我们一直在讲，不能脱离业务场景空谈技术，所以我们还是先从电商大促这个业务场景入手来分析。
+
+对于电商来说，核心链路就是交易链路。简单来说，就是用户要能登录，然后能通过浏览商品详情页下单订购，或者加购物车，通过购物车进行订购结算，这个过程中还要进行各种优惠的批价处理，库存的判断等等，形成订购之后，最终还要能够支付成功，一个完整的交易支付流程才算走完。
+
+在大促的峰值时刻，场景可能又有不同，因为绝大部分用户选购什么商品，早已加入到了购物车中，且各种优惠券也已经申领成功，就等着最后这个时间点直接下单完成订购。所以，在大促这个场景下，交易下单这个环节是核心中的核心。
+
+因为这个时间点的交易流量实在是太高了，所以近两年电商也改变了一些玩法，其目的就是希望减少峰值流量，让流量在整个大促阶段更加均匀。具体的运营和玩法细节这里就不详细介绍了。
+
+那么，我们要应对的场景就相对清晰了，就是在大促零点峰值时刻，评估好交易流量，再进一步转化一下，就是每秒的交易订单峰值。
+
+下图就是我们进行评估的路径分析示例，用户首先从首页、大促会场或者微信里的分享页面转化过来，然后通过搜索、店铺、详情页以及购物车进行最后的转化，形成订购下单和最终的支付。
+
+
+
+具体数值的评估上，我们会跟产品运营团队共同讨论，整体的业务目标由运营团队给出，比如GMV目标收入，UV、PV、转化率、客单价以及商品单价，这些都是业务目标。通过这些业务数据，我们根据上图的路径逐步分解，就会逐步得出每一层的流量数据。
+
+假设大促会场会有500万UV，根据GMV和客单价，如果要完成目标，推导出到详情页的转化率需要达到60%（产品运营需要努力达成这个业务目标），那详情页的UV就是300万；根据用户访问行为分析，对详情页的各个应用产生的QPS再做一个评估，这样单个应用的容量值就有了，然后再进一步向下转化，能够形成订购，形成加购物车的又有多少，再进行评估，最后就可以得出一个交易下单的峰值以及支付的峰值。
+
+计算出峰值后，还要与历年评估的峰值数据，以及实际的峰值数据进行对比，根据对比情况进行调整。评估出来的这个峰值，就是系统要承诺支撑的容量，因为只有达到这个容量值，才能支撑业务完成对应的业务目标。
+
+总结来说，这就是一个根据业务GMV、UV等目标，对技术上的交易下单峰值这个核心指标进行推导的过程。
+
+那么，接下来就根据评估的各个应用和基础服务需要承担的流量，先扩容一轮，同时开始构造数据模型和压测模型来模拟真实流量，以此验证我们的系统是否能够达标，过程中再进行局部的扩容和优化。
+
+一般来说，先进行单链路压测，比如购物车订购，详情页订购等场景的压测，达标后再进行多链路压测，最后再进行全链路压测，直至达成目标。为了能够保有一定的容量缓冲，最后几轮压测，我们会将压测流量调整到目标值的120%或150%，来保证系统能够应对足够极端的场景，这样才能够游刃有余地实现100%的目标。
+
+构造压测的数据模型
+
+如何构造压测的数据模型呢？这是一个比较复杂的问题，因为我们靠拍脑袋或者靠猜，是无法准确评估的。通常情况下，我们从以下两方面入手。
+
+一方面，数据模型要接近真实场景。这就需要我们不断地积累经验，记录早期大促的详细数据和真实场景（比如不同用户购物车里的商品数量、优惠策略、不同渠道比例等，以及各种运营活动的玩法），这样可以最大程度地模拟真实的用户访问模型。这个过程，蘑菇街更多的还是手工推导，像阿里做得比较极致，可以通过BI系统，将往年模型和当年模型进行分析比对，直接生成对应的数据模型，甚至是多套模型。
+
+另一方面，数据量要接近真实场景。数据量有很多维度，比如用户数量、商品数量、店铺数量、优惠券数量等等。这里一般会通过数据工厂这样的工具平台，结合运营团队给出的数据量评估，快速制造出对应量级的数据。另一种方式就是从线上将真实数据，进行敏感信息脱敏处理后，导出到另一张影子表中，专门提供给压测使用，这样做的好处是不会污染线上运行数据。
+
+总结
+
+通过上面的分享，我们应该不难发现，容量规划工作，单纯靠技术能力是无法解决的，需要经验和数据的积累，到了阿里这个体量就必须借助人工智能和各类分析算法这样更高级的手段才能解决。
+
+同时，容量问题，也不是简简单单通过资源扩容这种成本投入就可以解决的，扩容是最后的执行手段，但是怎么合理的、科学的扩容，就需要有合理的规划。当业务体量和复杂度到达一定程度时，就要依靠技术人员对业务的深入理解。能够合理规划业务、技术和数据模型，是需要一些经验积累，以及在各类极端场景下的经历。
+
+最后，如此复杂的技术体系，也只有在同样复杂的场景下才会被催生出来，才会有存在意义。所以，我们在学习借鉴时，还是要从各自的实际场景出发，慢慢积累，大可不必强求短期速成。
+
+你自己是否有过容量规划的经历？遇到过哪些问题？欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/23稳定性实践：容量规划之压测系统建设.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            23 稳定性实践：容量规划之压测系统建设
+                            容量规划离不开对业务场景的分析，分析出场景后，就要对这些场景进行模拟，也就是容量的压力测试，用来真实地验证系统容量和性能是否可以满足极端业务场景下的要求。同时，在这个过程中还要对容量不断进行扩缩容调整，以及系统的性能优化。
+
+今天，我们就来看压力测试的技术实现方式：压力测试系统的建设。我们详细讲讲压力测试的几个维度。
+
+第一个维度，压测粒度
+
+压测粒度上，我们一般会遵照从小到大的规律来做。
+
+1.单机单应用压力测试
+
+优先摸清单个应用的访问模型是怎样的，再根据模型进行单机单应用压力测试。这时我们就可以拿到单个应用和单个应用集群的容量水位，这个值就是后续我们根据业务模型分析之后扩容的基础。
+
+2.单链路压力测试
+
+获取到单个应用集群的容量水位之后，就要开始对某些核心链路进行单独的压力测试，比如商品详情浏览链路、加购物车链路、订购下单链路等等。如下图的交易下单链路压测模型示例，连线上的数字是不同应用或接口调用的流量占比。
+
+
+
+3.多链路/全链路压力测试
+
+当单链路的压测都达标之后，我们就会组织多链路，或者全链路压测。多链路本质上就是多个单链路的组合，全链路就是多链路的组合。如下图就是多个交易场景的多链路组合。
+
+
+
+第二个维度，压测接口及流量构造方式
+
+接口一般分为HTTP接口和RPC接口，这一点应该不难理解，就不做过多讲解了。
+
+流量构造方式上，根据压测粒度的不同，会采用不同的方式，我们常见的有以下几种方案。
+
+1.线上流量回放
+
+这种方式直接利用了线上流量模型，比较接近真实业务场景，常见的技术手段如TCPCopy，或者Tcpdump抓包保存线上请求流量。但是这种方式也存在一些代价，比如需要镜像请求流量，当线上流量非常大的时候就很难全部镜像下来，而且还需要大量额外的机器来保存流量镜像。到了回放阶段，还需要一些自动化的工具来支持，还要解决各种session问题，真正实施的时候，还是会有不少的工作量。
+
+2.线上流量引流
+
+既然线上回放比较麻烦，那为什么不直接使用线上流量进行压测呢？这个思路确实是可行的，我们前面讲过，压测的主要是HTTP和RPC两种类型的接口，为了保证单个应用的流量压力足够大，这里可以采取两种模式。
+
+一个是将应用集群中的流量逐步引流到一台主机上，直到达到其容量阈值；另一个方案是，可以通过修改负载均衡中某台主机的权重，将更多的流量直接打到某台主机上，直到达到其容量阈值。
+
+这个过程中，我们可以设定单台主机的CPU、Load或者QPS、RT等阈值指标，当指标超出正常阈值后就自动终止压测，这样就可以获取到初步的容量值。
+
+这种方式的好处是，不需要额外的流量模拟，直接使用最真实的线上流量，操作方便，且更加真实。下图是两种引流的方案示例。
+
+
+
+3.流量模拟
+
+上述两种流量模拟方式，更适合日常单机单应用的容量压测和规划，但是对于大促这种极端业务场景，真实流量就很难模拟了，因为这种场景只有特定时刻才会有，我们在日常是无法通过线上流量构造出来的。
+
+所以这里就需要利用数据工厂，最终通过流量平台来形成压测流量。这里的工具用到了Gatling，是一款开源的压测工具，用Scala开发的，后来我们针对自己的需求，比如自动生成压测脚本等，做了一些二次开发。
+
+
+
+如果会有多种流量模型的话，就要生成多个流量模型，具体可见下图：
+
+
+
+第三个维度，施压方式
+
+上面介绍了容量压测的构造过程，那接下来我们要做的就是对真实的线上系统施加压力流量了。很自然的，这里就需要有施加压力的机器，在上面“全链路压测系统”那张图中，你可以看到，我们的施压方式是通过上百台的机器根据压测脚本和压测数据对系统施压的，我来简单介绍一下大致过程。
+
+
+通过实现在Web控制台配置好的压测场景，自动生成压测脚本。
+利用数据工厂构造出压测数据，这个就是业务场景的模拟，像阿里做得比较完善，就可以借助AI和BI的技术手段生成很多压测模型，且基本都接近于现实情况下的业务场景。
+通过Web控制台，根据压测脚本和压测数据，生成压测任务，推送到压测集群的Master节点，再通过Master节点推动到上百台的Slave节点，然后就开始向线上系统施加模拟的流量压力了。
+
+
+关于施压机的分布，大部分仍然是跟线上系统在同机房内，少量会在公有云节点上。但是对于阿里，因为其自身的CDN节点遍布全球，所以他就可以将全球（主要是国内）的CDN节点作为施压机，更加真实地模拟真实用户从全球节点进入的真实访问流量。这种方式对于蘑菇街就显得成本过高，技术条件和细节也还达不到这个程度。
+
+当前阿里已经将这种压测能力输出到了阿里云之上，可以说是对其云生态能力的有力补充，同时也为中小企业在容量规划和性能压测方面提供了很好的支持。
+
+第四个维度，数据读写
+
+压测过程中，对于读的流量更好构造，因为读请求本身不会对线上数据造成任何变更，但是对于写流量就完全不一样了，如果处理不好，会对线上数据造成污染，对商家和用户造成资损。
+
+所以，对于写流量就要特殊处理，这块也有比较通用的解决方案，就是对压测的写请求做专门的标记。当请求要写数据库时，由分布式数据库的中间件框架中的逻辑来判断这个请求是否是压测请求，如果是压测写请求则路由到对应的影子库中，而不是直接写到线上正式的库中。
+
+在这之前，要提前创建好对应的影子库。假设建立影子库的原则是原schema + mirro，如果正式库是order，则影子库为order_mirror，这时两个库中的数据量必须是一致的。对于非敏感信息，数据内容也可以保持一致，这样可以在最大程度上保证数据模型一致。
+
+这里再呼应一下我们最开始提到的基础服务标准化工作，如果这个工作在前面做得扎实，它的优势在这里就体现出来了。我们刚刚提到的影子库的路由策略是基于中间件框架来实现的，如果使用的框架不一样，不是标准的，这个功能可能就很难应用起来。这一点在后面全链路以及开关等稳定性方案中，还会涉及到。
+
+今天我们介绍了容量压测的技术方案，比较复杂，而且需要对相应场景进行针对性的建设。关于细节部分，你还有什么问题，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/24稳定性实践：限流降级.md

@@ -0,0 +1,103 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            24 稳定性实践：限流降级
+                            本周我们继续来讨论稳定性实践的内容。在现实情况下，当面对极端的业务场景时，瞬时的业务流量会带来大大超出系统真实容量的压力。
+
+为了应对，前面我们介绍了容量规划方面的实践经验。不过，我们不会无限度地通过扩容资源来提升容量，因为无论从技术角度，还是从成本投入角度，这样做都是不划算的，也是不现实的。
+
+所以，我们通常采取的策略就是限流降级，以保障承诺容量下的系统稳定；同时还有业务层面的开关预案执行，峰值时刻只保障核心业务功能，非核心业务功能就关闭。
+
+今天我们就先来介绍一下限流降级的解决方案。
+
+什么是限流和降级
+
+首先，我们先梳理清楚限流和降级的概念，明白它们会发挥怎样的作用，这样才便于我们理解后续的解决方案。
+
+
+限流，它的作用是根据某个应用或基础部件的某些核心指标，如QPS或并发线程数，来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200，如果某一秒的QPS为210，那超出的10个请求就会被拦截掉，直接返回约定的错误码或提示页面。
+降级，它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。以RT举例，我们根据经验，一个应用的RT在50ms以内，可以正常提供服务，一旦超过50ms，可能就会导致周边依赖的报错或超时。所以，这时我们就要设定一个策略，如果应用的RT在某段时间内超过50ms的调用次数多于N次，那该应用或该应用的某个实例就必须降级，不再对外提供服务，可以在静默一定时间后（比如5s或10s）重新开启服务。
+
+
+这里再特别说一下降级，今天我们讲的内容可以理解为服务降级，后面我会介绍业务开关，可以理解为业务降级。这里只是叫法不同，不同的人有不同的理解，所以我们在讨论概念时，还是尽量回到我们要解决的问题和场景上来，上下文保持一致了，在观点和思路上也更容易达成一致。
+
+讲到这里，再提个问题，我们讲的降级，和熔断这个概念是什么关系？你不妨停下来，按照我们刚刚讲过的思路思考一下。
+
+常见的限流解决方案
+
+我们先看几种常见的限流类型。
+
+第一类，接入层限流。
+
+作为业务流量的入口，我们限流的第一道关卡往往会设置在这里，而且接入层限流往往也是最有效的。这里又有两类解决方案，根据接入层所使用的技术方案而定。
+
+1.Nginx限流
+
+Nginx或其开源产品是最常用的Web服务器，我们使用的是TEngine。对于一个Web类应用，如Web页面或H5页面，我们通常会将限流策略增加到这一层，会设置QPS、并发数以及CPU的Idle作为限流指标。Nginx有对应的函数接口，可以获取到以上指标信息，然后通过Lua脚本实现限流的逻辑，并作为TEngine的插件安装即可。
+
+2.API路由网关模式
+
+对于客户端模式的接入，我们使用了API路由网关模式，一方面可以更方面地管理客户端与服务端的链接，另一方面也可以通过配置的方式管理服务接口，这里的服务管理会复用到微服务架构的配置中心，并实现相应的路由策略。对于QPS和并发限流，直接在配置中心中进行配置即可。
+
+第二类，应用限流。
+
+这一类的限流策略跟上面API路由网关模式的限流相似，同样是依赖配置中心管理，限流逻辑会配套服务化的框架完成。
+
+第三类，基础服务限流。
+
+主要针对数据库、缓存以及消息等基础服务组件的限流而设定。同样，限流逻辑会配套分布式数据库中间件，缓存或消息的框架来实现。
+
+讲到这里，我来解释几个关键的技术点。
+
+
+资源和策略。资源是我们要进行限流的对象，可能是一个应用，或者一个方法，也可能是一个接口或者URL，体现了不同的限流粒度和类型。策略就是限流的规则，比如下面我们要提到的QPS和并发数限流。
+时间精度。主要指对于QPS、并发数或CPU的阈值判断。比如对于QPS，我们就会设定一个QPS时间精度（假设3s），如果低于阈值则不启用策略，如果超过阈值就启动限流策略。
+指标计数。对于并发限制请求，会统计当前的并发数，1次请求进入到限流模块加1，等请求结束退出时减1，当前正在处理的请求数就是并发数。对于QPS限流，统计QPS不能按照秒统计，因为第1s，系统可能就被打挂了，所以QPS得按照毫秒级别去统计，统计的级别越小，性能损耗越大。所以定在10ms~100ms的级别去统计会更平滑一些，比如将1s切成10份，每一份100ms，一个请求进来肯定会落在某一份上，这一份的计数值加1。计算当前的QPS，只需要将当前时间所在份的计数和前面9份的计数相加，内存里面需要维护当前秒和前面2秒的数据。
+限流方式。对于Nginx就针对总的请求进行限流即可，但是粒度会比较粗。对于应用层，因为配置中心的灵活性，其限流就可以做得更细化。比如可以针对不同来源限流，也可以针对去向限流，粒度上可以针对类级别限流，也可以针对不同的方法限流，同时还可以针对总的请求情况限流，这些灵活策略都可以在微服务的配置中心实现。
+
+
+
+
+
+Spring AOP。对于Java应用，绝大多数公司都会用到Spring框架，包括我们上面讲到的分布式数据库等组件，也一样会依赖Spring框架，比如我们用到的MyBatis开源组件。而Spirng框架中的关键技术点，就是IoC和AOP，我们在限流方案的实现上，也会利用到相关技术。简单来说就是，我们通过配置需要限流的方法作为AOP的切入点，设定Advice拦截器，在请求调用某个方法，或请求结束退出某个方法时，进行上述的各种计数处理，同时决定是否要进行限流，如果限流就返回约定好的返回码，如果不限流就正常执行业务逻辑。基于AOP这样一个统一的技术原理，我们就可以开发出与业务逻辑无关的限流组件，通常会在对外的服务调用、数据库调用、缓存调用、消息调用这些接口方法上设置默认的切面，并在业务代码运行时注入，这样就可以做到对业务透明，无侵入性。
+Web类型的限流。对于Web类型URL接口限流，我们就利用Servlet的Filter机制进行控制即可。
+控制台。上面我们讲了各种配置和策略，如果都是通过人工来操作是不现实的，这时就需要开发对应的限流降级的控制台，将上述的各种配置和策略通过界面的方式进行管理，同时在配置完成之后，能够同步到对应的服务实例上。比如对于Nginx，当一个策略配置完成后，就要同步到指定的服务器上生成新的配置文件并Reload。对于配置中心模式的策略，也就是Spring AOP模式的限流，在控制台上配置完成后，就要将配置值同步更新到配置中心里，同时再通过运行时的依赖注入，在线上运行的业务代码中生效。
+
+
+整体简化的示意图如下：
+
+
+
+限流降级的难点
+
+上面整体介绍了限流降级的解决方案，我们可以看到涉及到很多新概念，各种不同的限流类型，同时还有比较复杂的技术细节，所以要清晰地理解这些概念。
+
+对于降级，主要是针对RT来进行判断，它的整个技术方案没有限流这么复杂，且思路上跟限流是相似的，所以我们就不再单独介绍降级的技术方案了。
+
+从整个建设过程来看，我的体会是，限流降级的难点和关键还是在于整体技术栈的统一，以及后期对每个应用限流降级资源策略的准确把握和配置。
+
+我们先来看整体技术栈的统一，这其实也就是我们在专栏最开始就讲到的标准化建设。这里我们会基于一个统一的技术栈进行限流降级方案的设计，要求有统一的Web服务器类型。对服务化框架、各类分布式框架以及代码开发框架（如Spring），这些都要有很明确的要求。如果这里面有某些应用使用的框架不同，那么这套统一的方案就无法推广落地。
+
+我们在实际推广过程中就遇到很多类似的问题，导致大量的时间耗费在技术栈统一上，甚至会要求业务代码做出改变和调整，代码上线运行后再进行统一，这个代价是非常大的。
+
+这也是为什么我们在一开始就非常强调标准化的重要性。这里我们再强调一下标准化，再来复习一下以应用为核心的运维体系的思维导图。
+
+
+
+再来看对应用的限流降级资源策略的把握，这个就需要对应用和业务有深入的了解。比如开发人员要非常清楚哪些接口是核心接口，它的来源和去向有哪些；哪些来源是核心的，哪些是非核心的；如果要限流，需要对哪些接口限流，同时要重点保障哪些接口等等。
+
+对于限流和降级的具体策略，就是QPS和并发数的配置，也要来源于线上实际运行维护的经验，才能知道配置多少是合适的，配置太大没有限流效果，太小又会频繁触发限流，影响正常业务运行。
+
+所以，限流和降级也是一个动态调测和完善的过程，对于有些动态变化的资源是做不到一劳永逸的。
+
+怎么办呢？一方面我们要依赖人的经验；另一方面，从最终的解决方案看，当调用次数和日志达到一定体量时，我们希望能够借助机器学习算法的手段，来帮助我们分析什么样的设置是最合理的。
+
+今天我们讨论了限流和降级的概念、解决方案以及难点，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/25稳定性实践：开关和预案.md

@@ -0,0 +1,78 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            25 稳定性实践：开关和预案
+                            在稳定性保障中，限流降级的技术方案，是针对服务接口层面的，也就是服务限流和服务降级。这里还有另外一个维度，就是业务维度，所以今天我们就从业务降级的维度来分享，也就是开关和预案。
+
+如何理解开关和预案
+
+开关，这个概念更多是业务和功能层面的，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。
+
+在业务层面，就像我们前面经常提到的大促场景案例，我们会关闭掉很多非核心功能，只保留交易链路的核心功能。比如我们认为商品评论是非核心功能，这时就会通过开关推送这种方案将这个功能关闭。当用户访问商品详情页时，这个接口就不再被调用，从用户角度来说，就是在大促峰值时刻看不到所浏览商品的评论列表。
+
+在功能层面，我们技术架构中会使用缓存技术，但是要考虑到缓存有可能也会出现故障，比如不可访问，或者数据错乱异常等状况，这时我们就会考虑旁路掉缓存，直接将请求转到数据库这一层。
+
+这里有两种做法：一种做法是通过我们上一篇介绍到的降级手段，也就是我们常说的熔断，自动化地旁路；另一种做法，比如在数据异常情况下，请求是正常的，但是数据是有问题的，这时就无法做到自动化旁路，就要通过主动推送开关的方式来实现。
+
+预案，可以理解为让应用或业务进入到某种特定状态的复杂方案执行，这个方案最终会通过开关、限流和降级策略这些细粒度的技术来实现，是这些具体技术方案的场景化表现。
+
+我们还是接着上面的这个案例来讨论。因为每个业务或应用都会有自己的开关配置，而且数量会有很多，如果在大促前一个个推送，效率就会跟不上，所以我们就会针对某个应用的具体场景，提供批量操作的手段，通过预案场景将同一应用，甚至多个应用的开关串联起来。
+
+比如上面提到的商品详情页，我们不仅可以关闭商品评论，还可以关闭商品收藏提示、买家秀、店铺商品推荐、同类型商品推荐以及搭配推荐等等。有了场景化的预案，管理和维护起来就会更容易。
+
+除了业务层面的预案，我们还可以将预案应用到应急场景下，比如上面提到的缓存故障异常。在真实场景下，要考虑得更全面，比如缓存能够支撑的业务访问量是要远远大于数据库的，这时我们就要做功能降级，这就要考虑数据库是否能够支撑住这么大的请求量（通常情况下肯定是支撑不住的）。所以，遇到这种场景，我们首要考虑的是限流，先将业务流量限掉三分之一甚至是一半，然后再将功能降级到数据库上。
+
+这样就又涉及到多种策略的串行执行。如果没有预案都是单个执行的话，效率肯定会低，而且还可能涉及到多个应用都会执行相同的业务降级策略，这时就必须要有预案来统一管理，提前梳理好哪些应用需要在这种场景下执行对应的开关、限流和降级策略。
+
+技术解决方案
+
+技术方案上并不复杂，开关的字段主要以Key-Value方式管理，并从应用维度，通过应用名管理起来，这个对应关系就可以放到统一的控制台中管理。
+
+下图是整个开关和预案管理，以及推送的示意图，我们一起分步骤看一下。
+
+
+
+1.开关管理
+
+通过上述我们所说的Key-Value方式保存，与代码中的具体Field字段对应起来。这里就又会涉及到我们上篇内容中讲到的Spring的AOP和注解技术。
+
+如下面代码所示，我们通过注解方式定义了一个开关testKey，它与控制台中配置的Key相对应，并获取对应的Value取值，在业务运行阶段，我们就可以根据这个值，来决定业务执行逻辑，下面是简化的示例。
+
+@AppSwitcher(key="key1",valueDes = "Boolean类型")
+
+ private Boolean key1;
+
+代码中直接调用AppName对应的开关配置，进行不同业务逻辑的实现：
+
+Boolean key1 = MoguStableSwitch.isStableSwitchOn("key1");
+
+if (key1)
+{
+//开关打开时业务逻辑实现
+}else
+{
+//开关关闭时业务逻辑实现
+}
+
+
+2.开关推送
+
+当在控制台上修改开关值后，会推送到微服务的配置中心做持久化，这样当应用下次重启时依然可以获取到变更后的值。还有另外一种方式，就是通过HTTP的方式推送，这种情况的应用场景是，当第一种情况失败时，为了让开关快速生效预留的第二个接口。
+
+3.配置变更
+
+应用中引入的开关SDK客户端会监听对应配置的变更，如果发生变化，就会马上重新获取，并在业务运行时生效。
+
+4.预案执行
+
+就是多个开关策略的串行执行，会重复上面这几个关键步骤。
+
+关于开关和预案的内容，我们今天就介绍到这里。留一个问题，我们在上篇文章中介绍到限流降级方案的难点，请你思考一下，我们今天讲的开关预案这个内容，可能会遇到哪些难点呢？欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/26稳定性实践：全链路跟踪系统，技术运营能力的体现.md

@@ -0,0 +1,107 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            26 稳定性实践：全链路跟踪系统，技术运营能力的体现
+                            今天我们来分享全链路跟踪系统建设方面的内容。我们知道，随着微服务和分布式架构的引入，各类应用和基础组件形成了网状的分布式调用关系，这种复杂的调用关系就大大增加了问题定位、瓶颈分析、容量评估以及限流降级等稳定性保障工作的难度，如我们常见的调用网状关系。
+
+
+
+图片出自：https://www.linkedin.com/pulse/100-million-members-125-hours-watched-per-day-hundreds-probst/
+
+正是这样的背景，催生了分布式链路跟踪，也叫全链路跟踪的解决方案。
+
+关于这一块的技术解决方案，在Google的Dapper论文发表之后，近些年业界已经有非常多且非常成熟的实践经验和开源产品。
+
+比如阿里的鹰眼系统，就是全链路跟踪系统在国内的最佳实践；再比如美团点评的CAT分布式监控系统，也是从产品实践中逐步开源出来，在业界已经得到了非常广泛的应用；还有一些独立的开源产品，比如国内分布式监控技术专家吴晟创建的Skywalking项目，也是非常优秀的产品，而且也有比较广泛的应用。
+
+除此之外，还有大量优秀的商业产品，这类产品通常叫APM，应用性能管理系统，比如国内的听云、博瑞、OneAPM等等，他们在产品化方面做的会更完善，在很多场景下可以非常方便地落地应用。
+
+介绍上述这些产品，主要还是想说明，当前在分布式或全链路跟踪监控这个领域，无论是在技术还是产品层面都已经相对成熟，我们完全可以通过对这些产品的调研来选择适合自己的解决方案。
+
+蘑菇街在这块也是自研了一套体系，但是技术方案和思路上跟上述这些开源或商业产品都很相似，所以技术层面我就不再做详细赘述。
+
+如果想深入了解相关内容，一方面可以在网上找到非常多的资料，甚至是去阅读源码；另一方面还是推荐极客时间上陈皓老师的《左耳听风》专栏和杨波老师的《微服务架构核心20讲》，两位都是骨灰级的微服务和分布式架构专家，他们在技术层面的分享会更有深度和针对性。
+
+全链路跟踪系统在技术运营层面的应用
+
+接下来，主要分享我们利用全链路跟踪系统在技术运营层面做的一些事情，这里提到的运营，就是应用在线上运行时，我们根据应用运行数据所做的运行维护工作，这里我们会更加强调数据的作用。
+
+同时，这里的一个核心技术点就是 TraceID，当请求从接入层进来时，这个TraceID就要被创建出来；或者是通过Nginx插件方式创建放到http的header里面；或者是通过RPC服务化框架生成。然后在后续的请求中，这个字段会通过框架自动传递到下一个调用方，而不需要业务考虑如何处理这个核心字段。
+
+有了这个TraceID，我们就可以将一个完整的请求链路给串联起来了，这也是后面场景化应用的基础。下面我们就一起来看会有哪些具体的技术运营场景。
+
+第一个场景，问题定位和排查
+
+我们做全链路跟踪系统，要解决的首要问题就是在纷繁复杂的服务调用关系中快速准确地定位问题，所以这个场景是绕不开的。
+
+我们常见的问题场景，主要有两类：瓶颈分析和异常错误定位。
+
+首先看瓶颈分析。常见的问题就是某某页面变慢了，或者某个服务突然出现大量超时告警，因为无论是页面也好，还是服务也好，在分布式环境中都会依赖后端大量的其它服务或基础部件，所以定位类似的问题，我们期望能有一个详细的调用关系呈现出来，这样我们就可以非常方便快速地判断瓶颈出现在什么地方。
+
+比如下图的情况，就是某个页面变慢。我们根据URL查看某次调用的情况，就发现瓶颈是在RateReadService的query接口出现了严重阻塞。接下来，我们就可以根据详细的IP地址信息，到这台机器上或者监控系统上，进一步判断这个应用或者这台主机的异常状况是什么，可能是机器故障，也可能是应用运行故障等等。
+
+
+
+再来看一个案例。下图中我们可以看到，一次完整的请求耗时比较长，但是通过调用链分析会发现，其中任何一个单次请求的时延又非常低，并没有像上个案例那样有明显的请求瓶颈。我们再进一步分析，就会发现整个请求的列表非常长，且请求列表里面都是在访问缓存内容。很显然，这样的调用方式不合理，需要我们优化调用逻辑，要么通过批量接口方式，要么通过异步的方式，再或者要去分析业务场景是否合理。
+
+
+
+通过上面的案例，我们可以看到，在应用了全链路跟踪的解决方案后，复杂调用关系下的问题定位就相对简单多了。
+
+对于出现异常报错，也是一样的判断逻辑，限于篇幅我就不再赘述了。
+
+第二个场景，服务运行状态分析
+
+上面的问题定位，主要还是针对单次请求或相对独立的场景进行的。更进一步，我们在采集了海量请求和调用关系数据后，还可以分析出更有价值的服务运行信息。比如以下几类信息。
+
+1.服务运行质量
+
+一个应用对外可能提供HTTP服务，也可能提供RPC接口。针对这两类不同的接口，我们可以通过一段时间的数据收集形成服务接口运行状态的分析，也就是应用层的运行监控，常见的监控指标有QPS、RT和错误码，同时还可以跟之前的趋势进行对比。这样就可以对一个应用，以及对提供的服务运行情况有一个完整的视图。
+
+
+
+2.应用和服务依赖
+
+除了上述单个应用的运行状态，我们还可以根据调用链的分析，统计出应用与应用之间，服务与服务之间的依赖关系及依赖比例，如下图所示。
+
+
+
+这个依赖管理的作用，就是给我们前面介绍的容量压测和限流降级这两个工作做好准备。我们可以根据来源依赖和比例评估单链路的扩容准备；同时根据去向依赖进行流量拆分，为下游应用的扩容提供依据，因为这个依赖比例完全来源于线上真实调用，所以能够反映出真实的业务访问模型。
+
+同时，根据这个依赖关系，特别是服务依赖关系，我们还可以进一步分析依赖间的强弱关系，也就是强弱依赖。这一点又对我们做限流降级提供了对应的依据，也就是我们前面所说的，我们限流也好，降级也好，都是优先对非核心业务的限流和降级，这样的业务形成的依赖，我们就认为是弱依赖，是不关键的；但是对于核心业务我们就要优先保障，它们形成的依赖关系，是强依赖。无论是扩容也好，还是优化性能也罢，都要最大限度地确保强依赖关系的调用成功。
+
+所以，强弱依赖的分析，还是要从业务场景入手。比如对于电商来说，核心就是交易链路，我们就要判断如果一条链路上的某个应用或服务失败了，是不是会影响订购下单，或者影响支付收钱，如果影响，就要标注为强依赖，这个应用就要标注为核心应用；如果这个应用失败了，可以通过限流或降级的方式绕过，只是影响用户体验，但是不影响用户订购支付，那这个依赖关系就可以标注为弱依赖，该应用就可以标注为非核心应用。
+
+同时，因为我们的业务场景和需求在不断变化，应用和服务间的调用关系和依赖关系也是在不断变化中的，这就需要我们不断地分析和调整强弱依赖关系，同时也要关注各种调用间的合理性，这个过程中就会有大量的可优化的工作。
+
+通常情况下，这些事情对于业务架构师和运维人员来说，都会比较关注。因为业务架构师要对业务访问模型十分了解，他要经常关注这些信息；而运维会关注线上稳定性，需要在关键时刻执行限流降级或开关预案策略，所以也必须对这些信息非常熟悉。
+
+3.依赖关系的服务质量
+
+上面介绍了应用和服务间的依赖管理，同样的我们也会关注被依赖的应用或服务的实时运行状态和质量，这样就可以看到应用间实时的调用状态。是不是有的应用调用QPS突然增加了，或者RT突然暴涨，通过这个依赖关系就可以快速确认。
+
+
+
+第三类场景，业务全息
+
+顾名思义，业务全息就是全链路跟踪系统与业务信息的关联。从上述的介绍中，我们可以看到，全链路跟踪系统的应用更多的还是在技术层面，比如定位“应用或服务”的问题，应用或服务间的依赖关系等等。
+
+但是现实中，我们也会遇到大量的业务链路分析的场景，比如可能会有针对某个订单在不同阶段的状态等。假设一个情况是用户投诉，他的订单没有享受到满100元包邮的优惠，这时我们就要去查找用户从商品浏览、加购物车到下单整个环节的信息，来判断问题出在哪儿。其实，这个场景和一个请求的全链路跟踪非常相似。
+
+所以，为了能够在业务上也采用类似的思路，我们就将前面介绍到的请求链路上的唯一TraceID与业务上的订单ID、用户ID、商品ID等信息进行关联，当出现业务问题需要排查时，就会根据对应的ID将一串业务链整个提取出来，然后进行问题确认。这就会极大地提升解决业务问题的效率。
+
+总结
+
+今天我们从技术运营层面的应用这个角度重新认识了全链路跟踪系统。同时，从这个案例中，我们也应该看到，技术、产品和运营相辅相成，共同促进彼此的完善和成熟。
+
+全链路跟踪系统在技术方案的广泛应用，给我们提供了大量可分析处理的线上运行数据，从这些数据中，我们又能提炼出对线上稳定运行更有价值的信息。所以，技术之外，我们也应该更多地考虑技术在价值方面的呈现。
+
+今天的内容就介绍到这里，你在这方面遇到过哪些问题，有怎样的经验，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/27故障管理：谈谈我对故障的理解.md

@@ -0,0 +1,80 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            27 故障管理：谈谈我对故障的理解
+                            对于任何一个技术团队来说，最令人痛苦、最不愿面对的事情是什么？我想答案只有一个，那就是：故障。
+
+无论是故障发生时的极度焦虑无助，还是故障处理过程中的煎熬痛苦，以及故障复盘之后的失落消沉，都是我们不愿提及的痛苦感受。在海外，故障复盘的英文单词是Postmortem，它有另外一个意思就是验尸，想想就觉得痛苦不堪，同时还带有一丝恐怖的意味。
+
+写故障相关的文章，也着实比较痛苦。一方面回顾各种故障场景，确实不是一件令人愉悦的体验；另一方面，故障管理这个事情，跟技术、管理、团队、人员息息相关，也是一套复杂的体系。
+
+我们看Google SRE这本书（《SRE：Google运维解密》），绝大部分章节就是在介绍故障相关的内容。其实看看这本书就能明白稳定性和故障管理这项系统工程的复杂度了，而且从本质上讲，SRE的岗位职责在很大程度上就是应对故障。
+
+所以，接下来的几期文章，我会谈谈我对故障管理的理解，以及一些实际经历的感受，也希望我们每一个人和团队都能够在故障管理中得到涅槃重生。
+
+今天，先谈谈我们应该如何来看待故障这个事情。
+
+系统正常，只是该系统无数异常情况下的一种特例
+
+上面这句话，来自Google SRE这本书，我认为这是一个观点，但是更重要的，它更是一个事实。所以，正确理解故障，首先要接受这个现实。
+
+故障，是一种常态，任何一个软件系统都避免不了，国内最牛的BAT避免不了，国外最牛的Google、Amazon、Facebook、Twitter等也避免不了。业务体量越大，系统越复杂，问题和故障就越多，出现故障是必然的。
+
+可能你会有疑问，既然他们也存在各种故障，但是在我们的印象中，好像也没经常遇到这些大型网站整天出问题或不可访问的情况，这恰恰说明了这些公司的稳定性保障做得非常到位。
+
+这里有一个非常重要的体现，就是Design for Failure的理念。我们的目标和注意力不应该放在消除故障，或者不允许故障发生上，因为我们无法杜绝故障。所以，我们更应该考虑的是，怎么让系统更健壮，在一般的问题面前，仍然可以岿然不动，甚至是出现了故障，也能够让业务更快恢复起来。
+
+其实对这个理念的实践，我们在前面都已经介绍过了，比如限流降级、容量评估以及开关预案等技术方案的稳定性保障体系，这些技术方案本质上并不是为了杜绝故障发生，而是为了能够更好地应对故障。
+
+同样的，我们刚提到的那些国内外超大型网站，之所以能够保持很高的稳定性和业务连续性，恰恰是说明他们在故障隔离、快速恢复、容灾切换这些方面做得非常优秀，一般的问题或故障，根本不会影响到业务访问。
+
+所以，转变一下思路，重新理解系统运行的这种特点，会给我们后续在如何面对故障、管理故障的工作中带来不一样的思考方式。
+
+故障永远只是表面现象，其背后技术和管理上的问题才是根因
+
+简单表述一下，就是永远不要将注意力放在故障本身上，一定要将注意力放到故障背后的技术和管理问题上去。
+
+这里的逻辑是这样的，技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒。
+
+有时我们过分关注故障本身，就容易揪着跟故障相关的责任人不放，这样会给责任人造成很大的负面压力，进而导致一些负面效应的产生，这一块在后面我还会专门分享。
+
+与之对应的改进措施，往往就容易变成如何杜绝故障。前面我们讲到，从现实情况看这是完全不可能的，所以就容易输出一些无法落地、无法量化的改进措施。
+
+你可以思考一下，面对故障的时候，是不是经常出现上述这两种情况。
+
+所以，想要更好地应对和管理故障，当故障发生后，我们需要考虑的问题应该是其背后存在的技术和管理问题。这里和你分享我自己在故障后的复盘中，经常会反思和提出的几个问题。
+
+
+为什么会频繁出故障？是不是人员技术不过硬？人为操作太多，自动化平台不完善，操作没有闭环？代码发布后的快速回滚措施不到位？
+为什么一个小问题或者某个部件失效，会导致全站宕机？进一步考虑，是不是业务高速发展，技术架构上耦合太紧，任何一个小动作都可能是最后一根稻草？是不是容量评估靠拍脑袋，系统扛不住才知道容量出问题了？是不是限流降级等保障手段缺失，或者有技术方案，但是落地效果不好？
+为什么发生了故障没法快速知道并且快速恢复？进一步考虑，是不是监控不完善？告警太多人员麻木？定位问题效率低，迟迟找不到原因？故障隔离还不够完善？故障预案纸上谈兵？
+管理上，团队成员线上敬畏意识不够？还是我们宣传强调不到位？Oncall机制是否还需要完善？故障应对时的组织协作是不是还有待提升？
+
+
+总结下来，任何一个故障的原因都可以归结到具体的技术和管理问题上，在故障复盘过程中，通常会聚焦在某个故障个例上，归纳出来的是一个个非常具体的改进措施。
+
+用一句话总结：“理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。”（From SRE ，by Brian Redman）
+
+最后，作为管理者，我会问自己一个终极问题：下次出现类似问题，怎么才能更快地发现问题，更快地恢复业务？即使这一次的故障应对已经做得非常好了，下次是否可以有更进一步的改进？
+
+这个问题，会促使我个人更加全面地思考，且能够关注到更全局的关键点上。比如，是不是应该考虑有更加完善的发布系统，减少人为操作；是不是应该有整体的稳定性平台建设，包括限流降级、开关预案、强弱依赖、容量评估、全链路跟踪等子系统，以及建设完成后，应该如何一步步的落地；还有，故障预案和演练应该如何有效的组织起来，毕竟这些是从全局考虑，自上而下的一个过程。
+
+最后
+
+再表达两个观点。
+
+第一，出问题，管理者要先自我反省。不能一味地揪着员工的错误不放，员工更多的是整个体系中的执行者，做得不到位，一定是体系上还存在不完善的地方或漏洞。在这一点上，管理者应该重点反思才对。
+
+第二，强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上面提到的就基本都是技术手段，但是要建设一个完善的体系肯定要有一个过程，特别是对于创业公司。这时可以辅以一些管理措施，比如靠宣传学习，提升人员的线上安全稳定意识，必要的Double Check，复杂操作的Checklist等，但是这些只能作为辅助手段，一定不能是常态，必须尽快将这些人为动作转化到技术平台中去。
+
+这样做的原因也很明显，单纯的管理手段还是靠人，跟之前没有本质区别，只不过是更加谨小慎微了一些而已。同时，随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升。
+
+今天和你分享了我对故障这件事情的理解，期望这样一个不同角度的理解能够带给你一些启发，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/28故障管理：故障定级和定责.md

@@ -0,0 +1,89 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            28 故障管理：故障定级和定责
+                            故障管理的第一步是对故障的理解，只有正确地面对故障，我们才能够找到更合理的处理方式。今天就来和你分享关于故障定级和定责方面的经验。
+
+故障的定级标准
+
+上期文章中介绍到，如果我们的注意力仅仅盯着故障本身，就非常容易揪着责任人不放，进而形成一些负面效应，所以我们要将更多的注意力放到故障背后的技术和管理问题上。
+
+但是，这并不是说对故障本身就可以不重视，相反，故障发生后，一定要严肃对待。这里就需要制定相应的标准和规范来指导我们的处理过程。这个过程并不是一定找出谁来承担责任，或者一定要进行处罚，而是期望通过这样的过程，让我们能够从故障中深刻地认识到我们存在的不足，并制定出后续的改进措施。
+
+这里有一个关键角色，我们称之为技术支持，也有的团队叫 NOC（Network Operation Center）。这个角色主要有两个职责：一是跟踪线上故障处理和组织故障复盘，二是制定故障定级定责标准，同时有权对故障做出定级和定责，有点像法院法官的角色，而上面的两个标准就像是法律条款，法官依法办事，做到公平公正。
+
+所以，这里的一个关键就是我们要有明确的故障定级标准。这个标准主要为了判定故障影响程度，且各相关利益方能够基于统一的标准判断和评估。
+
+现实情况中，因为各方受到故障的影响不同，对故障影响的理解也不同，所以复盘过程中，经常会出现下面这两种争执场景。
+
+
+技术支持判定故障很严重，但是责任方认为没什么大不了的，不应该把故障等级判定到如此之高；
+技术支持认为故障影响较小，但是受影响方却认为十分严重，不应该将故障等级判定得这么低。
+
+
+遇到这种情况，技术支持作为故障判定的法官，就必须拿出严格的判定标准，并说明为什么这么判定。
+
+我们将故障等级设置为P0~P4这么5个级别，P0为最高，P4为最低。对于电商，主要以交易下跌、支付下跌、广告收入资损这些跟钱相关的指标为衡量标准。对于其他业务如用户IM等，主要区分业务类型，制定符合业务特点的定级标准。两个示例如下。
+
+交易链路故障定级标准示例：
+
+
+
+用户IM故障定级标准示例：
+
+
+
+故障定级的标准，会由技术支持与各个业务研发团队进行点对点的细节沟通讨论，从业务影响角度把影响面、影响时长这些因素串联起来。这样即使在后续出现争执，也会有对应的标准参考。这个标准可能覆盖不到有些故障影响或特例，但是技术支持可以根据自己的经验进行“自由裁量”。同时，每个季度或半年对标准进行一次修订和完善。这样，我们前面提到的争执就会越来越少，再加上我们内部树立了“技术支持角色拥有绝对话语权和决策权”的制度，执行过程中就会顺畅很多。
+
+对于P0故障，通常是由两个级以上的P1故障叠加造成的，这说明已经发生了非常严重的全站故障。
+
+不同的故障定级，在故障应对时采取的策略也就不同。一般来说，P2及以上故障就需要所有相关责任人马上上线处理，并及时恢复业务。对于P3或P4的问题，要求会适当放宽。整个过程，技术支持会给出一个基本判断，然后会组织召集临时故障应急小组处理。
+
+关于全年全站，或者分业务的可用性和可靠性，这个可以借鉴业界通用的MTBF（Mean Time Between Failures，平均故障间隔时间）、MTTR（Mean Time To Recovery，平均修复时间）、MTTF（Mean Time To Failure，平均失效前时间）这几个指标来衡量，这里我们就不详细介绍了。
+
+故障的定责标准
+
+上述的故障定级标准，主要是用来判定故障等级，使得故障相关方不至于过分纠结在等级标准上。而故障定责的主要目的是判定责任方。这就需要有明确的故障定责标准，我认为有两个主要目的。
+
+
+避免扯皮推诿。比如我认为是你的责任，你认为是我的责任，大家争执不清，甚至出现诋毁攻击的情况。
+正视问题，严肃对待。不是为了处罚，但是作为责任方或责任团队一定要正视问题，找出自身不足，作为改进的主要责任者，来落地或推进改进措施。
+
+
+关于第一点，避免扯皮推诿，大概是很多团队都会遇到的非常头疼的问题，也是最令人生厌的问题，所以避免这样的问题，就必须得有相对清晰的定责标准。
+
+比如我们经常会提到的运维背锅的说法，这种情况出现的场景经常是，某个核心功能出现了故障，有大量超时或失败，对应的开发定位一下，说我的代码没有问题，场景也没复现，这个应该是运维负责的主机、网络或者其他基础服务有问题吧，这个责任很轻易地就甩给了运维。类似的上游把责任推脱到下游的情况是经常出现的。
+
+我们自己的实践，是严禁这种情况出现的。也就是作为受影响方，开发负责人有责任端到端地把问题定位清楚，只有当定位出来的问题确实是发生在运维的某个部件时，才允许将责任传递 ，否则不允许出现将自己的问题简单排除，就推断或者感觉应该是其他责任方的问题，然后终止后续排查或者指定下游责任方的情况出现。
+
+当然，在这个过程中，如果需要配合，是可以要求各方投入支持的，因为共同的目标还是要清晰定位问题，找到解决方案。
+
+这时候，就更加需要开放和宽松的氛围，如果大家始终朝着如何摆脱责任或甩锅的目标行事，就会出现非常负面的效应，这一点后面我们会详细分享。
+
+关于定责，我们划分了几个维度，我简单示例如下。
+
+1.变更执行
+
+比如变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方；如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方；变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。
+
+2.服务依赖
+
+比如私自调用接口，或者调用方式不符合约定规则，责任在调用方；如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方等等。
+
+3.第三方责任
+
+比如机房IDC电力故障、服务器故障、运营商网络故障等等，如果确实是不可抗力导致，责任在第三方；但是因自身的冗余或故障预案问题导致故障，责任在应用Owner。
+
+有了这样的原则，在故障复盘时，就可以有效减少不和谐氛围的出现。因为每个公司的业务形态和特点不一样，里面的具体内容可能也不一样，上述的定责标准可能不完全适用，所以仅供示例参考。如果你在日常深受故障定责的困扰，建议尽快把规则明确起来，并能够与各方达成一致，这样就会最大程度地减少扯皮推诿的情况出现。
+
+总结
+
+今天我们讨论了故障管理中的定级和定责标准。蘑菇街在这方面的具体管理执行中，还是取得了不错的效果，所以分享出来，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/29故障管理：鼓励做事，而不是处罚错误.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            29 故障管理：鼓励做事，而不是处罚错误
+                            故障发生后，我们一定要严肃对待，要对关键责任人或责任方定责，但是定责的目的不是处罚，因为故障复盘一旦以处罚为导向，就会导致非常严重的负面效应。
+
+我们应该如何对待定责和处罚呢？今天就来分享一下我的理解，以及我个人的一些处理方式。
+
+关于定责和处罚
+
+定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的。
+
+但是，在具体的执行过程中，我们一定要区分定责和处罚。定责是对事不对人的，但是处罚就变成对人不对事了，因为处罚一定会跟薪资、奖金、绩效、晋升等这些跟个人利益相关的事情直接挂钩。
+
+我的观点是，处罚不能一刀切，更不能上纲上线，一定要慎重。
+
+关于是否处罚，我个人认为可以遵循这样的原则：对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。
+
+这样的规则建议通过设定高压线的方式让团队成员牢记心中，就像“酒后不开车”一样，简单明确。我大致列举几条我们的“高压线规则”。
+
+
+未经发布系统，私自变更线上代码和配置；
+未经授权，私自在业务高峰期进行硬件和网络设备变更；
+未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
+未经授权，私自在生产环境进行调测性质的操作；
+未经授权，私自变更生产环境数据信息。
+
+
+通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从我们的经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。特别是那种自我感觉没问题，就把命令噼里啪啦敲到线上的操作，是最致命的。
+
+2016年是公司业务高速发展的阶段，设备扩容比较频繁，网络割接操作也很多。因为没有明确严格的规则，导致团队成员为了赶工期，在白天进行网络设备变更，结果就是严重的P0和P1故障频发。复盘过程中，很多人的反馈就是：我以为是没问题的，我以为是没影响的。其实恰恰就是因为这种“想当然”，导致了严重故障。
+
+后来我们总结，在这些关键的操作上，如果大家意识到位，能够谨小慎微，绝大多数低级失误都是可以避免的，所以针对这些场景，我们就专门制定了高压线。
+
+制定高压线的效果也是很明显的。在近两年的时间里，我们没有出现过任何一例因为意识缺失或低级失误导致的P0和P1故障。反倒是跟我们有产品技术合作的第三方厂商，有时会出问题，我们了解下来，基本都是白天变更导致的，要么是没有放到凌晨实施，要么就是白天临时变更，没有准备充分。
+
+所以，制定明确的高压线规则，提升意识，碰一次就要疼一次。这个时候的惩罚是为了提升责任人的敬畏意识和主观意识，人为失误才会减少，处罚也才会有效。
+
+当然，更好的结果是，类似的故障越来少，处罚的执行也基本没有了。
+
+鼓励做事，而不是处罚错误
+
+前面我们分享过这句话：
+
+
+理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（From SRE ，by Brian Redman）
+
+
+我想很多朋友跟我一样，都会产生共鸣。仔细考虑一下，我们每个人的技术能力提升，甚至是质的提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进，这样一个过程提升起来的。
+
+虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。
+
+发生故障一方面暴露出我们整体技术架构的不足之处，另一方面，也给我们提供了未来改进的方向。同时，也是最重要的，我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，团队和个人素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。
+
+反观另一种管理方式，一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。
+
+所以，作为管理者，当一个故障发生之后，除故障本身外，还要关注更全面的内容，比如关注人、事情背景和前因后果。
+
+列举一下我之前经常遇到的两种情况。
+
+1.员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现了问题。
+
+这种情况在成熟的技术和产品中也极容易出现，比如开源产品，有时候不翻源码都不知道某个地方埋着深坑。即使是商业产品，像Oracle在他的官方bug库里列着一堆已知bug，就是明确告知用户使用时要非常小心，真的碰到bug了，官方一般也是建议升级版本。根据我的经验，对于这样一个庞大的bug库，不出问题一般没人会去把整个bug list都看一遍的。
+
+2.业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，这个时候可能任何一个小变动都是最后一根稻草。这种时候就需要群策群力，而不是简单处罚了事。
+
+这两种情况都需要全面了解信息之后，再做判断。甚至要优先传递信任，而不是不管三七二十一就直接批评和处罚。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。
+
+在当前这种新业务和新形态不断涌现，又要求快速迭代的背景下，软件开发这种技术工作很大程度上还是要依赖员工的创新和创造。所以在很多情况下，管理者一定要对故障有一定的容忍度，因为员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失，为别人做了嫁衣。
+
+所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。
+
+处罚的“负”作用远超我们的想象
+
+前面讲到，定责不是处罚，是就事论事。员工哪些地方做得不到位，是能力不足还是经验欠缺，这些东西主管可以基于事实，很正式、严肃地表达出来。通常情况下，员工也大多是可以接受的。同时帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。这种情况下，员工的感受是，主管尊重我，在帮助我。
+
+但是，话题和目的一旦转到处罚相关的事情，员工一般会有两种类型的反应：一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑（凭什么罚我不罚别人，又不是我一个人的问题等等）。
+
+这时，员工的注意力也会从怎么改进，转变到为什么要处罚我的角度上来。在这种消极和抵抗情绪中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一句，但是他压根就没听进去。
+
+从我们的经验来看，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。
+
+后来我们就取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。
+
+我的团队中，就出现过类似的情况。有员工导致了线上严重故障，当个季度绩效较差，但是因为全年表现突出，年终仍然是优秀；也有员工，因为连着两个季度触碰高压线，全年又无明显突出的表现，年终绩效也就不理想。
+
+总结
+
+我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。
+
+另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。
+
+最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/30故障管理：故障应急和故障复盘.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            30 故障管理：故障应急和故障复盘
+                            故障发生后，我们一定要严肃对待，要对关键责任人或责任方定责，但是定责的目的不是处罚，因为故障复盘一旦以处罚为导向，就会导致非常严重的负面效应。
+
+我们应该如何对待定责和处罚呢？今天就来分享一下我的理解，以及我个人的一些处理方式。
+
+关于定责和处罚
+
+定责的过程，是找出根因，针对不足找出改进措施，落实责任人。定责的目的，是责任到人，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，我们对于故障的态度一定是严肃严格的。
+
+但是，在具体的执行过程中，我们一定要区分定责和处罚。定责是对事不对人的，但是处罚就变成对人不对事了，因为处罚一定会跟薪资、奖金、绩效、晋升等这些跟个人利益相关的事情直接挂钩。
+
+我的观点是，处罚不能一刀切，更不能上纲上线，一定要慎重。
+
+关于是否处罚，我个人认为可以遵循这样的原则：对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况是要处罚的。
+
+这样的规则建议通过设定高压线的方式让团队成员牢记心中，就像“酒后不开车”一样，简单明确。我大致列举几条我们的“高压线规则”。
+
+
+未经发布系统，私自变更线上代码和配置；
+未经授权，私自在业务高峰期进行硬件和网络设备变更；
+未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；
+未经授权，私自在生产环境进行调测性质的操作；
+未经授权，私自变更生产环境数据信息。
+
+
+通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从我们的经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。特别是那种自我感觉没问题，就把命令噼里啪啦敲到线上的操作，是最致命的。
+
+2016年是公司业务高速发展的阶段，设备扩容比较频繁，网络割接操作也很多。因为没有明确严格的规则，导致团队成员为了赶工期，在白天进行网络设备变更，结果就是严重的P0和P1故障频发。复盘过程中，很多人的反馈就是：我以为是没问题的，我以为是没影响的。其实恰恰就是因为这种“想当然”，导致了严重故障。
+
+后来我们总结，在这些关键的操作上，如果大家意识到位，能够谨小慎微，绝大多数低级失误都是可以避免的，所以针对这些场景，我们就专门制定了高压线。
+
+制定高压线的效果也是很明显的。在近两年的时间里，我们没有出现过任何一例因为意识缺失或低级失误导致的P0和P1故障。反倒是跟我们有产品技术合作的第三方厂商，有时会出问题，我们了解下来，基本都是白天变更导致的，要么是没有放到凌晨实施，要么就是白天临时变更，没有准备充分。
+
+所以，制定明确的高压线规则，提升意识，碰一次就要疼一次。这个时候的惩罚是为了提升责任人的敬畏意识和主观意识，人为失误才会减少，处罚也才会有效。
+
+当然，更好的结果是，类似的故障越来少，处罚的执行也基本没有了。
+
+鼓励做事，而不是处罚错误
+
+前面我们分享过这句话：
+
+
+理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（From SRE ，by Brian Redman）
+
+
+我想很多朋友跟我一样，都会产生共鸣。仔细考虑一下，我们每个人的技术能力提升，甚至是质的提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进，这样一个过程提升起来的。
+
+虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。
+
+发生故障一方面暴露出我们整体技术架构的不足之处，另一方面，也给我们提供了未来改进的方向。同时，也是最重要的，我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，团队和个人素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。
+
+反观另一种管理方式，一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。
+
+所以，作为管理者，当一个故障发生之后，除故障本身外，还要关注更全面的内容，比如关注人、事情背景和前因后果。
+
+列举一下我之前经常遇到的两种情况。
+
+1.员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现了问题。
+
+这种情况在成熟的技术和产品中也极容易出现，比如开源产品，有时候不翻源码都不知道某个地方埋着深坑。即使是商业产品，像Oracle在他的官方bug库里列着一堆已知bug，就是明确告知用户使用时要非常小心，真的碰到bug了，官方一般也是建议升级版本。根据我的经验，对于这样一个庞大的bug库，不出问题一般没人会去把整个bug list都看一遍的。
+
+2.业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，这个时候可能任何一个小变动都是最后一根稻草。这种时候就需要群策群力，而不是简单处罚了事。
+
+这两种情况都需要全面了解信息之后，再做判断。甚至要优先传递信任，而不是不管三七二十一就直接批评和处罚。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。
+
+在当前这种新业务和新形态不断涌现，又要求快速迭代的背景下，软件开发这种技术工作很大程度上还是要依赖员工的创新和创造。所以在很多情况下，管理者一定要对故障有一定的容忍度，因为员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失，为别人做了嫁衣。
+
+所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。
+
+处罚的“负”作用远超我们的想象
+
+前面讲到，定责不是处罚，是就事论事。员工哪些地方做得不到位，是能力不足还是经验欠缺，这些东西主管可以基于事实，很正式、严肃地表达出来。通常情况下，员工也大多是可以接受的。同时帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。这种情况下，员工的感受是，主管尊重我，在帮助我。
+
+但是，话题和目的一旦转到处罚相关的事情，员工一般会有两种类型的反应：一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑（凭什么罚我不罚别人，又不是我一个人的问题等等）。
+
+这时，员工的注意力也会从怎么改进，转变到为什么要处罚我的角度上来。在这种消极和抵抗情绪中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一句，但是他压根就没听进去。
+
+从我们的经验来看，如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。
+
+后来我们就取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。
+
+我的团队中，就出现过类似的情况。有员工导致了线上严重故障，当个季度绩效较差，但是因为全年表现突出，年终仍然是优秀；也有员工，因为连着两个季度触碰高压线，全年又无明显突出的表现，年终绩效也就不理想。
+
+总结
+
+我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。
+
+另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。
+
+最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/31唇亡齿寒，运维与安全.md

@@ -0,0 +1,73 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            31 唇亡齿寒，运维与安全
+                            故障管理模块告一段落了，今天我们来分享运维安全的内容。在日常工作中，我们运维团队和安全团队的配合确实是非常紧密的，有非常多的交集，我觉得可以做个整体的分享，算是抛砖引玉，以激发更多的讨论和思考。
+
+运维和安全的关系
+
+运维和安全，双方有一个共同的特点，就是时常要面对非常棘手，甚至是影响公司口碑声誉的问题。对于安全来说，这一点尤甚，想一想用户信息泄露会造成什么样的后果就不难理解了。
+
+所以，运维和安全的合作，最初都是在这种场景下触发的，也就让两个团队显得更像是难兄难弟。
+
+另外一层关系，就像我们今天分享的题目，运维和安全的关系，就是唇亡齿寒的关系。因为安全是整个业务和技术体系的一道防线，当这道防线被突破，最直接的影响和损失就体现在主机、系统和数据上，而这些又正好是运维的范畴。说得直白一点，就是一旦发生了安全事故，造成的影响，以及后续的修复，这些工作都将由运维来承担。
+
+所以，在双方工作的协作上，我一直认为运维不能只是被动响应，而应该主动与安全合作，共建安全体系，与运维体系融合，把防线建设好，从源头控制。
+
+同时，安全问题和需求一般都会放置在较高优先级上来响应，并通过固定的问题响应机制实行联动，从而实现最高效的配合响应。
+
+蘑菇街安全体系简介
+
+这里首先介绍一下我们的安全体系，限于篇幅，我只对部分关键系统和平台做一个简要概述，同时会介绍一下每个系统与运维系统之间的关系。
+
+1.入网管控
+
+这是VPN接入的管控，并与员工的统一登录鉴权结合，做到一键登录。因为VPN接入后，就等于进入了线上的网络环境中，可以访问到很多敏感系统和数据，这里的入网管控就相当于整个环境的第一道防线。
+
+2.堡垒机
+
+当接入VPN之后，对于技术同学就会有进一步的需求，比如访问线下和线上环境，登录主机和网络设备做维护工作，这时我们就需要有另外一道关卡，就是硬件或虚拟设备的登录管控，这个就由堡垒机来实现。这里堡垒机维护的主机列表、主机用户名、权限配置等信息，就需要与运维系统中的CMDB以及运维标准化的内容保持统一。
+
+因为堡垒机基本属于每个公司安全建设的第一个产品，所以属于强需求，业界也随之出现了很多优秀的开源及商业产品，你可以自行了解一下。同时，关于这块内容，我们的安全工程师齐剑涛在2017年CUNTCon全球运维技术大会上做过分享，如果有兴趣可以进一步了解。
+
+固守服务器的第一道防线——美联集团堡垒机的前世今生
+
+3.主机安全管控
+
+在每台主机上运行一个安全Agent，实时地对可疑进程、可疑端口、可疑账号、可疑日志以及各类操作进行监控，一旦发现异常就会及时告警，确保能够第一时间发现异常，这种就可以一定程度上对黑客入侵导致的破坏进行控制。
+
+4.黑盒扫描
+
+这个系统主要针对主机上对外开放的端口和使用的服务进行扫描。比如我们之前遇到的Redis高危端口漏洞，OpenSSL心脏滴血漏洞等，同时从接入层会过滤出高频的url，通过注入或修改消息来模拟恶意攻击，量虽不会大，但是如果存在异常或高危漏洞就可以及时发现，同时这个扫描是不间断的。
+
+5.白盒扫描（代码审计）
+
+这个系统我们在前面的持续交付流水线中介绍过，会针对代码中明显的漏洞进行审计，比如XSS漏洞，SQL注入等问题，如果在代码中存在类似问题是不允许发布上线的。
+
+这个项目已经开源，地址：https://github.com/WhaleShark-Team/cobra
+
+这样，黑盒和白盒扫描搭配起来，就可以对内外部的服务和系统进程进行全方位的保障了。
+
+6.WAF，Web Application Firewall
+
+WAF用来对外部的Web服务进行保护。我们知道，对于业务系统来说，通常会有很多不正规的渠道来网站爬取各种信息，更有甚者会通过模拟用户行为来注册大量虚假账号，以此来领取各种优惠，或者提交大量虚假订单、评论等等，同时还会对服务器负载造成很大压力。对于这种恶意行为，就需要由WAF来保护，通过一定的业务规则配置和识别来阻止恶意访问。
+
+7.应急响应中心SRC
+
+在安全界，有这样一个不成文的说法，叫作三分靠技术，七分靠人脉，也就是安全的信息情报有时比单纯的技术攻防要重要得多。对于企业来说，除了要能够招聘到一些安全圈内的专业人士，另一方面，也要有对外公开的应急响应中心SRC，以此来聚集一些比较友好和善意的白帽子，通过他们主动发现一些网站和系统的漏洞，并能够通过SRC提交给公司安全部门。同时，作为企业也会有一些不同形式的奖励，比如奖金和纪念品这样的物质奖励，或者漏洞提交排名这样名誉上的认可，以此来形成更长久和深入的合作。
+
+同时，SRC也能弥补一些我们主动做的，但是防护措施不到位的情况，最大程度地借助社区和圈子的力量，共同保障企业网站、信息和数据的安全。
+
+上述我们提到的很多检测和限制规则，都会通过规则平台沉淀下来，这个就类似于我们的之前讲到的配置管理。
+
+最后，以一张图作为总结，来整体呈现我们的安全体系。也欢迎你给我留言继续讨论。
+
+
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/32为什么蘑菇街会选择上云？是被动选择还是主动出击？.md

@@ -0,0 +1,129 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            32 为什么蘑菇街会选择上云？是被动选择还是主动出击？
+                            2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。
+
+云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。
+
+但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
+
+最近，有很多同行对我们为什么做这个选择比较感兴趣。因为尽管混合云模式是当下的大趋势，但真正面临抉择时，又总会被各种具体的细节问题所困扰，犹豫不决。
+
+今天，我从蘑菇街的视角，结合真实情况，聊一聊我们为什么会做出上云这个选择。
+
+我们所面临的问题
+
+1.成本闲置问题
+
+对于电商，大促已经常态化，除了“双11”“双12”以及“6·18”这样的例行大促，每个电商还会有自己的营销活动，比如我们就会有“3·21”春季促销，以及每个月不同的主题促销。这一点对于其它电商也是如此。
+
+大促，从技术层面就意味着要在短时间内应对远远超过日常的峰值流量，可能是平时的十几倍，甚至是上百倍。为了支撑这么大的流量，就需要业务系统有足够的容量支持。
+
+虽然我们会从技术和架构层面来提升容量，但是，无论如何优化，充足的硬件资源扩容是前提条件。
+
+之前，我们在应对“双11”这样的大促时，只能采购更多的设备。与此同时，我们还要在机柜成本以及资源上下架等纯人工方面进行投入，这往往要花费几千万元的成本。
+
+但是，每次大促峰值一过，这些设备基本就处于极低的负载状态。这批资源要经过将近一年时间，随着业务量快速增长才能逐步消化掉，然后再进入到下一轮大促的采购周期中。
+
+所以，这部分成本投入的收益是非常低的，基本处于闲置状态。
+
+2.基础设施维护问题
+
+选择租用或托管IDC模式，随着业务量增长也会遇到一系列的问题。在我以往的实践操作中，我也遇到了以下几个问题，相信你也有过相似的困扰。
+
+IDC机房的选址。在中国互联网八大节点所在城市的IDC资源无疑是最优的，但是这些地方的优质资源却也是最紧张的。通常会被国内各大互联网公司或云计算公司提前占据，所以很难找到相对独立且成规模的机柜区域，而零散的机柜分布对管理和维护工作来说十分不便。
+
+退而求其次，就只能选择二级或三级节点，但是这样一来在网络质量上就降了一个或多个等级。同时，因为没有BGP线路，或者线路质量不高，就需要多线接入，这对业务体验以及管理维护都会带来很大影响。
+
+IDC机房的扩展问题。一个机房内的机柜消耗完，想扩展就只能另找机房，但是属于同一运营商，或同一ISP服务商的同城机房资源是否充足，又是一个未知数。
+
+不同机房间是否互联互通，以及是否增加跨地域的时延，对业务访问体验的影响很大。所以扩展性不足，会大大影响业务体验，甚至影响业务发展。
+
+如果是通过第三方ISP接入的，特别是存在多个ISP服务商的时候，在互联互通时，服务商之间的沟通协调非常耗费精力，且不同机房以及多ISP之间的专线成本也会增加。当基础设施达到一定体量，这个问题会非常突出。
+
+如果你也有过这方面的经历，相信你一定深有体会。
+
+资源利用率问题。即使我们做了虚拟化，按照业界实际情况，CPU资源使用率一般也就在10%-15%左右。所以要想大幅提升使用率，就是要在离线的混部，也就是类似大数据消耗资源特别高的计算类业务上进行资源调配：比如，在凌晨调度到相对空闲的应用服务器上；而在白天，则将资源释放出来给业务应用。
+
+但是，想要在离线混部技术上做文章，说起来容易做起来难，因为这在实际工作中是需要非常深厚的技术积累和非常高的技术门槛的。
+
+业务层面的调度是一方面，另一方面，底层硬件、网络以及操作系统这些也需要相应的技术支持。这其中具体的复杂情况，你可以通过阿里最近在这方面的一些分享体会一下。
+
+单考虑操作系统之上的应用和业务技术是无法满足要求的，所以，这就需要我们在进行技术规划时，在开始底层建设之前就要考虑全面。
+
+我们知道，国内外超大型的互联网公司，以及各大云计算公司，在硬件选型上都有自己的定制化要求。其中一个重要原因，就是为了尽量保持几万甚至十几万硬件设备的系统架构一致，从底层硬件开始就为后续的超大规模运维做技术准备。
+
+当然，这样的定制化需求，只有在需求量足够大的情况下才会被硬件厂商接受，一般如果只有百台或千台的规模，硬件厂商基本是不会考虑的。
+
+所以这就会牵扯出下面这个问题。
+
+3.底层技术投入和人才的问题
+
+通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂分布式存储如Ceph等等的专业人才。
+
+但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。
+
+人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
+
+当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像蘑菇街和美丽说这样以更加聚焦于业务，以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
+
+对于以技术创业为主的公司，其考量的出发点就完全不同了，这里我们不展开讨论。
+
+进一步讲，论体量和规模，我们自有的底层技术无论如何是无法与专业的云计算公司相比的，这就带来另一个问题：如何为这些优秀人才提供成长和发展？因为既然在体量和规模上比不过，那我们能够提供的个人成长空间和机会，一定也比不过专业云计算公司。这种情况下，大部分人才的去向选择就显而易见了。
+
+对于大数据，分布式中间件等岗位，也会存在类似的情况，因为它们大多需要体量和规模才能体现技术挑战性和成长空间。
+
+4.小结
+
+到这里我们做个小结，随着基础设施体量越来越大，我们在基础设施和平台服务层面，将会投入越来越大的财力、人力和最宝贵的精力。
+
+但是这项投入的收益和成效却不明显，且在这个层面的专业性上，我们与云计算平台之间的差距越来越大，脱节也越来越严重。
+
+我们的决策过程就是，以未来3-5年，甚至更长远的视角考量，我们认为上述这些问题一定会成为我们将来业务发展的障碍，因此上云就成了我们的不二选择，并成为公司的战略决策之一。
+
+纵观技术发展趋势
+
+1.从软件架构发展的趋势上看，从最早期的物理机，到目前主流的虚拟机，再到当前非常火热的Docker，以及可能在未来会成为又一主流的Serverless，我们对于资源层面的依赖越来越少，而这个趋势恰恰是云计算不断发展带来的改变。
+
+
+
+同时，像Serverless这样的技术理念，就是在公有云平台上，为了提升资源利用率，而衍生出来的。而且从目前看，Serverless也只有在公有云平台上才有意义。在私有云，或者是自建或托管IDC中，因为资源规模问题，没有看到太多的实践价值。
+
+2017年AWS re:Invent 2017峰会上，AWS共发布了在数据库、容器、人工智能、物联网以及网络等等方面的几十项新的产品技术服务。可以说，如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
+
+2.人工智能对云计算能力的释放。我们当前的人工智能主要是对机器学习算法的广泛应用，这里的两个前提条件，一个是要有足够大的数据量，另一个就是要有足够充足的计算资源。
+
+我们先看一个2017年的新闻：
+
+
+2017年5月份，谷歌宣布麻省理工学院的数学教授安德鲁·V·萨瑟兰使用抢占式虚拟机实例，在220000个GCE核心上运行了庞大的数学工作负载。据称这是迄今为止在公共云上运行的最庞大的高性能计算集群。
+
+
+计算任务阶段性的运行对资源需求是非常庞大的，一般企业很难提前预留足够的资源来做这个事情，这时云的资源优势和弹性能力就凸显出来了。
+
+可以说，未来人工智能的发展和应用，必然会依托于云计算。
+
+没有银弹
+
+软件工程中，我们一直在讲，没有银弹。前面我们介绍了我们遇到的一些具体问题，以及云计算的优势所在，但是没有银弹这条规律，仍然也适用于云计算行业。
+
+那么，是不是有了云计算，有了公有云，上述我们所说的问题就都不存在了呢？
+
+以公有云为例，它也一样会遇到IDC建设、扩展性以及基础技术投入等等问题，可能也会给我们带来一定的影响。但是对于公有云来说，因为自身财力和人力的优势，面对这样的问题会更容易解决一些，但对于我们可能就是难以逾越的难题了。
+
+同时，公有云虽然解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍然有很长的路要走，比如不同形态业务的差异化支持和服务问题。
+
+我想，这一点并不是云计算厂商不想做好，因为无论在技术、产品以及服务上，它们并不是一蹴而就的，而是各方面都需要一个逐步积累、磨合和摸索的过程，这就需要云计算厂商与业务客户共同努力，朝着同一个目标前进，需要彼此多一些耐心。
+
+我们也期望在国内见到AWS和Netflix这样的最佳组合，相互成就，共同成功。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/33为什么混合云是未来云计算的主流形态？.md

@@ -0,0 +1,129 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            33 为什么混合云是未来云计算的主流形态？
+                            2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。
+
+云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。
+
+但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
+
+最近，有很多同行对我们为什么做这个选择比较感兴趣。因为尽管混合云模式是当下的大趋势，但真正面临抉择时，又总会被各种具体的细节问题所困扰，犹豫不决。
+
+今天，我从蘑菇街的视角，结合真实情况，聊一聊我们为什么会做出上云这个选择。
+
+我们所面临的问题
+
+1.成本闲置问题
+
+对于电商，大促已经常态化，除了“双11”“双12”以及“6·18”这样的例行大促，每个电商还会有自己的营销活动，比如我们就会有“3·21”春季促销，以及每个月不同的主题促销。这一点对于其它电商也是如此。
+
+大促，从技术层面就意味着要在短时间内应对远远超过日常的峰值流量，可能是平时的十几倍，甚至是上百倍。为了支撑这么大的流量，就需要业务系统有足够的容量支持。
+
+虽然我们会从技术和架构层面来提升容量，但是，无论如何优化，充足的硬件资源扩容是前提条件。
+
+之前，我们在应对“双11”这样的大促时，只能采购更多的设备。与此同时，我们还要在机柜成本以及资源上下架等纯人工方面进行投入，这往往要花费几千万元的成本。
+
+但是，每次大促峰值一过，这些设备基本就处于极低的负载状态。这批资源要经过将近一年时间，随着业务量快速增长才能逐步消化掉，然后再进入到下一轮大促的采购周期中。
+
+所以，这部分成本投入的收益是非常低的，基本处于闲置状态。
+
+2.基础设施维护问题
+
+选择租用或托管IDC模式，随着业务量增长也会遇到一系列的问题。在我以往的实践操作中，我也遇到了以下几个问题，相信你也有过相似的困扰。
+
+IDC机房的选址。在中国互联网八大节点所在城市的IDC资源无疑是最优的，但是这些地方的优质资源却也是最紧张的。通常会被国内各大互联网公司或云计算公司提前占据，所以很难找到相对独立且成规模的机柜区域，而零散的机柜分布对管理和维护工作来说十分不便。
+
+退而求其次，就只能选择二级或三级节点，但是这样一来在网络质量上就降了一个或多个等级。同时，因为没有BGP线路，或者线路质量不高，就需要多线接入，这对业务体验以及管理维护都会带来很大影响。
+
+IDC机房的扩展问题。一个机房内的机柜消耗完，想扩展就只能另找机房，但是属于同一运营商，或同一ISP服务商的同城机房资源是否充足，又是一个未知数。
+
+不同机房间是否互联互通，以及是否增加跨地域的时延，对业务访问体验的影响很大。所以扩展性不足，会大大影响业务体验，甚至影响业务发展。
+
+如果是通过第三方ISP接入的，特别是存在多个ISP服务商的时候，在互联互通时，服务商之间的沟通协调非常耗费精力，且不同机房以及多ISP之间的专线成本也会增加。当基础设施达到一定体量，这个问题会非常突出。
+
+如果你也有过这方面的经历，相信你一定深有体会。
+
+资源利用率问题。即使我们做了虚拟化，按照业界实际情况，CPU资源使用率一般也就在10%-15%左右。所以要想大幅提升使用率，就是要在离线的混部，也就是类似大数据消耗资源特别高的计算类业务上进行资源调配：比如，在凌晨调度到相对空闲的应用服务器上；而在白天，则将资源释放出来给业务应用。
+
+但是，想要在离线混部技术上做文章，说起来容易做起来难，因为这在实际工作中是需要非常深厚的技术积累和非常高的技术门槛的。
+
+业务层面的调度是一方面，另一方面，底层硬件、网络以及操作系统这些也需要相应的技术支持。这其中具体的复杂情况，你可以通过阿里最近在这方面的一些分享体会一下。
+
+单考虑操作系统之上的应用和业务技术是无法满足要求的，所以，这就需要我们在进行技术规划时，在开始底层建设之前就要考虑全面。
+
+我们知道，国内外超大型的互联网公司，以及各大云计算公司，在硬件选型上都有自己的定制化要求。其中一个重要原因，就是为了尽量保持几万甚至十几万硬件设备的系统架构一致，从底层硬件开始就为后续的超大规模运维做技术准备。
+
+当然，这样的定制化需求，只有在需求量足够大的情况下才会被硬件厂商接受，一般如果只有百台或千台的规模，硬件厂商基本是不会考虑的。
+
+所以这就会牵扯出下面这个问题。
+
+3.底层技术投入和人才的问题
+
+通常在互联网领域，越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂分布式存储如Ceph等等的专业人才。
+
+但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。
+
+人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
+
+当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像蘑菇街和美丽说这样以更加聚焦于业务，以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
+
+对于以技术创业为主的公司，其考量的出发点就完全不同了，这里我们不展开讨论。
+
+进一步讲，论体量和规模，我们自有的底层技术无论如何是无法与专业的云计算公司相比的，这就带来另一个问题：如何为这些优秀人才提供成长和发展？因为既然在体量和规模上比不过，那我们能够提供的个人成长空间和机会，一定也比不过专业云计算公司。这种情况下，大部分人才的去向选择就显而易见了。
+
+对于大数据，分布式中间件等岗位，也会存在类似的情况，因为它们大多需要体量和规模才能体现技术挑战性和成长空间。
+
+4.小结
+
+到这里我们做个小结，随着基础设施体量越来越大，我们在基础设施和平台服务层面，将会投入越来越大的财力、人力和最宝贵的精力。
+
+但是这项投入的收益和成效却不明显，且在这个层面的专业性上，我们与云计算平台之间的差距越来越大，脱节也越来越严重。
+
+我们的决策过程就是，以未来3-5年，甚至更长远的视角考量，我们认为上述这些问题一定会成为我们将来业务发展的障碍，因此上云就成了我们的不二选择，并成为公司的战略决策之一。
+
+纵观技术发展趋势
+
+1.从软件架构发展的趋势上看，从最早期的物理机，到目前主流的虚拟机，再到当前非常火热的Docker，以及可能在未来会成为又一主流的Serverless，我们对于资源层面的依赖越来越少，而这个趋势恰恰是云计算不断发展带来的改变。
+
+
+
+同时，像Serverless这样的技术理念，就是在公有云平台上，为了提升资源利用率，而衍生出来的。而且从目前看，Serverless也只有在公有云平台上才有意义。在私有云，或者是自建或托管IDC中，因为资源规模问题，没有看到太多的实践价值。
+
+2017年AWS re:Invent 2017峰会上，AWS共发布了在数据库、容器、人工智能、物联网以及网络等等方面的几十项新的产品技术服务。可以说，如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
+
+2.人工智能对云计算能力的释放。我们当前的人工智能主要是对机器学习算法的广泛应用，这里的两个前提条件，一个是要有足够大的数据量，另一个就是要有足够充足的计算资源。
+
+我们先看一个2017年的新闻：
+
+
+2017年5月份，谷歌宣布麻省理工学院的数学教授安德鲁·V·萨瑟兰使用抢占式虚拟机实例，在220000个GCE核心上运行了庞大的数学工作负载。据称这是迄今为止在公共云上运行的最庞大的高性能计算集群。
+
+
+计算任务阶段性的运行对资源需求是非常庞大的，一般企业很难提前预留足够的资源来做这个事情，这时云的资源优势和弹性能力就凸显出来了。
+
+可以说，未来人工智能的发展和应用，必然会依托于云计算。
+
+没有银弹
+
+软件工程中，我们一直在讲，没有银弹。前面我们介绍了我们遇到的一些具体问题，以及云计算的优势所在，但是没有银弹这条规律，仍然也适用于云计算行业。
+
+那么，是不是有了云计算，有了公有云，上述我们所说的问题就都不存在了呢？
+
+以公有云为例，它也一样会遇到IDC建设、扩展性以及基础技术投入等等问题，可能也会给我们带来一定的影响。但是对于公有云来说，因为自身财力和人力的优势，面对这样的问题会更容易解决一些，但对于我们可能就是难以逾越的难题了。
+
+同时，公有云虽然解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍然有很长的路要走，比如不同形态业务的差异化支持和服务问题。
+
+我想，这一点并不是云计算厂商不想做好，因为无论在技术、产品以及服务上，它们并不是一蹴而就的，而是各方面都需要一个逐步积累、磨合和摸索的过程，这就需要云计算厂商与业务客户共同努力，朝着同一个目标前进，需要彼此多一些耐心。
+
+我们也期望在国内见到AWS和Netflix这样的最佳组合，相互成就，共同成功。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/35以绝对优势立足：从CDN和云存储来聊聊云生态的崛起.md

@@ -0,0 +1,99 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            35 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
+                            前面几期文章我们介绍了混合云模式，以及面向应用层的云架构解决方案的Spring Cloud。接下来，我们就以蘑菇街的两个具体案例，来分享一下基于混合云模式的具体实践。
+
+今天，我们先一起看一下我们最为熟悉的CDN和云存储建设。
+
+CDN和云存储
+
+我们之前提到，CDN应该算是最早期、最典型的公有云服务，如果我们在业务上用到了CDN服务，其实就已经算是在实践混合云模式了。
+
+蘑菇街作为ToC的电商业务，自然会有大量的图片访问需求，其中尤以商品图片为最。为了保证用户体验，我们的产品在2011年上线之初，就应用了CDN技术，当时我们合作的都是专业的CDN厂商。
+
+当然，大量的图片访问需求会带来大量的图片存储需求，且随着业务高速发展，这个需求量必然会极速增长。
+
+图片的访问需求量往往会以几百万、几千万、几亿到几十亿、上百亿的增长态势呈现。而它所占用的存储空间也会从G扩展到T，到几十T、几百T，再到后来的P级别。
+
+所以，起初我们在业务量不大的时候，还可以把图片存在自己的硬件设备上。再往后可以利用HDFS这样的对象存储技术来实现，CDN回源的请求全部回到我们自己的机房里。
+
+但是再往后，我们在这方面的专业性就不够了。这也是我在[《为什么蘑菇街会选择上云？是被动选择还是主动出击？》]一文中介绍到的：随着体量的增加，CDN对于专业技术深度的要求就越来越高，技术层面的投入也会越来越大，这个就与我们的业务发展诉求不一致了。
+
+因为对于蘑菇街来说，我们还是期望能够把更多的人力和物力应用到业务技术层面，而不是一味耗费在专业技术研究上。
+
+在2013年左右，业界开始出现专业的云存储厂商。在专业技术层面要比我们精深很多，而且他们聚拢了一大批业界专业人才，积累了各类海量存储场景的实践经验，所以他们在产品研发和服务支持上也是能够持续深入的。
+
+基于此，我们后来就选择了将海量的图片放到专业性更强的云存储之上。
+
+到这个阶段，我们的图片访问和图片存储就近乎完全依赖外部第三方的服务，同时也形成了CDN回源访问云存储这样的云应用模式。
+
+再往后发展，随着国内两大公有云巨头腾讯云和阿里云相继杀入CDN市场，这对传统的CDN厂商和新兴的云存储业务造成了很大的冲击。但究其主要原因，我认为还是由于云生态的规模优势发挥了作用。
+
+云生态的优势
+
+上面讲到，我们使用的CDN是专业的CDN厂商业务，但在当时它们并不提供云存储业务。
+
+同时，专业的云存储厂商固然在存储技术上更擅长，加上它们大多属于创业公司，也没有太多的财力和人力再杀入CDN市场。
+
+所以，这两块紧耦合的业务实际是由两类不同的公司在独立发展。但是，在阿里云和腾讯云这样的公有云巨头进入市场后，就极大地改变了这样一个格局。
+
+因为阿里和腾讯各自都有遍布全球的超大规模的自有业务，在CDN、存储技术以及资源上也有很深厚的积累。当公有云蓬勃发展起来之后，这样的技术和资源积累就可以从内部通过云平台输出给公有云的用户。
+
+那么，阿里云和腾讯云这种公有云模式有哪些优势呢？我们将CDN模式与其对比来看。
+
+1.技术层面。CDN模式下，图片上传云存储以及CDN回源云存储，基本都是走公网网络，在国内复杂的网络条件下，传输质量就很难保障。
+
+我记得2015年我来到蘑菇街接手运维的时候，就经常会遇到网站图片展示不出来或者打开特别慢的情况。这就需要找不同的CDN厂商定位一些个例问题，非常耗时且麻烦，令人头痛。
+
+在这种形态下，因为是不同厂商间的协作，所以问题只能在小范围内优化，无法从根本上得到改善。但是，在以阿里云和腾讯云为代表的公有云模式下，这个问题就会迎刃而解。
+
+因为阿里和腾讯这两大巨头各自都有全球规模的业务体量，为了保证自身业务的访问体验，它们一定会在CDN和存储技术的优化、整合上下足工夫，因此更具备自我改进的动力。
+
+尤其是上面我们提到的上传和回源过程，在公有云模式下基本都有专线质量保障。即使没有专线，他们也会不断优化中间的线路质量。
+
+上云后我们最明显的感受，就是上传和回源图片的成功率和速度都有非常大的改善，近一年来，我很少再碰到像图片展示慢这类问题了。
+
+2.成本层面。主要包括三块费用：
+
+
+CDN带宽费用。用户访问带来的CDN流量费用，由各CDN厂商收取。对于传统CDN厂商，之前价格相对固定和平稳，但是近两年公有云厂商入局后不断降价，在价格上有非常大的竞争优势，这也整体拉低了CDN价格。
+回源带宽费用。当CDN无法获取到对应图片时，回源到云存储获取，这部分回源带宽费用由云存储厂商收取。但是在云生态模式下，上面提到，CDN和云存储可以整合到某个公有云内部网络体系内，在这个生态中，这部分费用成本就变得非常低了。
+存储空间费用。这一项费用由云存储厂商收取，CDN和公有云这两种模式在这一点上没有太大区别。
+
+
+还有其他诸如裁图、HTTPS等服务，都分别会有不同的计费方式，但是这块不是主要成本。
+
+说到这里，我们从整体的商务角度看一下：如果一位客户在同一个地方购买的服务和资源越多，那么商务运作和议价空间就会越大，得到的优惠力度也会更大。这就跟我们在同一家商店买的东西越多、折扣越多是一个道理。
+
+但是，如果这些服务和资源都是不同厂商的，那就需要多方面沟通。整个过程耗时耗力，且能够得到的优惠空间也非常有限。
+
+所以，整体来看，云生态在CDN和云存储这个层面，实实在在地帮我们降低了成本。
+
+3.生态优势，强者越强。云生态的天然优势在于，云平台上聚集了海量的客户资源，只要进入到这个生态中，一般情况下客户都会首选生态内的产品，而不会再跳出去选择其它独立的产品服务。
+
+甚至即使之前用到了第三方的服务，客户也会逐渐转移回云平台这个生态体系中来。
+
+所以，我们现在可以看到这样一种趋势：很多独立的技术产品，正在向云生态靠拢，选择跟公有云合作，争取让产品进入到某个云生态中，并提供相应的云上解决方案和技术支持。
+
+同时，各大巨头也会寻找在某些特定领域，有相当深度的技术产品进行投资，让这些好的产品和解决方案进入到自己的云生态中，以便进一步为云上的客户提供更全面、灵活和多样性的支持。
+
+总结
+
+通过CDN和云存储这个案例，我们可以清晰地看到，随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云已经形成了自有的、独特的生态体系。
+
+这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。
+
+所以，利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。
+
+以上分享的这些内容，是我在近两年的工作中真切经历过的案例和感受，希望能在思路拓展上对你有所帮助。
+
+如果你在这方面有什么好的经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/36量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设.md

@@ -0,0 +1,115 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            36 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
+                            上期文章中我们介绍了CDN和云存储的实践，以及云生态的崛起之路，今天，我们继续聊一聊CDN。
+
+我们通常意义上讲的CDN，更多的是针对静态资源类的内容分发网络，最典型的就是电商的各类图片，还有JS和CSS这样的样式文件。通过CDN能够让用户就近访问，提升用户体验。
+
+但是这类文件只是以单纯的资源存在，与业务逻辑没有强关联。所以我们在技术上，可以使用业界通用的CDN和云存储解决方案。
+
+需要注意的是，本文中我们讲到的实践内容，同样是遵从静态内容，就近访问这个原则的。
+
+但是，因为其中包含了大量的业务逻辑，这就要求我们在面对不同的场景时，要有跟业务逻辑相关的定制化的解决方案。
+
+下面，我们就一起来看看页面静态化架构和二级CDN建设。
+
+静态化架构建设的业务场景
+
+我们仍然回到电商的业务场景中来。对于电商，访问量最大的无疑是商品的详情页，绝大多数用户都要通过浏览商品详情，来决定是否下单。所以单就这一类页面，就占到全站30%+的流量。
+
+那么，商品详情一般由哪些部分组成呢？我们看下面两个截图：
+
+
+
+
+
+以上两张图就是某个商品详情页的主要组成部分。我们可以看到，商品详情大致包括了商品名称、商品描述、产品参数描述、价格、SKU、库存、评价、优惠活动、优惠规则以及同款推荐等等信息。
+
+这里我们仔细观察可以发现，其实对于商品描述类的信息，比如商品名称、商品描述、产品参数描述等等，一般在商品发布之后，就很少再变动，属于静态化的内容。
+
+而优惠活动、优惠规则、价格等等则是可以灵活调整的，库存和评价这类信息也是随时变化，处于不断的更新中。
+
+说到这里，我们会想到，如果能够把静态化的内容提取出来单独存放，业务请求时直接返回，而不用再通过调用应用层接口的方式，去访问缓存或者查询数据库，那访问效率一定是会大幅提升的。
+
+所以，我们在参考和调研了业界的解决方案之后，引入了页面静态化架构。
+
+页面静态化架构
+
+静态架构中，我们采用的技术方案是ATS，也就是Apache Traffic Server。
+
+ATS是一个开源产品，本质上跟Nginx、Squid以及Varnish这样的HTTP反向代理是一样的。但是它能对动静态分离的场景提供很好的支持，所以在最初，我们直接引入了这样的开源解决方案。
+
+ATS的架构示意图如下：
+
+
+
+关键技术点：
+
+
+动静态分离。将页面上相对固定的静态信息和随时在变化的动态信息区分出来，静态信息直接在ATS集群获取，动态信息则回源到应用层。通过HTTP请求调用获取，最终通过ATS组装后返回给调用方，从而实现了动静态资源的分离。
+动态数据获取。直接采用ATS的ESI标签模式，用来标记那些动态的被请求的数据。
+失效机制。分为主动失效、被动失效和定时失效。对于静态信息来说，我们也允许它变化，但因为静态信息自身的特性，决定了它不会频繁变化。所以，我们会有一个失效中心，即Purge Center。失效消息通过HTTP的Purge方法发送给ATS，而失效中心则会通过订阅消息系统中特定的Topic，或者MySql中特定的binlong变更，执行失效。
+
+
+以上就是静态化建设的框架性的解决方案，这个方案在电商大促时往往能够发挥更加突出的作用。下面我就简单说明下。
+
+静态化架构在大促场景中的应用
+
+我们还是以业务场景作为切入点来看。以“双11”为例，参与大促的商家和商品，一般会在11月初完成全部报名。届时所有的商品信息都将确认完毕，且直到“双11活动”结束，基本不会再发生大的变化。
+
+它跟平时的不同之处在于，商品在大促期间是相对固定的，所以就可以将商品的静态化信息提前预热到ATS集群中，大大提升静态化的命中率。
+
+同时，价格、优惠、库存这些动态信息在日常是会经常变化的，但是在大促阶段是必须固定的。即使有变化，也只能体现在最终的订购阶段，而在用户浏览阶段尽量保持不变。
+
+所以，这时可做静态化处理的内容就会更多。换言之，静态化架构对于后端的访问请求就会进一步减少，特别是价格、优惠和库存这样的查询计算类请求。
+
+同时，我们静态化页面的范围可以更广，不仅仅是详情页，还可以包括各类大促活动的页面、秒杀页面、会场页面，甚至是首页。
+
+因为这些页面都是提前配置好再发布的，所以我们完全可以通过静态化解决方案，来分担更大的流量。
+
+以详情页为例。在静态化方案全面铺开推广后，静态化内容在大促阶段的命中率为95%，RT时延从原来完全动态获取的200ms，降低到50ms。这大大提升了用户体验，同时也大幅提升了整体系统容量。
+
+静态化方案和应用场景我们就介绍到这里。你可能会问：既然是静态化的内容，那是不是仍然可以借鉴CDN的思路，让用户就近访问呢？
+
+我们下面就介绍一下页面静态化与公有云相结合的方案：二级CDN建设。
+
+二级CDN建设
+
+上面我们提到的静态化方案，仅仅是我们自己中心机房的建设方案，也就是说，所有的用户请求还是都要回到中心机房中。
+
+静态化方案提升的是后端的访问体验，但是用户到机房的这段距离的体验并没有改善。
+
+从静态化的角度，这些内容我们完全可以分散到更多的地域节点上，让它们离用户更近，从而真正解决从用户起点到机房终点的距离问题。
+
+所以，我们接下来的方案就是：选择公有云节点，进行静态化与公有云相结合的方案，也就是我们的二级CDN方案。简单示意如下：
+
+
+
+引入了这样的二级CDN架构后，下面几个技术点需要我们多加关注。
+
+
+回源线路，公网回源转变为专线回源。之前我们的中心机房还是托管IDC模式时，动态回源部分都是通过公网回源，同时，静态化配置的推送也是通过公网推送到公有云节点，这对成功率和访问质量上都会有一些影响。但是我们上云之后，做的第一件事情就是将公网访问模式调整成了内网调用模式，也就是动态回源直接改为专线的动态回源。这样大大提升了访问质量，且进一步节省了部分带宽费用。
+弹性伸缩。利用了公有云节点之后，在大促时就可以很方便地进行动态扩缩容，以便真正地按需使用。而且自动化的扩缩容，以及日常的静态化配置推送都需要完善。
+高可用保障。为了保障多节点的高可用，在单个节点故障时，要能够快速切换。当前我们的策略仍然是，当某个节点遭遇故障，直接全部切换回中心节点。这里为了能够达到快速切换的目的，需要通过HttpDNS这样切换IP的方式实现。因为DNS缓存生效周期较长，如果是通过域名切换，则造成的影响周期会比较长。
+
+
+总结
+
+今天分享的页面静态化架构方案和二级CDN方案，是我在实际工作中较早跟公有云方案相结合的实践之一，并且在我们的日常和大促活动中，起到了非常好的效果。
+
+同时也可以看到，我们的业务一旦与公有云相结合，云生态的各种优势就会马上体现出来。但是无论选择哪种方案，都要结合具体的业务场景，才能作出最优的方案选择。
+
+公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。
+
+正如我之前提到的：只有挖掘出对业务有价值的东西，我们的技术才会有创新，才会有生命力。
+
+如果你在这方面有好的实践经验和想法，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/37云计算时代，我们所说的弹性伸缩，弹的到底是什么？.md

@@ -0,0 +1,57 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            37 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
+                            现在，我们经常听到的一些高大上的词汇，比如弹性伸缩、水平扩展和自动化扩缩容等等，你能否说一说，这些技术手段的主体是谁，也就是谁的水平扩展？弹性伸缩的是什么？同时，这些名词之间又有什么关系呢？
+
+下面我们就从弹性伸缩入手一起来分析讨论。
+
+弹性伸缩的主体是谁？
+
+弹性伸缩，一说到这个词，我们可能很自然地会联想到资源的弹性伸缩，服务器的弹性伸缩，容量的弹性伸缩，应用的弹性伸缩以及业务的弹性伸缩等等。我想这些理解都没有错误，但是可以发现，当弹性伸缩这个动词前面增加了这么多不同的主语之后，我们一下子就不知道到底该做什么了。
+
+其实有这样的困惑很正常。我们在讲标准化的时候就提到，做运维和做架构的思路是相通的，我们碰到问题后，一定要找到问题的主体是什么，通过问题找主体，通过主体的特性制定问题的解决方案。
+
+对于运维，一定要准确识别出日常运维过程中不同的运维对象，然后再进一步去分析这个对象所对应的运维场景是什么，进而才是针对运维场景的分解和开发。
+
+这里可以看到，弹性伸缩其实是一个运维场景，但是我们并没有定义这个场景的主体是谁，所以就会出现上面这些不同的主体。我们来假设以下几种主体。
+
+
+服务器的弹性伸缩。针对这个场景，假设业务是运行在私有云或公有云上，那我们只要能够通过云平台的API申请和释放资源，申请时初始化我们的操作系统，释放时销毁资源就可以。不过，在私有云环境下，为了能够保障弹性，我们必须自己提前采购、上架、装机、配置然后交付资源，需要大量的准备工作，公有云上就可以省去这些步骤，可以即拿即用。
+应用的弹性伸缩。这个场景下其实是默认包含第一步的，就是我们首先必须要拿到应用运行的服务器资源才可以，这一步做到了，下面就是应用的部署、启动以及服务上线接入流量。
+业务的弹性伸缩。我们可以再进一步思考，通常一个业务可能会包括多个应用，所以为了保障整个业务容量充足，这个时候扩容单个的应用是没有意义的，所以这时要做的就是扩容多个应用，但是这里面就会有一个顺序问题，先扩哪个，后扩哪个，哪些又是可以同时扩容而不会影响业务正常运行的，再进一步，业务承载的服务能力提升了，那网络带宽、缓存、DB等等这些基础设施需不需要也同时扩容呢？
+
+
+到这里，这个问题就已经变得非常复杂了，而且已经不仅仅是弹性伸缩这个词的表面含义所能覆盖的了，因为这个问题确实很复杂，所以这里暂时不做详述。
+
+好了，分析到这里，我们就可以看到针对不同的运维对象，弹性伸缩这个概念背后的含义是不一样的，所执行的动作以及制定的方案也是不一样的。通过上面的分析过程，我们在日常思考和工作开展中应该注意以下两点。
+
+第一，一定是从实际问题出发，找到问题的主体，然后才是针对问题的解决方案。要反复问自己和团队，我们解决的问题是什么？解决的是谁的问题？切记，一定不要拿着解决方案来找问题，甚至是制造问题。
+
+比如弹性伸缩这个概念，它就是解决方案，而不是问题本身，问题应该是：业务服务能力不足时，如何快速扩容？业务服务能力冗余时，如何释放资源，节省成本？按照这个思路来，我们自然就提炼出业务服务能力这个主体，面对的场景是快速的扩缩容，然后针对场景进一步细化和分解。
+
+第二，如果问题处于初期，且是发散状态时，主体可能表现出很多个，这时我们一定要找到最本质的那一个，往往这个主体所涉及的运维场景就包括了其它主体的场景。
+
+比如上面我们看到的业务的弹性伸缩，就包含了应用和服务器的弹性伸缩场景，它们只不过是子场景而已。从这个角度出发，我们的思路才能打开，方案才会全面。不然如果只是聚焦在服务器、应用、DB、网络等等这些非本质的主体上，提供出来的解决方案肯定也是片面的，而且经常会出现这样的情况，每个人都只从自己的角度出发说问题，始终无法达成一致。问题的根本还是我们没有一个共同讨论的基础，结果就是工作没少做，却始终没有解决问题。
+
+弹性伸缩、水平扩展和自动化扩缩容，它们之间的关系是什么？
+
+这个问题，我想已经不言自明了，找到它们的主体和要解决的问题，我们就会发现，其实它们之间的含义是一样的。
+
+总结
+
+今天我们以弹性伸缩为例，讨论了如何思考问题和分析问题。我们的讨论和分析归结到一点就是：独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工作的方向。
+
+现在业界各种技术上的Buzzword（时髦词）层出不穷，让人目不暇接，但是仔细观察和思考，你会发现它们背后常常隐藏着很多共性的特点，一定要抓住它们背后所要解决的问题和本质，这样也就不会乱花渐欲迷人眼了。
+
+而且通过这样的分析，我们会更容易发现工作中还需完善的地方，从而引导我们聚焦到实际问题中来，而不是浮于表面，把一些高大上的词汇挂在嘴边，却不见效果。
+
+关于今天我们讨论的主题，你还有哪些想法和心得，欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/38我是如何走上运维岗位的？.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            38 我是如何走上运维岗位的？
+                            在专栏介绍中，我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。
+
+聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。
+
+我是怎么开始做运维工作的？
+
+我做运维是在加入华为1年后开始的。在华为内部，我从来没有听说过任何贬低运维的说法，反倒是从华为出来，才开始听到一些言论，比如运维背锅、运维层次低等等，当时感觉还有点怪怪的，这一点下面会再详细讲到。
+
+我当时是在华为电信软件部门，大家熟知的短信、彩信、智能网、BOSS计费系统以及运营商客服系统等都是这个部门的产品。我到公司没多久就进入了一个新成立的项目组，为运营商开发一个阅读类互联网产品，因为是工作后参与的第一个正式项目，从需求讨论、方案选型、代码开发到上线这样一路跟来下，几乎倾注了我所有的热情。当时完全是封闭式开发，除了吃饭睡觉，其它时间基本都用在这个项目上，周六日都是泡在公司的。
+
+项目上线之后，基于运营商海量用户的积累，业务量很快就增长上来了，按照惯例，各种系统问题、故障宕机也随之而来了。当时我们团队规模不大，大家也都是齐心协力，出现问题我们总是一群人一起冲上去解决问题。之所以有这样的反应，主要是因为不忍心看到自己和团队一手打造出来的系统出问题。在华为，软件质量的荣誉感胜过一切。
+
+因为我经验尚浅，所以一开始都是跟在后面看着主管和老员工解决，后来对于一些疑难问题，我就会主动要求接过来研究一下，有时候一个问题要研究好几天才会有些眉目，不过也是在这样的一个过程中，随着解决的问题越来越多，经验也就越来越丰富，很快就成长了起来。
+
+再加上我一直是出现问题后，第一个做出响应和冲到最前面的那个人，主管和团队也对我有了足够的信任和认可，也正是因为获得了这样的信任和认可，后来我得到的成长机会就越来越多。
+
+这里就分享一点：
+
+
+要敢于承担责任，敢于表达自己的想法。特别是对于职场新人，只有承担，且敢于承担更多更重要的责任，才能够快速成长起来。一些重要事项，主管肯定是优先安排最稳妥和靠谱的人去做，这个时候老员工的优势会更明显，作为新人或经验尚浅的员工，如果没有积极主动的态度和令人放心的表现，很多好机会往往就与你失之交臂了。
+
+
+当时，我们解决完问题，不仅仅是内部解决完就好了，还要给客户汇报。说简单点，就是把问题原因、处理过程和后续改进措施，用客户能够听懂的表达方式讲出来。一般都是先用邮件发送正式的报告，然后再当面做解释和汇报。当客户不理解、不认可的时候，你就要花更多的时间和精力想办法去表达清楚。
+
+说实话，我当时认为这是非常浪费时间的事情，我想要是把这些时间都花在技术研发上该多好。不过，多年以后回过头来看，这个过程对于培养、提升自己的“软技能”是很有帮助的，主要锻炼了以下几个能力。
+
+
+能站在对方的角度考虑问题，或者说要有服务心态。很简单的一点，你不能拿着一堆晦涩难懂的技术术语去给客户解释，而是得用客户听得懂的业务语言解释。
+文字表达和口头表达能力。不论是书面的还是口头的，表达一件事情都要有清晰的逻辑，把前因后果理顺畅，先有结论，然后分条陈述。我现在能写这么长篇幅的专栏文章，很大程度上也是受益于这个过程中写报告的锻炼。
+从更全面的角度看待问题。有时候有些问题可能不仅仅是技术层面的问题，也可能出在其他方面比如业务逻辑、第三方、用户自身以及信息沟通上。一开始，面对这种问题我都是直接反馈说不是技术问题，跟我们没关系，可以想到这样的回答总是会被客户诟病。慢慢地我才发现，即使问题最终不是由你来解决，也应该全面考虑问题，跟客户一起讨论最终的解决方案，这样才会得到认可。后来我发现这是一个技术人员普遍存在的问题，比如，“我的代码没问题”，“在我的电脑上是好的”等等，其实就是缺乏全面看问题的意识，也是缺少站在对方角度考虑问题的意识。
+首问负责，问题闭环。问题找到你，你就要端到端负责解决，最终要给客户一个满意的答复，即使问题解决不了，也要能够获得客户认可的反馈。而且，如果这个事情是比较复杂的，需要时间和一个过程来解决，一定要在过程中及时反馈，而不是迟迟不响应。一个最常见的反模式就是“这个跟我没关系，你去找谁谁谁吧”，一句话就把客户的满意度给消磨没了。
+
+
+这么多年工作经历下来，我感觉对我个人职业发展帮助最大的，恰恰是上面这些良好的工作习惯，没有这些好习惯的扶持，单纯的技术技能成长很容易遇到瓶颈。而且，如果说技术技能是在不断更迭变化的，上面这些做事的基本原则却可以随时随地迁移使用。趁早养成良好的职业习惯，会对个人发展有巨大的好处。
+
+对这个阶段做个总结，我更愿意承担一些非常具有挑战性的工作，成长得就比较快。同时，在客户层面，我又相对比较愿意表达见解和意见。虽然那个时候没有什么沟通技巧，也没什么表达技巧，甚至有些时候是笨嘴拙舌的，但是，很多时候技巧是次要的，最关键的是要敢于表达，当团队需要这样一个角色时，是不是有人能够站出来承担起这个职责。慢慢地我在客户层面也得到了一定的认可和信任，成为一个真心诚意、关键时刻能靠得住的一个人。通过这样一个阶段，我不但在技能深度上有了积累，在广度上也体现出了明显的优势。
+
+我为什么会把运维当作职业发展的方向？
+
+这个阶段大约也就1年左右，我的主管就开始跟我沟通，由我来组建这个产品的运维团队，把线上运维、稳定性和部分客户沟通工作完全交给我。
+
+可能有些人觉得做运维是很低级的事情，让你做运维就是让你去填坑，其实对于这样的言论以及今天开头提到的什么运维背锅论，我是十分反对的。当然，更多的时候我也不是去解释，而是靠做事情来证明。
+
+说回到当时的事情上，当时主管在跟我沟通独立带一个运维团队时，我的感受不仅仅是晋升层面的喜悦，更多的是因为能够做运维而感到非常自豪。
+
+为什么会非常自豪，这就不得不提到华为内部，在当时来讲，就已经有非常完善和先进的运维体系和运作机制了，我们一起来看一下。
+
+在华为内部，运维是非常受尊重而且非常关键的岗位。如果你在研发团队中一直写代码，没有做过运维工作，是很难晋升高级别岗位的。所以华为的架构师、技术经理甚至是更高级别的研发主管，按照不成文的规定，都默认要在运维团队轮岗过，然后再选拔出来。而且这里面最最关键的是，运维这个岗位不是你想做就能做的，是有条件要求的。
+
+下面我们就来看看有什么样的条件要求。我当时是在华为电信业务软件部，华为的运维体系分为一、二、三线，我们分别来看。
+
+1. 一线维护
+
+这个团队是负责产品的交付服务和后续的客户服务工作。从技能上，很像传统运维，主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理；另一方面，也是非常重要的一点，要对一线客户满意度负责，也就是客户反馈的所有问题，甚至是客户工作中表现出来的喜怒哀乐都要关注。
+
+一线维护，最重要的就是必须要有非常强的服务意识。
+
+2. 二线技术支持
+
+因为一线维护面对的是单个具体的运营商，在遇到一些问题的时候，往往没有经验，但是二线因为要面对某个产品全球的局点问题，所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时，二线有可能就可以很快很好地帮忙解决，而不用直接透传到三线。
+
+同时，二线还要做好统筹协调，因为一线过来的问题不仅仅是产品本身问题，也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题，这就需要二线帮助一线协调专家资源进行处理，而不是一线再一个个找人，这时一线只管反馈问题即可。
+
+二线技术支持，大多由产品研发或者一线维护经验的人员抽调上来的，即使没有这些经验，也要下放到一线去锻炼很长时间，两三年都有可能，所以技术和经验上都相对更加全面，同时能够有较强的推进协调能力。
+
+3. 三线研发维优
+
+到了三线就是研发团队中的运维团队了，这个团队在华为叫做维优团队。这个团队就很牛了，一般都是从开发骨干精挑细选出来的，一方面是为了锻炼人，另一方面也是为了在出现问题时，能够有最专业、能力最强的人响应处理，因为电信级业务是国计民生的基础设施，一般传递到三线的问题，都是比较严重或者疑难的了，必须投入精兵强将第一时间解决问题。
+
+处理问题的过程中，还会不断完善工具体系，提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题，所以7*24响应，而且常年无休，比我们现在互联网运维的工作负荷要大得多，所以这个团队成员一般做个1~2年就会转岗晋升，不然身体肯定是承受不住的。
+
+三线研发维优，这个团队的成员就像军队中的突击队或尖刀连一样，总是冲在最前面，在高压状态下，解决最复杂、最棘手的问题，所以从选拔阶段，就有非常高的要求。最终经过这个团队磨练出来的人，技术能力、沟通协作能力以及全面解决问题的能力，都是非常突出的。自然地，在晋升发展方面就会有更大竞争优势。
+
+上述这样一个非常严密的一、二、三线运维机制和协作体系，各条线各司其职，发挥各自优势作用，串联起了客户、产品和研发整个技术支持体系，基本上就支撑起了华为电信软件在全球局点的技术支持和服务工作，这一点还是很强大的。
+
+也因为各自都有独特的价值体现，所以运维岗位上人员的存在感和成就感就会比较强，当然就不会觉得做运维是很低级的事情。同时，因为人员非常优秀，能力突出，这个岗位得到尊重也是必然的，甚至是令人向往的。
+
+其实，能够得到尊重，还有非常重要的一点，就是来自华为对客户和用户的尊重，真正的把“客户第一”融入到了整个公司的组织架构和运作机制中。
+
+这里我们不做过多发散，理解下来就是谁离客户最近，谁对客户负责，谁就能代表客户，谁就有最大的话语权，甚至是指挥权和决策权。体现在上述我们所说的运维机制上，就是：一线的声音，代表了客户声音；一线反馈到二线的问题，二线必须响应；二线传递到三线的问题，三线必须响应。
+
+当然，问题级别不同，响应效率可以不同。同时，三线可以根据客户现场情况，以及问题严重程度，对问题进行升级，以知会到更高层级的主管进行关注。
+
+在考核上，如果一线提交的问题，最终被定性为二线支持问题，或者三线研发质量问题，那二、三线的全年考核将会受到影响，如果是频繁出现问题，那就会受到严重影响，而且各级主管要承担连带责任。
+
+这套机制的根本目的，还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念，就自然会对质量和问题有敬畏感，研发维优那个时候大多都是远程电话与一、二线沟通，潜意识里就会把一、二线作为他们的客户，同样保持谦卑和尊重。
+
+所以，无论是从对运维的定位上，还是整个公司文化以及运作机制上，都形成了对这个岗位的高度定位和尊重。
+
+说回到我个人，因为当时项目性质的原因（前面提到本质上是一个互联网形态的项目），是高度定制化的，并不是传统电信业务的产品形态，所以当时我们无法直接获得一、二线的支持，所有的运维工作都由研发团队完全独立承担，当时我就是把一、三线的事情都做了，前面很长一段时间是既做开发又做三线维优工作，对我技能上的提升帮助非常大。再往后因为精力有限，在后端维优团队建立起来之后，我就花更多时间做一线工作，贴近客户多一些，这里就对我之前说的职场软技能的提升有很大帮助。
+
+当时华为的三线研发维优，其实很像Google的SRE岗位，各方面能力要求很高，不仅仅是软件开发这么简单，所以当时让我去做运维，并且给到我足够的授权去组建和带团队，就相当于让我去做SRE这样高端的岗位，我自然会觉得非常自豪。
+
+再往后，在这个专业方向上做精做细，形成差异化的优势，自然就会有更大的收获。
+
+给我们的一点启发
+
+这样的一个发展过程并不是我刻意设计过的，机会也不是刻意争取到的，就是平时多做一点，做得认真一点，确保最终能够拿到结果，而且稍微努力一下，尽量拿到比预期好一些的结果。在这个过程中，随着个人能力的提升和全面发展，后续各种机会也就随之而来了。
+
+如果让我总结就是这么平淡无奇，如果让我给出个人发展建议，想要从普通做到优秀的话，就是上面几句话。
+
+岗位上，可能不会跟我一样去做运维，但却一样可以做到优秀的架构师、技术专家、项目经理或产品经理等等，只要你有心即可。
+
+最后，你在个人成长和实际工作中遇到过哪些问题呢，有哪些感悟和心得，欢迎留言和我讨论。如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/39云计算和AI时代，运维应该如何做好转型？.md

@@ -0,0 +1,117 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            39 云计算和AI时代，运维应该如何做好转型？
+                            今天我们来聊一聊，在云计算和AI时代，运维应该如何做好转型？今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题，谈谈我的思考和建议。
+
+我们先来看业界的三个典型案例，一个来自国外，一个来自国内，最后一个是我自己团队的案例，都非常具有代表性。
+
+先看国外Netflix的模式。
+
+Netflix从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到，Netflix内部的运维工作全部都由开发人员完成，平台也由开发自己完成，只保留极少的Core SRE角色专门响应和处理严重等级的故障。类似的还有亚马逊，无论是其电商业务，还是AWS公有云服务，全部都由开发搞定。
+
+这样的团队因为其技术前瞻性，微服务以及分布式这样的技术架构早已落地，再加上其超强的技术能力，所以可以从一开始就这样来做。
+
+再看国内阿里的模式。
+
+阿里技术团队在2016年左右，也开始进行“去PE”的组织架构调整，原来需要PE完成的运维工作，全部由开发承担。原来的PE要么转岗去做工具平台开发，要么作为运维专家做产品规划和设计，还有一部分无法适应调整的PE就只能离开了。之前在业务稳定性保障过程中起到核心作用的PE，随着各类工具平台的逐步完善，在高度自动化之后，最终也只能面临职业和技能上的转型。
+
+这种模式，与Netflix正好相反，也就是一开始技术能力无法满足要求的时候，能靠人就先靠人，然后过程中不断完善各类自动化平台。
+
+最后，再说说我自己的团队，发展过程中的模式。
+
+我大致回顾了一下，发现从去年年初到目前，将近两年的时间里，我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人，我总结了一下主要有两个原因。
+
+第一个原因，随着自动化逐步完善，效率不断提升，单个PE能够支持的业务变得越来越多；同时，很多事情开发都可以自助完成。
+
+第二个原因，我有意识地招聘具备开发能力的人员，他们入职后一方面参与各类平台的开发，另一方面还要定期轮岗做一些运维工作。后来我发现，只要有效进行引导，同时具备运维和开发能力是不成问题的。
+
+所以，结果就是，应用运维的岗位需求已经没有这么强烈了。从趋势上看，跟阿里的发展过程非常相似。不过这个过程，我从来没有刻意地设计过，基本算是顺其自然。
+
+从上面的这几个案例来看，无论哪种情况，就运维来说，随着日常重复的人工操作被逐步自动化之后，如果还是固守原有的工作模式和思路，能做的事情、能够提供的价值，一定会越来越少。终究有一天，我们会面临和阿里PE同样的转型问题，而且这个转型是在可预见的短期内就会到来。
+
+既然预见到了趋势，那下面我们就来谈谈应该如何面对。
+
+应用运维的转型
+
+如果只允许给一条建议的话，我给出的建议就是：学会写代码。
+
+我们早期的运维岗位，基本上都不会对代码能力有很强的要求。所以对这个岗位上的同学来说，这一点就成了技能上最大的短板，也成了后续职业发展的瓶颈限制。
+
+但是，运维行业发展到现在，无论是从趋势上看，还是从我们现在所经历的实际现状来看，单纯靠人力维护的投入越来越无效。
+
+所以，无论是我们做运维转型也好，还是做其它技术转型也好，具备代码开发能力，已经成为一项必备技能。
+
+这里多说一点，我们大多数做运维的同学不具备代码开发能力，并不是自身的能力问题。很多情况下都是因为不够自信，对写代码心存畏惧，担心自己写不好，所以一开始就把自己给限制住了。如果是这样，我给的建议再多也没用，关键还是要靠自己先迈出第一步。
+
+现在我自己的团队中，有很多同事做了多年运维工作后，因为乐于尝试和挑战，很快就可以独立编程，而且因为自身有很多一线运维经历和经验，可以说即懂业务又懂开发，反而比单纯做平台和工具的运维开发更有竞争力。
+
+下面是一些具体的建议。
+
+
+代码开发上，我的建议是可以从Python、PHP或Go这些上手比较简单的语言开始。这里不是写脚本，一定要能够实现完整的业务功能或流程。一开始尝试去做一些简单的工具，实现一些简单的功能，再往后可以通过一些复杂的业务场景深入下去。一旦场景的复杂度高了，就会涉及到更高的开发技能，比如并发、缓存、消息甚至是服务化框架等等。关键是敢于迈出第一步，然后逐步转变。相信我，真的没有那么困难，我身边有太多的优秀转型案例，都是这么过来的。
+提升产品意识。这里不是要求运维同事都成为优秀的产品经理，或者具备很强的产品设计能力，而是一定要有产品意识，只要有这么一点点小转变就会带来大不同。我简单说明一下，我们很多运维同事，甚至是资深级别的，往往还是习惯于处在最末端，前面有什么事情找到我，我就处理什么事情，属于被动响应类型的。但是，如果你有产品意识，能够将你所做的事情整理汇总起来，然后做一下流程上的串联，再把流程中每个环节步骤的功能进行详细描述，同时在梳理的过程中，将一些不合理、不规范的地方进行标准化约定，也就是我们前面说的标准化过程，然后输出的内容就是平台开发所需要的需求分析和产品PRD的雏形了。如果能将所做的事情从单纯的运维操作转化到这个维度，那我们呈现的价值就完全不一样了。
+提升技术运营意识。这一点跟上面类似，简单来说，就是如何根据需求，把承载了标准化和规范体系的工具平台真正落地应用起来。同时，在落地的过程中，通过问题收集和一定的数据分析，然后再回到产品设计和需求实现流程中进行改进，形成一个良性的闭环。
+
+
+在阿里的PE转型过程中，有一部分转型去做效能工具研发，有一部分经验丰富的资深运维就转型去做了技术产品和技术运营这样的运维专家角色。对于开发人员已经可以自助完成的部分一线运维工作，运维专家还会在这个过程中对开发做一些赋能。
+
+所以，对于当前运维岗位上的同事来说，有这样一个先天优势来承担这样的职责，可以参考阿里PE转型的经验，根据自己的优势特点提前做好方向规划。
+
+云计算和AI带给我们的挑战
+
+机遇与挑战并存，上面我们更多地讲了机遇，但是与此同时我们也要看到挑战，甚至是危机。
+
+而最大的挑战和危机往往都不是来自内部，当我们还在纠结如何不被开发替代的时候，外面的技术环境已经发生了很大的变化，而这种变化带来的将是颠覆性的改变。
+
+有两个最大的外部因素，一个是云计算，一个是火热的 AI，我们分别来看。
+
+首先，云计算发展到今天，已经不是我们想象中的只能提供IaaS服务的云平台了，目前各大公有云上的PaaS产品体系也已经非常完善。我们前面讲的各类分布式中间件产品都有覆盖，而且这些产品，还都是各大公有云平台公司在自有业务上锤炼出来的非常优秀的产品。
+
+简单一句话，现在我们去做一个业务，基于这些基础服务，完全无需自研纯技术产品，只要专注业务逻辑开发即可。我了解到国内某新兴的O2O，每日超过千万笔的订单量，除业务代码外，其它基础层面的服务就完全依赖于某大型公有云的IaaS、PaaS以及周边的各类服务体系。
+
+这种情况下，非但不再需要大量的如SA、网络工程师、DBA以及应用运维这些岗位，就连技术门槛较高的分布式中间件研发岗位也会大量缩减，所以这个挑战和危机就会非常大了。
+
+这种情况下，我们应该如何面对？其实，我在前面的文章中已经给出答案，大家可以先回顾一下，然后再往下看。
+
+这里的答案就是，从价值呈现的角度来思考我们可以做什么。至于做什么我前面也提到过，比如持续交付以及稳定性保障体系。当然根据业务的不同特点，远不止这些内容。这些都是跟业务自身层面相结合的，与平台无关。与业务结合，就会有个性和独立的地方。如何根据自己的业务特点，找到跟业务相切合的价值呈现点，是我们每一个人应该去思考和探讨的。只有找到这些点，我们做的事情才会有价值和意义，我们所在的岗位才会有价值和意义。
+
+然后，再谈谈AI。这里说明一下，我们现在谈到的AI，其实大部分情况是在谈论AI的一种实现方式，就是机器学习算法。关于这一点我在InfoQ分享过一篇文章，我把链接附在文末，如果你感兴趣可以读一读。
+
+AI和Ops的结合，更多还是场景驱动的。就是我们要处理的数据量越来越多，面对的场景越来越复杂，而且会大大超出我们人力的认知范畴。比如BAT这样的公司，几十万台服务器的规模，出现一个问题，我怎么能够快速发现，快速定位，并最终快速恢复？如果是几百甚至几千台服务器，靠人还是可以搞定的，但是几十万台，靠人就不可能了。
+
+所以，这个时候，就需要借助技术的能力，而机器学习算法又正好可以满足我们的诉求。
+
+这里想特别提一点，机器学习算法的应用，是离不开场景和业务特点的，也就是说怎么用还是离不开人，离不开对业务和场景熟悉的人。从我现在了解到的情况来看，很多公司和团队，针对每一个场景都需要投入很大的精力去对某个特定曲线和算法进行调参优化，以确保它们的准确性，也还没有神乎其神地达到完全不靠人的无监督学习。这里面并不是说算法本身不具备这个能力，而是现实场景太复杂，我们不能用简单固化的算法来应对。
+
+说到这里，我想我们应该可以抓住这里面的关键点了，就是懂线上运维实际情况的人做这个事情，会更加适合。当然，这是极其理想的状态，因为机器学习算法的应用还是存在比较高的门槛，不仅仅是技术层面，还要一定的数学基础，需要对大数据产品有所了解等等，是个相对复杂的过程。
+
+所以，这里我的建议就是要多去了解，因为未来随着技术、数据和计算能力的提升，AI是一个必然的趋势。如果一点都不了解，极有可能就会被卡在门槛外面，这就不是转型的问题了。
+
+总结
+
+上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。
+
+新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是：学会写代码，培养产品意识，提升技术运营意识。
+
+当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护；同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。最重要的，这些岗位上的价值空间以及成长空间，将会变得极为有限，不管我们愿不愿意承认，这都是我们不得不接受的现实。
+
+同时，在云计算和AI时代我们面临的这些挑战和危机是可以预见到的，而未来还会存在大量的不确定和我们预见不到的东西，这种情况我下我们又应该如何应对呢？
+
+或许，唯一的办法就是不断地学习和提升自己的技能，保持对技术发展趋势的敏锐性，及时做出调整和应对，才是根本的解决之道。
+
+关于今天我们分享的主题和内容你有怎样的感想呢？你是否正在面临转型的困惑？是否已经成功转型，有什么经验？欢迎你留言与我分享讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+拓展阅读
+
+
+AI时代，我们离AIOps还有多远？
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/40运维需要懂产品和运营吗？.md

@@ -0,0 +1,75 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            40 运维需要懂产品和运营吗？
+                            在《云计算和AI时代，运维应该如何做好转型》这一期内容中，我提到两个转型建议：一个是技术产品，另一个就是技术运营。今天我就更加聚焦地来分享这个观点。
+
+我们运维接触更多的是软件生命周期中的运行维护阶段，我之前总结过一张图，就是在这个阶段要做的一些事情，把它们串起来就是下图：
+
+
+
+这张图的思路应该非常清晰了，而且对照一下我们日常在做的工作，基本上也离不开图中所描述的这些事情。
+
+这里我想表达的是，我们应该从这张图中敏锐地观察到，研发团队对运维团队的诉求，以及运维呈现的价值已经发生了变化，我们更加需要能够帮助团队建设出高效运维体系的角色，而不是能够被动响应更多问题的角色。
+
+运维的角色转变和价值体现
+
+打造一个运维体系，我们完全可以把它类比为一个产品业务体系。我们公司的组织架构中，针对一个产品或业务，如果要对其进行技术上的实现，自然就离不开类似运营提需求，产品分析设计、业务架构师设计建模、开发实现以及测试保障这样一环套一环的配合，每个角色都发挥着独特的价值。
+
+那么，对于一个运维体系，就相当于是面向研发团队内部的一套技术业务体系，只不过我们的需求方和客户是开发人员，而不是业务人员。
+
+我们对照一下可以发现，运维团队中技术环节的角色是不缺的，但是缺少的是业务环节的产品和运营角色。但是我们做事情，不一定非要有岗位上的明确设置才能往下做，只要有能起到这个作用的人承担这样的职责就够了。而这里，最合适做这个事情的，一定是运维，因为运维是日常线上运维的执行者，只有运维最清楚这里面的细节、问题和痛点，换其他人可能很难能够讲清楚。
+
+当然了，我们也不能强制要求运维一定要完全具备产品经理和运营经理的专业素养，这样就本末倒置了。这里我们强调的是运维要有产品和运营意识，总结起来最本质的就两点：第一，能将需求讲清楚；第二，能将产品推广落地。
+
+技术产品
+
+关于技术产品，其实主要就是回答以下几个问题：
+
+
+是不是能够把原本靠人工完成的很多工作转化成需求？
+是不是能够把日常工作中运维和开发的痛点转化成需求？
+是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求？
+
+
+这个过程中，可以尝试把自己做的事情串一下，用流程图也好，时序图也好，把整个过程梳理一下。过程中每个环节具体要做的事情可以通过文字描述的方式写出来，尽量分条罗列，清晰有条理。这里也可以参考我们前面讲过的内容，把一些标准化和生命周期管理的方法论融进来。这样可以一举两得，我们的标准化制定能力，场景需求分析能力慢慢都提升上来了。
+
+你可以按照我们刚才讲的内容动手做一下，这样整理出来的一份文档或者内容，其实就是一个产品PRD的雏形。如果你想要更进一步，有更加专业的输出，也可以参考了解一些产品设计方面的知识。
+
+当需求提炼出来之后，跟对应的运维开发一起合作，将需求真正落地实现。这样一个过程下来，运维的价值和能力体现是不是就跟之前有了很大的不同呢？
+
+技术运营
+
+通过上面技术产品的工作，可以做出一些有针对性的工具和平台来。但是，仅仅有工具和平台还远远不够，因为只有把这个平台真正落地，并产生了实际效果，才是有意义、有价值的。这个“真正落地”就是技术运营要做的事情。
+
+所以，接下来要做的就是落地。
+
+
+平台推广落地。工具做出来了只是第一步，得要有人用，这就需要去推动落地，让大家都来使用，从而真正给团队带来规模上的效率提升。同时，我们的技术产品也是各种标准和规范的载体，在这个落地过程中，也是标准落地和执行的过程，就需要运维和开发配合做出一些改造，为后续更大规模的效率提升和平台建设打下基础。
+线上运行数据分析。通过我们的平台和工具，对线上业务和应用运行时的指标进行数据分析。比如，应用上线或者每次变更上线后，线上运行的情况是怎样的，容量有没有降，RT有没有上涨，监控有没有异常，用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要通过数据、图表和曲线的方式呈现出来，并基于这些呈现进行分析和判断，做出后续运维决策，比如是否需要扩缩容，是否需要处理问题，是否有改进的地方。在这一点上，应该要形成对整个业务和技术架构体系改进和完善的正反馈才行。想想看，业务运营是不是也非常关注业务的数据报表，也要依赖数据情况决定后续的业务运营手段。
+过程改进。平台更多的是一个执行工具，但是工具的使用是要配合大量的标准和流程一起来运作的。比如上面我们提到的，如果一次发布之后流量下降，RT升高很多，面对这样的问题我们应该有怎样的应对机制，这里就体现出管理和流程的重要性了，要解决好不同角色和团队之间的协作问题。同时，过程中需要改进和完善的内容，能够落实到平台和工具的，也要形成正反馈，来提升我们工具和平台的效率。
+
+
+这个过程可以用下图来表示：
+
+
+
+我们面临的业务场景在不断发展和变化，这就决定了技术运营过程也必然是一个持续发展和完善的过程。所以从这个角度讲，技术运营的生命力和竞争力将会是持久的。
+
+在腾讯，运维就被定义为技术运营，第一次听到这个岗位名称时，感觉还是很贴切的。另外，我在很多大会上听海外的华人工程师分享，Operation这个词都是被直译成运营，但是在国内我们大多还是把Operation翻译成运维，从字面上就把这个岗位的定位给拉低了。
+
+不过，叫什么不重要，只要我们通过今天的内容看到，具备技术产品和技术运营的能力才是最关键的，这一点最重要。
+
+总结
+
+最后，我们再总结一下，运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同。
+
+从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗？欢迎你留言与我一起讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/41冷静下来想想，员工离职这事真能防得住吗？.md

@@ -0,0 +1,114 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            41 冷静下来想想，员工离职这事真能防得住吗？
+                            本周主要和你分享几个关于个人成长的话题。前面我们讨论了在新时期运维如何做好转型，运维是不是要懂产品和运营这两个内容，都是为了我们能够成长为技术骨干，最大限度地发挥出自己岗位的价值。
+
+今天我们就往后聊一聊，当你从技术岗位转换到管理岗后，应该如何适应新的角色，做好技术管理。技术管理这个话题很大，不是一下子就能说透彻的。所以，我就把处理员工离职问题做为一个切入点，从这个角度说起。
+
+从员工离职说起
+
+年末年初，对于任何一家公司或者一个团队来说，最令人头疼的事情就是员工离职问题，特别是骨干员工的离职，对团队带来的影响和损失，以及团队氛围和信心上的影响是非常大的。
+
+其实从员工离职这件事情上，我们还是能够反推出一些在日常管理中的问题，甚至是我们作为技术管理者自身存在的问题。同时，我们还应该从这件事情上找出我们的改进措施，不断提升我们的技术管理和团队建设能力。
+
+Design For Failure的软件架构设计理念，同样也适用于技术管理工作。
+
+因为我在EGO会员组（极客邦旗下高级技术管理者社群）专门分享过类似观点，引发了一些讨论。所以今天借着这个问题，详细分享下我在这方面的一些经历和感受，同时我也会给出一些技术管理中的反模式，这些是需要我们引以为戒的。
+
+关于员工离职的两个观点
+
+我先给出对于离职的第一个观点：对于离职这个事情，本质上就是员工个人发展和团队发展不匹配之间的矛盾。
+
+稍微解读一下就是，如果员工个人发展速度很快，而团队提供的空间或机会不足，员工就会调岗甚至离职，寻求更好的利于个人发展的机会；而如果公司和团队发展很快，员工跟不上组织发展的节奏，这种情况极有可能就会被团队淘汰。
+
+反观其它的理由，主管因素、薪酬福利，或者因为世界太大想去看看等等，这些都只能算是表面上的直接因素，或者叫导火索因素。
+
+比如，我们现在经常说的，员工离职最主要的因素之一是与主管不合。如果我们仔细想想，根本上还是因为主管在目标方向上与员工个人诉求达不成一致，或者管理方式上限制了员工个人发展，所以员工选择离开，或者团队主动淘汰，本质上的原因还是离不开发展这个诉求。
+
+但是，有时候员工对于个人成长的不满意和不顺心，无法客观理性地表达，最终就都归因到主管身上；当然作为主管，有时候不考虑员工感受和自身因素，就简单粗暴地进行管理，也不是没有问题。所以看问题要全面，我相信更多的情况是因为双方性格和风格上对不上，并没有什么是非对错，所以一切看开最好。
+
+接着彼此间发展诉求的矛盾这个问题，我再给出第二个观点：对于员工离职，从管理者角度，我们应该理解为必然结果，坦然接受，而不是避而不谈。
+
+每个人在不同阶段，总会有不同的成长和发展诉求，所以总会有一部分员工在一家公司待到一定年限之后，会为了寻求更加适合自己的机会而离开，因为员工和公司之间的发展不可能始终保持匹配，所以从这个角度来讲，员工个体上的离职是一个正常现象，也是必然结果。
+
+上面这个观点来自于领英CEO里德·霍夫曼写的《联盟》这本书，这里结合我自己的感受和理解谈一下我个人的看法。
+
+如果能意识到是必然结果，那我们要做的就是 Design For Failure，不要试图去完全避免和杜绝离职，而是要有措施能够有效规避离职带来的问题和风险。也许最大的问题在于，道理我们都懂，但是能做到的不多。
+
+所以，下面就来谈谈应该如何做好技术管理。
+
+谈谈如何做好技术管理
+
+1. 帮助员工做好个人中长期发展目标规划
+
+主管应该跟员工一起确认员工任期内的中长期成长和发展目标，让员工能够在任期内发挥最大的作用和价值，同时能够尽可能地让员工在任期内达成自己期望的成长目标。对管理者来说有一件很重要的事情，就是能够找到团队发展和员工个人发展相契合的价值点。
+
+这里很重要的一点，做技术管理者，一定要从关注事情、管理事情转换到关注人的层面。要关注人的成长发展，关注成长发展中的问题和疑惑，关怀人的工作体验和心理感受，这个才是管理的核心。一定不要忽略人这个核心要素，人的事情搞不定，其它任何事情都无从谈起。
+
+我们很多管理者当前是缺失帮助员工做中长期个人成长这件事情的，更多的是做眼前工作的任务指派，甚至是指令性下达。所以现在很多员工离职，都会提看不到发展目标，看不到空间等等。这里的关键还是上面说的管理工作缺失，大多是我们没有帮员工做，而不是真的没有空间了。
+
+这个事情要放到平时做，从团队人数还不多的时候就开始。我的团队30多人，基本每个月都和团队的每一个人做一次一对一沟通。如果实在忙不过来，那就针对核心骨干和有潜力的员工。这个沟通要持续做，并持续调整。如果放到员工要离职了再做，再去承诺，就没有意义了。
+
+2. 进行梯队建设
+
+各层管理者和HRBP，要有意识做好梯队建设，确保人才能够源源不断地输入。如有有员工离职能够有人顶上来，至少是有Backup，不至于因为一两个人离职团队就垮掉了。这块就涉及到招聘和“传帮带”机制的建立。
+
+团队成员不一定都是水平很高、能力很强的人，关键是要合适，能形成合力。所以团队中既要有经验丰富和技能突出的明星员工，又要有发展诉求强烈的骨干员工，还得要有对各种事情充满激情和新鲜感的小鲜肉。每个梯队的特点和风格不一样，形成互补，发挥各自独特的价值，这样的团队才能够有生命力。
+
+3. 提升管理意识
+
+我也是从技术转技术管理，说实话栽了很多跟头，吃了很多亏，才慢慢有所转变，这个过程比较漫长。所以，对于刚做技术管理者的员工，HR团队一定要辅助做好“转身”的培训和赋能，不然就得吃“一将无能，累死千军”的亏。
+
+同时，在这个事情上，更高级主管层面也应该要有些耐心，甚至有些时候要容许一些管理上的失误，不至于一出问题就一竿子打死。因为管理这个事情很多时候是需要管理者个人从一件件事情，甚至是一个个跟头中，一点点去“悟”到的。
+
+技术管理中引以为戒的一些反模式
+
+上面讲了做技术管理应该重点做哪些事情，那下面再说说应该少做甚至不做哪些事。
+
+1. 事必躬亲，不懂授权，不敢授权
+
+最常见的情况就是所有事情都会参与、过问甚至是干涉，更甚者，因为自己做更快，就懒得指导员工，直接亲自上手做。这样下去，久而久之，就相当于剥夺了员工成长的机会，剥夺了员工独立思考的机会。
+
+我的建议是，对于非紧急的事情，还是让员工自己动手完成。你可以指导，可以给建议，但是不要代替员工执行和思考。
+
+2. 总认为自己才是最正确的
+
+懂得授权和分配工作后，往往把自己的想法和经验强加于员工，因为总觉得自己的经验才是最好的，即使思路上和方式方法上仅有一点点不同，也要跟员工争个是非对错。长久下去，员工的主观能动性就没有了，不但容易失去与员工之间的信任，还极容易造成与员工之间的矛盾。
+
+我的建议跟上条相似，可以更多地给员工授权，多从边界条件和目标结果上提问，让员工主动思考。如果员工的方案是可以达成目标的，就可以放手让员工去做，过程中关注进展和风险，多给辅导和建议。
+
+3. 仅仅关注技术层面，忽略全局
+
+因为技术管理者大多是从技术岗位上成长起来的，有时看问题难免会片面。典型的一个问题就是只关注技术层面，不看全局。比如外部的需求澄清、进度要求、服务支持等，这些都是非技术层面的，恰恰可能也是一线员工所不擅长的，所以更需要技术管理者来关注。
+
+我的建议，技术管理者一定要先关注全局，然后再看细节。对于管理者的要求，更多的是要“做成事情”，而不再是技术骨干阶段的“做事情”。
+
+总结
+
+最后，我们来总结一下。
+
+对于离职想表达的两个观点：
+
+
+员工离职反应了个人发展与团队发展之间的矛盾；
+员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。
+
+
+对于技术管理，这其实是个很大的话题，今天我们提炼一个重点：
+
+
+技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。
+
+
+在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。
+
+这里推荐一下我们隔壁的专栏《朱赟的技术管理课》，我订购后阅读了很多文章，产生了很强的共鸣，同时也收获到一些硅谷技术公司的先进管理经验，很有帮助。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/42树立个人品牌意识：从背景调查谈谈职业口碑的重要性.md

@@ -0,0 +1,103 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            42 树立个人品牌意识：从背景调查谈谈职业口碑的重要性
+                            求职者的背景调查是我去年频繁遇到的一个职场场景，经过仔细琢磨，我有了一些自己的感受和思考。同时，这也带给我一些启发，让我对自己后续的职场表现有了一些新的认知和调整。
+
+我在这里分享出来，希望能对你有所帮助。
+
+对求职者的背景调查
+
+2017年的时候，特别是年初和年中，我陆续接到了几家公司委托的第三方机构，对我所在团队的前成员，甚至是我上家公司团队的员工做非常详细的背景调查。
+
+可能是因为与我相熟，有些公司的主管有时会直接联系我，对某些求职者在我们公司的表现和业绩情况进行了解。
+
+而且这种了解不仅限于我，我团队中的部分员工因为工作年限较长，在同行业的圈子里彼此也非常熟络，所以也会有人直接联系这些员工了解更全面的信息。
+
+背景调查对于关键岗位和高级别岗位，至少在互联网公司，已经成为了必须环节。而且越关键、越高端，背调审计就越严格。
+
+不管来自哪一方面的背调，最终被咨询一方的意见，都有可能影响到求职者的面试结果。
+
+第三方背调，一般都是在候选人经过层层选拔之后，在正式Offer发放前做的最后一项审核工作。所以如果在这个环节出现问题，眼睁睁和机会擦肩而过，就十分可惜。
+
+而对于行业同行内的背调，一般会在面试前进行。所以当你参加面试时，面试官极有可能已经对你形成了初步印象和评价，面试过程就可能是这个初步印象的验证过程。
+
+所以，面对这样的情况，我也会非常谨慎。我会尽量客观地给出我的评价标准，比如技术技能、沟通协作能力、态度表现，以及是否有比较突出的业绩贡献等等。
+
+之所以提供这些信息，是为了让对方来判断候选人的自述是否符合真实情况，以便对方做出决策。
+
+但是，两种情况下，我会比较旗帜鲜明地给出我个人的建议。
+
+第一种，对于我认为特别优秀的，我会给出强烈推荐或者非常推荐的建议。
+
+第二种，对于确实存在短板或较大自身问题的，我也会客观反馈，建议对方在候选人面试时或入职后，在管理上多加注意。
+
+我之所以这样做是因为，别人来咨询我，是对我个人的信任，我既要客观不能夸大，也不能藏着掖着掩盖事实。同时，我也要给出更加真实的一手信息。当然，我在向别人求助时，也期望别人能以同样的方式来反馈我。
+
+如何树立个人口碑
+
+谈到这里，你可能会问，既然这个环节我们自己完全不可控，那我们又怎么能确保得到被咨询人正面客观的评价呢？
+
+我的答案是：背调过程不可控，但是我们自身的表现却从来都是可控的。
+
+也就是说，我们应该把注意力放到日常工作的表现上来，因为我们所有的评价依据都来自于此。
+
+我们应该常常自问：我在工作中是否能做到积极主动，具备主人翁意识，敢于承担更多更大的责任？我在工作中是否能够不断取得成果，在团队中或跟团队一起作出较大的贡献，取得较大的业绩？
+
+以我之前公司团队的一位同事为例。
+
+这位同事是我们Oracle数据库的DBA（数据库管理员），当时他入职的时候刚毕业一年多，经验一般，但是到了岗位上很快就融入了，经常会给我提出一些在数据库层面的优化改进建议。并且在我们评审通过之后，他会自己主动去落地执行。
+
+在整个过程中，他跟其他团队成员配合得很好。出结果后，还会主动跟我一起去客户那里作汇报。久而久之，我对于他的工作很放心。后来我就放手让他自己去沟通，在他的协助下，我也减轻了一定的工作压力。
+
+后来随着能力的成长，他基本承担起了DB的全部运维职责。他在岗的那两年左右，跟团队密切配合，在确保数据库没有出现过大故障的同时，还输出了很多提升性能和容量的优化案例。（要知道Oracle数据库的优化，能够带来的成本收益还是非常巨大的。如果你了解或维护过Oracle，应该会深有体会。）
+
+在与他共事的时间里，我们更多还是同事关系，但是相比其他人，我会对他抱以更多的信任。后来他转投去别的公司工作。
+
+就在去年，我突然接到一个电话，对方是一家第三方背调公司，代表国内顶级的某支付公司，对他申请DBA技术专家岗位进行背景调查。
+
+这时我脑海里涌现出的，都是他以往种种优秀的表现。所以背调问我的每一个问题，例如表现是否突出，工作态度和责任心如何等等，我除了实事求是地回答之外，还会特别用到“非常突出”“非常优秀”之类的赞扬之词。
+
+这是比较突出的一个案例。其实绝大多数情况下，我们只要能够做到尽职尽责，态度认真，把精力投入到工作上，就不用对背调过于担心。
+
+但是如果想要树立个人的好口碑，那就需要我们付出更多，要让团队和其他成员明确你独特的个人价值，就像我上面所讲的这位同事一样。
+
+要引以为戒的反例
+
+讲到这里，我也要举两个反例，这都是我在实际工作中遇到过的情况，请你引以为戒。
+
+第一个，诚信问题，这是高压线，触碰不得。比如填写个人薪酬信息时，为了想获得更高的薪酬定价，故意捏造事实，肆意夸大之前的薪酬待遇。其实这些都是可以通过背调调查清楚的，如果存在造假，用人单位会直接拒绝。
+
+我遇到的一个真实案例就是，候选人经过了终面，但当我们通知他最后一步背调完成，然后准备发放Offer时，他却反馈不准备接受offer了。
+
+我们当然感觉比较可惜，但通过推荐人了解情况后，才得知他因为虚报薪酬太多，自己感觉心虚而不敢来了。
+
+同样，在工作岗位上千万不要故意制造假数据，或者泄露工作信息谋取个人利益，这类错误触犯的后果将会更加严重。
+
+第二个，消极怠工问题，这一点我认为是职业道德问题，是令人厌恶的。比如有的人在离职前的时间里，消极怠工，交接工作时不积极配合，经常迟到或早退，中途睡大觉或者跑出去不知所踪。
+
+可能他认为反正要离职了，一切都无所谓了，也就不再重视个人行为是否妥帖，是否合乎公司规范，是否符合起码的职业道德和职业素养。
+
+而这一行为恰恰会让团队其他人给他贴上“不负责任”“不靠谱”“职业素养欠缺”的负面标签。如此，他在将来背调时，可能就会因为这么简单的几个形容词，而被否定掉了，造成个人职业生涯莫大的遗憾。
+
+当然，如果你因为意见和思路与团队或他人无法达成一致，而闹情绪，传播负能量，为团队协作制造障碍等等，这种消极表现也是不可取的。
+
+共勉
+
+在职场中，我们个人的职场信息和表现，就像我们的整个求学经历一样，会被详细地记录、跟踪和完善，这就更要求我们必须要学会树立我们的个人品牌，珍视自己的职场口碑。
+
+而职场口碑的树立，关键还是来自于我们日常工作中一点一滴的表现，甚至是通过某些很细微的工作慢慢积累起来的，这是一个渐进的过程。
+
+俗话说“千里之堤溃于蚁穴”，往往一不留神，因为一件负面的事情或行为，就会使你个人职场口碑和个人品牌瞬间坍塌。
+
+所以，请守住职场底线，让我们共勉。
+
+欢迎你留言与我讨论。
+
+如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（一）.md

@@ -0,0 +1,48 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（一）
+                            我们的专栏原计划共36期，在三个多月的时间里，收到了你的很多反馈，我也对应做了一些补充，所以我们的运维体系管理课算是拖堂了，一直更新了42期，至此告一段落。
+
+从今天开始，我们按照专栏的四大模块，分三次来整体梳理一下。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+应用运维体系
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（三）.md

@@ -0,0 +1,48 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（三）
+                            今天我们来梳理专栏的另外两部分，“云计算时代的运维实践”和“个人成长”。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+云计算时代的运维实践
+
+
+
+
+
+
+
+
+
+
+
+
+
+个人成长
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/划重点：赵成的运维体系管理课精华（二）.md

@@ -0,0 +1,64 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            划重点：赵成的运维体系管理课精华（二）
+                            今天我们来梳理第二模块“效率和稳定性最佳实践”。我从每一篇文章里选出一句最想告诉你的话，制作成知识卡，帮助你回顾文章内容
+
+我们专栏的四大模块分别是：
+
+
+应用运维体系建设
+效率和稳定性最佳实践
+云计算时代的运维实践
+个人成长
+
+
+愿你已拥有不一样的运维思考！
+
+效率和稳定性
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/新书《进化：运维技术变革与实践探索》.md

@@ -0,0 +1,33 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            新书  《进化：运维技术变革与实践探索》
+                            你好，我是赵成，久等了。
+
+经过近5个月的打磨，《进化：运维技术变革与实践探索》这本书终于和你见面了。
+
+
+
+这本书的内容主要来自我的专栏。当编辑告诉我专栏文章可以集结成书出版时，我才意识到，原来我已经不知不觉地输出了一个相对比较完整的运维体系，当时的感觉：一切都是水到渠成。
+
+在专栏的基础上，我们对书的内容做了更加深度的修订。全书共十个章节，重新梳理了章节脉络使之更加清晰，让你能够更系统地阅读这本书。
+
+书稿完成后，我邀请几位好朋友写推荐和序，他们写的内容反过来给了我很多启发。我在专栏的一篇文章里说过，我的很多看法也是和业界的很多专家多次沟通交流后形成的。在这里，我把优维科技CEO王津银老师给书写的序分享给你，我们一起听听他说的话，或许你和我一样，也会有很深的共鸣。
+
+
+随着基础架构服务化越来越成熟，应用架构的服务化正走在路上，应用作为业务需求的第一载体也越来越重要了。什么是应用？为什么需要应用？有了应用，如何构成体系化的管理能力？作者的书恰恰在这些维度上给了我们详细的答案。
+
+从纵向维度——独立以Ops的阶段来看应用，应用体系的构建也涉及很多方面。作者从标准化规范体系、组织变革、工具平台、自动化、意识等多个侧面做出了讲解，论述非常全面。从横向维度来说，应用生命周期跨越了研发、测试和运维等多个角色，这里面产生了一条重要的IT交付价值链，也就是今天DevOps里面讲的持续交付。说到持续交付，看似一个简单的工具链打通，却需要突破诸多障碍——组织上、工具上、文化上等。组织上来说，必须要打破部门墙，否则工具链肯定对接不上。工具平台能力要分解来看，涉及多个方面：项目管理、需求管理、环境管理、配置管理、部署管理、测试管理、监控管理、服务治理等，这些在作者的书中都给出了答案。这是非常难得的总结，是因为作者过去在研发、测试和运维上的综合经历，才能够给出这么一个体系化的指引。
+
+本书还给了我一个更重要的启示，并且作者也一直是这样践行的——对于每一个运维人来说，在如今IT业务瞬息万变的环境下，我们更需要深度地思考、总结和分享交流，才能触达问题的本质。
+
+希望你如我一样，能够从书中获取大量的养分，并反哺到你的工作中。让我们一起通过书中的文字来仔细体会作者的思想吧。
+
+
+最后，开卷有益，期望这本书能够带给你不一样的运维思考，我们共同进步。
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/特别放送我的2019：收获，静静等待.md

@@ -0,0 +1,127 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            特别放送 我的2019：收获，静静等待
+                            你好，我是赵成。好久不见！
+
+还有一周就是2020年的春节了，2019年就真的结束了。最近忙完各种年终总结、年会，终于有时间总结下自己的2019了。我把这个小复盘发布在公众号上，也想在这里分享给你。
+
+我2019年定目标的时候，并没定多大的目标，主要是害怕最后打脸，所以就定了要做三件事情：健身、英语和写字。看到这三个目标，你是不是会心一笑，谁还没立过这样的Flag呀！
+
+现在看，我还真是做到了，而且还超额了。
+
+不过，三件小事，虽然很小，但是因为坚持了一年，却给我带来了很大的改变，也是19年回顾下来，给我带来最大成就感的事情。
+
+健身
+
+到目前为止，健身坚持了一年半了，每周2～3次，每次1小时左右，有时候时间紧张，10～15分钟HIIT。
+
+18年9月份开始跟教练锻练，到19年3、4月份开始，体重就开始降，一开始是小肚子没了（八块腹肌还没出来），再到后来胸挺了（胸下垂得到有效缓解），屁股也翘了，肩膀有棱角了，背也比之前直了，总之身材变好了，穿衣服也好看了。
+
+好几次出去演讲，除了被问专业问题之外，竟然还会被人主动问到你是不是在健身，身材保持这么好，你是怎么做到的。每当被问到这样的问题，就非常开心，发自内心的喜悦。
+
+其实，19年3月份之前，我也练了差不多快半年，这半年变化不大，反而因为健身消耗比较大的原因，吃得比较多，体重不降反升，差不多长了5、6斤，特别是肚子，比原来还粗一圈。
+
+说实话，那个阶段，很长一段时间都觉得非常挫败，练了这么长时间没什么效果，真的都想放弃了。
+
+但是，变化就是在几乎要放弃，但是又想再继续坚持一下的纠结点上出现了。我自己都不敢相信，这个临界点出现后，20天不到，体重就降了10多斤，到目前为止轻了十五六斤，稳定在69公斤左右，夏天的时候会更轻一些。
+
+当然，健身带来的好处不止身材好，精神状态也好很多。之前不午休，下午就崩溃，现在反应也没这么大。之前出差折腾一下，就很疲惫，经常会头痛，要花大半天调整，现在没有任何反应，可以持续地保持非常好的精神状态。
+
+9月去敦煌走了次戈壁，3天90公里，在每天睡眠只有4个小时的情况下，体力精力已然充沛，毫无压力。
+
+
+
+还有，健身还要特别注意就是要控制饮食，所以健身后碳酸饮料基本不碰，特别甜的东西不碰，多吃蔬菜水果和高蛋白食物，早睡早起，生活状态也变地更加健康。
+
+有时候我跟人开玩笑说，我现在可以做到想胖就胖，想瘦就瘦，其实我现在真的可以做到，秘诀就在于自律带来的“体重”自由。
+
+这是坚持带来的第一个小成就。
+
+英语
+
+坚持了一年的英语学习，每周两次外教口语课，每天读几篇英文新闻和文章，听个5～10分钟英文新闻或演讲或访谈，坚持读了四本英语原版图书，看得比较慢，但是一点点都能看懂了，慢慢地速度也提上来了，虽然做不到一目十行，但是相对熟悉的内容范围内，一目2～3行还是可以的。
+
+
+
+其实最早触发我重新捡起英语的原因是，我想申请海外的国际会议演讲。所以19年初尝试报名了SRECon亚太区演讲，申请的Proposal在好友的指导和帮助下竟然通过了。这个会议的通过率差不多是10%，当时真的很兴奋。
+
+6月份去新加坡做了第一次英文演讲，终于走向国际舞台了，跟LinkedIn、Facebook和Google的大牛们同台了，当时我的外教老师给我发了条消息：The world is our stage（世界才是我们的舞台）。
+
+哈哈，还是忍不住开心下。
+
+
+
+不过，过程我不是很满意，因为那个时候无论在发音、节奏、流畅和精准表达上，都差很多，只能算是一次当场的英文表达，并不能算演讲。
+
+当时在会场上有很多国家和地区的工程师，口音都不一样，特别是印度口音，完全follow不上，当时被一个印度的工程师提问，直接给问懵逼了，好在有朋友在，临时给救了场。
+
+Anyway，这算是一个美好而有意思的开始。
+
+
+
+再说件特别的事情。这次过去，还见到了我20多年没见的高中班主任，当时给过我莫大的鼓励和启蒙的老师，很多过往多年的记忆也一点点被勾起。
+
+原本一个很小的期望，去做一场国际演讲，然后打开了英语学习之门，然后体会到了阅读英文原版图书和与国际友人交流的乐趣，也更加开拓了视野，见到了许久未见的故人。
+
+所以，一件事情，想做就去做，做了就可能会带来完全意想不到的惊喜。
+
+英语学习的积累，跟健身一样，靠一点一滴日积月累。有时候单词不认识，长句子理不清逻辑，听力跟不上，表达想不到合适的单词，真的是想快也快不起来。
+
+咋办呢？只能一个单词一个单词地去查词典，反复地读和背，长句子反复读，把主谓宾一个个挑出来，再去看修饰部分，再理解再读，听力听不懂就反复一遍遍听，看原文，看懂了，再听，说不出来，就换啰嗦的方式表达，不行就Chinglish表达，完了再找地道的英文场景的表达方式来修正，反正就是使劲往外憋。
+
+没办法，就是一点点磨。所以，我觉得真正的学习和能力提升是永远没有捷径的，过程一定是枯燥和乏味的。
+
+其实现在也没做到流利表达，但是相比6月份，可以自信地讲，如果我再去讲一次，一定要比6月份好过N多倍。所以，争取20年再去申请一个英文Topic，做到比6月份更优秀。
+
+写字
+
+2017～2018我写了咱们这个专栏，19年就想继续沉淀自己的一些思考和收获。我看了下，19年我写了30多篇公众号文章。后来发现有些东西想到了就想写，但并不适合放到公众号里碎碎念，所以后来又开了知识星球，一年下来，写了360+篇，每篇300～800字。
+
+所以，从量上看，我觉得ok。我翻了下公众号文章，特别是上半年写的几篇，还是下了功夫，也带来比较大的阅读量，特别是有几篇转来转去，阅读量是我公众号内部的好几倍了。
+
+公众号的文章是收集信息并整理后输出的，有一定深度，自然阅读量也会不错，所以从这个角度讲，虽然有了星球可以随时写，但是今年在写作的思考深度上其实是有点偷懒了，公众号发的文章偏少就是这个特征，这里是要反思和改进的。
+
+所以，2020年，我会继续回到极客时间，会有一个小专栏输出，可以期待下。
+
+三件小事的总结
+
+无论是健身、学英语、还是写文章，我当初并没有立什么具体的Flag，没有了Flag的压力，我反而没有了太多的压力，完全当兴趣和小挑战来做，就是坚持，尽量不中断。
+
+而且每次努力做到跟上一次一样是最低要求，如果能做到比上一次好就更棒了，何况我健身将近半年，还有点倒退，将近半年，连及格都没做到，但是好在没放弃，反而最终是变得越来越好，甚至超出我原来自己心目中的想象。
+
+后来，我也想明白一个理儿，就是无论健身还是英语，都是我对我自己的期待，我做得好与不好，只对我自己有影响，并不影响别人怎么样，当然其实别人也并不care你身材好不好，能不能张口说漂亮的英语，关人家啥事呢。
+
+我想做的只是改变我自己，我没有必要非得立个Flag给别人看。
+
+所以，在个人成长上，努力做好自己，坚持对个人有益的一些小事，努力做到比上一次好一点点，我就觉得已经受益匪浅了。
+
+今年得到年会上，罗胖第一张PPT分享就是贝聿铭的名句：“我一直沉浸在如何解决我自己的问题之中”，很有共鸣。
+
+健身给我带来了更多自信，身体好心情也不会太差，精神更充沛的情况下，也保证了我有更充足的精力做更多其它有挑战性的事情，英语可以帮我打开一个新的空间，比如看英文原版书，跟国际友人交流，去国外演讲，阅读和写字，让我可以结交和认识更多志同道合的朋友，也让更多的认识我、了解我，而且还有机会到更大的内容平台上是展示，本身就是个品牌建设过程。
+
+所以，坚持的力量在一个人身上总会以某种方式呈现出来，比如，别人会主动问，你的身材这么好，是怎么练出来的。
+
+工作
+
+还是聊聊跟云的关系，18年的时候，我们把IaaS层的网络和主机迁到了云上，当时虚拟机、容器、还有很多中间件仍然是自建自运维。19年7月份，我们就把这些也全部迁移掉了，能用云的都用云，把上云做得更加彻底，团队精力上也可以更多地放在业务建设上，我也有更多的精力去探索一些新方向，比如5G、边缘计算、视频技术等。
+
+19年仍然有一些机会接触不同行业的同行，讨论和学习IT技术，眼界也更宽了些，也发现自己的不足，就是对某些领域的描述和呈现提炼不够，与不同级别的专家沟通，其实是需要不同层次的语言和呈现方式的，这块后续在工作中要提升。
+
+最后，2020年的计划
+
+工作上全力以赴，仍然坚持健身、英语、阅读和写字这几件小事，几件小事坚持了一年，如果能够坚持2年、3年，我觉得其实也是不小的成就。
+
+嗯，仍然不立Flag，每天或每周认真坚持几件事就好了。
+
+转一个前两天看到的句子，作为对新一年的期待：
+
+人生，难以量化，收获，静静等待。
+
+最后，你的2019是怎样的？对2020又有怎样的期待？来留言区一起聊聊吧！
+
+                        
+                        
+                            

专栏/赵成的运维体系管理课/结束语学习的过程，多些耐心和脚踏实地.md

@@ -0,0 +1,74 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            结束语 学习的过程，多些耐心和脚踏实地
+                            我的运维体系管理课专栏，已接近尾声，这是最后一篇，也是我们的结束语。
+
+我打算分两部分来写，一部分来对我们的专栏学习做个总结，另一部分打算写一下专栏文章写作这件事情给我带来的改变，或者说我个人的一些收获。
+
+专栏学习的总结
+
+在学校的时候，曾经有一位历史老师讲过，历史书可以很厚，厚到将每一个历史事件和细节都记录下来，要用图书馆来保存这么多的文字内容；但是历史书也可以很薄，薄到用几句话，几段文字就可以描述，用人的脑子就可以记住，因为历史的发展规律总是相似的。
+
+我想这条规律对于我们的学习也同样适用，学习也是一个从厚到薄的过程。起初我们对一个领域或行业不熟悉，这个时候要学习大量的知识，不断向别人请教。但是在这个过程中，随着我们自己的不断实践和思考，逐步总结提炼出一条条原则和经验，甚至形成自己独有的方法论，然后再通过这些原则和经验举一反三，指导我们来应对在这个领域中所遇到的各类问题。
+
+我想我们专栏中所分享的内容，就是厚的那一部分。希望这个专栏可以给你一个指引，告诉你方向在哪里，应该从何做起，这样就不必在混沌中从头摸索；至于薄的那一部分，虽然在最后几篇文章中我们有一起复习，但是，更希望你能够亲自实践和参与，形成自己的总结。
+
+这个过程，可以多一些耐心，多一些脚踏实地。
+
+对专栏的总结，我借用Bob大叔（Robert C·Martin ）最新图书《简洁架构》（Clean Architecture）中的一句话，原文如下：
+
+
+The goal of software architecture is to minimize the human resources
+required to bulid an maintain the required system.
+
+
+翻译过来就是：
+
+
+软件架构的目的，是将构建和维护所需的人力资源降到最低。
+
+
+万变不离其宗，我们整个专栏的文章和内容，其实就是围绕着这句话展开的。从厚到薄的学习过程，我想用这句话来总结，再准确不过。
+
+我在专栏写作中的收获
+
+再来谈谈专栏写作给我带来的一些改变，或者说我从中的收获，期望对你也有帮助。
+
+1.专注带来效率提升
+
+当我发现有一件非常重要，且优先级非常高的事情摆在面前时，自然而然地就能意识到哪些事情是不重要的了，也不会再为要做哪些事情，不做哪些事情而反复纠结。
+
+专栏写作对于我来说就是非常重要的事情。在一个相对较短的周期内，持续输出系统化的高质量文章，无论对我的时间，还是精力，都是极大的挑战。
+
+所以，我索性将那些相对不重要的事情暂时放下，不让它们占用我的宝贵时间，消耗太多精力。比如，我大大减少了使用手机的时间，准确来讲是减少了各类社交软件，以及各类资讯软件的使用频率，在工作时间基本不去碰这些软件，高效完成工作。写作过程中就更加坚决，除非电话打过来，否则手机也不碰。
+
+再比如，大大减少不必要的活动和会议。我有一个很简单的原则，就是超过30分钟的会议，我就拒绝，而是通过当面沟通的方式了解会议要讨论的内容，通常情况下，5~10分钟就可以得出有效结论。所以凡事事先充分准备，也成为我这段时间提升效率的关键原则。
+
+找到适合自己的节奏。我个人的习惯是早起早睡，所以我会将写作的时间安排在早上。晚上我一般会思考和策划输出内容的框架，这样第二天一早就可以专注地把内容写出来，在头脑最清醒的时候写作最高效。同时，避免周末不必要的活动和外出，大部分文章都是在周末集中输出的。
+
+总之，当我全身心投入一件事情时，原来担心的精力不足，时间不够这些情况都没有发生，反而会觉得时间更加充足，对计划的掌控更加游刃有余。
+
+2.总结回顾是最好最快的提升方式
+
+我们常常认为不断地学习新知识，一定要跟得上这个时代的所有新热点，才不至于掉队，才会不断提升。保持这种对新知识的敏感，我认为是没有问题的。但我想表达的是，学习再多的新知识，如果不能学以致用，它们都只是停留在纸面的上的内容而已。所以，单纯地学习，并不能提升技能，丰富经验。
+
+相反，对于自己正在做的事情，或者已经完成的事情，能够不断总结和反思，就能帮助我们完整地、体系化地获得提升。讲到这里，我分享下文章写作过程中的一个小细节，让我感受非常深刻，期望对你也有启发。
+
+起初我在规划内容的时候，脑子里梳理出来的东西都是大的框架，比如持续交付部分，按照原计划写4~5篇文章。但是，当我真正开始写的时候，我非常详细地回顾了我们经历过的持续交付过程，把中间的建设过程，使用到的工具集，包括如何落地执行，以及如何与外部合作这些都仔仔细细地罗列出来，突然发现我之前罗列的条条框框仍然是很粗的，所以就重新细化分解，最终用更多的篇幅完整细致地详述了整个持续交付体系。
+
+同时，这个过程中，因为要讲清楚一些细节，以及为什么要这样做，我会去翻阅和查询大量的资料，确保我自己的理解是深刻和正确的。同时，还要把以前我们为什么这样选型也重新梳理一遍，提炼出很多方案选型方面的原则。这个过程再次加深了我个人对一些原理和概念的理解，也让我自己对本来模糊或模棱两可的认知，有了更清晰的认识，对我来说也是更进一步。所谓教学相长，我觉得应该就是这个道理。
+
+整个过程下来，我的感觉就是，如果没有这样详细的总结回顾过程，很多细节和有价值的信息就随时间的漂移而遗落了，而这些信息一旦遗落，我个人如果再经历类似的过程，可能还要重走弯路，也就谈不上什么进步了。
+
+所以，在我们不断学习，接收新知识和新内容的同时，也不要忘了时常做一下总结和回顾。而总结和回顾的最好方式就是写作，希望你也可以逐步养成记录日志和博客的习惯，真的会受益匪浅。
+
+最后，感谢你的阅读和反馈。一路相伴，我们共同成长。
+
+希望你能够通过专栏的学习，更进一步！
+
+                        
+                        
+