未来金融研究所第14期：以应用为中心重塑金融研发效率原创

我先做个呃简单的自我介绍啊，就是前面有提到我是呃腾讯coding续部的一个负责人，那我在coding的期间呢，呃，就是这三四年间，我是呃我们团队帮助过很多的金融机构去完成我们的一个研发效能的方案设计和落地。啊，我和我的团队呢，啊，是比较专注于应用交付这一块，那在这个领域呢，呃，就是已经做了30年了啊，在服务了很多的这个金融机构以后啊，我们呢，就是在这过程中总结了很我们在金融机构生时代遇到的一些挑战，以及说我们怎么去应对这些挑战的应对道。那这次分享了分三个部分，第一部分是说人生时代啊，金融机构研发的一个痛点和挑战，第二部分呢，是以应用为中心，这个理我们能够去解决啊，遇到这些挑战啊，然后第三部分呢，是我们这些理念啊，实际在一些金融机构中落地的一些案例的分。

好，我们先开始第一，呃，第一个环节就是说啊，我们的痛点和挑战。嗯，很多的金融机构啊，相信都已经或多或少在尝试使用生的技术，使用K的技术来去提高他们的一个服务的一个可靠性，说去进行降低成本呀啊之类啊，就此类的一些尝试啊，生的这个优势和它的整个大趋势基本上是毋庸置疑的了。但是呢，在云原生时代以后啊，啊整一个研发啊，无论是我们，呃，就是哪个行业都好，只要他接触了云原生，那么整个研发的过程中啊，会有很多的一个新的挑战，我们可以看到这张图里面的应用的一个开发交付和运维态啊研发或者说呃，运维和配管都会遇到。

在云原生时代之前啊，就是更多的不一样的挑战。这里面呢，就是包括了学习门槛的，呃，那个变高啊，然后配置门槛的变高啊，包括说我们的规范啊，就是非常难落地，包括说我们的一个啊，发布很容易出错，发布物料容易漏发，容易错发，灰度验证也困难，排错定位也困难啊，然后。还有是资源和应用的一个关联也比较困难等等。那我们一个一个问题来展开说啊，这一张图呢啊，就是2017年啊，CNCF就是云生啊基金会landscape的一个全景图，也就是说啊，当时在这个基金会里面，他们认为这就是原生的全部了，也就是说研发团队。把这些东西学完，你就成了云原生专家啊，你才能用好这个云原生，那这一个呢，咬咬牙可能还能学下去，但是我们再再来看一下2022年啊，就是这个五年的一个发展时间里面，CNCF里面的一个项目啊了一一倍不止啊。

那么就是你作为一个研发啊，你心里可能就要想了，就是我就做个业务，写个API，那怎么还要学那么多乱七八糟东西呢。云生啊，它的复杂性啊，实际上呢是呃，现实上是移到了给研发，移到了给开发者，大大的增加了我们开发者的一个心智负担。开发者除了要去面对业务的一个复杂性以外呢，就是呃，在应用开发，应用的交付，应用的运维，都多了很多新的知识，新的工具，新的智能啊，技能需要学习啊。如果他不学这些东西，很可能会去，就是没有办法去做好他的工作。我们金融机构里面呢，就是业务就已经够复杂够难学了，还要分神去学那么多东西，那这个心智负担呢，他还是就是他不是学完一次以后一劳永逸啊，他还会就是随着这个时间的增长，随着云原生的不断的繁荣，随着业务的增长，会一直的去增加啊，直到我们的研发最终就学不动了，心智不堪重负，然后呢，导致我们整个研发团队的一个产能会出现断崖式的下降。

那第二个问题呢，就是我们的一个，呃，规范非常难落地。那在云原生的时代呢，很多机构啊，它还用着，呃，就是S啊，或者GILA之类的一些老一代的这些呃呃工具来去支撑我们的。那呃，通常呢，都是手动的去完成我们的一个呃压模的配置啊，我们在呃就是呃那个招行，还有就是易方达啊，这些很头部的一些机构里面，其实都遇到了类似的问题啊，那其实他们的团队已经或多或少的已经完成了应用上的云啊，应用云员说话啊，已经完成了业务团队的一个敏捷转型。

但是呢啊，因为我们的基础设施啊，还有那个工具链，它并不是云原生时代的东西，它并不能适配我们的这个云原生的场景，所以呢啊，导致这些工具不好用，导致每个小团队他们都是八仙过海，各显神通，各自用着不同的工具，用着不同的云原生特性。那自动化的能力呢，呃，就是非常弱，这就导致了说全部都是手工的去去管理这些东西啊，那手工去管理意味着你要去统一管控。啊，是几乎做不到的，因为各个团队都会因为业务压力而去消极对待你的这些管控啊。那最终呢，就是说因为没有办法去做一个呃统一的规范和一个统一的呃那个治理和演进啊，所以导致我们云原生啊，应该有的各种的高可靠啊，低成本啊这些呃红利没有享受到。

