12月22日，第十二届中国IDCC产业年度大典·金融科技高峰论坛暨《管理体系在银行业数据中心的创新与实践》首发仪式在国家会议中心举行。

2017年被誉为金融科技元年，区块链、人工智能、大数据、云计算对银行业的影响正在不断深入，这其中面临更严峻的网络安全、监管、容灾等问题。针对这一现状，中国银行总行、IBM、中国信息通信研究院、平安科技、中国银行数据中心（上海）、腾讯、中国信息安全认证中心、中国电信、中国银行江苏省分行等数位企业高层就金融科技当下趋势及问题进行演讲。

平安科技云计算解决方案资深架构师郑士晖做题为《金融日志云平台》的演讲。

郑士晖：大家好，首先感谢活动的主办方IDC给了这么一个机会，给大家共享一下我们平安科技在金融日志云方面的经验。之前我们听到一些专家，比如IBM的邢总，包括张总从不同战略的维度，阐述了如何帮助金融行业企业做的经验。

我想从其中的一个维度，金融日志云这个方面在做深一步的阐述，看看我们平安科技如何将云计算、大数据、人工智能做一个结合，并且有一个切实的落地。

先简单做一个自我介绍，我是平安科技云计算解决方案的架构师郑士晖。可能一些数据图片有些缺失，大家听我讲。先简单介绍一下平安集团相信大家都很熟悉，是我国三大金融科技集团之一，2017年跻身于财富五百强的第39位。平安科技是集团的全资子公司，定位是作为集团的互联网技术和创新技术的孵化基地，我们在北上深5个地区都是有自己的分公司。我们的口号是科技引领金融。我们是想通过一系列的问题贯彻到整个演讲之中，我们阐述我们需要解决什么样的问题，我们是一个什么样的产品定位，我们是如何实现的，能带给用户什么样的价值，在座各位老总很多都是金融行业的，我们在金融行业特别关心的安全方面，我们有些什么样的自己的特色？

首先看一下，日志管理的一个现状跟挑战，我相信每位公司里面都有很多的应用，随着信息化技术的发展，环境日益复杂，设备的种类日益繁多，以前可能只是一个小小的集群，它的数量也是固定的，几个网络设备就跑得很好，网络工程师、系统工程师只需要登录进去搜集一些具体的日志，就知道这个日常是什么样子的。但是随着技术的发展，这个传统的管理方式，运维方式日益不够。比如说云计算来了，相信大家听了两天各位专家的讲座，为云计算这个技术，可能脑海里多少有点概念。云计算是什么？从我个人的经验，我用一句话简单的概括一下它主要的内容，云计算是一系列的能够使用户无论从空间还是时间上弹性的获取资源的一个系数的集合。

用户想什么时候拥有多少体量的资源，它就能拥有。举个例子，我们在ADW上，他能给用户带来什么样的效益呢？我能设置自己的规则，随着请求的递增，我可以横向扩展前端的ECTO的集群，随着访问量的下降，我可以节约用户的成本，给我们运维工程师带来的挑战是什么？我想搜集这些日志请求可能无处去搜。另外一种场景随着访问量的递增，上一秒有5个结点，下一秒就有好几个结点，随着并发请求的递增，一个完整的端到端的日志，应该是能呈现给用户，不管是网络端，服务器端，中间件端到服务器端，随着环境的复杂化，我如何去做这个事情？不同级别的运维团队只关注自己职责范围的事情，他没办法完整的视角呈现给用户。随着云计算来了以后，微服务的技术也来了，微服务主要是解决一个什么场景呢？之前设计系统的时候把一大堆模块全部设计在一起，前后也不分离，越做越多。导致一个什么结果呢？模块功能日趋复杂，因为咱们知道开发团队跟运维团队是天生打架，开发团队最关注什么？我希望最快的速度上我的新功能，运维团队新版本上来以后尽量保持环境的稳定，随着矛盾的日益加深，我们就出来微服务这样一个概念。它简单一点，它做了一个什么事儿呢？使每一个功能模块以一个明确的边界，一个服务干你自己的事，你可以把数据库，外部服务器全部把它连在里面，有单独的开发团队和运维团队去运维它就行了。由于技术的向性，拥抱了叫容器的技术，容器解决了什么问题呢？可能用户比较关心，我这个应用在我这边好，为什么老是有这样那样的问题？我们把不同的环境到镜像里面去，你每次发布直接用你的镜像包，而且横向扩展非常简单，跟我们日志管理带来了什么挑战呢？

