活动实录 | 京东金融PE谈如何颠覆应用运维认知

导读：[GO SRE！] 为数人云SRE系列活动专题，本文是3月4日北京站线下活动“当西方的SRE赶上东方的互联网”中京东金融王超老师的分享。

他将从SRE，Devops， PE间的关系开始，介绍企业该如何构建适合本身的运维组织架构并管理团队，讲解持续交付、监控、容量规划等具体运维场景实操，从工程实践的角度解读大规模复杂化的业务场景下运维指导思想的落地。

王超 / 京东金融企业高级PE

目前在京东金融平台负责一个20人左右的应用运维团队（PE团队），也曾负责人人网PE团队。现阶段主要关注运维与业务的融合、业务可用性保障，运维平台建设和团队管理。

---

我是今天最后的演讲者，前面几位都是很知名的运维专家，对你们提到的不少运维痛点我都感同身受，谈到国内运维行业的发展，我没有在国外工做的经验，今天讲的经验都是我在国内不算美好的IT行业环境下的亲身实践和总结，其中也吸取了不少国内运维行业专家前辈的指点，但愿对你们有借鉴的意义。

刚毕业时我在一家世界500强的传统行业公司信息中心作应用运维，后来换到人人网，再后来就是京东金融。从传统行业跳到人人网的时候，加入的是一个刚创建的技术运维团队，我从初期的运维工程师，成长为后来的运维主管。2014年到京东金融的时候，从0开始搭建起整个应用运维团队，从初期建设团队到一个比较稳定的状态，把公司的业务支撑好，这里面有不少经验能够和你们分享。

DevOps

DevOps 是传统瀑布流的交付方式中的Dev（开发）和Ops（运维）的关系。

开发和运维有一个矛盾点，开发的人以为写好代码交给运维，就能够上线部署了，后面的事与我无关。代码像炸弹同样，上线后若是出了问题老是运维背锅。运维的人以为开发的人老是找麻烦，老是不靠谱，因而把控变动的次数和审核流程，使开发的人不能申请更多的上线，好比一个星期只容许上线一次，就这样阻碍了业务的发展。DevOps解决了这个矛盾，协调了技术运营、QA还有开发三者间的关系。

DevOps误区

国内有不少错误的作法，好比写着招聘DevOps职位，但描述的工做职责跟传统的运维没有太多明显的变化，仍是作发布和SA；有的团队把名字改为了DevOps，可是作的是运维开发的工做，要注意“运维开发”不是DevOps。DevOps是一个落实到团队里的文化理念和最佳实践，不仅是运维团队作，也不仅是开发团队作，而是你们一块儿作DevOps，甚至有可能单独设有有一些协调员去作发布、交付工做。因此，DevOps不仅是一个团队的名称。

我在人人网的时候， DevOps的概念比较火，公司建了一个DevOps团队，后来在专家的指点下，咱们把团队名称改为了PE团队。另外，DevOps并非系统管理员加上自动化工具就够了，在部门里，SA作发布用了不少自动化的工具，但你们要知道，自动化只是一种手段和工具，要想好最终的目标解决的是怎样的问题。最后，DevOps也不是把root权限给了开发人员。开发的人员有root权限会引入很大的风险，DevOps须要控制这个风险。

DevOps技术目标

DevOps的最终目标

DevOps的最终目标是创建一个流水线、准实时交互及时性的业务流程，快速把产品推上线，产生业务价值，最大化业务输出。作事必定要想公司的路线图是什么，公司要作什么样的事情。公司新发布一个产品，上线一个在社交网站上的新消息流功能，目标就应该是把这个功能推上线，服务更多的人，而不是简简单单的作一个工单的处理。目标不同，结果也是不同的。

从技术的角度或者是架构的角度来说，DevOps须要快速部署的平台。这一点是你们都很承认的，不少如今DevOps培训都仅仅作技术上的快速部署平台，可是缺乏对DevOps其余方面的培训。DevOps真正的价值是由业务的结果判断的。最大化输出业务，而不止是IT项目的范围或成果，就是对业务产生了多大的影响。