那第三个挑战呢，就是说呃应用的云原生化通常都是呃伴随着我们的软件架构，像微服务的一个架构演进，那在缺乏那个完整的工具的支撑下面呢，就是很多时候研发是只能记忆去呃找到我们这次版本到底要更新哪一些镜像，哪一些配置，以及说哪一些数据库，也就是说这些物料啊，经常会因为啊记错了或者操作失误，会导致错发或者漏发啊，还有就是我们本来发到测试的一个配置会移到生产上啊，这种呃就是通啊，经常会导致我们的线上事故啊，然后呢，根本就没有办法去证我们的发布的效率和可靠性。那随着我们的业务的一个发展呢，这个呃，就是微服务会越来越多啊，环境也会越来越多，也就导致说我们的整一个发布的工作量和复杂性都是指数级的增长的，当这一个啊，就是复杂性超过了团队的一个接受极限的时候呢，啊，应用交付的故障率会剧增啊，研发经常加班，然后呢，就是甩锅现象频发，消极情绪也会持续的积累扩展啊扩散，那导致我们整个团队的一个研发效率低啊，氛围差。

嗯，那相信很多的一个机构里面都已经有了一些监控和日志的一些工具啊，啊，其实监控日志调用工具的一些啊，就是出现它满足了我们不同视角的这个观测需求啊，以便我们去定位问题。但是呢，这些工具并不是，呃，就是同一批出来，就是他们是随着历史的发展啊，他们这些工具在不同的时机啊，不同的时产生，且往是独的一些工具，人员呢，往往是需要整合我们的监控日志调用链这三种类型的一个观测的数据，观测的信息啊。

那才能去呃完成我们的一次排查，那呃这就是导致我们的研发人员呢，需要在呃多个工具之间来回去跳转，影响我们的一个效率。在混多的情况下，这个问题发的严重。第二个问题是说，我们传统的这些观测工具啊，它往往是一个资源视角。那呃资源视角是指就我们呃面向运维那种资源视角，但是研发它关系是它的业务，它需要的是一个业务视角，两者之间的信息架构是一个呃天然割裂的研发在定位问题的过程中呢，需要去很多呃就是信息架构之间的一个差异。这也会影响它的一个效率啊，那第三个问题是传统的一些观测工具啊，呃解决了研发对不同视角的一个观测需求，但是呢，呃他却忽略了不同视角之间的相关性啊，例如说呃就是监控告警他暴露的问题，但也只是暴露的问题，具体是什么问题，去哪排，这需要有，就是对应的研发有相当的经验才能去出来。

那这个呢，也是比较严重的影响我们的一个效率。那总结一下，就是说因为工具的视角的一个割裂，及说数据断的问题呢，使得我们用的时间会进而导致我们用户的一个满意度降低。当达到用户可以接受的一个就是呃，极限的时候呢，用户的满意度啊，也会就是断崖式的下跌，影响我们的一个用户口碑。那解决以上的这几个问题呢？我们的是要以应用为中心，构建我们的应用生命周期的一个管理平台。

那这个呃概念是什么意思呢？就是说我们呢，认为研发团队应该在一个就是应用为中心的平台上面啊，很可靠很高效的去完成它的应用的建模，应用交付以及应用运维啊，整个应用生命周期的一个操作的闭环。那在这几个领域呢，其实最近几年已经有好一些的呃，比较先进的方法论或标准出现了，例如说建模里面有，呃，有O啊，然后应用交付领域有发布引擎啊，有什么？呃，就是application code诸此类，那应用的领域呢，有open标等。那我们coding的，呃，这个产品呢，就是基于这一些先进的理念构建的啊。那呃，我们下面呢，就过分一我们呃就不的呃是融机构面这个团队去落地一些呃效能治理的一些方案，然后呢，我们在这些方案里面来看看包比是怎么样应用为中心，来解决之前我们提到的种痛点。

前面提到一个问题，就是说金融机挑金融机构里面都遇到了呃，类似的或者同样的问题啊，几乎就同样的问题，那他们一般呢，都是有一些呃，运维或者配管啊，天生的为每个业务团队去配置我们的KS啊，配置部署流程啊，甚至会要一些工具来去给他们啊去使用。那随着业务的增长呢，我们的呃，就是这个机构里面，团队里面的应用和服务数量啊，也在持续的增长，再加上有测试环境，灰度环境，然后甚至生产环境都是可用区啊，那配置的工作量啊，是几何级的增长的啊，因为他要这几个因素全部乘起来，这样的一个增长方式。

啊，我们呢，呃，是通过二里面的视角分离的方式来解决这个配置门槛的问题的。在刚刚我们提到的这种就是呃，几何级增长的这种配置的复杂度啊，呃里面呢，就是呃，因为有大量的重复配置，那团队想要去完成我们的人生建模，就只能依赖增加人手，用不同的就是配款人员或者运维人员来去给不同的团队服务，给不同的团队去帮他们写这些K的。这其实就相当于一份代码拷贝了很多份，然后呢，随着我们的一个业务发展，这些代码还各自做了一些修改。那过一段时间以后啊，这种就是重复又有点变化的代码，你想要去落地什么原生规范是不可能的。那在使用了O视分，通过插件封装好了云原生的一个统一规范，剩下的呢啊，有其他的配管研发人员啊，来去通过我们的那个奥这个平台，这个系统，来去基于零代码的方式，来去就基于UI来去完成我们的应用原生的定义，以及说规范的落地。

