以下内容以第一人称的视角，为您全面回顾视频内容！
——
ONE
某银行案例
门户
关于门户，众所周知，过去在OA里面，提到很多关于门户的概念。2020年，在北方有一个银行的客户，提了一个门户的诉求。
| 背景
随着业务的高速发展，该银行后端的整个运维平台越来越复杂，入口也越来越多。
典型的就是运维部门人员复杂，有网络管理员、系统管理员、应用管理员、以及DBA等等各类角色，不同角色的运维工程师会使用不同运维平台或工具。因此，该银行希望上层有一个门户来帮助其去收敛整个底层平台一些能力的入口，以及信息的一些呈现。
| 千人千面工作台
了解该银行需求之后，我们当时决定把这个门户变成一个千人千面工作台。
在做了这样一个定位之后，既然是满足千人千面的一个WorkSpace的话，那这里面就需要我们有精准定制的能力。针对不同用户的角色，甚至说大到行业小到客户，然后再小到客户里面的每个用户，需要很多定制化的能力来满足不同角色的需求。那低代码的解决方案，能够帮助我们很好的去解决这个问题。
从这个门户的整个核心设计的目标来讲，大概有几个方面：
第一个方面，希望这个千人千面工作台能够成为一个系统的入口
这其实是属于最初级的一个能力，就是把所有系统的入口都收敛起来，把它挂进去。比如说这个银行客户的系统里面有30多个平台，那不同平台的系统入口，我们不希望是由每个运维人员去记，运维人员可能还好一点，那对于一些新人或者外部门的人来说，根本就没法记了。
第二个方面，希望这个千人千面工作台能够成为产品和服务的入口
为什么叫产品和服务入口？作为运维部门，它是一个服务部门，它里面有大量的产品和服务需要暴露给周边的外围部门。那这个时候，就需要在这个门户上面要有这样的一个入口平台，帮助他们去暴露运维侧的一些产品和服务，比如说我们这里面有数据库，DBA的一些中间件等等这些产品，以及给他们开通xx防火墙等等这一类的服务。
第三个方面，希望这个千人千面工作台能够成为信息的入口
这个怎么理解呢？这个地方其实就是说我们底下的运维平台在运行的过程中，暴露承载了大量的信息，比如说来自于监控平台的信息，来自ITIL服务平台的一些信息......那这些信息需要我们聚拢、收敛到上层。然后我们希望这个角色能够进入到这个平台之后，能够快速的让人看到这个信息的一个状态，来代表整个服务的状态或者运维的状态是什么。
这里面清晰的入口包含两个不同的角色，第一个就是普通的运维人员，比如说像网络管理员、DBA......第二个就是领导者，这两个角色的信息诉求是完全不一样的。普通运维人员更多关注的是执行层面，领导者更多关注的是运维部的运行状态，比如说事件的趋势、故障变更情况、业务可用性、成本、资源状况概览等等。
以上，我们之所以设定门户的目标为这几个方面，是基于每个角色作为重点能力的考虑。最终我们知道要搭建这样一个千人前面的平台，就必须通过低代码的方式来实现。
之前有介绍优维低代码的能力，有UI可视化的低代码、中间层能力的低代码、以及数据层的低代码。那在门户这个层面上，更多的是以UI可视化的低代码偏重多一点，通过UI可视化的低代码来收敛用户系统的操作入口、信息入口、产品和服务的入口。
那在我们将优维整个低代码能力平台导入之后，差不多两个月左右，就帮助该银行成功实现了这个千人千面的门户平台，并交付给用户去使用了。
ONE
某券商案例
从场景化定制到产品化定制
该券商在导入优维低代码的能力，经历过两个阶段：第一阶段是微应用定制阶段，第二阶段是产品级定制阶段。
| 背景
这是一个非常大型的券商，2016年优维就与该券商达成合作。在导入优维低代码之前，该券商已经搭建了CMDB、自动化运维、发布平台、CNP等等30多个平台，可以说运维底座基本上已经完成。
| 微应用定制阶段
基于这个底座建设完成之后，优维公司在之前给该券商导入的自动化能力平台部分，越来越满足不了该券商的一些个性化需求，随之产生的问题也接踵而至。
● 第一个问题就是需求的定制化的一个效率和满意度的问题
我们经常会收到客户提的一些个性化的需求，但说实话，服务客户多了之后，从需求整个响应周期、时长来讲，其实没办法做到那种面向客户的快速响应。
我自己经常有时候也说，这可能是我们今天国内做项目制的一个天然的问题。当需求提出来之后，需要经历甲方现场的项目经理，再到乙方公司的项目经理、产品经理，再到研发部，然后去设计、去实现，最终可以把这个能力交付给客户使用，需要两个月左右的时间。特别是在建立一定的流程规范的前提下，基本上需要这么久，那这个时长对于客户来说是非常不满意的。
● 第二个问题就是需求实现成本的问题
我们从整个交付链来看，如果真正把这个竞争能力交付给优维来做，那优维的产品研发人员，他并不是在客户现场的人员，而且通过一两次来了解客户的需求，我觉得这个其实是有点天方夜谭的。所以，就导致了我们做这个需求实现成本的问题。离客户越远，那实现这个需求的代价就越高，就意味着一次就能理解客户需求的准确性就越低。
针对以上问题，后来我们就商量说，能不能在这么多能力平台之上，我们把这个定制的能力交给客户自己去解决。因此，在2020年开始通过引入低代码的方案去解决以上问题。
的确，用户个性化的能力是越来越多，那我觉得从系统层面上来讲，稍微有一个特别的地方就是我们是没办法让任何一个厂商去解决这个问题，只能把这个问题抛给上层的低代码。
“
举个例子
比如拿灾难切换这个场景来说，有CMDB、自动化运维、监控三个系统。那我切换场景：
第一步是要找到切换的系统，这个时候需要进入CMDB里去找；
第二步执行相应的自动切换的动作，就需要到自动化系统里面去操作；
第三步需要去监控系统里面查看切换完成之后的状态是否是正常的。
因此，可以看一个灾难切换的场景，就跨越了三个平台。
那这三个平台可能来自于不同的厂商，那今天如果是说我们想实现某一个能力的话，这个需求提给任何一个厂商，貌似都不是最优的答案。比如说去跟CMDB的厂商提，CMDB的厂商说这个需求不在我的范围里面，而提给自动化运维的厂商，自动化运维的厂商说我要跟其它平台做集成，做交互，这个定制成本太高，监控同样如此。所以，后来客户也觉得这里有一个掣肘的问题存在，跟厂商之间的目标等等有一点不一致。
因此，后来就想着说，那就在上面基于低代码由客户自己来做了。
我们在2019年定的那个项目里面，我们当时是定了券商行业很多个性化的一些场景。我们讲的第一个阶段是微应用定制阶段，其实对应的就是这种小需求小场景的定制阶段，比如说：
我们想看看智能投顾业务目前交易量情况是什么样子的？
我们想看看设定一个系统的自动化切换的场景是什么样的？
我们想看看做一个批量部署应用的场景是什么样？
......等等这类的需求场景。
那在券商这个项目里，提了七个微应用场景，这七个微应用场景都是券商行业所特有的场景。这里有一个问题就是，在产品定制上，考虑假如优维把这七个微应用场景都做了，优维是没办法再对外去输出。因此，就和该券商商量，以双方共赢的模式，结合该券商的场景需求，优维把这个平台的能力封装起来。
七个微应用，只有一个是优维公司开发的，剩下的六个由客户自己来实现定制。为什么会有这样一个设计？主要考虑的是，希望通过优维低代码平台赋能客户掌握自主定制开发的能力，因为随着客户业务发展，未来会有大量微应用场景需要定制。
目前这个项目已经结项了，我们大概也做了差不多一年左右的时间，因为很多业务需求，包括系统平台一些能力的调整，我们把这七个微应用基本上实现了。整个项目结束下来，我觉得最大的收益就是，甲方客户通过低代码平台的能力，实现了运维向Ops运维开发的方向去转型。其实客户在转型的过程中，其遇到的技术鸿沟是非常大的，如果客户是按照原生的那种模式去开发自己的运维平台，需要掌握的能力非常多，从前端到后端，从技术、存储等等这些微服务架构，这个鸿沟太大了。其次，前端的业务部门和周边的开发部门给运维部门提了一些需求，运维承受的压力也是非常大的。
所以，低代码是一个很好的低成本、高效率的转型工具，也是一个帮助运维人员向运维开发转型的过渡工具。低代码的高效率，让客户再转型的过程中需要跨越的鸿沟没有那么大，所需要掌握的技术点也没有那么多，特别是优维公司低代码的整个解决方案，我们尽量把很多的能力在底层里面就屏蔽掉，对客户不做过多的透明，就是让客户的开发人员能够更多的聚焦在自身业务需求的分析和理解，以及原型的设计上面，这就是低代码的核心能力点。
| 产品级定制阶段
今天优维公司导入了很多平台，其中有一个非常核心的平台，就是持续交付的平台，每天在该券商系统里面承载了大量的发布变更。
这里面，发布变更包含三个方面：
二进制程序的发布变更
配置的发布变更
数据库的发布变更
除了以上三个方面的发布变更，还有很多组合逻辑，比如说我今天要发程序，我也要发配置，我明天要发程序发数据库，我们后天要发程序，配置和数据库，就是各种逻辑都在缠绕着。那这么多逻辑在一起，其实它整个的发布部署的要求是不一样的。
所以，在这里面就涉及到编排的逻辑。那这个逻辑其实非常复杂，就是我们今天怎么样去切合着，甚至还有到真正的客户这一侧，他的不同的业务系统，这个编排的逻辑和方式方法要求是不一样的。
大家都知道，券商的核心业务系统，国内目前是由金证、恒生两家服务商提供的。那这两家服务商提供的，其实是按照自己乙方的产品版本交付节奏，或者说可能有时候也来自于证券交易所，证监会等等一些政策可能出来的一些东西。那在这个稳定的节奏之下，如何去把控这样一个变更模式，确保这个变更是在一个安全可控的情况下发布到生产环境，再开发测试生产，资金的流转。
所以这里面就产品，我们觉得就是说今天通用的什么业界讲的那个DevOps工具，特别是Jenkins或者什么之类的一个发布工具，远远满足不了金融行业复杂的要求，比如说安全的要求，在可控上的要求，在不同的业务系统之间的整个发布要求。所以，我们就想着如何把产品级的这个定制能力进一步赋能给客户。
“
一个前提
那在这之前，我们有一个非常重要的前提，就是我们优维自身所有的产品是不是低代码做的？
这个是我们的前提，如果优维公司本身的能力平台不是低代码构建的话，你今天想通过低代码来实现产品级的修改，这几乎是不可能的。我们只能说，保证在同一个能力框架体系里面，一套标准下面去构建，才能够说我把这样一套机制交给客户去修改。
基于这一点，在很早探索低代码的时候，优维公司就坚决走了这样一条路，就把优维所有的产品，以前所谓的那种产品开发模式全部转向了低代码。我们在去年上半年就开始组织重构，把我们所有的产品基于低代码这个模式全面重构了一遍。
之前我在公开的分享里面也讲过，我们通过低代码的重构，把优维公司所有产品的一些构件积累起来了，共积累了上千个构件，其中就包含跟业务强相关的，比如主机的构件、网络存储的构件、监控的构件、自动化运维的构件......这些构件都能够被拿来即刻使用的。那有了这样一个构件级的能力，客户在上面基于他的修改，也就变得简单了。
一个矛盾
其次需要先解决一个矛盾。
因为它不是微应用级别，而是产品级的修改。那优维公司自己在该，客户也在改，那问题就来了，怎么把这两者融合起来？
我们内部在产品的设计上做了一个动作，就是把一切看成资源，比如URI页面、menu、菜单、以及页面打开之后page的构件，都把它们看成是一个个资源。这些资源在我们整个产品构建的时候，都把它们明确的定义和积累起来，因为低代码本身其实也是把这些东西一个个当成资源来看待的。
你可以认为，优维公司产品，它自身有个很大的容器，这个容器里面就是把我们所有的资源装载进去了。你也可以认为这个容器是一个master容器，但是在代码上是没有分支这一说，我们不能在代码上面建立这样一个耦合机制，如果在代码级别建立这样一个耦合机制，就回到了我们过去多版本的那个机制上面去了，那根本就没办法解决这个矛盾。
那回到第一个微应用的定制阶段，假如产品级的能力想扩展的时候，可以通过微应用来扩展。所以在这个master的容器里面，可以理解为它是一个大的微应用，它把所有的东西转载进来。今天，假如客户要对这个master主干的能力去修改，可以拉一个分支，这个分支就是特有的微应用。这个微应用就像一个小容器，把需要修改的资源装载进去。
今天你对产品级的修改就是容器背后所链接的page和构件的资源的修改。当然最终可能还有延伸到后端的一些什么API的再编排，那这就需要我们之前讲的我们的业务逻辑FollowBuilder去做的,包括我们的数据层DataBuilder。
那有了这样的一个机制，那我们今天在这个特有容器里面，可以把URI以及Menu所对应的后端的资源，在这个容器，在这个微应用里面重新定义一下。
定义完了之后，系统在启动的时候，我们就可以把这个资源重新再去加载。这就相当于在Windows启动的时候，把注册表的一个注册项给修改了。你可以理解，刚才我们在这边列的UIR、Menu以及peag等等各类资源，就相当于是优维公司产品的一个注册表，如果要对这个注册表进行修改，可重新去生成一个容器，对这个能力进行修改。修改之后，接下来系统在启动的过程中，就扫描这个注册表，发现这个URI对应的资源项被改了，那接下来就可装载新的资源。
因此，就实现了这样一个产品级定制修改的能力。那优维这个修改的能力和客户的修改能力是兼容的。目前，这个产品级的定制阶段正在实施中，项目进展顺利。通过在该券商成功实践积累，今年还将微应用定制的机制推荐给了几个银行、几个金融客户，再深度去打磨、去使用。
在前面也讲了，随着业务的深入，客户的需求越来越多，我们没办法对每一个客户的需求及时响应。但这也不代表我们不去看业务需求，不去看客户需求，产品的生命力一定是要帮客户解决问题，只不过在这个能力业务平台之上，去借助另外一个类似“核武器”的东西，就是低代码。
我们想通过低代码的解决方案，将这个定制的能力赋能给客户，让客户获得一些自主开发的能力，让其快速实现个性化的需求，这样一来客户就不会全心依托在优维的服务体系上面。
同时，优维公司通过这样一个能力示范和赋能，促使优维公司在产品边界上不断去突破和创新。我们知道今天IT的变化是非常快的，进入云原生时代后，整个IT能力是日新月异，创新不断，那围绕我们这样管理性的平台，需要把握未来整个IT的变化趋势，实时的推出一些新的产品能力，比如说优维今年也在探索混沌、价值流、云端等等之类的产品。我们希望通过不断的突破与创新，来构建更加先进、安全的产品和解决方案，赋能客户，帮助客户快速实现数字化转型。