Facebook里有两个词说得特别多，一个是Vision（视野），另外一个是Impact（影响力）。作事前想一想这件事对公司是否是有正向的影响，影响力有多大？视野加上影响力很重要。举个例子，作一个架构的组件，可能短时间内公司用不上，可是在明年也许会产生很大的效果，产生很大的改变，那就能够作。作完之后今年可能没有产生效果，可是明年可能对几十人、上百人的开发效率产生很是大的提高，这就是有意义的。因此要看最终的结果，而不仅从一个项目的角度去考虑。

DevOps速度&业务连续性

双峰挑战。系统基本上均可以分为这两类：是关注于快速上线的交互型系统，仍是关注业务的连续性的记录型（SOR）系统。咱们公司是作金融的，其中的交易系统就属于对业务连续性要求特别高的。有些产品则更关注于速度，好比web、app的开发，上线后若是有问题立刻回退就好，对用户不会产生特别大的影响，这就是典型的交互型系统，这类系统也比较适合用DevOps。要区分系统是否适合DevOps，银行、证券的的核心系统要把控好，不够成熟就不要上DevOps。

DevOps风险&安全

DevSecOps就是除了DevOps，还要注意安全。互联网公司对三点很关注，那就是速度、成本和质量。要快速的上线、快速的迭代，也要控制好成本。质量不能出问题，业务连续性不能断，若是常常丢数据，业务不能使用，公司的品牌会受到很大的影响。金融公司则更关注于安全，假如数据被窃取了，用户数据或交易纪录被篡改，是致命的。数据很是重要，因此DevOps里又加了一个DevSecOps 。

关注风险，但没有绝对的安全。DevOps的经典书籍《凤凰工程》里有一段情节，有个作审计的人老是特别郁闷，由于总以为IT的人不按审计的要求去修复全部问题，会出很是大的问题。可是最终的结果是审计成功经过，由于公司里财务的人经过业务上的检查，解决了发现的安全问题，也就是说即便IT上存在一些问题，也能够经过业务的方式弥补，达到最终的安全。DevOps告诉咱们，你要关注风险而不简单是安全，在避免风险的前提下，制度不该妨碍业务的发展和交互。另外，也要经过技术提高安全，简化流程，尽可能实现自动化。设计流程很容易，不少公司里面都有特别多的工单，可是你要想你的工单是否是有做用？好比说是否是全部的项目的上线都须要安全的人审核，若是能自动判断没有风险的话，可否自动化流转？

DevSecOps和DevOps同样，也要增强人与人之间的沟通、协做，负责安全的人应该和开发、运维、测试人员一块儿防范风险。

SRE

谈谈SRE， SRE须要负责可用性、时延、性能、效率、变动管理、监控、应急响应和容量管理等相关的工做，包括工程研发、平常运维以及监控响应方向的工做。

深究PE

重点分享我正在作的PE是什么，先介绍一下PE的起源。你们比较承认的是从雅虎开始流行的，国内最大的团队就是阿里的PE团队，后来受阿里影响不少公司也设了PE职位。PE这个词有的叫产品运维工程师，有的叫业务运维工程师，也能够直接认为就是应用运维团队，简单来讲就是负责业务或应用相关的一系列工程上的事务。

这是Facebook的招聘描述，PE既拥有软件也拥有系统方面知识的工程师，要保障Facebook 的服务平滑的运行，有足够的容量知足将来的规划。这也是刚才说的Facebook很强调两点：一个是视野，一个是影响力。技术人要有视野，能预见公司将来的业务发展，根据视野作设计。一方面要保证服务平滑运行，另外一方面要知足将来的容量规划，以此设计基础组件，要有长久规划设计的能力。每一个Facebook 产品，包括基础设施，都有PE的人。

听阿里毕玄老师说，阿里的PE团队打散到不一样的BU业务单元里。你们要根据自身的状况考虑，Facebook 团队比较大，每一个大团队都有两个PE的人跟进，他们有广阔的视野和经验，背景也比较好，从整个团队来看，既有新人也有老手，组成了多样化的团队。

