（点击“此处”获取王超演讲完整PPT）

讲师介绍

大家好，我是京东金融负责PE团队的负责人王超，很多人可能还不太了解PE这个岗位，PE这个岗位在雅虎、阿里、Facebook等多个互联网公司都有，全称是Product Engineer（产品运维工程师），也有一些公司叫应用运维，可以简单定义为生产环境的产品的技术运营，在京东金融所有生产环境的业务运维、大数据及中间件的运维都是需要PE团队主导或主要参与。

我过往的经历是在人人网负责PE运维团队，再早的时候是在一家传统的大型央企里负责应用运维。从三个公司的职业发展路线来看，我经历了从传统行业到大型互联网公司，再到互联网金融的几次转变。不同的经历带给我不同的思考角度，这也是我希望跟大家分享的内容。

运维体系的关注点主要有这四项：速度、质量、成本、安全。

公司里最重要的是如何创造更大的业务价值，产品的发布要快，技术的瓶颈不能成为业务快速迭代、新产品上线推广的制约因素。

业务的快速交付，线上的质量仍然需要保证。

尤其对于金融行业来说，安全是非常重要的。支付行业有一个名词叫资损，代表资金受到损失。在交易过程中可能会存在重复发单、营销活动，比如说给用户多发了钱，而且用户提现了，这笔钱追不回来，就造成了资损。因为技术或业务上的问题可能导致的资金损失会达到上千万甚至更多，所以作为金融行业的运维人员，一定要重视安全问题。

人员成本和IT运行成本一直是互联网公司的两大项支出，对于大规模互联网公司，服务器规模几万几十万，对资源的优化，服务性能的提升，合理的评估容量水位线，以及预算制定，成本核算，这些也都是运维需要做的工作。

DevOps是继Agile、Scrum和XP之后衍生出来的，延展到运维领域中的新兴的运动。

DevOps协调开发、QA测试和技术运维三种角色，加强了相互之间紧密的沟通协作。

从项目规划、代码开发、构建、测试，再到发布、部署、运营和监控，DevOp是一个闭合的环，保持着持续的不中断的迭代发布部署。而其中的最后几个环节，运营监控并反馈到需求方，往往是容易被忽视的环境，而DevOps强调了反馈（Feedback）的重要性，完成了部署以后一定要通知到需求的提出者，让业务方进行确认，保证结果得到验证。如果参加过DevOps Mster沙盘训练应该会对这一点深有体会，DevOps对业务最重要的作用就是保证业务战略快速推进和快速回馈。

开发与运维之间往往会存在部门墙，其中一个原因是，运维注重的是安全稳定，开发注重的上线发布的速度。思考问题的出发点不同，导致了相互之间理解的不同、沟通的不畅。

运维为了保证生产环境的稳定性，可能每周只设定一个上线窗口，在每周三晚上上线一次，可能开发会觉得等不到这么久，因为业务的需求很着急上线。这不仅仅是技术问题，也涉及到业务和组织结构管理的问题。让我们先从DevOps的思想分析一下问题。

1）DevOps认为更小、更频繁的变更意味着更少的风险

传统模式的公司IT可能一个月或一个季度才发一个版，可对于互联网公司来说这个周期就太长了。比如业务上提了一个紧急需求，要周末办一个推广活动，网站要上线新页面，但运维如果说下个月才能上线，业务上就已经没有价值了。所以技术上需要支持更快更频繁的变更。

如果把要需求切割成更小的粒度，每次变化的代码量更少的，意味着这部分的测试也更明确，代码审核起来也比较快，所以风险可以控制的更低，发现问题也可以马上回退解决。

2）让开发人员更多地控制生产环境

让开发人员更多地控制生产环境，但不是简单的把运维操作权限交给开发人员，因为操作的风险还是要控制。以京东金融为例，我们的做法是让开发人员参与生产和运维，但并不是直接登录到机器上操作，而是在运维平台上授权受限制的操作，如应用的创建，发布部署，启停等。我们也需要提供相应的监控系统、日志平台，可以让开发人员在平台上进行查看日志、检测服务状态等操作，不需要登录服务器。

3）以应用程序为中心理解基础设施

应用程序对底层环境有没有依赖，发布在物理机还是虚拟机上，根据业务的需求需要部署多大规模的服务节点，如果做多机房部署。这样类似的问题我们希望在上线前就跟研发同学做好沟通，制定好整体的技术架构和部署架构，研发同学对基础设施有更好的理解对整体架构的优化非常有帮助。

4）设计简洁明了的流程，尽可能自动化

人、流程和技术，这三者是技术管理中很重要的三个因素。人与人之间都存在差异性，思维角度不一样，而且互联网公司人员的流动性也很大，所以人其实是不太好控制的。而流程虽然重要，但是如果只是靠人的约定去执行的流程，得不到好的落地，效果一定不会好。因此我们的做法是依靠平台，把流程固化到平台里，在平台中规避有风险的操作。通过引导式的流程，完成应用立项，应用发布，扩容缩容等操作，因为每一步都有较好的提示，很少出现误操作的情况。

5）促成开发人员与运营人员的协作

DevOps的终极目标是建立流水线式的准时制（JIT）的业务流程，最大化业务产出。 业务产出最终的衡量应该以业务交付完成的指标来判断，也就是说是否准时上线了，以及上线后业务人员是否认可。

康威定律，设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。反过来，如果你的系统设计或架构不支持，那就无法成功建立一个有效的组织。不同公司的组织架构不一样，往往导致服务架构也不一样。DevOps场景下如何设计合理的组织架构，也是我们需要思考的问题。

