阅读之后，对你有帮助，那就点个赞再走吧

除了例行的故障应急和故障复盘，我们还会定期对一个时期内的故障案例进行总结。比如按照一个季度、半年和全年的周期，这样可以更容易地发现一些共性问题，以便于研发团队在稳定性建设方面的规划。举个例子，2017年年底，我们整体总结了全年的故障案例，对P0~P2严重级别的故障进行分类汇总，就发现全年第三方原因的故障，以及数据类的故障占了很大比例。我们再往细节分析，发现第三方原因的故障，多数是机房IDC的电力、网络切换，单台服务器硬件故障导致的。

我们做个小总结，对于故障的态度，我们还是得要辩证地看。对于是否处罚，也要具体问题具体分析。完全不处罚，或者一刀切，一律处罚都是不可取的。作为管理者，还是要将规则和标准定义清楚，在执行时才能够做到公平公正。另外，管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情的前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。最后，你在故障定责和处罚方面有什么经历和想法，欢迎留言与我讨论。

今天我们讨论了故障管理中的定级和定责标准。蘑菇街在这方面的具体管理执行中，还是取得了不错的效果，所以分享出来，欢迎你留言与我讨论。

再表达两个观点。第一，出问题，管理者要先自我反省。不能一味地揪着员工的错误不放，员工更多的是整个体系中的执行者，做得不到位，一定是体系上还存在不完善的地方或漏洞。在这一点上，管 理者应该重点反思才对。第二，强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上面提到的就基本都是技术手段，但是要建设一 个完善的体系肯定要有一个过程，特别是对于创业公司。

今天我们从技术运营层面的应用这个角度重新认识了全链路跟踪系统。同时，从这个案例中，我们也应该看到，技术、产品和运营相辅相成，共同促进彼此的完善和成熟。全链路跟踪系统在技术方案的广泛应用，给我们提供了大量可分析处理的线上运行数据，从这些数据中，我们又能提炼出对线上稳定运行更有价值的信息。所以，技术之外，我们也应该更多地考虑技术在价值方面的呈现。今天的内容就介绍到这里，你在这方面遇到过哪些问题，有怎样的经验，欢迎留言与我讨论。

在稳定性保障中，限流降级的技术方案，是针对服务接口层面的，也就是服务限流和服务降级。这里还有另外一个维度，就是业务维度，所以今天我们就从业务降级的维度来分享， 也就是开关和预案。如何理解开关和预案 开关，这个概念更多是业务和功能层面的，主要是针对单个功能的启用和停止进行控制，或者将功能状态在不同版本之间进行切换。在业务层面，就像我们前面经常提到的大促场景案例，我们会关闭掉很多非核心功能，只保留交易链路的核心功能。比如我们认为商品评论是非核心功能，这时就会通过开关推送这种方案将这个功能关闭。

首先，我们先梳理清楚限流和降级的概念，明白它们会发挥怎样的作用，这样才便于我们理解后续的解决方案。限流，它的作用是根据某个应用或基础部件的某些核心指标，如QPS或并发线程数，来决定是否将后续的请求进行拦截。比如我们设定1秒QPS阈值为200，如果某一秒 的QPS为210，那超出的10个请求就会被拦截掉，直接返回约定的错误码或提示页面。降级，它的作用是通过判断某个应用或组件的服务状态是否正常，来决定是否继续提供服务。

容量规划离不开对业务场景的分析，分析出场景后，就要对这些场景进行模拟，也就是容量的压力测试，用来真实地验证系统容量和性能是否可以满足极端业务场景下的要求。同时，在这个过程中还要对容量不断进行扩缩容调整，以及系统的性能优化。今天，我们就来看压力测试的技术实现方式:压力测试系统的建设。我们详细讲讲压力测试的几个维度。

通过上面的分享，我们应该不难发现，容量规划工作，单纯靠技术能力是无法解决的，需要经验和数据的积累，到了阿里这个体量就必须借助人工智能和各类分析算法这样更高级的手段才能解决。同时，容量问题，也不是简简单单通过资源扩容这种成本投入就可以解决的，扩容是最后的执行手段，但是怎么合理的、科学的扩容，就需要有合理的规划。当业务体量和复杂度到达一定程度时，就要依靠技术人员对业务的深入理解。能够合理规划业务、技术和数据模型，是需要一些经验积累，以及在各类极端场景下的经历。

