OpsWorld 运维世界大会由运维帮、云技术、Linux中国三大社区联合举办，三大社区汇聚了大量的技术精英和行业领袖，拥有广泛的群众基础和专家人脉，订阅号粉丝达到20多万人，技术内容覆盖整个互联网技术圈。为了加强行业内的技术交流，本次大会希望通过分享先进的互联网技术，碰撞彼此的思想，一起打造世界领先的互联网技术分享平台！

王春生
【主持人】：大家好！非常欢迎大家来到上午的老王专场。这一场是我们整个大会的第一个分会场，也是上午唯一的分会场，本身讲的都是运维方面的内容，但是因为这个场上午两位分享的嘉宾都姓王，并且我也姓王，而且这个厅还是钻石厅，所以我们三位钻石老王为大家做一些分享，希望大家在上午的分享中得到一些需要的知识和理解。

上午的第一个分享人是王春生，他在国内已经从事了15年的基础运营，在系统分析、系统架构方面都有很深厚的经验，近几年在新浪的手机微博做技术保障工作，创造了15年技术架构层面零故障的记录，这是非常了不起的。上午春生为我们做的介绍的题目是“Ops，Notonly Ops”，下面有请王春生上台演讲。

【王春生】：谢谢大家来到这个老王专场，我也特别荣幸当一回钻石王老五。这是我第一次来深圳，向深圳的同学或者是南方的同学们问个好，祝大家工作愉快。

说到我的题目，其实我当时想了好久，包括我对之前工作的整理、总结，我始终在想一个问题，到底用什么名字合适，最后想出了“Ops，Notonly Ops”这个名字。前段时间我重读了做JAVA优化的一个文章，他在描述在他们工作的过程中，他确实是感觉不到Ops的存在了，我也和一些更高级别的领导沟通过，说国内的运维状况是什么？做运维的同学是怎么辛苦的，往往还有很多坑要运维去扛，这个状况应该怎么改善？在国内Ops这一层的差别还是比较多的，我觉得在国内Ops是不会消失的，有人说云时代Ops这个岗位会不会消失，从我个人的体会来讲，大家大可放心，当然会有一些岗位受到挑战，这些岗位我们可以抽空去聊一聊。

我在2004年刚毕业就加入了新浪，当时加入了国内比较大的一个LAMP平台的设计和开发工作，那时候我们的岗位叫系统工程师，其实我挺讨厌运维这个岗位的。很多时候你在做工作的时候你没办法挑语言，所有的语言你都要去尝试写一些，也不仅仅是用一些开源的体系。后来我做过一些WEB服务的开发，还有一些中间件的开发。我大概是2012年底重新回到新浪，做手机微博运维的工作，当时这个工作相对比较难做，了解到我和他们的操作的思路还是比较契合的，确实这个岗位和职责是运维，但是从我个人的体会来讲，有很多方式并不是从运维的角度出发去做的。我也翻译了两本小书，卖得都不是很好，所以出版社的编辑并不是很满意，其中一本是《NoSQL权威指南》，是一个关于NoSQL的体系的介绍，没有太多的直接相关的内容。我的微博叫“平凡的香草”，我的微信是chunshengster，欢迎大家加我，我们一起交流技术。

谈到Ops，在圈子里有这样一句话“锄禾日当午，不如运维苦，左手是测试，右手是Dev，你要和测试的同事衔接，测试环境里面发现的各种各样的问题，或者测试的时候发现的各种各样依赖的问题，很多情况都是要运维团队去解决的，然后右手是Dev，不管是线上还是线下，在出现问题的时候，大家都在想运维在哪里，要运维来帮我处理。所以有一些同学就会比较痛苦，甚至会帮开发的同学解决他在开发中的问题。当然在我们实际的过程中，我不知道在座的有多少是从事产品运维的，产品运维还要跟客服、运维打交道，因为有人投诉，或者有人反馈哪里访问不了了，这是一个特别常见的问题，其实也是需要运维出马的。虽然说我们很辛苦，我们在技术的生态链里边貌似是在最末端的，但其实我们应该是无处不在的。所以运维是一个很伟大的岗位。