组织架构设计的时候，比较有意思的一点就是该如何去打造高效的开发和交付小团队，就像上图“双比萨团队”说的那样，如果你不能给一个团队提供两个比萨饼，那么这个团队就太大了。要想达成组织结构的高效，最底层的小团队在一块就需要多沟通、多碰撞，所以怎么设计你的更容易沟通的组织结构也很关键 。

如上图所示，上面是开发、产品、测试，下面对应的是SA、DBA、运维开发、安全、网络部门，PE的角色起到了相互衔接的作用。PE的角色也有点像特种部队，特种部队经常是三人为一组执行外勤任务，这三个人里可能还有一些分工，有的人偏战略指挥、有的人负责执行任务、有的人负责联络通信。而在这三个人后面，其实往往还有几百人在做大后方的支持。后勤人员通过特种部队的摄像头等设备，对回传信息做数据分析，指导特种部队行动路线，执行计划等。

作为参考，我觉得我们在运维工作中也需要小而灵活的团队来跟产品、开发的人进行更直接的沟通，了解需求，根据需求制定解决方案，解决遇到的问题。

所以我负责的PE团队也尽量来设定成三四个人一组跟进某些业务线，其中每个人都可以尽量多了解对应的业务，当需要运维的其他部门配合时，再把这些业务需求转换成运维的术语，传递给运维内部的其他部门 。

DevOps官方的五大原则：

• 文化（Culture）

• 自动化（Automation）

• 精益（Lean）

• 数据度量（Measurement）

• 分享（Sharing）

重点提一下数据度量（Measurement）。

监控如果做得不到位，小的问题不容易发现，一出问题就是业务中断的大问题。大的互联网公司的监控工具一般都会对时延非常的敏感，如内部广泛使用的APM应用级性能监控工具，如果某个应用的服务接口性能从100毫秒变成120毫秒，很可能就会触发报警，报警就会驱动大家去查为什么接口性能慢了、是不是硬件问题、是不是网络问题，运维会配合开发进行细致的调查。这些细小的问题驱动了我们在技术上多去分析思考，也会促进我们开发更细粒度的监控和分析工具排查问题。

应用从立项到发布上线、不断的迭代变更、扩容、缩容、迁移以及生命周期结束后的下线，需要一个完整的生命周期的管理。

我们做应用的全生命周期的管理时，结合了内部的流程系统、应用信息管理系统、自动部署系统，并对外提供API接口。

应用中心类似CMDB，但CMDB偏底层基础设施一些，比如管理操作系统、物理机、网络、数据中心。但是应用生命周期更关心应用本身和周边关联的系统。

应用立项时需要做很多工作，确定所用资源的套餐，根据业务容量规划需要的节点数量、基础组件的版本、网络拓扑、网络申请、网络权限等，立项以后还会经过很多次的信息变更。如果仅依赖文档把每次变更做以记录，很容易在人员交接流转的过程中信息遗漏丢失，给后续接手的人操作带来风险。通过在系统间自动化流转的时候自动记录下应用信息，保证了应用信息和生产环境的一致。

这些信息也作为服务对外提供接口。举个例子，应用监控的配置如果脱离应用系统单独维护，每次应用扩容缩容都需要通知到监控系统进行修改，很容易造成应用扩容或者迁移后监控会有遗漏，造成潜在风险。但是监控系统以应用中心对外提供的接口数据作为基础信息，就保证了数据都是实时准确的，也避免了各个系统重新配置的工作。

应用部署的工作对基础环境的依赖非常大，比如Python程序的部署，对Python版本的依赖，再底层的OpenSSL等文件库的依赖，以及对操作系统的依赖。

早期的运维很多都是通过脚本+配置文件的方式来实现批量执行的，判断需要的依赖环境，再进行依次安装，每次执行前可能还需要临时修改脚本或者配置文件的内容，比如要操作的IP列表文件。复杂的任务以及多人操作的时候这样的方式就存在了较大的风险。

Puppet、Ansible、Chef这些配置管理工具很好的解决了这个问题，这些工具指导我们更多的通过配置管理的方式，如把软件部署的依赖关系通过Ansible Playbook来定义，通过角色分组严格的控制执行的目标状态，操作可以重复执行，哪个环节出现问题也可以准确定位，结果得到了更好的保障。

而容器时期的到来，首先是更好的解决了环境的一致性的问题，通过镜像封装的方式将基础环境打包到了容器镜像中，保证了从开发、测试、到生产的环境一致性。Mesos、Kubernetes等流程编排工具更好的解决了部署的问题，只需要关注应用本身的信息以及部署的规模，平台已经解决掉了大部分的问题。

运维跟开发人员一样，需要多了解技术架构和业务架构。

多了解技术架构和业务架构，才能在生产遇到问题时更好的理解和处理问题，在理解研发提出的需求时更好地理解问题，甚至提出更好的解决方案。

业务架构中主要用的一些基础组件 ：

• GSLB

• 网关

• 服务化组件

• 消息中间件

• 缓存

• 配置管理平台

• 分布式调度

• APM

• 日志平台

运维行业也会细分，业务运维的角色会越来越像数据化的运营，从应用的整个生命周期持续的跟进和优化，关注更快的迭代、更高的访问质量、安全的威胁，关注成本的分析，这些问题也促进我们不断的深耕技术，为业务提供价值。

为了更好的质量，我们需要做好以下的数据监控：

• 基础服务监控（网络、OS、DNS等）

• 数据服务监控（DB、缓存、消息等）

• 应用性能监控

• 分布式调用跟踪和监控

• 日志监控

• 业务指标监控

现在AIOps也是很热门的研究方向，分享几个主要思考点：

• 采集数据是基础，事件信息汇总、对数据需要打标签；

• 报警关联分析，找根本原因；

• 自动报警降级或升级；

• 容量水位线预估与自动扩容；

• 从人工规则向机器学习过渡。

希望后面再找时间详细地展开分享。