智能运维在金融核心领域的研究与应用

本文由 dbaplus 社群授权转载。

各位朋友大家好，很荣幸今天能跟大家分享关于智能运维的一些研究和实践成果。

分享概要

1、背景介绍

2、智能运维研究

3、智能运维应用实践

4、智能运维实施路径

一、背景介绍

在开始演讲之前，我先简单介绍一下中国结算。我们公司是中国证券市场的中央证券登记结算机构，负责上交所、深交所、股转公司所交易的全部金融产品以及部分场外交易产品的登记、存管、结算业务。

作为资本市场的核心基础设施，我们所负责管理的证券总市值近 67 万亿元人民币，在我们这里开户的投资者总数超过了 1.5 亿，跟我们打交道的主要是各个证券市场参与方，包括沪深交易所、证券公司、结算银行、上市公司、香港结算等境内外的将近 4350 家市场参与方，我们与他们进行各类数据交换，来完成登记结算业务处理。

我们的技术系统既有传统主机，也有开源开放平台。传统主机负责后台批处理业务，开放平台负责前台实时业务、在线交互业务。因此我们的技术系统需要同时具备高安全性、高可靠性及海量处理能力。

目前的技术系统能满足这样的高需求，但资本市场每年都有创新业务。前些年沪港通、深港通，去年的沪伦通、今年的科创板，还有未来要推出的交易所与银行间债券市场互联互通，这些业务都会导致证券登记结算系统与外部的耦合度增加。为了满足未来发展需要，技术系统在转型，从专有化向国产化转型，从集中封闭式向开放分布式转型，从双数据中心向多数据中心转型。而在转型发展中，技术系统传统运维模式将面临着三大挑战。

一是安全运行挑战，我们公司对安全要求非常高，现在传统运维模式是事后处置模式为主，这个已经不能满足需求了。二是人力紧缺挑战，技术系统运维工作量大，而且风险很大，运维岗位特别是值班岗位的吸引力逐渐降低。三是远程运维挑战，一般来说数据中心地理位置是较为偏僻，多方面因素使得运维成本逐渐增加，可用人力资源日趋紧张，运维压力日趋增大。

传统的现场运维、事后处置为主的运维模式有必要得到改变，才能进一步的提升技术系统安全性、稳定性和高效运行能力。而当前主流运维技术已从自动化运维向智能运维发展，如何利用人工智能来辅助甚至部分替代人类，以此进一步提升运维质量和效率，成了当下研究的热点。

现在主流运维技术已经从自动化运维向智能化运维发展了，我们开展了智能运维研究，希望能回答以下问题。

• 一、智能运维到底是什么，它的定义是什么？

• 二、我们引入智能运维的目标是什么？

• 三、在传统金融机构中，如何找出合适的应用场景。

• 四、基于当前运维现状，如何构造智能运维的技术架构。

• 五、这条智能运维道路该怎么走，该采用何种实施策略。

二、智能运维研究

运维是什么？其实就是技术人员想尽一切办法用尽一些手段，使系统处于一种长期稳定，高效安全可运行的状态。早期的 1.0 时代的运维是采用手工的方式，耗时耗力，风险也大。

之后的 2.0 运维是自动化运维，利用工具部分替代了人的操作，实现了大规模和批量化的操作，比如说利用脚本来实现对系统监控、发布部署等等。现在大部分金融企业都已经是自动化运维了，也用了很多的自动化工具，软件有监控、硬件有监控、机房环境也有一个监控系统，工具多，而且功能日渐重叠，层次化、模块化都有不足，监控、运维、告警各成体系，缺乏统一化体系。并且自动化运维的本质依然是人与自动化工具相结合的运维模式，人工决策与实施是运维的主要驱动力，受限于人类自身的生理极限以及认识的局限，无法持续地面向大规模、高复杂性的系统提供高质量的运维服务。

3.0 时代的智能运维则是通过机器学习等人工智能算法，自动地从海量运维数据中学习并总结规则，并作出检测、预测以及决策的运维方式。它能够模拟人类运维的操作，甚至能帮人类做出运维决策。它就像是一个机器人，不眠不休的帮我们盯着系统，不仅能对异常做出预警，而且在出现异常后，它能迅速帮我们查找引发异常的原因，甚至能主动修复异常。

相对于手工运维、自动化运维而言，智能运维的优点体现在效率高、可用性高，我们学习使用智能运维的成本低，就像智能手机那样简单方便。

