博时基金的DevOps实践

车宏原

博时基金信息技术部总经理

APP201

Microsoft Tech Summit 2017

微软技术暨生态大会

朱盟

博时基金信息技术部总经理助理

目 录

Microsoft Tech Summit 2017

微软技术暨生态大会

基金行业的IT挑战

转型要求和思路

应对策略和实践

变化和未来

行业业务发展快，竞争态势复杂

1998

首批全国社保基金

投资管理资格

2005 QDII资格特定客

户资产管理资格

2011 首批保险资金

投资管理资格

2002

首批公募基金

投资管理资格

2008首批企业年金基

金投资管理资格2012首批

RQFII资格

2016首批基本养老保险证券投资管理资格

从传统公募和专户到

大资管

从传统渠道销售到

互联网金融

从中国大陆业务到

国际化

成熟技术应用带来

行业变革

自主研发能力，难以满足期望

人员怎么管 生命周期管理 应对业务变化 产品化开发 开发能力

• 成本高、变动大、水平参差不齐

• IT员工规模管不上去

• 外包人员规模管不上去

• 代码未妥善管理

• 文档、代码注解不全

• 缺少开发管理历史资料

• 合作开发不能在甲方管

• 集成和部署效率低

• 业务部门不了解需求开发进度

• 管理层不知道IT在干什么

• 跟着零碎业务需求跑

• 没有统一的架构把空

• 不重视分析和设计

• 版本管理混乱

• 面对大型复杂系统开发，无从下手

• 积累了多年的系统更新换代，困难重重

信息系统的自主研发能力，在一定程度上决定了业务能开展的广度和深度，长远看还决定了传统金融行业在互联网时代的生存能力和创新发展能力。

目 录

Microsoft Tech Summit 2017

微软技术暨生态大会

基金行业的IT挑战

转型要求和思路

应对策略和实践

变化与未来

转型目标转型目标：IT快速应对业务变化，推动与引领业务转型

建设三个能力

大型开发团队的管理能力

大型复杂系统的开发能力

产品化系统的开发能力

关注三个重点

加强产品化思维

改变开发和运维协作模式

持续改进，持续创新

重点1: 加强产品化思维改变以往欠缺规划设计、没有统一架构把控的开发方式，转变为产品化研发思维，提升IT价值。

问题

• 业务部门各层级需求散乱， IT部门疲于奔命地跟着业务跑，久而久之造成IT系统繁杂混乱，没有统一的架构把控；IT部门沦为业务部门短期业务目标的附属品，加强了IT部门成本中心的印象。

转型思路

• IT部门需要加强架构把控，在建立的规范化的研发流程中，发挥产品经理和架构师作用，强化IT部门对产品的规划设计能力，交付能力。

• 减少意外问题和重复性工作，高效满足了业务散乱的诉求，要让IT团队可以有更多的时间投入更有意义的产品规划和创新中去，逐步加强IT部门的影响力。

重点2: 改变研发和运维协作模式改变以往严重依赖运维获取用户好评的方式，转变为研发运维一体化模式。

问题

• 系统运维表现，决定了用户对IT的评价，因此投入顶尖的人员到运维部门，造成“救火”模式来解决问题。

• 高水平运维人员变为研发人员，随意改动系统，不会对IT系统进行长远规划。顶尖人员做运维，也会因成就感不足，造成人员流失。

转型思路

• 加强研发过程质量管理，减少运维阶段问题。

• 一线运维重沟通能力，二线运维重研发能力。

• 通过自动化持续交付实践，逐步降低软件交付过程的复杂度和人员依赖性。

• 为开发人员提供自助式的运维服务能力，逐步将人员结构向研发倾斜。

• 通过基础架构即代码的实践，改变运维服务模式为运维能力模式。

重点3: 持续改进，持续创新

建立持续改进，持续创新机制，转变IT部门为企业业务创新的主体。

问题

• 互联网金融的崛起揭示了IT在金融业的重要地位。

• 高盛、纽银梅隆等CEO称自己是IT企业，FinTech被传统金融机构热捧。

• 但实际上，很多公司的IT作用有限，仅能做到对业务运营的支持，很难起到公司期待的推动和引领作用。

转型思路

