某金融公司实践 | 从SRE&DevOps&PE谈如何颠覆应用运维认知

王超 / 某金融企业高级PE

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

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

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

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需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作，包括工程研发、日常运维以及监控响应方向的工作。

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应该是服务的第一响应者，有问题要马上处理。大家要有这个意识，有问题要能快速处理，这也要靠公司机制去保证，并不只是靠人。人不可能7*24小时处理问题，但是机制可以保证，包括轮班，一线二线的人分离任务，在保证核心的人不要太累的同时处理问题。性能分析师，利用有限资源承载更多的业务，我们公司每次大促前都要做全链路压测，做评估、扩容，先做性能分析，然后在进行容量规划。系统管理员是基本功，要懂操作系统，懂网络，也要能写Code，开发工具等等。开发工具并不要求是很大的平台，可以和专业开发人员一块去开发，解决问题就好。最后，产品工程协调员，加强人与人之间的沟通。

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

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

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

我之前在人人网带的团队有7、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，统一告警中心等系统做深度的整合。

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

智能运维

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

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

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

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

                                                                                       ------------------       END      -------------------

来源：中生代技术

原文链接