运用工程师，容器级的，如果说前面物理集群的部署准备时间很长，它要几个月，生命周期也很长，但是容器的生命周期，我可能只有几天，几个星期，因为它后面不管是什么平台也好，会自动根据我这个物理宿主机的结点进行调度。日志信息，如果你没有一个统一的平台去搜集维护的话，你是非常痛苦的。

是不是微服务之后，容器之后咱们的技术就到此为止了呢？也不是，但是撇开这个片子说一下，咱们AWS上，包括其他的主流的云平台上，前几年推出一项大家应该听说过，叫无服务器服务，或者也可以叫它函数服务，它的目标，我不单以服务为边界，我可以以功能为边界，你把功能的代码传到公有云的平台上，我以最快的时间帮你运行，用户只需要按照你使用的次数进行付费，这个以毫秒级，几十毫秒就解决了，底下还是容器技术去支撑的，但是生命周期这么短，如果没有一个统一日志管理框架，运维团队很难面对日新月异的技术的挑战的。

数据的多样化，之前也提到有结构化数据，半结构化数据，我不多阐述。

最后想讲信息利用率，咱们做日志管理都知道，市场上有一些开源的产品，比如说ERK。现在这个信息化社会，什么东西最值钱？我认为，不代表任何人数据最值钱，为什么这么多公有云平台以非常低廉的价格推出人工智能的框架，吸引大家去使用？一方面他是想自己做自己的平台，在市场上抢占市场，这是表面的，人工智能脱离了训练数据它什么都不是，公有云想借助广大的用户拿自己生产环境的真实数据不断训练他自己的人工智能框架，同时也能获得行业内的真实数据，对在座各位老总而言，大家自己公司里面的真实的生产数据，其实是最宝贵的部分。我们不能光像以前传统的环境一样，只是对这些信息做一些搜集、监控、预警就结束了，我们应该也应用一些大数据、人工智能的先进技术，对这些历史信息做一些分析，并且能够不断地训练自己的人工智能框架，有一个对未来的预判的功能，这个也是我们平安科技对日志管理上面的一个战略规划。

这就是我之前提到过的，可能传统意义上，系统工程师手动敲一些命令为主，后面辅助一些脚本，包括自动化系统的一些定时任务，做一些脚本化的运维。现阶段大部分公司停留在第三阶段，结合一些自动化工具，结合CACD的工具做一些闭环，环境来了以后我可以搜集这样的信息，简单的方式呈现给用户，大多数公司到此为止了。我们平安科技往后，通过对历史数据的一个探索，一个分析，提出了一个AI智能化运维，我们尽量将一些潜在的风险消灭于没发生的时期，我们称之为前瞻性的智能运维，不光是日志数据，我们发现所有数据的分析基本可以总结为下面几个阶段，采集、存储、搜索、展现、监控和预测。我们这个产品的亮点是后面的预测，智能化预测跟分析这个阶段。

首先看一下我们这边的基本能力，我们平安日志云能对接几乎所有的设备，支持十几种形式的采集，并且我们集成于平安云基础上，用户不需要安装，你只要到界面上选择我需要这个服务就行了。

我们有大概一千多个UI的模板，给用户展示你各个层级的信息，因为我们一个特色，我们可以从产品的维度，将你散落在不同设备，不管是网络设备，虚拟机，数据存储这一层面，只用一个视图给大家展现出来。随着访问的递增，我在哪一个层级上响应的时间越长，可能哪一个局部地区，影响的范围是多少？甚至于通过历史数据的分析来看每多一千两千并发请求，后面哪一个局部消耗的时间更长。我们也开发了自己的一个搜索数据套现。某金融子公司的安全部门可能说最近有一些员工有一些违规事件，不在我们公司规定的职场环境里面访问到我们这些系统，你能帮我查一下历史数据，可以自己上传公司内网的IP段作为我们自定义的数据集，作为所有相关资公司下面的数据，以下哪几个IP在过去的一周或者一个月的时间之内，在非工作范围内登录这个系统，可能有一些安全隐患，剩下的就是安全部门去查，电脑该查的查。不同的云供应商有自己不同的实现，阿里云本来自己有一个能实现这个功能，这么多的存储信息里面，按照用户自定义的颗粒度和维度挖掘我想要的东西。

平安日志云，我们建立在平安云上面，我们平安云满足一行三会安全监管，在座各位都是金融界的大拿，在其他的安全方面，不管是从RBAC还是从用户数据组的划分，我们针对自己的用户都有明确的划分，并且我们可以采用一些敏感数据混淆之类的技术手段，能呈现报表的时候，掩盖掉一些相对敏感的用户数据，后面会有详细的说明。