在2007年圈子里面提到了这样一个概念，叫DevOps，不想请哪位同学分享一下，你心目中或者你实践中的DevOps是什么样的？

【观众】：我是来自龙光地产的。我不能说很深刻的理解，因为最近才开始关注运维帮和这里面的一些内容。我想从我的字面理解，应该是全自动化的运维，减少我们的一些工作。我前一段看到运维帮在分享SRE，我想这里面应该对它有很好的定义。我的理解比较粗浅，所以今天才来听课。

【王春生】：刚才这位同学分享的DevOps是说有很多自动化的方式，用自动化的方式去解决Ops里的问题，也提到SRE的概念。

DevOps在我的理解是比较抽象的，包括官方的解释，它是一个文化运动，在实际的生活中，我们能够看到有很多种形态的DevOps，比如说运维的同学把运维的工具写成代码，我们这样的团队很多时候叫做DevOps。开发的团队去参与到很多运维的工作，甚至去关注线上技术运营的工作内容，或者一些问题的解决，我们也会把他称为DevOps。

从我个人的理解，DevOps是面对交付的。交付这个概念在软件开发的领域是说得比较多的，当然我们在运维的这个体系里边，或者从我们的视角来看，开发需要一套新的环境，用运维去完成，运维交付给开发的这样一个环境，这个过程就是交付。开发完软件之后，然后把它交给运维，让运维去做线上的部署，这个过程也叫交付，或者开发自己去做部署，这个过程也叫交付。在有一张比较经典的关于DevOps的解释的图片里面说，在运维和Dev之间有一堵很高的墙，而DevOps是要把这个墙拆掉，让Dev和Ops能够很好地合作。我们做运维或者是做开发，参与到Ops里面，都是DevOps的情况。

除了DevOps，还有NoOps的概念，产品功能代码的测试、部署、回滚，这些在我的理解是比较经典的DevOps参与过程里面需要关注的一些环节。然后产品功能运行状况的监控和问题的解决，还有关于这些过程里面的自动化的问题。当然，如果说我们要做一个服务器部署的技术体系，确实是自动化，也负责交付，它可能更底层一些，和业务的交付不是直接相关。小米有一个关于运维的博客，我不知道有多少同学关注到，他们有一个博客叫noops.mi，我最开始了解到noops是从他们那里知道的，他们做了很多开发相关的事情，在申请存储资源，部署并切换服务的时候，比如说开发要看线上的服务的状态的时候，以及排查和解决问题的时候，确实是需要一个非常现代化的体系，有很多很直接的问题，我们不需要登录到服务器上，而是通过技术系统，能够更加直观地提供相应的信息。谷歌在2012年提出SRE这样一个概念，现在是比较盛行的，在我们的工作中大体上会参考这样的事情，或者说我们在团队的安排和规划上，有一部分同学是从事这样一些工作的，比如说产品功能的SLA的度量和分析，故障的复盘分析、提升产品功能稳定性、提升产品功能响应速度。

之所以画这样一个连接图，一方面是大家会用Ops这样一个进程或进展先后的顺序，另外还有一点就是我们在功能开发和基础设施建设的方面，它确实也是存在一个依赖关系的。比如说如果没有DevOps做的自动化工具，NoOps是很难往一个专业方向发展的，如果没有NoOps和DevOps所开发的这样一些系统，SRE也是很难操作的。