上面两张图呢啊，就是讲的比较粗略，然后我们来具体讲讲这视角分离到底是什么意思啊。呃，K8S的这个呃复杂性啊，它对于研发的复杂性呢，主要是由于这个超大规模的压文件的管理，以及说就是这个文件背后对应的开发式行为的这个复杂度啊，也就是说研发或者呃就研发他要去学习的这些复杂度，它要面对复杂度主要就是某和K某对应的这些，呃，就是K的行为，那这种啊，超大规模的某管理呢，依靠少部分人去做人工管理，总有一天是应付不过来的。

要想去管好，把手落地，无非就两条，一条呢就是呃，人少管不过来，这就啊让更多的人啊去学习，也就是说让每一个研发都成为K80专家，把任务分摊到每一个人头上。但是这条就听听听就觉得不靠谱，就是说啊，它意味着牺牲研发这种宝贵的资源，在跟啊生产啊，跟产生价值毫无关系的事情上啊，它成本高，而且研发人员也未必愿意去去学这东西。那第二条呢，就是像我们中用OAM去实现一个视角分离，大家可以看这张图啊，那呃，这样做法呢，就是说我们啊上面的云人生专家团里面的少部分的这些生专家，他通过服务模板去封装我们K8S范，然后呢，通过运维插件去封装我们K8S的一个生态，或者说其他一些扩展的能力，比如说资源限制，比如说探针啊，比如说监控调用链等等的一些黑白式生态能力。

原生专家呢，可以根据实际的情况规定我们的生产环境啊，必须要去满足某些规范，就是说生产环境一定要有资源限制，一定要有探针，一定要有监控等等的一些运维插件，那呃，这样的话呢，它就可以去利用平台来去做到一个可以自动落地的一个原生规范。奥比呢，会把这些封装好的这些模板和插件生成对应的表单给到研发同学，那么研发同学呢，就下面这一条线，他其实不用怎么去学习K，就是他只要基于啊，就是我们运营商专家封装好的这些模板和插件啊，通过平台里面可视化的一个表。

然后去填写它业务相关的一些，比如说镜像啊，然后呃，就是环境变量之类的一些业务的参数，它就可以完成它的一个服务的创建和应用的定义，这样呢，我们就啊大幅的去降低了云生的复杂性啊。呃，然后呢，同时呢，我们也通过这个自动化的一个模板和插件，完成了我们的一个规范的落地。研发呢，就是通过这个表单和呃那个就是呃，还有就是那个插件啊，去完成这个配置以后呢，包比会把我们呃对应的这些的代码放到的仓库里面，那我们把云原生架构呢，分成了三层的一个架构模型，就包括业务层，业务层呢就是生命的我们应用的一个基础元素，包括服务，包括配置，包括数据库的一个变更脚本。

这三个都是一体的，被我们所管的，然后呃，交付层这里呢，主要是我们应用交付的流程，资源层呢，就是我们的应用运行时的环境和基础设施，那基于我们APS的这个，呃，这个理念啊，我们将应用到存在代码库里面呢，后续是可以实现我们的一个统一的演进啊，统一的一个就是也方便他去审计，可可以方便他去回溯。那下面我们来看一下，就是上面这些理念啊，就是用户实际用起来的时候体验是什么样的，大家可以先观看一下这个视频。A类型的应用创建流程，需要企业内具备云原生技术的运维同学配置好服务模板和运维插件。然后研发同学填写服务模板和运维插件的参数来创建服务。进而完成A应用的建模。首先演示运维同学配置服务模板和运维插件，从coding团队主页进入应用中心，点击左侧菜单的服务模板。

基于理论。模板和运维插件。只需要落户。这些配置代码仓库，然后就可以创建服务模板了。选择内置的国用模板，进入服务模板编辑页面所在包含工作服和服务发现的编程模板，模板中包含的一些内置的系统。比如说镜像端口号、服务名称等，也可以跟需求添加自变量，这些变量都是研发同学创建服务的时候需要填写的对象。接下来我们模拟一个。收听我们一些更新服务模板的基本信息。然后是烟模板部分，这内置模板机是涵盖的常见的内容，不需要怎么调整。这里假设每个服务的优雅耗是不同，我们可以添加一个强制关闭等待时长的自定义变。