还有一块，我们认为的特色，之前提到我们会根据历史数据，通过用户自定义，或者我们内设多个KPI指标，以一个完整的流程图的方式，或者其他智能训练报表的形式，给用户展现出来一个完整的视图，并且我们能够通过历史数据的分析，提前预知系统管理员，产品经理，告知我可能未来出现的高峰。我们后面也会说双11，虽然比不上天猫，但是金融公司多少会有金融衍生品的金融推销，我们至少提前一个月，通过邮件等方式通知相关管理团队说，未来可能会有这么一个请求的高峰出现，按照历史，可能web层会承受相当大的压力，我们可以有一些选择，提前把Web结点进行扩充，我也可以给当前的租户预先分布足够的虚拟资源，以应对于当时高峰来临时候的自动伸缩，我们尽量把这些，轻量化被动型的运维，变为主动性的前瞻性的运维，这是我们的思路。这是我们简化的工作流程，左边是采集端，我们能够应对几乎所有的一些产品设备，并且是我们平安云上的虚拟机也好，物理机也好，包括容器服务容器也好，用户只要选择了我们的服务，就不需要做预判。

一到我们的处理中间层，我们有自己，首先进来以后会有一个存储，存储方面我们也分了冷热存储两部分，热存储可能是SSD高性能的存储为主，可能会将一部分之前的历史数据弄到性能相对低的冷存储上面，保证热存储里面最新的数据性能比较高。用户一旦对历史数据有搜索的要求，我们可以通过自动化的方式把数据进行唤醒，重新加入队列的操作，对用户是无感知的。

它的设计里理念有点像亚马逊的S3，就是一个冷热存储的概念，要降低成本，不然全部用SSD的话这个成本是不行的。为了应对采集端数据量比较大，我们自己开发了一套基于硬件同步的消息队列，保证数据采集上来，不会因为某一个结点宕机，会造成数据的损失。我们也有自己的搜索引擎，可以根据冷热存储里面的用户顺序，按照用户自定义的查询语言进行一个搜索。我们可以报警策略我们可以输入成各种维度的定制报表，也可以通过常规的方式，以邮件的方式，跟下游的系统做集成。

在真实的生产环境中，我们是跟平安集团内部的一个监控系统做一个集成的，因为单纯的日志管理平台做所有的事，它是做不到的，只能做到一个监控、预测、提醒的作用，所以它多少还是要跟其他系统联合起来作用。最后也是跟我们另外一个平安的呼叫中心做一个集成，他是7×24语音服务，接到报警消息以后，可以通知对应的人员（客户、管理员）进行对应的操作，这是简化的流程图。   

这是一个抽象的逻辑架构图，底下是用户层，我们可以应对所有的各种各样的OS、APP，包括后面的物联网设备。云方面，我们主要是因为主要是服务集团内部，只对接了一个平安云。因为一些历史原因，可能各种各样的子公司以前用不同的虚拟化技术实现了一些自己的私有环境，我们也对接了一些OA去支撑不同公司的环境。我们根据实际需要在移动端也有自己的SDK，供下面这些其他的子系统进行一个集成跟调度。之上的模块，就是之前提到的不管从采集、数据管理，包括机器学习都会有自己对应的抽象的模块。所有的这些功能点都有对外的供下游的系统进行调度，以形成一个完整的集团内部的生态圈。

后面从智能运维和安全两个角度来阐述一下我们这个产品具体的特点。首先是智能运维，以前我们设置各种报警维度，都是根据一些行业的经验，有的甚至于系统管理员比较缺乏敏感度，可能网上查一查阀值是多少就这样设了，动态阀值功能，管理员可以设80%作为一个预警的阀值，我也可以通过无监督的训练的框架，不断地学习，通过历史真实数据的学习，可以给你判断出一个合理的阀值，既能够使预警线不会高，失去它应有的作用，也能起到降低行政资源的作用。可能这个系统CPU常见10G，20G，根本不需要这么大内存，我可以通过这个提醒管理员，是不是释放一些不必要的东西？我们也可以通过一些技术手段，能够实现一些瞬发高压的预判。比如说这台服务器90%的时间都很正常，突然上一分钟因为一些网络的原因，访问请求量很高，但是不代表我这个机器崩了，某一秒可能有99%，95%风险请求，这个我们框架也能区分出哪些是可能导致我系统崩溃的，哪些只是由于网络异常的原因造成的。