从今天开始，和你分享我对微服务和分布式架构下的稳定性保障的理解。稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏，以及杨波老师的“微服务架构核心20讲”专栏都有非常详细的介绍。所以在我 的专栏里，我会结合特定的场景，并着重从运维和技术运营的角度来分享。我们所面对的极端业务场景首先，看一下我们当前所面对的极端业务场景，我把它大致分为两类。

今天我们以弹性伸缩为例，讨论了如何思考问题和分析问题。我们的讨论和分析归结到一点就是:独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工 作的方向。现在业界各种技术上的Buzzword(时髦词)层出不穷，让人目不暇接，但是仔细观察和思考，你会发现它们背后常常隐藏着很多共性的特点，一定要抓住它们背后所要解决的问题和本质，这样也就不会乱花渐欲迷人眼了。

今天分享的页面静态化架构方案和二级CDN方案，是我在实际工作中较早跟公有云方案相结合的实践之一，并且在我们的日常和大促活动中，起到了非常好的效果。同时也可以看到，我们的业务一旦与公有云相结合，云生态的各种优势就会马上体现出来。但是无论选择哪种方案，都要结合具体的业务场景，才能作出最优的方案选择。公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。

通过CDN和云存储这个案例，我们可以清晰地看到，随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云已经形成了自有的、独特的生态体系。这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。所以，利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。以上分享的这些内容，是我在近两年的工作中真切经历过的案例和感受，希望能在思路拓展上对你有所帮助。如果你在这方面有什么好的经验和想法，欢迎你留言与我讨论。

上期文章我们介绍了混合云，以及在实际操作中我们常见的几种混合云模式。今天我们来聊一聊Spring Cloud如何解决应用层的云架构问题。对于Spring Cloud，你大概不会陌生，它跟Spring生态中的另一个开源项目Spring Boot，基本上已经成为国内绝大多数公司向微服务架构转型时的首选开发框架。

上面我以蘑菇街为例，分析了我们为什么会认为混合云会是未来一段时间内的主流形态，并推测了可能还会出现的其他混合模式，比如多云平台的混合、多云平台服务的混合等等。不管如何选择和使用，我们一定还是要以满足业务场景为出发点，脱离了这一点，单纯追求技术深度和复杂度是没有意义的。在公有云或混合云应用过程中，你曾遇到过什么问题，或者有什么好的建议，欢迎你留言与我讨论。

2018年1月22日凌晨，我们美丽联合集团旗下的蘑菇街和美丽说的业务，整体搬迁到腾讯云，完成了从托管IDC模式，到腾讯云上混合云模式的转变。云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情 况，所以不会存在是否上云这样的纠结。但是对于蘑菇街这样体量的公司，搬迁上云，就必须要考虑得更全面:考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。

至此，我们整个持续交付体系的内容就全部介绍完了。对于整个过程的总结，你可以参考本专栏“持续交付”主题的第一篇文章《持续交付知易行难，想做成这事你要理解这几个关键 点》，我在文中对整个持续交付体系进行了比较完整的梳理。细心的你应该可以发现，到本期文章为止，我并没有提到太多DevOps相关的内容，而这个恰恰是当前业界非常火热的概念。在写作过程中，我也没有特别强调持续交付是什么，持 续集成是什么，而这些又是当前DevOps里面特别强调的部分。

到这里，我们稍作一个总结。关于持续交付中的流水线模式，我们在前面两期文章以及本期的分享中，相对完整地介绍了从需求分解开始，到代码提交、软件构建，再到功能和非功能测试验证的整个过程。这个过程就是我们常说的持续集成。之所以我没有在一开始引入这个概念，是因为，如果我们将注意力集中到这一过程中具体的动作和问题上，会更有利于我们理解，而不是一开始就被概念性的术语和框架束缚住。

上期文章我们介绍了需求分解与应用对应的管理方式，以及提交环节的开发协作模式，今天我们详细介绍一下提交阶段的构建环节，也就是我们经常提到的代码的编译打包。

在前面5期文章中，我们分别详细介绍了持续交付体系基础层面的建设，主要是多环境和配置管理，这些是持续交付自动化体系的基础，是跟我们实际的业务场景和特点强相关的， 所以希望你一定要重视基础的建设。本期文章是我们持续交付系列的第6篇文章，从本期开始，我们进入到交付流水线体系相关的内容介绍中。

我们简单构建一张模型图来对线上环境作个展示:我在这两期文章中介绍了这么多环境，我们可以看到，环境建设是一项异常繁琐复杂的工作，这些工作不是一蹴而就，而是根据实际的场景和问题催生出来的，所以是个逐步渐进的过程。而且，因为不同的业务类型和场景，以及业务发展的不同阶段，场景和问题可能都是不一样的，而且其建设需求也不一样，所以在实际操作中，一定要切合具体情况进行建设。再就是，环境管理是复杂的，多一个环境就多一份管理成本。所以环境并不是越多越好，反而是越精简越好。