每一个变量和规范或减值可输入的值。这里设置字段，必点字段类型，选择证书这一个取值范围。这样我们的自定义变量就。假设公司规定应用在生产环境必须配置资源线上。其他环境不做要求。这个需用运维插件来实现。我们保存当前的服务模板。进入运维插件一创点维插件目前内置的四种运维插件模板。所以我们选择符合我们需求的资源限制。我们可以看到运维插件的编辑页和服务模板介绍的一种功能也类似，但是不过原理不一样，因为插件有两种工作模式。第一种是排的对象，另一种是基于目标对象创建一个新的对象。我们的需求是为服务增加资源限制。随意使用推模式，点击保存，回到刚才创建的服务模板中，添加运维插件，选择我们刚才创建的资源限制插件。

这里我们选择生产环境生效即可实现生产环境必须填写资源限制字段，至此，一个基本的服务模板就创建好。我们刚才提到的生产环境其实就是应用的一个运行环境。一个应用可以有多个环境，一个环境对应一个K8集群，因为同学需要为研发同学准备好应用的环境。要想创建环境。我们首先需要添加配方。接下来演示运维同学添加给办询病与应用的运行通径管理，从coding团队主页进入基础设施。在集群管理页面，我们选择添加集群，根据实际需求选择，然后我们复制安装命令，执行T指令VK8集群安装客户端。这里节省时间到安卓。咨询管理多了一个高分，懂的进。这安装编辑中心集成信息，需要注意的是标签字段A字段就是刚才创建运维插件时所用到的。

这里添加的是测试环境，所以我们选择测试集群。这样一个集群就配置好了，按同样的操作，我们把生产环境的集群也添加进来，集群添加完成后，就可以去应用中心创建应用。点击创建应用，输入基本信息后，选择book这个空的代码仓库。创建好应用后，我们进入应用页面，在环境卡片内点击创建环境。先创建测试环境，选择测试集群。如果要求只能部署在特定命名空间，可以在in space覆盖字段中填写。这样就完成了一个环境的创建，同样的操作，我们在创建一个生产环境。截至目前，所有操作均是器云原生的运维同学操作。那么研发同学需要做什么呢？其实只需要根据服务模板来创建服务就可以。接下来实际操作一遍，点击页页面的服务管理创建服务，输入服务名称，选择运维同学创建好的服务模板，点击下一步可以看到服务B中间的表单元素，来自服务模板上的系统变量和自定义变量。

首先选择镜像，目前支持三种类型的信息防控，填好镜像后，我们在这一个端口后往下，我可以看到一个强制关闭等待时长字段。这个就是运维同学按规范要求的强制填写的字段，中间部分填写结束。又是环境变量和运维插件，我们先看运维插件，可以看到有一个模板内置的资源限制插件，可以强制应用于生产环境，我们填写对应的值，研发也可以根据需求自行添加运维配置好的其他插件。运维插件填写完成后，我们先创建服务，接着看环境变量，它实际上就是容器的NB字段。

可以直接添加，也可以引用配置或密钥，我们去配置管理，创建配置，输入配置名称配置项，这里随便添加几个配置项。保存，我们回到服务管理，先添加一个普通配置项，然后点击引用配置或密钥。选择刚才我们创建的配置。这里可以引用配置中的某个配置项，也可以全部引用保存服务，按同样的逻辑添加其他服务。接下来我们演示数据库的变更。首先我们点击数据库菜单，点击加号，从一个数据库实例里面导入数据库，这样也就告诉了我们的应用的数据库模型是什么样的。我们可以看到，这个应用用到了两个数据库。每一个数据库用到了哪些数据表？表里面的字段和索引是什么样？如果我们需要对数据库进行变更，可以点击右上角的创建变更，或者点击变更进入修改变更。

点击创建变更填种要对哪个数据库进行变更？填写变更记录语句，论函知识填写为公语句。当发布出措施。这个回归语句来回滚掉，已经进行了变更。然后我们可以选择一个环境，点击预执行。这个会把你的数据库的STEM拷贝出来。尝试进行变更，看看是否会出错。进而让研发及发现错误的语句，避免发布失败。我们刚才创建了四个服务，并填写了配置。比较常见的场景是应用在不同环境下，每个服务的配置可能不同。那么应该如何处理呢？其实只需要进入环境的配置管理，在当前环境为服务添加配置即可。我们进入测试环境，点击配置管理添加环境配置覆盖在这里，我们可以为任意一个服务配置符合当前环境的变量。

包括服务配置、环境变量和运维插件。我们覆盖ae这个环境变量，同时希望测试环境不开启资源限制。运维插件可以在运维插件页关闭该插件，点击确认。接着我们来到生产环境，同样也是更新A这个变量。切换到运维插件卡片可以看到，在生产环境下，资源限制，运维插件是无法被研发同学关闭，保证了规范化应用管理的同时，也保留了足够灵活性。至此，应用建模功能演示结束。好，嗯。我们接着来讲啊呃。是的。呃，然后呢，我们来说到就是呃，我们之前有遇到不少的一个机构啊，都有这样的问题，就是说我们呢，呃，那个部署架构啊，云原生啊云原生化，然后我们软件架构呢，也是已经是微服化了，那但是呢，我们的工具还在用，就十几20年前的一个精品，或者一些类似老一代工具，那么这个工具根本没有办法很好的去应对我们原生微服务时代的一个发布的一个场景。