不同系统有不同的采集频率，一般5秒钟或者10秒钟，展现在报表上的力度是用户自定义的，有可能有时候异常发生在中间，我们这个框架也能根据在粒度中的异常，不会把它忽视过去，也可以在图表上以报表的形式，图文的方式给管理员呈现出来。

后面智能预判会在一些敏感的时间，比如说双11，比如说911，一些政治安全敏感的时间通知系统管理员，安全管理员这一个月是不是加强某一个设备的安全巡检，按照历史数据报警，可能在web端承受的高压超过规模了，这样经过在事件来临之前的调整，能把对这些瞬发高压，包括安全隐患，对自己的损失降低到最低。

最后有一个比较大的特色，前面提到我们会把一个产品维度和不同设备的信息健康状态汇总到一个流程透视图里面去，可以清晰的看到从一个请求进来，经过了web层，中间层，多少层设备，每层设备响应是多少，每层设备可能会有些什么异常，当前并发量多少，以一个图形的形式展现出来，并且有一些插件跟外面的工具有点像，甚至于可以深入虚拟机，可以给你探测到，这个方便我们的开发人员做一个性能的调优。

就是之前提到的一个流程透视图，UI现在还不是那么的炫，我们的开发团队也是在努力的完善自己的UI，对终端用户而言不需要感知这么多细节，UI的细致程度对用户来说是第一位的，中间看到系统里面，右边这一块，可能是访问量比较高，有可能是LB下面的某一个结点崩掉了，管理员就可以知道我这个影响范围是多少，第一步做怎么样的切换工作，然后再去做分析。

我们平安的日志云是完全基于平安云的基础之上的，我们平安云在今年10月底之前陆陆续续获得8项国内外安全方面的资质，含金量比较高的有等保4，有可信云服务，在座的都是专家，这方面就一言概之。平安云是我们平安日志云坚实的基石，提供了绝对安全的环境，我们在北上深有三地五中心的全部都符合一行三会安全监管的同城异地灾备的数据中心，全部都是自建的。

剩下的，我们是讲述一下我们这个平安云在安全方面能做的一些事，首先我们是内嵌了30多项业内外安全指标。用户也可以通过自己的一些实际需求，定制化自己的安全指标，然后拖拽出来自己安全的报表，去显示自己系统的安全状况。安全数据的混淆是这样的，我们平安内部有一帐通这样的产品，我们以ID的形式贯穿整个平安产品用户的生态，所以它有一些IP的信息是相对比较敏感的，我们出报表感觉有些信息没有必要呈现给终端用户所以我们通过一些预判，在出报表之前把一些敏感信息混淆掉展现，这个只是在表现层，并不会修改日志源本身的信息，我也可以给日志打标签，可以从产品维度，也可以从设备的维度，打标签，区分各种各样的不同角色的人员。

产品经理可能对我这个产品整个环境，都需要有一个了解，系统管理员，需要对所有的数据库都要有自己的管控，所以我们这个是通过以标签为主，这也是从某一个侧面体现我们数据的安全层。

最后，我们是能通过自己的机器的框架，能做出一些异常的判断，像前面说的哪些可能是一些CC攻击，这张图里面，很抱歉，因为都是一些真实环境的数据，一些安全部门说用户名也是非常敏感的，所以马赛克处理掉，一处理掉也看不出来干啥，最多能够看一些能做哪些服务，这个时间响应是多少。

之前还有一些事是一个子公司，他发现可能受到攻击，我发起登录请求，但是不是每个登录请求都可以通过这个验证，都会有一个验证请求，也可以通过我们自定义的搜索语言给他检测出请求验证的比例是多少，我们给他预定一个0.3，0.4的比率，通过搜索日志把整个环境的信息做一个汇总，给他整出一个表，以下几个IP在过去的一个小时，两个小时之内发起了链接需求，但是并没有怎么做验证，可能这几个IP有隐患，安全部门自己分析。还是这句话，这个系统只是起到一个监控预警的作用，并不能自己去落地这么多的潜在问题，还是需要跟其他系统，跟团队去合作的。

但是我们相信前瞻样式的运维是一个未来的发展趋势，并且每位公司里面的这些历史数据是咱们最大的一些财富。跟市场上的同类的产品，我们也有过比较，因为它是公开演讲，我总结下来一句话，适合自己公司环境的解决方案可能才是一个最好的方案。谢谢大家的时间。