何佳佳:基于开源的民生银行运维实践

本篇文章4785字，读完约12分钟

何佳佳:基于开源的民生银行运维实践 民生银行设计了一套自己的运维发展蓝图，主要由系统管理中心大数据专业平台团队独立设计，实现了开源大数据基础设施。此外，该团队基于开源标准实现了整个日志平台。基于这两个核心基本组件，建立了一系列操作和维护工具和平台。 2018年3月21日至22日，由中国信息通信研究院主办、中国通信标准协会支持的“奥斯卡”在国家会议中心举行。

作为会议的子论坛之一，银行发展论坛于22日下午举行。

李晓峰:让我们邀请民生银行的技术专家何佳佳分享民生银行基于开源的运维实践。开源系统中有许多漏洞，这就是为什么运输和开发的概念被结合在一起，新词被创造出来。既然你想建立一个开源的私有云，你就不能绕过开源。请让我们听一下民生银行的介绍。

民生银行技术专家何佳佳发表了题为《基于开源的民生银行运维实践》的精彩演讲。

以下是这次演讲的文字记录:

贺佳佳:各位领导、各位专家，大家好。我分享的话题是民生银行基于开源的运维实践。事实上，前任领导人和专家已经制定了一些关于云计算的指导方针，包括开发开源软件，包括引入蓝图。我将从底层操作和维护支持的角度来看如何做云计算，包括开源支持。

我在2003年参加了这项工作，现在基本上我只有两半。在上半年，在传统制造业中，我几乎完成了各个领域的大部分信息技术工作，所以我基本上对信息技术的各个领域都有一定的了解。下半年，民生银行被追加到基本做核心系统运维，包括关键组件的运维。在过去的两年里，更多的努力集中在工具平台的建设上，包括ITIL过程和开发平台。现在民生银行正在实施。

民生银行是一家特殊银行。它是第一家私有的国有股份制银行。它的发展非常快。其21年的历史已经从最初的10多亿英镑发展到目前的3700亿英镑。它有一个特点:业务和需求短，顺利，快速，有效和结果导向。那么，在这种情况下，我们将面临什么样的挑战？刚才提到的快速发展的业务有它自己的业务特点，包括它的灵活性和多样性。再加上近年来的互联网金融模式，对我行的影响比较大，但民生反应也比较及时。例如，余额宝出来后，如意宝很快就被划掉了。在这种业务开发情况下，业务架构的调整速度非常快，从而推动了底层应用架构甚至技术架构的转型和演进。同时，对技术迭代的要求非常高。从以前单一的开发和操作框架到现在的多元化框架，各种新技术层出不穷，如人工智能、机器学习等。当然，从封闭的商业软件模式转变为开源模式更为重要。有一个数字可以证明这些变化。2017年，我们更改了所有应用程序超过10，000次，并且仍在增加。

从信息技术的角度来看，我们主要是在2000年左右的单一应用架构。从2012年到2013年，随着新的核心项目上线并转化为SOA架构，从架构图中可以看出逻辑和应用架构的复杂性。在过去的两年里，出现了更大的跨度，分布和微服务的转变，以及新技术和新架构的高速发展。同时，刚才提到的新技术将引领业务，包括该应用领域的技术创新，也包括业务创新。例如，自2015年以来，我们与国家发展和改革委员会合作开展了一个金融云研究项目。经过两年的研究和积累，我们设计并实现了一个分布式微服务架构方案，并推出了一个分布式核心系统。该系统主要采用分布式架构，即我们当时做的金融云研究项目的登陆。此外，新的零售信贷系统利用大数据智能分析等新兴技术，实现了决策引擎、反欺诈、贷后监控等功能，给业务带来了巨大的业务创新，而且这种创新还很多。

当然，这也给我们的操作和维护带来了一些困难。从应用架构演进到技术迭代，速度越来越快，而我们的运营和维护支持能力的发展将会相对缓慢。存在两个主要问题，一是传统的运行维护模式，难以适应支持高速变化的应用和技术，导致运行维护的持续被动响应需求。二是依赖封闭的商业软件工具，需求有限，转型缓慢且不灵活，变相增加了运维的被动性，减缓了保障能力的发展。为了应对这些问题，我们也在思考如何打破游戏。