Ops这个岗位发展了这么多年，它的目标和价值其实也发生了比较大的变化。在10年前我所从事的Ops岗位和产品的性能，比如说用户访问的速度，我们很少有这样的概念。那时候我的服务器是活着的，端口是开着的，进程是存在的，我在机房的某一个监控点能够连接到我的服务，得到正常的响应，这个事就搞定了。但是随着时代的发展，发现这些基础支撑已经远远不够了。再后来我们会发现开发的一些需求，然后整个运营体系里边对基础系统的需求越来越多，越来越快，随着大家的创业氛围或者个钟点子、理念的爆发，可能我们每天都会有千奇百怪的、频繁的对基础系统的需求。基础系统交付的速度和效率会直接影响开发的部署和上线的进度，也就是产品很难面市。所以对研发效率来讲，它已经变成一个瓶颈，这个阶段大概是在2005、2006年，会有很多内部平台化的产品出来。有平台、有快速部署，然后我们又有很多架构相关的问题，这种架构问题并不仅仅是说当产品提出一个需求，然后开发去写代码就好了，他还要关注到这个环节要怎么做它的稳定性、可用性才更好。在2008、2009年的时候，这种系统架构师就比较流行了。我们解决了基础的问题，然后提升了研发效率，又用系统架构的经验，让产品更稳定，然后我们就开始关注产品的服务质量。也就是说我们从用户的视角去关注整体系统的稳定性、可用性、延迟是怎么样的。

我今天会从这样几个角度和大家简单分享一些我的经历：自动化、监控、架构、SLA、SRE。相对来说这些话题都比较粗浅、比较宽泛，更细的内容我们可以会后细聊。

自动化大家并不陌生，我相信更多的同学接触自动化这个名词的时候，很多时候可能是入行的第一天，我们的老板就说我们要把我们的体系做成自动化的，我们有很多手工的命令，你能不能写一个脚本让它自动化执行。实际工作中我们会发现自动化确实能够解决很多手工所带来的问题。我们到这个自动化体系里面，大概能看到自动化有这样几种形态，一种形态是我们可以把几十条、上百条指令封装成不同的脚本，还有一种情况是我们会用Puppec、Chef、Ansible、Saltstack，或者是自研的系统，对这些自动化的体系，大家都不太陌生，但是在我们做配置变更的过程中，我们会发现一些问题。比如说你的公司如果有很多产品线，用一套Puppec、Chef够吗？会不会有配置权限的互相影响？貌似会有。会不会有一些没有权限做变更的同学，他一不小心做了变更？会不会有配置做了上线之后，然后发现它出了问题，那我能不能做快速的回滚？这是从线上的自动化配滚体系里边抽象出来的这样一个简单的功能架构图，从我个人的体会来讲，这些是核心的引擎，或者我认为Puppec、Chef、Ansible、Saltstack是一个DevOps，或者是一个自动化配置的引擎，但是在这个引擎外面，为了能够让我们运维的部署更有效率，让运维的部署更加靠谱，它需要有很多周边的功能去做配置、管理。

从我们自己手写代码到我们使用一些配置管理的工具，到Docker的产生，我把它做了这样一个流程，从配置标准化，然后到我有什么样的需求，需要运维帮我做一个变更，一些高级的实现，无论是自己开发还是内部执行，它可以通过调用API的接口实现变更，然后到配置管理的数据库实现。比如说PLP的运行环境，你不用管它是怎么运行的，你只要把它放到它自己的环境里，它就能自己执行了，这方面是有很多PaaS产品的。Docker在这一块是解决了很多问题的，从配置化的角度来讲，docker可以把整个运行环境打造出来，开发工程师或者部署工程师可以在修改docker的时候把代码复制进去就好了。从环境即组件这样一个情况来讲，docker确实解决了很多问题，你不需要在线上变更了，如果说线上的某一个基础环境要发生变更的话，你只需要重新打一个docker的文件就可以了。

当我们自动化运行之后，到底哪里出了问题，我还是有一只眼睛要来看它的，如果你不能度量它，你就不能管理它。

我们在实际做监控的时候考虑到这些原则，比如说最小粒度原则，在监控体系里面，有这样几个比较重点的目标，比如说我们要发现它确实出了问题，如果说我们能够定位到问题所在就最好了，在现实中我们被某位同学坑的时候，我们也经常看到有同学跟老板说，某某业务又出现问题了，那里有一个报警。运维的同学会很痛苦，到底哪里出了问题，能不能给我一个详细的资料，我们要不停地查。我在做监控部署的时候会考虑到他是在最小单元收集问题，这里出了问题我就知道是这里，我们在发现问题的时候往往也是从比较大的维度发现问题的，然后才需要做定位，所以我们还需要很多汇总。我们要有监控的广度和深度。监控在实际工作中还有容量的评估以及架构自动化的一些价值。