除了写代码，PE也要会写文档。作运维的人必定不要抗拒写文档，无论在哪里，文档都很重要。好的文档能把事情描述清楚，给别人去看，传播给更多人，而不仅是在本身的脑子里面。PE要作容量规划，像京东每一年都有两次大促，618大促，双十一大促，PE要规划容量和性能可否够知足业务的发展。PE须要调试处理最困难的问题，全部运维都知道调试排查问题（Trouble Shooting），可是能作好的很难。不少公司作问题处理的时候，若是有乙方的支持，只要问题能解决，公司的人就不去想是问题的缘由。

咱们须要反思，再去自我提升，好的PE问题排查和总结范围的能力都很强，简单的问题也能够找到深层次的缘由并作长期的提高改进。PE要加入到值班轮转里，在值班的时候处理问题。PE要作产品协调员，和工程师团队一同协做，这和SRE里相关的部分很像。

PE会和不少人打交道，这点对其余职业也是通用的。我很强调人与人之间的沟通协做，PE是一个协调员的角色，要和PM、产品经理、程序员、网工，或者SRE沟通，与各个组协调把事情作好。我招PE的时候，很注意软技能，若是软技能方面有问题，只想作技术，不少事情都很难处理，后面的风险会更大。对于我的，无论是运维仍是其余职位，想更好的发展都应该提高软技能方面的能力，更多地与合做伙伴、同事共同协做，你们达成一致的目标，协做完成任务。

目标部分再说一下，管理者还要评估PE的绩效，保证业务正常运转，这也是管理者的一项重要工做。PE或应用运维工程师如何作发展计划？若是不转型，仍是按PE方向发展，我以为发展为架构师是很好的规划。

总结一下我对PE的定位。首先，PE应该是服务的第一响应者，有问题要立刻处理。你们要有这个意识，有问题要能快速处理，这也要靠公司机制去保证，并不仅是靠人。人不可能7X24小时处理问题，可是机制能够保证，包括轮班，一线二线的人分离任务，在保证核心的人不要太累的同时处理问题。性能分析师，利用有限资源承载更多的业务，京东每次大促前都要作全链路压测，作评估、扩容，先作性能分析，而后在进行容量规划。系统管理员是基本功，要懂操做系统，懂网络，也要能写Code，开发工具等等。开发工具并不要求是很大的平台，能够和专业开发人员一块去开发，解决问题就好。最后，产品工程协调员，增强人与人之间的沟通。

PE实践及心得

如何结合组织架构设计技术架构

三个角色的定义都说完了，再说说如何结合组织架构设计技术架构，这里有很经典的康威定律原则——组织结构会影响技术架构，技术架构会影响到运维架构。康威定律很重要的一点是说，假如团队里有N我的，每一个人都要跟N-1我的去沟通，团队越大沟通成本越高。

如何设计结构下降沟通的成本？传统模式下不少公司都是职能型的团队，开发、运维、测试属于不一样的职能团队，开发的人写好代码给运维的人上线就好了。在新的互联网公司中，除了传统的职能型团队之外，还有实施矩阵式管理，作单元化、BU化组织架构的，这样能够下降沟通协做的成本。

我以前在人人网带的团队有七、8我的，如今的团队比较大，有差很少20人。20人的团队怎么设计结构？我把业务线打散到两个不一样的业务组里，这里也有一个2-pizza team的原则。假如两个pizza都喂不饱团队的时候，团队的沟通成本实际上是很高的，管理也有难度。要把团队打散划分红更小的线，8人之内是比较合适的。

我也会设一些虚拟的小组，相似于矩阵式管理，有一些技术小组作大数据、分布式缓存，Docker、Nginx 等等，目的是什么？有点像Google SRE的50%原则，50%的时间作开发任务。可是我没有办法让他将50%的时间彻底去写程序，由于有不少事情要去作，并且咱们也有专门的开发团队，但我能够设一些技术的小组，分离业务和技术的事。每一个人50%的时间去作跟技术相关的事情，这样他们本身也会以为有意思一点，最终的目的不只是作一个纯业务的运维，而是给PE们提高的空间。