首先，我们将视角转向操作和维护模式。我们最早的是传统的组织结构，它将在许多专业领域建立中心，实现集中管理。职位将有明确的责任，职位之间将有一定的隔离。工具级别，包括过程级别，将比应用程序操作和维护级别有更清晰的定义。这种机制在当时是一种理想的情况，但它不一定适合不断变化的环境。我们如何改变它？我们正在考虑给该组织蒙上阴影。解决办法主要是从三个方面入手。首先是虚拟化。从最棘手的应用操作和维护点开始，我们建立了一个虚拟的操作和维护团队，将工作分组到业务相关组中，将它们分解成多个部分，通过虚拟的小团队提高灵活性，并鼓励跨组和跨中心轮换。在此基础上，建立了两个跨中心的虚拟团队，一个是过程团队，另一个是工具和平台团队。流程团队将在整个中心设立流程负责人，总体设计将控制各种信息技术流程，包括问题、事件、变更等。工具和平台团队也是多中心的，他们将考虑如何从实际应用场景中构建我们的工具和平台。在这种虚拟化划分的基础上，实现了整体的扁平化管理、统一的资源分配、统一的工作流，实现了更有效的协作能力，实现了全局信息共享，并对应用场景、工具和流程进行了深度集成和设计。

在工具和平台的层面上，我们已经转换并设计了一套我们自己的操作和维护开发蓝图，参考了AIOps的概念和忽略。核心基础能力层是我们的基础，主要由系统管理中心侧的大数据平台专业团队独立设计，实现基于开源的大数据基础设施。此外，该团队实现了一个基于开源的日志技术平台。中间逻辑平台层包括三个方面。一是监控，主要是基于开源的Zabbix来构建监控系统；在自动化和DevOps部分，以前更多的使用商业软件，开源软件Ansible、Jenkins等软件逐渐作为后台来封装和集成上层。这两者通过信息技术服务管理进行互动和流动。最外层是应用程序场景层，它将从应用程序操作和维护的角度来看特定的难点或需求，并推动消费场景的设计。我们仍然相对积极地开拓新的收入来源，并且发展迅速。例如，大数据平台团队现在不仅使用开源软件，还为社区做贡献。慢慢地，我们将从购买和使用封闭的商业软件转向商业软件和开源软件的集成。以下是对这些级别情况的简要介绍。

核心基本能力主要指大数据基础架构。设计并实现了三个集群，包括计算集群、非计算集群和实时计算集群。这三个平台执行各自的功能，并服务于批处理数据任务、在线查询、实时消息和流处理。如何控制如此多的资源是一个大问题。大数据控制平台是我们团队专门开发的，用于支持大数据基础架构的运行。平台层实现了接口逻辑和执行层Ansible的封装。它支持项目管理和功能管理，以及批处理作业启动和资源库使用监控和跟踪。日志技术平台主要基于ELK技术栈。我们建立了全行的整体日志视图，总行和分行的层级架构，并通过平台管理所有日志。包括日志收集、传输、存储、分析和可视化，都是在这个大平台上完成的。

在监控方面，二次开发和包装主要在zabbix上进行。一是建立新的监控系统，二是与旧的监控平台整合。通过大数据平台分析和后处理响应行动。此外，我们最近在实施容器云和容器监控方面做了重要的工作。我们还通过基于Zabbix的新监控系统支持集装箱。

接下来是关键的应用场景层。我们从应用操作和维护的角度来设计和实现应用场景。我想给你介绍几个场景。第一个场景是平台全景运维平台，实现实时业务数据分析和可视化。主要功能包括业务数据可视化、实时分析、根本原因分析和问题诊断、系统交易质量(包括变更和风险)的主动感知以及及时反馈。该项目去年获得两项大奖，一项是金融电子化颁发的运维创新贡献奖，另一项是行业科技创新二等奖。这个图更直观，当前银行架构越来越复杂，如SOA，分布式和微服务都面临着同样的问题。例如，一个3秒钟的交易必须经过许多城市的计算机房和系统，包括服务器。如何定位和找到问题的原因实际上是一个特别困难的话题。