但缺点也显而易见，一是建设成本高、研发难度大。毕竟用智能手机简单，但是研发智能手机困难。二是它是一种新技术，很多公司都处于起步阶段，这就意味着未来发展中遇到的坑，可能没什么先例可循。

为什么说它是一种新技术呢。这是一张 2017 年 Gartner 发布的成熟曲线图，在这张图中，智能运维就像刚出生的婴儿，它才刚起步。

那最近的情况又怎么样呢？我们开展了广泛的调查研究，发现智能运维不仅在科研领域有诸多的研究成果，甚至在多个行业已经落地了。自从 2016 年智能运维概念提出，到现在就有多个产品与应用落地，智能运维之所以热也是因为它已展示出强大的生产力。

回过头来看智能运维的定义，智能运维其实是基于人工智能算法，分析挖掘运维大数据，从海量的数据中学习并总结规律，最后利用自动化工具模拟人类实施运维操作、实施运维决策的过程。也就是说智能运维由算法、数据、工具组成，它们就像是人的大脑、眼睛、手一样密不可分。

运维大数据平台是眼睛，用来采集、存储运维数据，能将各种各样的数据信息转换成有价值的、格式统一的数据。那么什么是运维数据呢，它有哪些组成呢？我们梳理了运维数据由三部分组成，分别是监控数据、日志数据以及配置信息，前面两个是系统运行中产生的动态数据，而配置信息则属于静态数据，它们都是用来描述系统的状态。

和一般的大数据平台基本一致，运维大数据平台也是由数据采集层、存储层、计算层、展示层所组成。不同的是在计算层中，离线计算是对历史数据进行批量分析与计算，得出运维主体画像和运维知识图谱，实时计算是对实时数据进行在线计算，一般用于做检测、预测、查询等。因此数据计算层是智能运维算法所工作的区域。

智能运维算法是大脑，它有两个阶段，第一个阶段是通过人工智能算法挖掘运维数据，构造、训练系统的模型，用来描述系统的特征。第二个阶段是利用训练好的模型对系统的状况作出检测、做预测、做决策。这两个过程类似于一个医生的培养，通过第一个阶段的学习、训练，熟悉了解各种疾病的原理以及治疗手段，在第二个阶段实际看病的时候，就根据不同的病人的症状对症下药。

详细来看第一个阶段，如何构造、训练系统的模型，就是通过多种算法挖掘运维历史数据，从而得出运维主体画像，然后构建运维主体之间的关系，最终形成运维主体的知识图谱。这里有三个概念，运维主体是指系统软硬件及其状态，画像是描述运维主体的自身属性的描述，比如说容量画像、指标画像等。知识图谱是基于画像，用来描述主体之间相互关系，比如说故障失效传播链。

举个例子，如何来构建故障失效传播链。我们知道系统的异常，它的源头都是由故障引起的，在分布式环境中，这个源头故障可能并不是本系统的，可能是其他服务器上的软件 bug、硬件异常或者参数配置错误所导致。因此这里就存在一个链条，就是故障失效传播链条。

构建故障失效传播链条是对失效现象进行回本溯源的分析，查找引起该失效的可能的故障原因。有很多种方法可以用来获取失效传播链条，其中一种是基于故障树的分析方法，通过各个应用模块的调用链和软硬件的配置信息获得业务之间的逻辑调用关系，以及物理模块的关联关系，构成可能的故障树用以描述故障传播链。利用机器学习的方法，对该故障树进行联动分析与剪枝，形成最终的子树，这个子树就是故障失效传播链。其他的算法，还有随机森林、孤立森林、Pearson 关联分析等。

如何利用训练好的模型、知识图谱呢，那就要依靠动态决策类算法了，这个就是智能运维算法第二个阶段要做的事情。动态决策类算法就是用已经挖掘好的运维画像与知识图谱，结合实时监控数据作出检测、作出预测，作出决策。比方说，可以用训练好的故障失效传播链对现有的系统状态进行分析，将实时的运行状态信息与模型中的故障特征进行匹配，预测未来一段时间内发生失效、发生异常的概率。

另外一个例子就是单指标异常检测，是对系统中单个 KPI 关键性能指标的异常，比方说突增、突降、抖动进行识别和检测。这种持续时间短的指标抖动并不意味着系统现在出现异常了，但它代表系统存在一些潜在的故障，如网络故障、服务器故障、配置错误等等。