• 打好基础，包括IT文化、研发管理体系、先进技术架构。有了好的基础，IT才有能力前置，参与业务创新。

• 构建双模IT的研发模式，兼顾可靠与敏捷、确定性与探索性、传统与创新等研发思想。

• 管理能落地，改进能固化，建立相应的组织、流程、平台，建立持续改进，持续创新机制，稳步推进、逐步深化转型。

基于敏捷的研发管理

敏捷认为软件研发过程相比传统项目管理过程多出了2个关键的可变因素：价值和质量。软件项目的计划必须将变更考虑在内，视作正常情况，用计划来适应变化，而不是约束变化。

从敏捷到DevOps：研发转型逐步深入

全面启用CI/CD流程

引入Docker容器化技术

环境标准化统一管理

完善应用发布审批流程

减少人工参与

引入容器编排平台

实现应用无停机更新

启动微服务架构改进试点

需求

BACKLOG

RELEASE

运维研发

可交付产品

构建 | 评估 | 改进

团队协作

运维

研发完善配置管理流程

引入单元测试和自动化测试

持续集成提供调测环境

加速开发和测试反馈速度

提升测试环境获取效率

发布

规划需求管理流程

项目管理流程

迭代规划流程

报表和监控反馈容器监控能力建设

持续反馈能力建设

DevOps – 软件研发管理的行业趋势和价值DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技

术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品

和服务，开发和运营工作必须紧密合作。

• 更快的业务响应速度• 行业领先团队的部署速度快 200x，问题修复速度 快24x

• 更稳定可控的质量• 行业领先团队的变更错误率低3x，降低线上问题修复时间 2500x，减少22%的意外问题

• 更高的安全性保障• 行业领先团队少一半的安全性问题

• 更高的员工满意度• 更高的工作热情和主动性，更愿意向其他人推荐自己的企业和产品

• 更高的ROI投入产出比• 减少重复性工作，减少宕机时间，让员工有更多的时间投入更有意义的工作，如新功能开发

数据来源：“PuppetLab 2016 State of DevOps Report” 中汇集了过去5年中超过2,5000名来自全球的技术专业人士的调研结果。

https://puppet.com/blog/2016-state-of-devops-survey-here

双模IT（bimodal）

• 目标1：持续稳定现有业务的发展，即如何依托现有的运营能力保持业务稳步增长。这

个业务目标对于IT的直接要求是安全、稳定，不要出大事，小事快速解决。

• 目标2：推陈出新，布局新的产品和模式。该目标要求高度灵活、适配的IT能力，灵活

性强调快，适配能力强调了弹性。

• 既要支持和推动传统核心业务的高速稳健发展，又要能够敏捷、高效地探索业务创新

公司同时面临两种压力

• 模态1（Model 1）叫做可靠（Reliable）IT，其强调安全性和经济性，其对应上述的目

标一；模态2（model2）叫做敏捷（Agile）IT，其强调的是速度和灵活性，对应上述

目标二；

• IT管理不是一个简单的两者取其一的问题，而是需要在上述两者不断平衡决策的问题；

• 从长远看，模态1和模态2会长期并存，可靠的IT奠定了敏捷的基础，敏捷又促进形成新

的稳定。

双模IT

空中换引擎，转型过程不影响对业务支持

对转型的理解和支持

管理流程、管理工具、操作习惯的转变

既有经验与新兴的技术、创新的业务需求之间的碰撞

获得的收益项目背景：该项目是2016-2017年重大项目

• 业务复杂，系统价值和质量把控难度大。需求涵盖多个业务部门、涵盖投资前中后台业

务，专业性非常高。

• 限定开发时间，进度把控难度大。业务急需，限定在某个时间点前大部分功能上线。

• 项目规模大、人员构成复杂，资源管理难度大。峰值时开发和测试人员超过xxx人，分

布在不同城市的不同地点，有正式员工、长期外包人员、项目合作人员。

项目三大难点

• 研发管理转型的实践，建立了大型团队管理能力、大型复杂业务系统开发能力、产品化

系统的开发能力，助力该项目顺利开展，并实现高水平建设目标。

• 建立从需求到运维的强大的端到端协作平台，实现各阶段任务的分配与高效协同。