下图是过去的真实案例，这是一个特别费力的诊断过程，由相对较慢的本地事务问题引起。这里不再详细描述，但有两个主要问题急需解决。一是全局优化不能直接告诉我们哪一点是异常的，二是局部问题隐藏在大量的全局事务中，难以定位。

基于这些难点，我们开始启动这个项目。主要设计思想是绕过应用服务运行过程中不易察觉的信息收集和各种检查的自动完成，通过应用编程接口、多维分析提供给上层进行实时显示，甚至通过动态规则引擎和机器学习的参与反馈给上层进行问题根源分析和整体操作融合实时显示。下图是当前的实现。一个是非常简单的主页条目。它可以输入多种元素，如返回码、IP系统缩写、序列号、服务名称、日期、系统A和系统B之间的访问关系等。背景自动区分并输入不同的分析视图。此外，您还可以直接访问系统的全局操作视图，该视图实时显示系统的运行状况以及每个系统之间的链接。如果较低级别的指标发生变化，它将在较高级别做出快速响应。例如，它将以红色突出显示，并且问题及其原因可以很快知道。该视图支持向下单击应用程序或链接视图。我们建立了交易量、业绩和异常三个指标集，并围绕这三个指标集进行了多维分析。

应用程序视图用于显示应用程序和事务链接的情况，并围绕刚才提到的三个指标集进行分析。通过动态规则引擎和机器学习，进行分析和判断，识别异常变化和趋势。例如，左下角的服务调用分析通过规则判断显示当前交易情况和同一历史时期的正常情况，并进行比较和显示。此外，还有对交易高峰的分析。我们可以在界面上快速拖拽，快速识别异常点和问题原因。

以下功能场景是单个事务链接分析。这部分功能对操作和维护非常有用。例如，图中的这种端到端事务调用要经过十几个系统和服务。通过该功能，您可以直观地看到哪个原子服务慢，哪个链接异常。

该平台的整体框架相对简单，数据分析逻辑是基于大数据平台实现的，使用了卡夫卡、火花流、专家系统、再贴现等组件。过程可视化层使用民生自己的开放框架来形成一个平台，而上层使用开源用户界面组件并嵌入自然语言处理。

第二个应用场景是我们的自主创新项目实时指标驾驶舱，用于显示商业银行的基本经营指标，包括资产、负债等实时信息。民生银行过去只能在T+1日报告中查看前一天的数据。通过这个新框架，它现在可以在几秒钟内近乎实时地看到当前的指标，包括存款和贷款等各种指标。现在，我们的银行领导每天必须多次检查这个功能。该功能可以方便地查看手机上的实时情况，实现对多维度的深入分析，如按组织统计。此外，它可以快速识别变化较大的事务。将不详细描述逻辑角度。它主要包括三层:数据访问层、数据计算层和接口服务层，最终提供给手机显示。

第三种情况是更多分布式系统上线，提供关键的分布式事务跟踪功能。分布式体系结构中的调用很复杂，很难排除故障。我们使用分布式服务框架按照规范定义逐一记录呼叫信息，使用专家系统进行持久存储，并集成开源的Zipkin进行分布式跟踪显示，这样分布式系统的问题定位将非常方便。该功能与以前的Onplat项目相连接，实现了外部调用和内部调用的联动集成。

四是一目了然的平台，实现基于模板的快速配置，将交易信息、各种中间件、服务器、数据库等底层基础设施的信息收集在一起，从而一目了然的看到应用系统的整体运行情况。

刚才提到的应用案例只是我们操作和维护工具和平台的一部分，以及其他工作。例如，在正在进行的标准化组件的开发中，我们已经建立了供应用程序开发团队使用的标准日志组件，并且还在设计其他类型的组件。下一个操作和维护步骤的计划分为几个方面。一方面，应用程序场景被深入设计，其中一些开始满足业务需求。我们正与业务部门合作推广这一点。另一方面，它将加强前端平台层面的建设，即时通讯的联动，并提供更丰富的API、移动显示等。同时，计划通过机器学习将更多的海量数据抽象到知识管理系统中，然后形成一套固定的后处理方案，通过自动化实现自愈自主。

这都是我的分享，谢谢！