通过智能运维算法的结果，运维人员可采用多种运维手段，如切换流量、替换容器等方式规避系统失效，保障系统稳定运行。而这些运维手段其实还是需要依靠自动化运维工具。

自动化运维工具是一双手。它是基于确定逻辑的运维工具，可以对技术系统实施诸如重启、回滚、上线等系列操作。自动化工具是 2.0 自动化运维的产物，也是智能运维算法作出决策后，实施具体运维操作所依赖的工具。刚才说智能运维算法是培养一个医生，那么自动化运维工具相当于是医生开的药、打的针、做的手术，是直接作用在技术系统上的。

其实从这里，我们也能发现，智能运维与自动化运维的关系并不是离散的，分割的。智能运维与自动化运维其实是相辅相成，完善的、标准的自动化运维会使智能运维实施更加迅速，智能运维反过来也是对自动化运维的一种能力增强。

为了保证每一次运维的操作最终能反过来增强智能运维的能力，这就需要有一个运维的闭环。智能运维闭环不仅包括运维主体画像和知识图谱的构建和利用，也包括运维人员的经验反馈，以及系统变更的反馈。毕竟智能运维决策是不能百分之百保证准确，仍然需要实战来不停的修正和调整。

运维人员依据智能运维决策，或者异常修复建议，来对技术系统进行运维操作，有些运维决策是有效的，有些可能是无效的，最终需要人工标注有效的建议，剔除部分无效的建议。

因此，智能运维系统就可以从运维人员的标注中，通过强化学习来增强运维决策能力。当然，运维人员对技术系统的部分运维操作，比方说新版本上线、系统扩容、配置参数调整等等，是会影响技术系统，也会对运维主体画像和知识图谱产生影响，从而对智能运维决策造成影响。所以需要重新来计算获取运维主体画像和知识图谱，因此智能运维闭环的运行过程类似于一个循环上升的过程。

三、智能运维应用实践

了解了智能运维是什么，那么我们该怎么做。

目前我们的运维面临 安全运行、人力紧缺和远程运维的三大挑战，因此我们实现智能运维的主要目标可归纳四点：事前智能预警、事后快速定位、夜间无人值守、远程集中管理。

1）事前智能预警是在异常发生前，就能通过微小的征兆做到提前感知。就像是地震、山洪自然灾害爆发前的会有一些不一样的征兆，感知这些征兆，提前预测危险。

2）事后快速定位是在异常发生后，从报警信息中分析异常发生的原因，甚至能基于历史经验，给出最好的处理建议。

3）夜间无人值守是我们考虑到交易结算系统是证券市场核心基础设施，需全天候安全保障。但在非交易非日终处理时段，特别是夜间，系统需要处理的业务量相对较低。因此可以采纳无人值守，实现夜间操作无人化，进一步解脱运维人员。

4）远程集中管理则是对地理位置偏僻的数据中心采取远程监管的手段，比如说用智能巡检机器人，代替人工巡检。从而减少派驻现场值守的人员数量，降低运维成本，解决人力资源紧张等问题。

为达到智能运维的目标，结合当前运维现状，我们梳理了能够落地实现的四大类应用场景，分别是：智能预警、智能检测、智能值守与智能巡检。

智能预警则是在异常发生前，预测异常发生的概率，从而提醒或有针对性的对异常提前规避。主要场景有日终作业预测、关键路径智能分析、以及指标预警。

我们技术系统最重要的一项工作就是做日终处理，跑批处理作业。日终作业预测是对作业的运行时间进行预测。怎么来预测呢？首先构建每个作业任务的运行时间特征模型，看它是与哪些数据有紧密联系，比如说成交量、权益数量、回购成交数量。

然后用历史的数据来训练这个模型，最后利用模型来预测。我们对作业做了分析，发现很多是可以用来做预测，而且误差值都不超过 10%，比如预测日终存管数据发送作业的完成时间，预测的误差就在 3.7%以内。

批处理作业是按照一定的关联条件组织在一起，合并成多个作业运行图，然后被系统自动调度运行的。关键路径智能分析，就是以日终作业预测的结果为基础，将运行图上的作业运行时间进行组合，预测我们关注的核心任务作业的最终完成时刻。

比方说，有一个作业运行图在下午三点正式启动，我们要来估算存管数据发送这个作业什么时候能完成。但是估算并不是简单的将路径上的作业时间加起来，因为每个作业运行时间的预测值与实际值是有误差，必须要根据实际的完成时间利用算法不停的修正。