啊，研发需要发版，需要提测，经常需要靠回忆来去整理，我们要发布什么镜啊，发出什么配置，那呃，而且呢，就是这一些更糟糕的情况是说这些零零散散的一个变更啊，它发是需要到不同的系统里面去发布的，例如说我在啊里面去发布镜像，然后我在我的配置管理的一个平台上去发布的配置，然后我到一个数据库的一个发布平台去发布我的数据库啊，那而且甚至这些发布都不是一个人做的，而是几个人做的，那这种呃，中间的一个信息的丢失啊，信息的呃传递效率以及说出错的概率都是比较糟糕的。

那如果我们漏发了一些东西或触发了一些东西呢？就是呃少则导致我们的测试就不通过打回，那呃甚至会引发一些生产的事故。在中呢，我们是通过application方式，我们的一个团队的一个可靠性。那呃，在我们的呃发布中呢，还有一个呃经常会有团队遇到的一个问题，就是数据库的变更，特别的不靠谱，不同的一个开发呢，就是变的语完。啊，会由呃配管或者运维员工的去把他们整理起来啊，然后呃合并进一个大的文件或者一个文件夹，然后进行员工的发布，那但是这些语句并不是百分百的能执行成功的，那如果执行出错了以后呢，他再去反馈到给呃那个开发，然后开发去修改，然后再去再发布诸如此类的一个啊。

反馈环环发。例如说我要发完数据库才能去发配置诸此类的一些依赖，那整个过程呢，它呃是只能去依靠我们人员的素质来去保障它的一个可靠性啊。呃，所以说一旦出错回滚啊，追溯也特别困难啊，效率呢和效率和可靠性都特别低。那在我们比呢，进行优化了以后呢，我们呃，使用database的理念去自动的整理不同开发提交的这些数据库的一个变更，其实就像之前那张图一样，我们呃把你的镜像的变更，配置的变更和你的数据库的变更全部都落到一个代码库里面，这样的话呢，我们可以利用代码仓库来去做到很完善的一个版本管理。

那在提在在开发，呃，真正的去提交这一个变更和提测发版之前，其实开发呢，是可以利用奥比这个平台来去啊做这个预执行，就是它可以把它的语句模拟的在生产和测试环境来去检查，来去预执行，看看它会不会失败，这样的话呢，研发它可以在开发的阶段。他就知道了这个语句啊，就真的发布的时候会怎么样，进而呢，他可以去啊，就快速的修复掉这个问题，避免有问题的时候留到发布的环节才被发现。啊，那呃，OB里面呢，就是总体来说，我们去解决这个发布可靠性的解决方案，是的一个自动配和的一个发布引擎啊，开发者呢，他只用专注于他自己负责的这个代码配置和circle。

P里面呢，它的一个，呃。自动配的一个引擎啊，会持续的去监听我们应用的一个品库及代码库，那会自动的把你的变更啊，包括镜像和配置和口的一些变更给自动的啊配起来。然后呢，随后这些应用的这些变更物料啊，会被我们的这个发布引擎啊，以可视化的方式放在我们用啊中间的这个版本里面啊，开发者或者说发版人呢，在版本发布之前呢，可以对所有的变更进行审核和追溯啊，确认没有问题以后呢，我们会做一个发版的一个流程。那将应用原子化版本化的方式发布到我们的多个环境中，保障了我们多环境发布的一致性和可靠性，同时呢，因为我们是基于代码商户，基于版本的，所以说里面也可以基于这一个版本啊，进行一个原子化的回滚。

我们看一下就是刚刚啊说到的这一些点，他在啊，就实际操作里面啊，它是怎么样去，就是怎么样的一个体验呢，我们呃进视频。应用的交付流程。需要先创建部署流程，确定上线流程，设置审批卡点，然后创建一个版本，审核版本，改动内容。然后执行上线流程即可。首先我们来到应用页，点击部署流程，创建一个上线流程，点击添加阶段，选择应用部署，选择test环境，更新流程名称为部署测试环境。接着我们在添加一个阶段，选择流程控制中的人工确认阶段。输入确认信息和确认。这个就是我们在发布生产环境之间的一个加点，接着我们的添加一个部署生产环境的阶段，点击保存一个应用上线的流程，就我们回到应用页面，可以看得到右侧有个的变更。

这也就通过一条粉丝引去实现。可以感觉到应用变化，我们点击去发来到创建版本页，版本由基本信息和版本变更两部分组成。基本信息用于记录和描述版本。我们重点看看版本变更部分，版本变更包含四个部分，就是版本中。维持版本这个业绩。本方内容。经常变更则列成了服务进行改动。由于本次发版是首次发版，所以全部服务能力出来。接着变更我们之前那个事情所做的。全部都可以机会一次发版体验观察呢。同时，我们还可以查看具体的变更。就拿刚才改动过的AU服务配置来看，影响环境是testing。在环境下。