SLM服务级别管理

下技术管理上的实践，即便是互联网公司，ITIL这样偏传统的管理方式也有不少可取的地方，咱们如今也用得着，并非抛弃掉全部传统的理念，要根据公司的须要，无论是ITIL仍是SRE，仍是其它方法均可以借鉴，以此设计你的组织结构。我会保留传统的东西，像SLM，在SRE里叫SLO。为何叫SLO不叫SLA了？

由于SLA是服务协议，更多时候是甲方和乙方签协议。公司内部没有协议，而是设定一个目标，开发跟运维间达成一致，要有数据化的考量。SLA或SLO都不仅是一个可用性的目标，还包括不少的方向，好比维护的时间是否可靠？包括性能、备份、问题解决的时间这些都是考量的指标，不仅是数字。咱们内部的SLA会分得很细，根据业务的类型，对不一样业务的影响会有很细的评估。

变动管理

80%的故障都是变动引发。变动很频繁，互联网公司里面天天可能都几十次、上百次的变动，测试环境没有测试到业务的问题的可能性是很大的。变动管理的内容能够再看一下，好比CMDB，变动的时候仍是要有基础库作记录的，有了基础库后面才能作不少事情。

重大事件及故障管理

重大事件及故障管理，公司有问题的时候怎么快速的解决，有不少的细则要作，咱们设有服务台、监控这样的岗位，经过数据更准确的定位问题，你们一同协做、排查。缩小排查范围有法可依，好比根因分析法，排错法。不是简单的沟通好就好了，还要检查变动记录、收集问题。

事件处理流程

不少时候，现场处理问题动做比较快，后面分析时复原问题说不清楚。操做前尽快的把问题现象记录下来，包括监控信息、堆栈信息等等，以便于后面分析。处理流程尽可能梳理清楚，对应的作分类，看问题是常见的仍是很是见的。常见的问题有对应的应急案，快速的进行处理就好，若是是很是见的，须要技术和决策人参与，看究竟是紧急的问题仍是平常的问题，快速决策和解决。这里更多的仍是须要有协调，有应急预案，应急的预案须要通过演练。

故障分析会

故障分析会也叫复盘，有了故障之后组织故障分析会，目的是为了不相同的问题重复的出现，作改进。这时，前面收集的信息就有用了，根据收集的信息复盘故障，你们看看当时发生了什么问题，怎么解决的，有没有更好的办法去定义故障级别，而后分析根本缘由，这很重要。开故障分析会应该放松心态，开放共享，不要用指责的态度，而是追求事实，去看根本缘由，共同提升、改进，分清因和果。不少时候分析出的问题并不必定是真正的缘由，可能有更深层次的缘由。

五问法， 就是要多问，你们一块儿讨论，不要停留在表面。每个人从本身的视角去看当时发生了什么，能够提出不少问题，引导进入深度思考。

杂事—50%时间去作开发或虚拟技术小组的事情，SRE说50%的时间作开发，可是我认为50%的时间不必定全作开发，开发的时候也能够作一些技术的事，只要是长远讲，对你的组、对公司有好的影响的事，我以为就能够了，目的是同样的，多作自动化，促进你们提升能力。

自动化—减小重复性工做，减小手工操做带来的不肯定性。不少公司作自动化的同时，致使风险也变多了，因此怎么样作正确的自动化？正确的自动化减小了重复性的工做，减小了错误，解放了人类，可是错误的自动化对应的只是把人类机械化了。之前手工作不少次的，如今变成一次就执行了，系统没有给你正确的反馈。这和DevOps说的同样，不只能更快速迭代的发布，还要有反馈的信息，收到有反馈的异常信息之后能快速的回滚，这点很重要。