这就像是我们走迷宫一样，从入口到出口有很多条道路，而我们要选择是一条时间最长的道路才能计算到出口的时间。但这个迷宫不好走，每走一步，迷宫的障碍物可能会重新排列组合，在走下一步之前就需要重新计算了。

目前预测的结果与实际的结果拟合度，或者说相似程度超过 90%。也就是说我们现在有能力能够精准预测关键作业的完成时刻了。当今天成交量很大的时候，我们就能够预测发送给香港结算、参与人的数据能具体在几点几分发完。

智能预警第三个场景是指标预警，它是针对某一应用或系统，根据其历史运行的信息，基于时间序列构建其正常运行的基线（其实就是它的一个指标画像）。

然后，再结合该应用当前的运行状态、指标数值，来预警是否出现异常。比如说 web 应用服务器的可用线程数量，假设它出现了一个急剧的下降，可能这种孤立的现象对当时的系统可用性不会造成什么影响，但若在业务高峰期持续发生，将会大概率导致应用服务器的性能下降，这个服务器上的其他应用也会因此受到影响，就无法正常对外提供服务了。

下面这张图就是可用线程数的一个示例，橙色代表是可用线程数的历史趋势图，也就是一个正常的范围，蓝色代表实际的变化曲线图。那么可以发现在一个时间段内，它的线程数是出现了急降，这个可用线程数指标异常也就意味着未来一段时间可能会出现问题，这个预警就意味运维人员需要介入了。

目前，在智能预警这个场景下，我们打造了预警平台，是对作业预测、关键路径分析、指标预警的一个综合展现，它能对多个关键的技术类指标和业务类指标实现预警。

既能做连续的基于时间序列的指标预警，比如说线程数、性能、ASP 使用率等等。也可以对离散的、基于时刻的指标做预警，比如说作业完成时刻、文件到达时间。

这里有一个阈值或者说是正常范围的选择，一般来说有两类，一个是固定类的阈值，比如说存管数据必须在约定时间之前完成发送。另一个是通过大数据平台计算得到，一般是基于时间序列的，比如说系统的 ASP 使用率的基线、性能基线等等。

第二大类应用场景是智能检测，是从事前分析、事中告警聚合、故障定位、事后经验沉淀等多个方面，来辅助运维人员的决策过程，实现对异常快速定位和有效处理。

在这类场景中，异常报警聚合是将冗余的报警信息进行聚合。系统在检测过程中常遇到的报警风暴问题，在分布式环境中，一个异常、甚至一个普通的系统重启操作都可能会有多条报警短信。

之所以出现这种情况，一个原因是目前所监控的指标较多，粒度较细，第二个原因是分布式环境下，各个系统之间服务的依赖性是增强了，一个应用状态的变化会导致有依赖关系的多个应用发出报警。

大部分的报警其实是冗余的，是可以被精简。那如何来精简，如何来合并呢？一种简单的方式是将相同时间段内多个关联性较强异常报警聚合成单个独立的报警信息。这种方法实现简单，但是准确度不高，可能会忽略到重要的报警。另一种方法就是挖掘历史报警数据中的关联关系，建立关联的报警策略列表，报警的时候就根据规则有所为、有所不为。

故障根因分析是基于准确报警，分析查找异常发生原因，定位产生异常的故障。当异常被检测的时候，通过报警聚合缩小异常的范围，然后再利用故障失效传播链查找可能的产生异常的原因及其概率。甚至可以基于历史经验，相应的提出解决方案。这是对故障失效传播链和报警聚合的一次综合应用。

智能异常检测是对已有的异常事件进行标注，用无监督异常检测及基于算法的工具，在历史日志中自动搜索匹配已标注的异常事件，以此训练机器学习模型，实现对异常的自动判断与检测。

智能值守就是在机房值班中引入人工智能，一方面可以将值班操作智能化，另一方面可以将运维数据可视化，提升对系统的处理能力和掌控能力。

在值班操作智能化方面，主要关注两点，报警处理和异常处理。报警处理是如何在众多的报警中确定有效的报警。报警在两个时间段有不同的处理方式，在工作时间段的报警就要采用前面所说报警聚合。但在重启的时间段内，系统也会有很多的报警，但这些报警就显得很鸡肋，忽略掉呢又不敢，一个个处理呢，又太麻烦了。