• 建立量化指标和报表，实现进度、成本（资源）、质量的有效管控。

• 建立版本管理和配置管理，衔接过程管理和工程管理，提升产品化水平。

• 建立自动化持续交付能力，开发团队更多精力关注业务难点，关注价值和质量的实现。

研发管理策略

能力提升

快速交付

成本控制

价值与质量提升

推动和引领创新

提升资源配置比例

IT战略规划框架的重要基石

成熟先进的基础设施

先进高效的管理体系：敏捷、DevOps

科技与业务融合的IT文化

新一代业务系统先进技术架构BOFA 企业数据中心

支持高速发展、快速应对变化

把握金融科技创新、推动和引领转型

目 录

Microsoft Tech Summit 2017

微软技术暨生态大会

基金行业的IT挑战

转型要求和思路

应对策略和实践

变化与未来

形成流程的实时反馈回路

建立全局观 建立反馈 持续改进

• 应用生命周期系统建设• 量化管理能力建设• 指标体系建设• 报表体系建设

• 配置管理能力• 自动化能力• 工艺改进团队建设• 内部知识库建设

研发流程模型化 研发流程数据化 研发流程可视化

流程持续改进

建立度量

持续评估

发现问题

提出方案

执行改进

进行总结

建立流程

工具落地

Plan：根据评估结果发现问题，并提出解决方案；给出流程规划和操作指引，与项目组确认，形成最终方案。

Do：实施改进方案，并随时跟踪项目组反馈，对方案有效性进行持续评估。

Check：任何的改进都必须能够被评估，评估可以是主观或者客观。

Act：被评估证明效率有所提升的，形成流程并在工具中固化。

研发流程改进• 需求过程• 开发过程• 测试过程• 运维过程

实践 – 实施全景图

实践 – 逻辑结构全图

实践1 –ALM-TFS的使用

Ant, Maven, MS BuildTFS Release

Selenium

项目管理

小秘、禅道

配置管理

TFS Web Portal

配置管理工作项追踪

（需求、任务、缺陷…）

自动化测试持续集成持续发布

集成的报表与分析测试管理项目规划与管

理

端到端的集成与追踪

SQL Server Reporting ServicesSQL Server Analysis Services

SVN

原有平台

软件研发协作统一平台

研发运维一体化

服务器监控反馈生产问题

TFVCGIT

TFS Work Item Tracking TFS Web Portal System Center

数据辅助决策

测试及缺陷管理

HP QC

自动化UI测试

无

发布管理

手工

运维监控

未知

研发大数据

无法提供

研发流程透明化规范化 开发人员效率提升 提高软件交付质量与效率实施效果 快速响应业务变化、早于客户发现问题

实践2 – 配置管理方式转变

实践2 – 配置管理方式转变

完整

灵活

受控

可回溯

基线

代码

易理解

可重复

速度快

依赖明确

定位异常

一次构建，

任意部署

构建

易理解

状态可查

记录

依赖明确

环境变化需

重新构建

环境

易理解

需计划

授权和审批

紧急变更

变更

易理解

可靠

快速

标识ID

包含依赖

核查机制

发布

简单

可靠

可追溯

日志完备

必须授权

检测机制

监控程序

不断改进

部署

实践2 – 试点系统版本管理策略

MasterB

v1.0 release 运维or其他Branch

测试

T RI

FI FI

RI

TT

v1.1 release v1.2 release

bug

B

T T

FIT

测试 测试

本地1

本地2

原则不允许Branch之间发生交互，Branch只能与Master发生交互

Master和Branch有新迁入时，需进行静态代码扫描、项目构建、单元测试、发布包生成

Master中配置参数默认为开发环境参数

测试环境及生产环境配置参数由对应环境管理员控制

建议每个Branch拥有独立的开发集成环境和测试集成环境

上线回撤操作时，一般建议回撤至最近一次成功上线版本

实践3 – 工程自动化程度提高

CodeReview &Discussion

PR 触发的预构建

合并到master

• Squash• All Commits

部署到DevTest 环境.

部署到SIT/UAT/Prod

环境.

CI & CD 工作流 监控编码工作流

编译单元测试

静态代码分析

发布包准备

远程创建/操作 DevTest

环境.

Docker Pull& Run