不少的DevOps平台都只是作了自动化，可是风险是否是控制好了？系统可否有效反馈？发布失败的时候能不能停下来？要作好对应的信息反馈。错误的自动化对应的会给出错误的信息，致使决策失误，这是必定要注意的。好比金融证券行业，作了必定的自动化交易（量化分析），程序自动作投资、买卖股权、买卖股票，彻底自动化。可是若是系统没有作好，就是灾难性的，风险仍是很严重的。核心系统必定不要缺乏人工干预，并非彻底自动化就不须要运维了，决策或者风险很是高的地方，仍是须要人去作。

最后一点，理解构建的东西，设计任何一个系统必定要知道下面具体的实现。发布的时候告诉研发的人后面有什么风险，系统是怎么设计的，懂了原理以后才能规避更多的风险。

数据化运维

如今都说数据化运维，有点相似于运营，有些运维作得比较好的话仍是能够往公司的运营方向转。很巧的是，运维和运营的英文的单词都是“operation”，都是偏运营的方向，目标也是同样的，作运维作得好的时候，应该有更多数据化的东西给公司作决策参考。尤为是监控跟线上处理相关的，对应的数据都是你的来源，这些来源都会作智能运维的数据采集，好比说网络监控，操做系统监控，DNS等服务监控，基础组件的监控。基础技术组件服务，像DB、缓存、消息等，架构的组件都须要作数据化的参考，没有这两部分数据的话，作应用级性能分析的时候就很难。

这些信息之间也会作一些联动，举个例子，好比某应用的接口访问慢了，究竟是由于网络缘由慢了，仍是缓存慢了，仍是DB慢了？要把这些信息作联动才能作更好的分析，若是作数据化运维就须要不少数据作分析。京东金融也作了分布式调用的跟踪，咱们如今说的微服务，之前叫服务化，再往前是SOA，对应的都会涉及调用链的关系。一个请求下来可能后面有几十个、上百个应用，这时怎么发现是链条上的哪一个请求变慢了？咱们用的是本身开发的分布式调用跟踪系统，也可使用日志监控，业务的解决方案，好比ELK、Splunk，日志易等。本身开发的系统能知足咱们大规模高复杂度场景的须要，还能和咱们的CMDB，统一告警中心等系统作深度的整合。

下面两个是业务指标，好比，支付系统会有支付可用率的指标监控，也有对应每一个银行分类的可用率，全局业务的监控大盘，这些都是业务方向的监控需求，方便进行快速的分析决策。因此，对业务连续性要求高的系统大多会设置一个监控中心或是做战指挥室，有不少监控的大屏，作数据化的运维，用数据作决策、分析。数据化运维从此的发展空间是很大的。

智能运维

采集大量的数据是基础，再发展的话，还会作事件汇总，打标签的数据积累。详细来说，一方面作数据采集，一方面按事件分类。触发一次代码的变动上线，或者业务的机房间流量切换，或者一个网络的工单，都是不一样的事件，什么样的事件致使了数据的波动，他们是有相关性的，要综合的分析找出根本问题。

再智能一点，像咱们报警会作降级或者是升级，自动判断问题。报警问题对业务是否有影响？是否是重复报警？级别比较低，常常重复报又不须要人去处理的就下降级别。另外，智能预估和自动扩容，人工的规则向机器学习过渡，多打数据标签，作一些智能化的处理。智能运维是将来的方向，空间仍是很大的。

总结

从实践经验看，首先必定要明确公司团队的定位、发展方向，公司的使命、愿景和价值观是什么。让每一个人都理解，才能产生比较好的团队做战能力，根据公司的状况去看组织结构，根据组织架构招到合适的人，设计系统、不断实践、持续迭代，分析、总结，长期规划。咱们虽然作技术、管理，不少时候也要借鉴商业的模式，怎样更快速的作一个新的产业出来。

最后一点我说一下“带来变化”，无论在哪家公司，都应该尝试一些新的改变，而不是简单的作重复的事情。要有一些长远的规划，多作长期能带来更大影响的事情，多作推进我的，公司，社会进步的事情。