关于广度和深度，有一些简单的列表，比如说基础环境要监控什么，业务要监控什么，依赖服务要监控什么，我会重点给大家提一下业务监控这一块。比如说我们线上提供了一个登录服务，从基础服务的角度来讲，我是正常运转的，我请求一个页面，它有内容返回，我们就认为这个登录是正常的，这样的理解是有一定偏颇的，真的这样就说它的登录服务是正常的吗？如果连不上数据库，连不上PLP，一直连接失败，这就说明登录服务是失败的。如果你依赖的时间，它的响应率发生问题，直接导致前一个发生故障，这种情况我们需要用什么方式排查？

这是一个比较简单的关于系统监控的Nginx列表。目前做得比较靠谱的系统服务程序都会提供类似内部运行状况的接口，如果它没提供，要么你就别用它，要么你就给它增加这些接口。

这是一个汇总表，这一页是针对我们的每个业务接口所做的监控，这个监控来源于Nginx日志的实时分析，我们会通过分析Nginx日志，然后来获取这个接口的响应时间，以及响应时间的区间。

有用户或者是有客服向我们反馈说某一个产品功能不太能用了，然后运维去查系统的状态，Nginx的状态、PLP的状态，有没有引擎这一级别的错误的时候，开发的同学在看他们的代码自己写的日志，他们会从产品功能记录这些日志。我们会把开发所记录得几乎所有的日志全部通过实时分析的方式反映到监控系统里面来。像这样一个状况，比如说成功、响应时间、发生的时间、接口等等都反馈出来，一旦用户反馈说我的功能不能用的时候，我们可以不用让开发的同学去服务器查日志，我们可以在监控系统里面看看到底有多少不能登录，是不是大面积的。针对这样一个考虑，我们做了一个框架，是一个叫Plog的框架，它可以通过一些简单的配置将我们几乎所有的日志通过格式化的处理，然后得到一定的日志，当然它还是需要我们补充一些代码的，这里可以用一些语法将我们的日志进行分割，然后写一个统计分析的脚本，把这些日志投递到监控系统里面去。

目前我们差不多所有的日志都通过这样的框架将它分析出来，然后把关键的字段提取出来之后，投递到监控系统里面。通过分析，像所有的调用逻辑，我们都可以通过对功能这一层面的分析得到它的业务量的请求。

这是一个比较综合的展示界面，这一层上面两行是根据Nginx日志分析出来的，下面这个请求是根据业务自己记录的日志分析出来的，它们都是同一个接口。在我们现实中我们把针对单个业务（比如说针对登录业务）所有监控项全部提取处理。我们可以看到这个上面Nginx的请求量发生了一个比较大的变化，它的响应时间还是很好的，我们从上面这两个图可以看出来，这里面发生了一个快速失败的情况。在这里我们发现有一个红色的区域，这里是请求后端接口，或者是在PLP运行的过程中，它的某一个操作发生了大量的错误。实际的情况是说PLP在这里请求后端的某一个接口的时候很快就失败了。

我们在Zabbix上做了一个插件叫Sort，它可以看到在同一个时刻某一个监控项，哪一个接口的表现是最差的，当然这个表现最差，你可以通过错误率或者响应时间去做分析。

监控系统有一些优点，比如说你的实时监控，能够实时的获取系统运行的状态，我们可以尽可能多的得到系统里边哪里出了问题，哪一个IDC或者说哪一组机器出了问题。但是也一些时候，我们也比较难定位到在代码这一层面能够反馈出来的问题，尤其是在微服务的年代，如果说我们依赖的服务发生了问题，它的问题到底是什么？我们知道它失败了，但是失败到底发生在哪里？它的CURL是一个常用调用的接口，在它里面它会给我提供我的DNS请求的时间，建立连接的时间，传输数据的时间，还有传输数据的大小，以及请求的IP地址，它能告诉我几乎所有的信息。这样当我去建立一个连接失败的时候，我可以比较清楚地知道是DNS出了问题，还是建立连接出了问题，后来在后端数据方面发生了比较多的问题。