一种办法就是建立基于报警数量、报警顺序和报警内容的基线，一般情况下，重启时的报警都会在这个基线范围内，如果有不符合基线的报警出现，比如说数量增多了或者顺序变化了，那就大概率出现了真正的异常了。

另一种办法是采用聚类分析或者孤立森林算法，将众多的报警进行分类识别，将可以忽略的报警，与真正的异常报警进行分类识别。这里是基于一个前提假设，那就是真正的报警是少量的，并且与可以忽略的报警是有明显的不同。

第二个层面是异常处理智能化，首先要确保准确的报警发送到正确的业务处理人员、开发人员和项目负责人。更进一步是对可以处理的报警或者有历史修复记录的报警，在不影响业务系统正常运行前提下，系统可以自动的采取修复手段，比如说引流、扩容、重启等等，直接修复异常，部分做到无人值守。

运维数据可视化是丰富监控对象、提升数据可视化程度，并且要与现有的监控相集成，尽量减少监控界面。

智能巡检有两类，一类是机房类智能巡检，可以引入智能巡检机器人来代替人工巡检，对机房环境、电气设备、硬件设备进行检查。

另一类是应用层面的自动巡检，这种应用层面的自动巡检不同于以往的应用集中监控。应用集中监控只能对应用的技术状态进行监控，看看这个进程是否存活、有没有宕机，但没有在业务层面上实时的分析和判断应用的可用性。一个应用进程没有宕机，但是它 hang 住了，但在业务上没法访问，没法正常提供服务的。

怎样才能检查这种异常情况呢，我们采用了基于 RPA 机器人的应用巡检，利用 RPA 机器人既可以模拟人机的交互操作，也可以模拟应用模块之间的相互调用，从而对应用系统进行不停服务的在线检查。这种定期的巡检，一方面可提前判断关键业务的可用性，提前感知异常，在异常对市场造成影响前，可对异常做出预警，跑赢异常。另一方面也可结合历史数据与当前 KPI 指标，预测应用系统未来的可用性。

其实，判断业务的可用性有很多种方法，一种办法是对 KPI 指标进行监测。但在我们这里可行性比较低，因为我们业务复杂程度很高，而且部分业务量随市场变化而波动，市场是很难被评估的，因此 KPI 指标建模难度很高。举个例子，前一段时间我们的统一账户平台接收到的用户查询量迅猛上升，原因就是券商要查找潜在的科创板投资者，科创板投资是有门槛的，2 年且证券资产和资金不低于 50 万。但这类查询业务可能过了一段时间后又降下去了。所以这种建模是比较困难的。

外部应用可以用 RPA 机器人来巡检，内部应用组件之间可以采用互检方式来探测应用的可用性。内部应用要具有自我测试、自我检查的基因，比如说模拟的应用可以定期对被检测的应用发起服务调用，而实际的访问参数是沙箱化的参数，与生产数据完全隔离。这样，模拟的应用就可以通过返回值来判断业务的可用性。

在智能巡检这块，我们实现了一个综合巡检平台，它能集中统一显示内部应用和对外应用的自检情况。在出现外部应用异常时，能快速结合内外部应用的互检日志，快速的定位问题。在出现内部应用异常时，可以结合应用依赖关系的知识图谱，分析可能的异常影响范围，从而有针对性的启动应急预案。

为了实现智能预警、检测、巡检、值守这四大类场景，我们在已有的工具基础上，结合了技术发展路线，设计了智能运维平台的目标架构。这个架构仍然是围绕智能运维算法、运维大数据平台和自动化工具所组成。

四、智能运维实施路径

最后，我们构想了实施智能运维的道路，这是一条从点到面，从简单到复杂的渐进式发展道路。

最开始要建设基础的运维大数据平台，然后是实现简单的、基础的智能运维应用，比如实现应用自动巡检、指标智能预警等，接着从单点应用场景入手，实现单个运维智能化，然后实现局部的一大类场景的智能化，最后多个局部的应用场景组合成一体化的智能运维，实现智能运维的闭环。让运维人员将工作重心从繁琐的操作中，转移到探索需求、定义场景、专注业务中来。

通过智能运维的研究与应用，我们也有一些体会。一是数据是基础极其重要的，运维数据的搜集整理保存工作一定要先行。对于一些异常类的标注数据，目前我们仍需要去研究去探索，怎样利用实验的方法获得。