A的值是t s product环境下AA的值是product，符合我们的预期。版本还包含数据库变变更，我们上一个视频添加的数据库变更也包含其中。创建版本，版本创建好之后，我们可以选择合适的时间发布，比如说现在我们点击发布按钮。选择刚才创建的上线流程。这样应用就进入到版本发布的流程中了。在发布期间可以点击查看环境，进入环境页面，查看环境内的服务状态。回到发布流程页，我们发现测试环境已经通过部署。此时，测试人员可以去测试环境验收，我们假设验收通过，他们确认人，也就是我，就可以以通过审批执行部署生产环境阶段，将应用发布至生产环境。Pro的发布引擎会先执行数据库的变更。然后进行配置和镜像的变更。

也就是把烟发布到集群中，也就是在这一个阶段中版本的三种发布物料。镜像配置和数据库变更都被一起发布到了对应的环境中。至此，应用的交付流程也是结。那么我们再来说呃第三个我们遇到的一个就是比较共同的一个痛点，就是说呃，其实我们现在谁都没有办法去保证我们线上永远的不出故障，不出事故，那么决定我们啊一个呃就是机构的一个服务质量啊，呃它其实决定性的因素是说，哪怕出了故障，那我们的故障的恢复的时间是不是短。啊，这在很多时候呢，要依赖于我们的研发啊，有多快能够发现问题，有多快的去解决这个问题。很多的一个机构啊，早就已经啊有了成套的一个监控日志的，呃，告警这些系统，但是呢啊，就是我们在很多的一些金融机构里面都发现了这个问题，就是说这些监控日志啊，在云生时代的今天，对于研发排查问题来说啊，不够友好，不够好用啊，首先是说这些平台里面的信息啊，基本上都是以资源为视角，也就是说他要去呃管就是我们的呃，PA要去管我们的资源啊，是deploy还是一个sta set要去管它的label啊，要去管这种东西。

然后呢，呃，而且他在不同的一个平台里面，就是要去查找他信息的方式是不同的啊，这就是说研发他需要大量的无效的信息中才能找到他自己关心的内容。其次呢，是说这些可观测的工具啊，通常都是互相独立的，而研发人员排查定位问题是需要啊整合分析三种类型的一个观测的数据，这就导致说研发人员要回的啊，然后在里面去这信息啊，影响整一个效率，那在混合多的情况下呢，这个问题会发的一个严重，因为不同的云，它的观测工具又不一样啊，那呃，第三个问题就是说我们信息的问题啊，就是研发人员呢，就是只能在里面串联不同工具之间的一个。

啊，那在里面呢，我们是以应用为中心，提供给研发人员真正他关心的一个业务视角的一个观测信息，啊，同时呢，我们是在不同的观测工具之间做了呃，很好的很方便的一个跳转和信息的串联。那你们是怎么做到的呢？啊包里面呢，有一层adapter的一个服务啊，是自研的，然后呢啊统一的去处理我们的监控告警日志和调用链这些数据，并且我们为每一种啊数据都提供了啊，就每一类型的数据啊都提供了啊这个数据的标准啊实现我们观测工具的一个可扩展性，就是说。

我们图中啊，例如说啊日志我们支持啊那个CS啊支持lock，支持啊EK，那么如果啊就是有个机构他用的是啊别的日志其实是可以通过我们的这个标准来去扩展它的啊一个就是呃接入的，那呃目前呢，我们呃比的一个生态兼容上面呢，我们支持普如师lock skywa等等的一些开源的一些观测啊工具，同时呢啊为了保证我们用户在生产环境上的观测工具的一个可靠性呢，我们也对接了腾讯云的云监控啊，还有那个应用性能观测以及日志服务等等的产品。为我们的一个生产环境做保家护航，Adapt模式呢，屏蔽了观测工具的一个复杂性啊，在这个基础上我们重新设计的观测的界面啊，那呃，全部置到了我们应用的环境里面，再结合我们应用的模型，最终呢，为用户呈现出来，是以应用为中心，以研发的视角啊为就是视角的一个观测的产品。

那我们呢，无论是开源啊，或者混合云的一个使用场景，或者是我们的呃，多云的一个使用场景啊，对研发来说，它的体验是一致的，都是在同一个应用，同一个啊就不同的环境，但是它的呃用户体验是一致的啊，不需要再切来切去来啊来去浪费他的精力啊，同时我们也解决了一个工具孤岛的问题。同时呢，观测产品所呈现出来的数据啊，都是以应用为中心的，也就是说在这个应用里。通常你仅仅可以看到这个应用里面的观测数据。这样我们来去解决我们的一个呃，观测数据啊，就是噪音多以及割裂的问题。