当然我们仅仅一条一条的提供数据还是不够的，我们还需要在系统里面做一些汇总的工具，能够比较快的发现，到底我们的系统里面什么情况是最严重的。这是PLP的一个统计分析表，它能够告诉我每一个IDC的PLP慢请求的堆栈情况，它还能告诉我PLP里面哪个函数是最慢的，这是整个IDC分析的情况。当然这里边还会有分析哪一台机器的慢日志是最多的，这是另外一种情况的监控，当然它也是基于数据分析，它可以分析得更细。

这里谈一下ELK，很多时候我们拿ELK做数据分析，在这里我们发现了它的一个不错的拓展功能，这是一个客户端崩溃的日志，我们在这个基础上做了一些格式化分析，实现了这个客户端崩溃的查询系统，在这后面我们多做了一件事情，我们可以把软件崩溃的日志通过查询的方式把它投递到开发的bug管理系统里面，当线上发生崩溃的时候，我们除了要快速解决，崩溃的原因，以及导致崩溃的bug，直接把它交付到研发的体系里面，让他们进行修复，而不必再一条一条的去查到底哪个崩溃是最严重的。

我们做了自动化，也做了监控，下面我们再讨论一下关于系统架构的问题。

我个人有这样一个理解，系统的稳定状况多半原因都是因为架构的问题。架构里面都存在什么样的问题，或者我们用什么样的方式去解决呢？这是一个现在比较典型的移动互联网或者微服务的架构图，它有一个客户端的接口，有一个PC的接口，当然有很多都不存在PC端接口了，下面还有一些各种各样关系的RPC的接口，还有一些通用或者开放的接口。这些接口除了封装之外它底层还会依赖关系型或者非关系型数据库队列。

在这样一个架构里边，我们需要关注哪些问题呢？比如说我们在底层的这些依赖接口里面是不是在架构层面有备用的逻辑，也就是说当我请求到某一个IDC的某一个接口的时候，如果这个接口挂了，是不是我们的系统可以快速的甚至自动的切换到其它IDC的同样一个业务的接口上去？我们的请求量过大的时候，是不是可以有这样一个过载的保护？当我们的某一个依赖的服务挂掉之后，是不是我们的业务还能够再让那些可以运行的业务继续运行，也就是做一个自动降级的服务。这里面还包含你要做熔断和过载的话，它们是不是有相应的配合。

我们刚才提到了自动化、监控，我们把它结合起来是什么样的呢？我不知道有多少同学参与过中间件系统的研发，在10年前我们实现过一套自动化体系，这个体系在网上有很多的文档介绍。这个体系的后面是后端的服务，通过监控系统，把后端可用性提供到DNS或者consul，前端根据实际情况自动调整后端的服务。另外一个方式是比较现成的，我看到大众点评提供了一套类似的机制，就是用的confd+templated，这个机制是相对比较运维化的。

这是MySQL的，通过这样的监控配置管理系统，可以实现架构的自动化。

这是Hystrix的自动化架构，这张图可以从网上搜索到，你会发现它有自动注册，以及自动注销的功能。这个调用方通过在Eureka server里面获取信息，要把它调用到哪个端口上，得到信息之后，它再去Application service里面调用。Hystrix是一个调用的机制，它会自动把这些接口不可用的IP直接下掉，这同样是一个在架构上实现自动化的价值。

Hystrix的践行方案，在这里有一个简单的描述，大家如果对这个感兴趣，可以看一下Hystrix的一些代码。