二是算法是关键，算法复杂程度高，学习成本高， 不同场景需要合适的算法，我们在做预测类算法的时候，发现不同算法所取得的效果是有很大差异的。但是算法，是需要专业的人才。智能运维不是一蹴而就的，我们在实施智能运维的时候，也需要借助外脑的帮助，与科研机构、技术公司共同努力。

最后，工具是手段。智能运维是需要通过工具来实现运维的决策。但这并不代表没有自动化运维，智能运维就做不了。智能运维是辅助或者增强运维能力，智能运维建设是可以反过来倒逼系统运维升级的。

谢谢大家，我的演讲到这。

Q&A

Q1：现在自动化运维，真正的应用到一些场景，比如说操作，出现一些问题，处理是自动化的运维工具，自动做完以后反馈给你吗？

A：智能运维是利用自动化运维工具做具体操作，然后在利用智能运维闭环做一些反馈。这里需要强调的是，在智能运维闭环是智能运维起步阶段的时候有一些运维操作建议，并不是智能运维自己所产生，仍然需要人为导入。

目前来说只有在开放平台当中，用到这一部分，在传统的小型机里面没有很好应用到这部分，比例不是特别高。因为智能运维是起步阶段，修复的意见建议并不多，这里也是需要一个积累的过程。我认为智能运维系统，核心价值不在于怎么构造系统，在于经验落地，对于运维人员而言，最重要一点不是运维工具好不好，就是运维经验积累，这才是我们更加关注的一点，只有把经验积累起来之后，智能运维系统在后面建设过程当中，将运维经验结合进来，就可以辅助运维人员来处理各种异常。

现在热点在于智能运维系统怎么建，但我们不仅关注眼前，也要考虑后面的运维决策数据的积累。我们在实施过程中发现系统搭建容易，但是运维决策数据积累很困难。

Q2：我感觉您说的运维，是不是所谓的专家系统一个东西？运维是一部分，业务跑批的时候，运维人员干涉不是特别多，跟业务开发逻辑有很大关系，特殊性比较强，不知道怎么解决这种经验的问题。

A：运维经验是一个专家系统，但专家系统和智能运维系统不能混为一谈。举个例子，在日终跑批的时候出现异常，一般可以做暂停，把整个运行图停下来，处理完异常后再继续跑运行图。这个时候的处理方法一般都是有很多种，一种是重新载入相关数据来做重新处理，一种是直接改数据继续跑。这些批处理作业的运行控制是由一个批处理运行控制平台来实现，业务开发只需要关注业务，这些异常处理的工作可交给平台来完成。

但是智能运维并不是局限于异常怎么处理，而是需要在异常出现之前进行预测，预测异常发生的概率，预警异常带来的影响范围。比如在跑批的时候，一些数据文件晚到了，就会对运行图上后续的作业产生影响，对业务就会产生影响。智能运维就是来预测这种影响到底有多大，甚至可以根据前面提到的运维经验、运维决策给出一些建议，来帮助运维人员、技术人员来解决这些异常。

Q3：我现在发现做运维，我上了很多监控，以前没有自动运维，都是人工做的。我们现在想学一下智能运维，能够自己生成，现在用 AI 算法，原来是 100 万，过滤出来 20 万，不是很精确，您这边有没有什么好经验？

A：阈值我们也是初学者，您说的是连续性的。

追问：人工做阈值是很准的。

A：我认为可能有两个原因，一个是数据量太少了，不能满足学习算法的要求。第二个原因是算法，没有用对合适的算法或者算法没有合适的调优。

我们在做日终作业运行时间预测的时候用到很多种算法，每一种算法可能跑出来的效果都是不一样的，怎么办呢？我们就取多个算法结果的中位数，然后与历史经验数据重叠起来，进行多次拟合和融合，让预测值更加逼近实际值。

作者介绍：

陈林博，中国证券登记结算有限责任公司上海分公司智能运维负责人。工学博士，毕业于同济大学计算机系统结构专业，曾获上海市青年五四奖章（个人）、上海市青年金才等荣誉。2014 年进入中国结算上海分公司技术开发部，目前从事基础技术架构的研究与应用，主要负责智能运维平台、容器云平台、分布式微服务平台(SCAP)、分布式批处理业务平台(BASP)等研发。

原文链接：

https://mp.weixin.qq.com/s/uMNWadsk5omWOY6zVlIAuA