那面对这个数据的问题呢，我们呢，是需要建立观测工具之间的一个关联性的。啊，随着openry的这个技术的兴起啊，给了我们一条很好的通。在微服务架构下呢，链入追踪记录了啊，一次用户所请求的所有的节点和它的上下文信息啊，那使得我们的系统啊数据具备一个业务的性质。我们将链路追踪的唯一标识就是那个trace ID记录到了日志和监控系统中，这样呢，我们就不仅可以解决观测工具的数据断层问题，还可以让整一个观测数据具备业务的性质啊，建立了我们业务相关的一个观测统一平面，最终呢，我们啊以此带来了一站式湿滑的体验。我们来看一下就是，呃，我们在观测这一块，就是用户的体验是什么样的。请观看视频。运用运维流程，首先需要运维同学配置观测数据的来源。

然后研发同学就可以在环境内使用观测的能力，从口团队主页进入基础设施。对测试环境配置观测员，我们准备了一个DEMO应用，已经在集群内安装并配置好了开源的观测工具。如果为了稳定，可以选择腾讯云的云监控机NT和日志服务cos。后续也会支持腾讯云应用性能观测。目前我们输入配置好的观测工具的地址即可完成观测工具源的对接。接下来。我们以一个A指标低于预期值为例，看一看在欧的研发同学是如何拍照，然后再逐个介绍产品的功能，打开企业微信工作群。发现工作群有告警消息，通过告警内容，我们知道是低于预期，需要排查原因。打开告警中提供的地址。直达应用，强环境监控。

大致浏览定和服务指标后并未发现异常。切换到业务大盘面板。S标P95线已经超过八秒，需要借助链路追踪工具定位原因。我们将路标移动至平五线附近的原点上，点击K后面的链路追踪图标。即可直达导致监控异常的链路。我们通过鸟瞰图快速找到最后一个耗时长的子弹，点击查看详细信息，哦，吼，原来是这个服务设置了休眠时间，点击旁边的日志按钮。这里记录了更多的信息。如果还需要更多的日志信息，还可以通过上方的查看日志按钮。可以直接拉出来和该电路相关的全部日志。由此，一次丝滑的排照流程就结束了。接下来我们详细介绍一下各观测工具。首先我们进入环境页，点击系统卡片，映入眼帘的是波系统内置的监控面板。

包含应用级别资源指标和服务级别的资源指标。在服务监控内还可以点击服务名称进入服务监控页。这是以单个服务为视角的监控面板，提供了更详细的资源指标。如果你的服务是Java或者高，那么还会自动创建语音指标，包含了常见的监控图表，与服务相关的业务指标可以在上面分享。我们点击创建图表，进入监控编辑页。提供了九种常见的监控图表类型。我们添加一个业务指标，选择指标单位保存业务指标就添加好了。除了应用监控和服务监控外，包台提供了自定义监控，我们点开监控页左侧的业务大盘。这个就是自定义的监控面板，可以自行拖动修改布局。除此以外，还提供了自定义变量能力，通过变量的组合可以快速查看具体服务的监控指标。接下来我们看链路追踪，链路追踪记录一次用户请求所经过的路径信息。

是微服务架构下排查故障的利器。我们可以通过请求、时间、状态、耗时等筛选条件查找一行列。也可以直接通过，可以随地查询，我们点击有一常标识的电路，即可查看电路的调用详情。在鸟瞰图中，长度反映了各个节点的耗时情况。红色则标记当前节点存在异常，点击即可快速定位，点击日志图标则可查看当前的相关的日志。右侧标签则提供了更多辅助牌照的信息。接下来我们看看日志。搜索方提供了原生的语法提示，在筛选条件中也有提供了类似能力，添加一个筛选条件后，可以在条件筛选栏快速对齐，进行启用金等操作，简化操作步骤下的日志数量统计图。直接反映了符合条件的日志分布情况。

我们还可以通过框选的方式快速查看某个时间段的日志信息。左边是显示的日常有索引字段，通过写示和隐藏字来控制右频表格所写的里。也可以打开日现查同步字段，日志内容中含有ID标识，系统会自动识别。并建立前往链路追踪的通路，查看相关链路数据。最后，如果日志处于带有筛选条件的搜索模式下。还可以查看日志上下文，找到该时间附近的日志信息。最后，包台收集了服务的K8相关事件，由于研发同学辅助牌照，比如常见的因资源不足导致无法调度的事件等均可以在这里看到。至此，应用运维产品介绍结束。接下来的时间交给演讲者。好，那么啊，最后呢啊，我想提一下，就是说奥比这个产品啊，就是我们跟coding呢，是做了良好的一个整合，我们依赖coding一站式平台，早就已经很成熟的这些啊，包括项目协同，代码托管集成啊，测试管理品库等等等一些呃，一整套的一个工具，那我们为很多的一些金融机构啊，实现了我们全的一个效。

那最终呢，就是大家可以看一下这个的一个对比图啊，我们帮助了很多的一个金融机构，包括一些的银行部的证券啊基金等等的一些机构来去实现了我们啊DEMO的全流程的一个可靠性和效率的一个优化啊，帮助很多机构去啊，提升了他们的一个研发效率啊，节约了成本，以及说啊甚至有一些啊过了一些的一些定级等等。