UI 自动化／性能测试

手工测试／用例

远程创建/操作Prod环境

远程操作UAT环境

Docker Pull& Run

UI 自动化／性能测试

手动验证／测

试

Docker Pull& Run

上线验证

• Auto• Image:test

• Approval• Image:uat

• Approval• Image:production

获取代码

Performance,Log &

Analytics

Performance &Log

Performance &Log

包／依赖管理

DockerBuild &

Push

实践3 – 自动化工具的引入

领域 工具

静态代码扫描 SonarQube

自动化编译 Maven

动态代码扫描 Junit

自动化测试

接口 POSTMAN、KUGA_BDD

性能 Jmeter、Loadrunner

UI ui automation、selenium、Appium

自动化发布发布 自研发布小工具

监控 NetGain、APM监控、自研业务监控平台

实践3 – 工程自动化实例

实践4 – 容器平台的建设

实践5 – 度量系统：研发数据模型

实践5 – 研发管理指标体系建设

研发管理指标体系

过程管理指标

工程管理指标

事务管理

交付物管理

资源管理

代码质量

测试质量

版本质量

实践5 – 研发报表体系

研发报表体系

组织级

项目级

团队级

研发管理指标体系

过程管理指标 工程管理指标

事务管理 交付物管理 资源管理 代码质量 测试质量 版本质量

项目进度表 资源使用表

项目进度子表

团队进度报表

代码度量

提交度量

跨平台，跨技术栈，跨

项目

异构技术栈

统一代码质量度量

测试用例度量

缺陷度量

版本维度上的多级质量，进度，事务综合报表

实践5 – 研发报表

实践6 – 研发管理转变

流程建模（需求、研发、运维）

明确流程各阶段产物

使用建模管理工具

事、人管理的分离与结合

追踪

质量

敏捷

更高的研发管理要求

实践6 – 统一建模的使用

实践6 – 研发场景定义

实践6 – 研发成果定义

实践6 – 运营方式的转变

DevOps

ITIL

实践6 – 运营方式的转变

变更计划会 –变更计划看板

变更回顾会 –运营报告

更高的自动化程度

基于变更管理进行日常运维工作

从负责操作变化为管理变更过程

目 录

Microsoft Tech Summit 2017

微软技术暨生态大会

基金行业的IT挑战

转型要求和思路

应对策略和实践

变化与未来

变化 – 总体

能力的提升

大型复杂系统的研发及运维能力

大型开发团队的管理能力

产品化系统的研发能力

快速应对业务变化

需求、研发和运维的高效沟通机制

变化 – 项目管理

一个规范的研发流程管理体系

研发过程规范化、数据化、可视化

更强的项目管控能力

更可靠的运维机制

需求质量的提高

发布效率上升

变化 – 配置管理

配置管理成为研发管理工作的核心

配置管理更灵活并可追溯

更高的信息安全管控

更高的风险控制

自动化程度逐步提高

形成一套可持续改进的配置管理方法

变化 – 团队

成员更具有全局观

一个研发团队

职责全栈VS技能全栈

逐步形成有效的培养体系

招聘及管理成本下降

良好的外部专家合作机制

变化 – 困难

旧系统的改造

数据库配置管理策略

人员技能的转变

团队思路的转变

如何让业务加入进来

未 来

继续提高配置管理水平

继续完善基础服务建设

推进基础架构管理的变革

岗位角色的变化

业务模型成为公司的核心资产

IT真正成为企业的一种能力

更多信息和资源

Azure 中国官网站: https://www.azure.cn 最新产品与解决方案信息

中国区 Azure 官方文档: https://docs.azure.cn 提供产品服务文档，开发人员指南，代码样例和 SDK 下载

Azure 在线培训: https://school.azure.cn 提供面向场景的项目搭建教程，Azure 专家大咖专栏，和网络直播课程

Microsoft 云科技公众号 (ID: MS_CEChina) - 最新行业资讯、产品介绍、案例分享

Azure 云技术支持公众号 (ID: VNET_AzureSupport) - 由世纪互联运营的 Microsoft Azure 公有云平台技术支持

Microsoft 云科技公众号 Azure 云技术支持公众号

中国区 Azure 官方文档 Azure 在线培训

谢 谢 !