DevOps是从Agile、Scrum和XP中衍生出来，并延伸到运维领域的新运动。大家好，我是京东金融PE团队负责人王超。很多人可能不太了解PE职位。PE职位在雅虎、阿里巴巴、Facebook等很多互联网公司都有。全称是ProductEngineer（产品工程师）。运维工程师），也有一些公司叫应用运维。可以简单定义为产品在生产环境中的技术操作。京东金融所有生产环境的业务运维、大数据和中间件的运维都需要PE团队的主导或主要参与。过去的经历是在人人网负责PE运维团队，早期在大型传统央企负责应用运维。从三个公司的职业发展路线来看，我经历了几次从传统行业到大型互联网公司，再到互联网金融的转型。不同的经历带给我不同的思考角度，这也是我希望与大家分享的。运维体系四象限运维体系主要关注速度、质量、成本、安全这四项。速度一个公司最重要的是如何创造更大的商业价值。产品发布要快，技术瓶颈不能成为业务快速迭代和新产品上线的制约因素。优质业务的快速交付，在线质量仍需保证。成本人员成本和IT运营成本一直是互联网企业的两大支出。对于大型互联网公司来说，服务器的规模是几万、几十万。资源的优化，服务性能的提升，容量水线的合理评估，预算的制定，成本的核算，这些也是运维需要做的工作。安全性尤其对于金融行业来说，安全性非常重要。支付行业有一个词叫capitalloss，代表资金损失。在交易过程中，可能会出现重复的计费和营销活动，例如向用户发送更多的钱，用户提取现金，钱无法收回，造成资金损失。因为技术或业务问题可能造成千万甚至更多的资金损失，作为金融行业的运维人员，一定要注意安全问题。DevOps简介DevOps是从Agile、Scrum和XP中衍生出来，并扩展到运维领域的一种新运动。DevOps解决的问题DevOps协调开发、QA测试和技术运维三个角色，加强他们之间的紧密沟通和协作。从项目规划、代码开发、构建、测试，到发布、部署、运维、监控，DevOp是一个闭环，保持持续不间断的迭代发布和部署。而最后几个环节，运营监控和反馈给需求方，往往是容易被忽视的环境，而DevOps强调反馈（Feedback）的重要性，部署完成后一定要通知请求方，让业务方确认确保结果得到验证。如果你参加过DevOpsMaster沙箱培训，你应该对这一点有深刻的理解。DevOps对业务最重要的作用是保证业务策略的快速推进和快速反馈。开发和运维之间往往有一道部门墙。原因之一是运维注重安全稳定，而开发注重上线速度。思考问题的出发点不同，导致相互理解不同，沟通不畅。为了保证生产环境的稳定，运维可能每周只设置一个上线窗口，每周三晚上上线一次。可能开发会觉得等不了那么久，因为业务需求很急，要上线。这不仅仅是一个技术问题，更是一个业务和组织架构管理的问题。我们先从DevOps的角度来分析问题。DevOps认为更小和更频繁的更改意味着更少的风险。传统企业IT可能一个月或者一个季度才发布一个版本，但是对于互联网企业来说，这个周期太长了。例如，业务有急需，周末需要举办促销活动，网站需要上线新页面等。但是如果运维说下个月上线，这个业务就没有价值了。因此，技术需要支持更快、更频繁的变化。如果把需求切到更小的粒度，每次改的代码量更少，意味着这部分测试也更清晰，codereview也更快，这样风险就可以控制的更低，问题可以得到解决立即发现。回滚解决。让开发者更多地控制生产环境，让开发者更多地控制生产环境，但并不是简单地将运维操作权限交给开发者，因为运维的风险还是需要控制的。以京东金融为例，我们的做法是让开发者参与生产和运维，但不是直接登录机器操作，而是授权在运维平台上做一些限制性的操作，比如创建应用，发布和部署，启动和停止等。我们还需要提供相应的监控系统和日志平台，让开发者无需登录服务器即可在平台上查看日志和检测服务状态。关注应用，了解基础设施应用是否依赖底层环境，是发布在物理机还是虚拟机，需要根据业务需要部署多大的服务节点。如果做多机房部署，希望在上线前能和研发同学就类似的问题进行沟通，制定整体的技术架构和部署架构。研发同学对基础设施有了更深入的了解，对整体架构的优化有很大帮助。帮助。设计简洁明了的流程，尽可能实现人员、流程和技术的自动化。这三个是技术管理中非常重要的因素。人与人之间是有差异的，思维的角度不同，互联网公司人员的流动性也很大，所以人其实不好控制。过程固然重要，但如果只是按照人们的约定来执行过程，如果执行得不好，效果肯定不会好。所以我们的做法是依托平台，把流程固化到平台上，避免平台上的风险操作。通过引导式流程，完成应用项目建立、应用发布、扩缩容等操作，因为每一步都有很好的提示，很少有误操作。促进开发人员和运营商之间的协作DevOps的最终目标是建立流线型的即时(JIT)业务流程，以最大限度地提高业务产出。业务产出的最终衡量要通过业务交付完成的指标来判断，即是否按时上线，上线后业务人员是否认可。康威定律，设计系统的组织产生等同于组织间通信结构的设计和架构。相反，如果你的系统设计或架构不支持它，你将无法成功地建立一个有效的组织。不同的公司有不同的组织结构，这往往导致不同的服务结构。DevOps场景下如何设计合理的组织架构也是我们需要思考的问题。在设计组织架构的时候，比较有意思的一点是如何打造一个高效的开发和交付的小团队，就像上图中的“DoublePizzaTeam”，如果你不能给一个团队提供两个pizza，那么团队太大了。为了实现高效的组织架构，顶层的小团队需要更多的沟通和碰撞，所以如何设计你更容易沟通的组织架构也很关键。如上图所示，最上面是开发、产品、测试，最下面是SA、DBA、运维开发、安全、网络部门。PE的角色起到了相互联系的作用。PE的作用也有点像特种兵。特种部队通常三人一组执行野战任务。三者之间可能存在某种分工。沟通。而这三人的身后，往往还有数百人在支援后方。后勤人员利用特种兵摄像头等设备，对传回的信息进行分析，指导特种兵行动路线，执行预案。作为参考，我认为我们在运维工作中也需要一个小而灵活的团队，与产品和开发人员更直接的沟通，了解需求，根据需求制定解决方案，解决遇到的问题。所以，我负责的PE团队也尝试成立一个三四个人的小组来跟进某些业务线。他们每个人都可以尽可能多地了解相应的业务。当其他运维部门需要配合时，将这些业务需求转化为运维术语，传递给运维内部的其他部门。DevOps的原则DevOps的五个官方原则：文化（Culture）自动化（Automation）精益（Lean）数据测量（Measurement）共享（Sharing）专注于数据测量（Measurement）。如果监控不到位，小问题不容易发现，一旦出现问题，就是业务中断的大问题。大型互联网公司的监控工具一般对延迟非常敏感。例如，APM应用级性能监控工具在内部被广泛使用。如果一个应用的服务接口性能从100毫秒变化到120毫秒，很可能会触发告警，告警会带动大家排查接口性能慢的原因，是不是硬件问题，是不是网络问题，运维会配合开发进行详细排查。这些小问题会带动我们更多的从技术上去分析和思考，也会促使我们开发出更细粒度的监控分析工具来排查问题。DevOps系统构建应用全生命周期管理应用需要从立项到发布上线的完整生命周期管理，生命周期结束后不断迭代变更、扩容、缩容、迁移、下线。我们在管理应用的全生命周期时，结合内部流程系统、应用信息管理系统、自动部署系统，对外提供API接口。应用中心类似于CMDB，但CMDB有一些底层基础设施，如管理操作系统、物理机、网络、数据中心等。但应用生命周期更关心的是应用本身和周边的关联系统。一个应用项目的建立需要做很多工作，包括确定使用的资源包，根据业务容量、基础组件版本、网络拓扑、网络应用、网络权限等规划需要的节点数量。.项目建立后，会有很多信息变化。如果仅仅依靠文件记录每一次变更，在人员交接和调动过程中很容易遗漏和丢失信息，给后续接班人的操作带来风险。通过在系统间自动传输时自动记录应用信息，保证应用信息与生产环境的一致性。此信息还用作向外界提供接口的服务。例如，如果应用监控的配置与应用系统分开维护，每次应用扩容或缩容时都需要通知监控系统修改，容易造成应用扩容或迁移后的监控遗漏，带来潜在风险.而监控系统采用应用中心提供的接口数据作为基础信息，保证了数据的实时、准确，避免了重新配置各个系统的工作。InfrastructureasCode——DevOps的基础应用部署非常依赖基础环境，比如Python程序的部署，对Python版本的依赖，对底层OpenSSL等文件库的依赖，对运行环境的依赖系统。很多早期的运维都是通过脚本+配置文件的方式批量执行，判断需要的依赖环境，然后依次安装。每次执行前，可能需要临时修改脚本或配置文件的内容，例如操作IP列表文件。复杂任务和多人操作存在较大风险。Puppet、Ansible、Chef等配置管理工具很好的解决了这个问题。这些工具引导我们使用更多的配置管理方式，比如通过AnsiblePlaybook定义软件部署的依赖关系，通过角色分组严格控制执行目标状态，操作可以重复执行，问题可以准确定位到任意位置链接，结果更有保障。随着容器时代的到来，首先更好的解决了环境一致性问题。通过镜像封装将基础环境打包到容器镜像中，保证了从开发、测试到生产的环境一致性。Mesos、Kubernetes等流程编排工具可以更好的解决部署问题。你只需要关注应用本身的信息和部署的规模。该平台已经解决了大部分问题。熟悉技术架构的运维，就像开发人员一样，需要更多的了解技术架构和业务架构。只有更多地了解技术架构和业务架构，才能在生产遇到问题时更好地理解和处理问题，在理解研发提出的需求时更好地理解问题，甚至提出更好的解决方案。PlatformasCode业务架构中主要使用的一些基础组件：GSLB网关服务组件消息中间件缓存配置管理平台分布式调度APM日志平台未来展望数字化运维运维行业也将细分，业务运营角色而维护会越来越像一个数据化的运营，从应用的全生命周期持续跟进和优化，专注于更快的迭代、更高的访问质量、安全威胁和成本分析。这些问题也推动我们不断深耕技术，为业务提供价值。为了更好的质量，我们需要做以下数据监控：基础服务监控（网络、OS、DNS等）数据服务监控（DB、缓存、消息等）应用性能监控分布式调用跟踪监控日志监控业务指标监控智能运维——AIOpsAIOps也是现在很热门的研究方向，我分享几个主要的思考点：采集数据是基础，事件信息是汇总的，数据需要打标签；告警关联分析，查找根源；自动报警降级或升级；容量水线预估及自动扩容；从手动规则过渡到机器学习。希望以后找时间详细分享。王超，京东金融高级技术架构师，应用运维团队（PE团队）负责人，同时负责人人网PE团队。经历了京东金融运维系统从0到N的过程，经历了618、双十一大促的数次考验。目前主要围绕DevOps、运维与架构的融合、业务可用性保障、运维平台搭建和团队管理。