帮助大家答疑解惑。同时请大家扫描屏幕中的二维码填写调查问卷。完整填写问卷，我们将抽取五名有效回答的幸运观众，送出我们的鹅场Q版公仔一只，期待收到您的反馈与意见。下面把时间交给潘俊明老师。好，我来啊，挑选一些问题回答啊。呃。呃，第一个问题是说OEM是coding新出的功能吗？呃OAM呢，它是一个开源的，然后呃有很多就是头部的厂商，包括腾讯阿里微软啊一起去呃共建的一个开源的一个应用交付应用建模的这么一个标准啊，然后呢，Coding呢是啊，我们刚刚的那介绍的那个产品里面的应用建模，也就是说我们呃去服务模板啊，运维插件，然后我们的呃研发人员来去通过表单来去创建服务应用这一套东西是O这个标准的一种实现。

啊，然后它是呃这种实现下，我们在coding就是这一个产品的一个新功能，对的啊，然后呢，也是呃一个就是我们开源社区里面的一个比较新的念，它这个的意思就是说我们的整个应用的一个建模的东西，他要以get仓库为唯一的一个资料源，也就是说我们所有的应用的东西都应该啊存到代码仓库，然后再做发布啊，不应该是手动的对着某个集群去操作，这样的话呢，我们呃就是代码仓库始终是一个呃代表着啊可信的呃，跟生产环境对等的一个呃描述对。

是用来提高可靠性。啊，这是第一个问题，然后啊第二个问题是啊，这个平台对于K8S应用支持看起来比较好了，但是对于很多金融机构来说，可能还有很多一个历史的债务啊就呃，例如说虚拟机啊呃需要管理，那咱们平台是怎么应对这个情况呢？啊这一个呢，呃，就今天演示的虽然是K8S的部分，然后呃，我们平台呢，是有支持啊主机组的部署的，因为啊我们这个OM的建模，它是一个呃平台无关的一个啊建模也就是说它既支持K8S的服务，也支持啊这个主也就是虚拟机。呃，然后呃，还有个问题是，刚刚看到你们部署流程编排特别简单，那么对于灰度蓝绿部署怎么支持啊，这里面也是我们在呃那个。

刚刚演示里面没有提到啊，但是呃咱们就是在正在呃灰度中的版本是有这个能力的，就是呃特别一提的是说，我们认为通过流程来去编排整个灰度的过程，呃就是在这是很多传统的一些CD工具的一个做法，但是在这些传统的C工具中，我们基本上没有见过能配出来可靠的呃灰度发布的流程的，特别是如果你这个灰度还是一个全度灰度的话，基本上流程是配不出来的，所以说呃这里面的呃，我们的做法是说让呃研发或者运维配管来去配置一个表单，这个表单来去生成一个相对动态的复杂的一个流程，来去做到我们的一个呃灰度发布，啊这个可能在呃，就是大概呃灰度完了以后，大家可以去试用一下。

呃，然后一个多服务工程的情况下，每次根据需求更改的微务不一样，在版本变更时，我如何可以灵活的勾选多个来创建一个发布单啊，或者针对这种情况怎么解决的？呃，面对灵活的多应用发布有什么建议呢？呃，目前我们只能针对每个微服务的department进行单独发布，如果每次发布服务太多就有点麻烦，对的啊，就是这一个，正是我们在做呃这一个包比的时候所呃发现的一个行业里面的共同的一个问题，就是发布会分在很多很多流水线里面，然后每个都要点一下，然后靠员工去呃想就是到底我要去发什么东西，那呃刚刚我们的版本里面啊，其实它基于我们的，我们会呃监听代码仓库监听我们的呃进像仓库来去自动版，有变化的东西才会进到我们的版本里面。

啊，也就是说版本里面它自动的显示出来的，就是你有变化过的这些地方啊，没变化的它根本就不出现。那如果说呃，他就是你改了，但你又不想发，呃，在刚刚版本那个页面里面啊，我们的镜像前面是有个勾的，就是你把它去掉勾选，然后呢，我们的发布引擎会排除掉这一个呃，Department的发布。对。嗯，好，然后平台是不是符合信创的标准呢？是的，它是符合信创标准的。呃，还有个问题是界面，呃是挺简单的，但是如果研发的人员不喜欢用UI，而是喜欢用代码来操作，呃，能不能兼容呢？啊，这个是这样子的，就是，呃，咱们OB的这个设计理念呢，是呃，UI是一套界面，代码仓库也是一套界面，也就是说两边的操作是双向的，你改界面，那么界面的操作会反映到代码仓库去，然后呢，你改代码仓库，代码仓库的修改也会反映到界面去。

这样子，也就是说研发人员他不需要去放弃自己的一个习惯，他依然是对着代码仓库来去操作也是可以的。好，我现在把时间还给主持人。好的，感谢潘俊明老师的细致解答，未来金融研究所系列直播第14期到此结束，再一次感谢潘俊明老师和朋友们百忙中抽出时间参加本场会议，希望今天的分享能够为您提供更多的帮助，祝您工作顺利，期待与您在腾讯金融云其他。

活动上再相见。