最后，不知道你有没有感受到，单单一个线下环境就要如此复杂和繁琐，整个持续交付体系建设是多么的有挑战性，就可想而知了。我们对线下环境稍微做个总结:集成测试环境，主要供测试使用，这个环境会最大程度与线上版本保持同步。作为对应用的功能、需求、业务流程等在正式发布上线进行验证的主要环境，集成测试环境的稳定性和可测试需要加强保障，进行全套建设。同时，作为整个线下环境的中心节点，也要为开发测试环境和项目环境提供部分依赖服务。

今天我们针对多环境的配置管理进行了分享，这里更多的还是思路和方案上的引导。如果你对Maven和AutoConfg不熟悉的话，建议自行查询资料进行学习了解，甚至是自己动手 尝试一下。另外，对于文章中的方案，我是尽量简化了场景来分享的，虽然思路上是相通的，但是实际情况下各种细节问题会更繁琐，要具体问题具体分析。你在这个过程中遇到过什么问题?有什么好的解决方案?或者还有什么具体的疑问?欢迎你留言与我一起讨论。如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见!

今天我们来看持续交付的第一个关键点:配置管理。按照持续交付的理念，这里所说的配置管理范围会更广，主要有以下几个部分。版本控制依赖配置软件配置环境配置讲持续交付，一上来就先讲配置管理，主要还是想强调:配置管理是基础，是关键。我们后面将要讲的每一个持续交付环节，都对配置管理有很强的依赖。这个基础工作做不好，也就 谈不上的持续交付的成功。勿在浮沙筑高台，我们做工具平台或系统，一定要重视基础的建设。同时，这里还有一个前提，就是一定要做到代码和配置的分离。不要让配置写死在代码里，需要依靠严格的规范和约束。

我们现在经常会接触到这些名词，比如持续交付、持续集成、持续部署、持续发布、DevOps和敏捷开发等等。大多有关持续交付的分享或文章中，这些名词经常会同时出现。它们 之间到底有什么区别?我自己之前也弄不清楚，直到看到乔梁老师的这张图。这里我重点解释一下持续交付这个概念，通俗地说，持续交付代表着从业务需求开始到交付上线之后的端到端的过程。后面我们会针对这个过程的关键环节进行分享。受篇幅所限，其它名词就先不作过多解释了，你可以看图自己体会，都不难理解。后面针对某些概念我们还会提到。

最后，我们来总结一下。对于离职想表达的两个观点:员工离职反应了个人发展与团队发展之间的矛盾;员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。对于技术管理，这其实是个很大的话题，今天我们提炼一个重点:技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。

最后，我们再总结一下，运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整 个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同。从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗?欢迎你留言与我一起讨论。如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见!

上面我结合一些运维发展到目前的现状以及呈现出的趋势，做了一些分析和建议。最后我们总结一下。新时代下，机遇和挑战并存，我们确实面临着岗位和技能的转型。我给出的建议是:学会写代码，培养产品意识，提升技术运营意识。当然，转型这个过程也不会完全是绝对和极端的，以后就一定是一个运维都不要，一个SA也不要，一个网络工程师也不要。但是，我们应该看到，这些岗位会更加收敛。一个是岗位 设置上会收敛到各大云平台厂商这里，做专职的基础和后端的服务维护;同时随着自动化的完善，在岗位数量上也会收敛，不会再出现大批量的岗位需求。

在讨论一个需求时，如果表达的都是API、缓存、数据库、消息队列等等这些专业术语，估计 业务部门的同学肯定是跟不上我们的思路的，这样的沟通通常无法正常地进行下去，所以就会经常出现业务同学说业务的事情，技术同学说技术的事情，两边不能达成一致，矛盾就 产生了。看问题的角度不同，解决方案也就不一样了。先举个之前我遇到的例子，有个部门给我们提了一个在服务器上安装翻墙软件的需求，结果我们的工程师就照着这个需求去做了，最后发现软件怎么调都启动不了，中间还牵扯到网络同事的配合，需要检查网络上的配置，最后就差动网络设备了。

表面看是做稳定的，但是我觉得更好的一种理解方式是，以稳定性为目标，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监 控、应急响应和容量管理等相关的工作。SRE的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力，同时还需要良好的沟通协作能力，这个就属于职场软技能。最后，还是我反复强调的观点，要想做好运维，就得跳出运维的局限，要站在全局的角度，站在价值呈现的角度，站在如何能够发挥出整体技术架构运维能力的角度，来重新理解和定义运维才 可以。