回到从自动化到监控到架构的治理的方案上面，好像我们该有的都有了，但是应该用什么样的方式去评估运维到底好不好，或者一个架构到底稳不稳定。我们这个理念实际上是从很久很久以前就存在的，但就从我自己的体会来讲，有很多同学并不是很喜欢，或者有很多的团队其实对这样一个名称都是比较反感的。比如说它是老板看的一个报表，老板要知道你们到底干得好不好，这是KPI，然后它也是我们工作的时候的压力所在。当时我们在做这样一套系统的时候，我是从运维团队的角度主动做这个事情。因为我发现在监控的维度去看，我们确实能够实时的发现问题，我们用ERK去补充，能够更深地挖掘里面的问题所在，但是不是还有一些隐患？比如说它每周在响应时间、成功率上有一个比较微弱的变化，这种趋势在监控系统里面其实是很难去发现的，甚至我们还有一些维度，因为它实时，所以功能受到的限制更多一些。我们能不能有更全面的数据分析？也就是说我除了可以度量自己对他人的承诺之外，作为一个服务调用方，我还可以度量被调用方我调用的那些服务的可能性，然后我可以做多维度的数据挖掘，然后我还可以回溯历史事件。

这是一个在SLA系统里面比较常见的界面，它表现了重点城市、慢速比等等，慢速比是我们使用的一个概念，比如说我们把超过3秒的请求就作为一个慢速请求，超过3秒的请求的数量除以总量，这样就是一个慢速比。还有成功率、城市成功率，以及按照各种客户端统计的。

我在考虑这个的时候，我是希望让开发团队喜欢SLA，让SLA帮他提升效率，提升运维工程师的KPI，让运维工程师也喜欢它。

这是一个实际的例子，在某一天发现图片上传的成功率发生了一个比较巨大的变化，通过SLA系统，我们分析各个网络的情况。然后从城市来看，都发现不太能找到问题所在。最后我们发现这个问题是在哪里？是因为iphone的客户端，因为它的客户端发生了一个巨大的变化，问题就锁在了iphone的客户端。

我们如果让我们的SLA系统能够更好地帮助运维和开发解决问题的话，我们做SLA系统的同学是需要理解我们的网络架构、业务架构的。这是我们做SLA的同学画的SLA系统架构的简图，它的每一个分析项的定义都是自己分析出来的。

这是之前手机微博通过SLA系统分析得到的数据，在某一天它的慢速比发生了一个比较大的变化，响应时间也发生比较大的变化。我们包含了很多产品的数据，发现另外一个平台也发生了这样的变化。再后来我们定位到是我们共同调用的一个接口，它的某些服务器上的响应时间发生了比较剧烈的变化。虽然说这个变化或这个状况我们是可以通过监控系统发现的，但是并不代表着所有的团队的监控体系都是一致的。通过这样的数据，我们就可以把它的问题挖掘出来。

整体来讲我们有自动化、监控，会有在架构上考虑容错性、性能自动化，然后我们有SLA，我们发现这样的体系比较全面了。但是是不是我们有了这样的体系之后，我们的整体业务运营状况就OK了呢？在也类有一个新的岗位，是专门做产品运维的，产品运维主要做哪些工作呢？他会把开发、运营、客服所有需要运维解决的事情串起来，他会用SLA体系、监控体系，以及架构体系的工具，把问题分析出来，从目标上提高产品的可用性。

这是一个案例，开发有一个新的需求，产品运维的团队开始做设计，说这个需求应该怎么解决呢？后面他就给CM发一个Ticket，这可能是说一句话，或者是调一个接口，然后再给后面监控的体系，还有SLA的体系都发Ticket，他们的配置管理系统开始做事，监控系统也开始做事，最后他们这个做完了，产品运维的同学就可以告诉开发，我们这个体系做完了，你就可以上线了。

这是通过SLA系统分析出来得到的一个问题，比如说Operation timed out，这是出现问题比较多的地方，最后发现发生的原因是内网的某一组交换机比较老了，丢包比较严重。从业务层面或者从应用的层面，将这个内核里面的RTO的时间进行缩短。

我们的运维体系里面无外乎监控、配管、自动化架构体系、平台化、Docker化等等，不管用什么方式，总之在运维这个岗位发展到今天，应该有更多的公司货业务会从整体上考虑我们的产品、业务是否OK，用户的使用是否良好，也就是说我们还是要向这样一个台阶迈进，不管用什么样的方式。