今天我为你介绍了我们正在实践的一些运维组织架构方面的内容。后来当我翻阅《SRE:Google运维解密》这本书时，发现如果按照书中的章节目录进行分类的话，基本上都可以与 前面我介绍的部分对应起来，这也更加坚定了我们要按照这套组织模式运作下去的信心。

通过上述的分析，我们可以看到基于以应用为核心的CMDB中，又衍生出“应用-集群服务分组-资源”这样一个运维体系中的核心关系。经过这三部分的分析，我们之前所说的基于应用为核 心的运维视图就可以建立出来了，我们再次示意如下:今天我们讨论的内容提到了，监控、发布、基础服务以及稳定性平台会依赖CMDB中“应用、集群服务分组-资源”的对应关系信息，但是当CMDB中的这些关系信息发生变化，比如新 增一个IP，或者下线一个IP，这些信息是如何传递到其它平台的呢?这些平台又是如何查询这些关键信息的呢?

CMDB是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，所以我们说应用才是运维的核心。你可以看到，如果仅仅基于CMDB的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上给业务带来价值了。但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，做这些事情带来的价值就会大大不同。

我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分:基础设施层面:IDC机房、机柜、机架、网络设备、服务器等;应用层面:应用元信息、代码信息、部署信息、脚本信息、日志信息等。这两部分是整个运维架构的基础部分，运维团队是维护的Owner，需要投入较大的精力去好好地规划建设。

在专栏介绍中，我简单分享了自己为什么会走上运维这个岗位，一是责任心使然，出现问题时总是会主动冲在前面解决，另一个是在这个过程中技能提升得很快，很有成就感。不过当时受篇幅所限，并没有完整说明，所以今天我想再来聊一聊这个话题。聊这个话题还有一个出发点，就是当下业界对运维的认知和定位还是存在很多问题的，有不少贬低运维的言论，所以我想结合自己的经历谈谈对这个事情的看法，期望能够带给你一些启发。

今天我们分析了应用的生命周期，再结合之前讲的标准化内容，我们就找到了做运维架构的切入点，套路也就有了，总结一下就是:从生命周期入手，划分阶段，提炼属性，理清关系，固化基础信息，实现运维场景。同理，这个思路还可以运用到基础设施和基础服务对象的生命周期管理中，虽然它们只是子生命周期，但是具体到每个基础服务上面，同样需要这个管理手段和过程。

前面我们一起讨论了为什么要做标准化，标准化的套路是什么，并按照套路进行了基础设施和应用的标准化示例。我想这些内容可以帮助我们举一反三，尝试着应用到实际工作中了。今天，我继续跟你聊基础架构标准化的问题，但是今天我计划不谈如何进行架构标准化的细节，而是想强调一下基础架构标准化的重要性，因为从我个人的经历和我实际观察到的情况来看，这块的问题会更普遍一些，而这一部分又影响着后续一系列效率和稳定性平台的建设方案。

今天我专门来讲讲标准化这个工作。可以说这项工作是运维过程中最基础、最重要的，但也是最容易被忽视的一个环节。我做过多次公开演讲，每次讲到这个环节，通常会有单独的一页PPT，就放四个字，字号加大加粗，重复三遍，这四个字就是“标准先行”，然后演讲过程中会大声说出“标准先行，标准先行，标准先行”，重要的事情说三遍，目的就是想反复强调这件事情的重要程度，一定不要忽视。我们运维工作的开展常常不知从何下手，或者上来就冲着工具和自动化去了，却始终不得章法，工具做了一堆，效率却并没有提升。

今天我来讲一下微服务架构模式下的一个核心概念:应用。我会从这几个方面来讲:应用的起源、应用模型和应用关系模型建模以及为什么要这样做。最终希望，在微服务的架构模式下，我们的运维视角一定转到应用这个核心概念上来，一切要 从应用的角度来分析和看待问题。

众所周知，Netfix是业界微服务架构的最佳实践者，其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可遵从的原则和实践经验。Netfix超前提出某些理念并付诸实践，以至于在国内众多互联网公司的技术架构上也可以看到似曾相识的影子。当然殊途同归也好，经验借鉴也罢，这都不影响Netfix业界最佳实践者的地位。同样，在运维这个细分领域，Netfix仍然是最佳实践的典范。所以专栏的开始，就让我们一起看看世界顶级的互联网公司是如何定义运维以及如何开展运维工作的。