此为实战经验输出章节，重点在于自我的经验总结和实践经验记录，自己在整个过程角色是架构师和研发部门负责人角色，即设计和执行合一。
背景
开始介入的时候已经基本上完成一版本，部署和架构基于传统的服务化方案，进行RPC之间调用，服务器和监控的模式还是传统的虚拟机资源分配的形式，项目管理按传统的软件工程管理进行。项目的规模属于中型项目，政务民生类项目，用户规模大概在城市级百万级左右，每天涉及到资金交易在亿级别，项目周期大概是1年多，属于业务型服务。
以下阐述规避涉密因素不涉及相关单位和公司字眼。
概述
从传统业务架构的服务器发布，同时也包括项目管理开发流程（CMMI3结构），再到传统的项目管理运维等进行架构升级，升级的目标为业务中台架构，为下一步数据运营管理做好基础。升级过程从团队、专家、业务、架构等几个维度进行的调整，以适应当前IT行业的发展和数字化市场环境，在这个升级的过程不仅仅是技术项目的升级，更多的是组织架构，团队技能的升级，以消除前期传统模式留下的弊端。
升级过程阐述分四个维度，主要升级的成果点：
-
传统系统架构升级中台系统架构模式，即提取业务中台，大中台，小前台模式；
-
管理模式转换成中台组织架构模式，即中台专家支持，业务兵团走前端；
-
软件项目开发转换成行业产品型研发，即输出项目的同时输出中台产品型服务；
-
传统的运维模式升级成自动化运维模式，即全方面的运维监控体系，可自动化可预警；
按前期-中期-后期三个时间段时间编写，整个过程我有我思。
升级过程
这个过程无疑还是一个突出的问题：决心。中台型的转变需要整体团队的互相配合。每个节点做好自己的事情，需要上下一心的转变，领导层的意识和可行性的架构能力的支撑。
过程基本是老打法、老方式，而这也是最有效的。
前期
前期最主要的还是团队的意识，这里的团队包括的不仅仅是一个组，而是整个团队的上下意识，这个过程调整了组织结构，这基本上将原有的项目管理模式归由研发部进行整体指导，主要是：
-
调整组织结构，技术支撑下沉到研发部；
-
技术架构重构，进行二次架构的升级，形成全体升级转变的指导思想；
-
将升级战略上升到团队最高层面，思想意识统一；
以上几步基本上解决了执行的基础保障，也是中台架构的基础保障条件。
架构升级的前期遇到的最突出的问题，旧系统的切换，这是一个矛盾点，在不违背大家过大的意愿下，调整的架构设计，当中也做了很多妥协，另一个是牺牲一部分技术妥协团队的接受，一步步推进。从上而下的业务模式改变，主要包括几个点：
-
虚拟机转变成k8s容器化，升级虚拟机配置，减少服务器数量；
-
发布过程集成docker容器化，同时调整最小配置，减少大家的学习成本；
-
流量的切入转换成对外nodeport的形式（rpc协议），这是一个妥协点，主要还是考虑到技术的过度；
-
服务化设计保留原来的基础工程结构，保留前期的CICD还有服务调用模式。
上面几步基本上解决了基础层的问题点，还有过程持续构建的弊端点，资源不稳定点等。
中前期
基础层的解决和保障，最终还是回到业务建设上。
最可能出现问题的一点和沉淀能力的抽取考虑上，原业务架构，比如原来就没有考虑到这样的方式，进行的项目还有工程研发等，这个基本上最有可能导致后期上线不稳定的因素，做了几点：
-
培养和完善手册，还有培训机制，将各个责任点下放；
-
保留原服务工程的调用机制，尽量在k8s上进行妥协和解决问题，实在不行的再调整业务代码；
-
完善运维机制和监控机制，原有的业务排查方式和发布式的转变；
-
多层面上进行运维角度的整合，包括系统、日志、链路、流量、灰度等多个层面的保障；
-
去掉一些不可控的业务节点，保留原运行模式，规避各类安全策略的问题，这也是一个妥协点。
-
业务服务抽取可形成产品模块，此从业务层面进行妥协，调整代码和项目结构；
-
多处运用消息机制，进行业务模块的解耦和可产品化调整，此也从业务层面上进行妥协。
基于以上多种结构的调整，基本上业务中台架构的雏形很快体现，这个过程消耗了差不多几个月的时间，基本上还是符合预期点，在有项目的推进下，其实各个部门还有项目组基本上感知性还有排斥性没有多大的体现，在研发和技术的支撑上，转变过程基本上无感知。
中期
这是一个问题暴露阶段，这个过程需要的全员的配合，这也是为什么在前期下放责任和思想 统一的原因点，一个架构师，一个部门是无法支撑起团队能力的。
过程问题最突出的一个体现：信心问题。这个是前期自己的问题点，当然，这也是在自己把控范围内的一点，也是必然会出现的一个情况，这个跟以前转型（自己在多家大中型团队做过转型）基本上是一模一样的问题体现，有的时候，在理论上是可避免的，但是在操作上却是不可避免的。
初期的验证和转换调整操作，基本上觉得没什么问题，但现实是不可预知的，在综合业务场景上并不等同于互联网型的通用项目，行业软件存在很多不一样的因素，它里面包含了很多复杂的业务逻辑，类似于银行系统，并不是那么敢轻易换掉oracle一样。当前项目也涉及到大量的资金交易也较大。在上线暴露问题点的同时，很多找到的解决方案都没有涉及到，这步让团队在切入过程中，心态上比较紧张，对新架构的信心程度还有各个节点的支撑人员也头疼。
一个场景是在前期基本上按k8s服务之间调用方式来进行的，但是在内外网络隔离，还有外围服务的时候，IP判断的问题，还有各种第三方插件的问题等，还有各个使用群体（比如银行）上相应表现不佳。沟通协调，排查困难程度较大，单个层面无法解决，最终是上下层统一协调解决点。
类似于上面的场景，并不是说有多大困难，而是部分场景下没有思路，各种条件下问题比较隐性。这个过程是团队会面对的问题，在最终解决下，会更进一步的提升团队的能力点，最终达到内部接受到自然状态。
另一个是一些操作的不成熟，还有验证性，需要大量的生产和测试验证，以确保可行性和后期的稳定性，这些前期验证环境有操作，但是也有很多未知，这些都是要面对克服的问题，这个过程几乎都是熬夜过来（几乎每次转型都遇到类似），同样需要整体团队的解决能力。
后期
这里针对的是在架构设计层支撑和中台研发团队架构的支撑上的后期。
到这一步的时候，业务中台架构基本上便向于稳定，由原来的中台架构雏形，转变成业务中台架构。不管是技术、团队、业务、专家还有各个场景下的沉淀都已经有了沉淀能力，包括解决方案等，形成一套业务中台能力点，主要包括以下几个点：
-
团队组织能力，形成中台组织架构保障，研发层和业务层；
-
技术沉淀能力，形成技术中台和研发支撑层；
-
产品输出能力，形成行业产品沉淀，形成基础的行业标准产品组件；
-
解决方案能力，在行业软件中形成一套可行的解决方案；
-
中台业务能力，业务大中台产出，小前台业务建设的综合能力。
余下的，更多的是架构设计的前期问题梳理和进一步的优化，各个管理功能的完善和进一步沉淀产品能力，集成到中台管理平台上，同时在各个团队和小组之间进行经验分享和总结。同时为下一个业务场景进行梳理。
其它
按目前的行业发展来看，当前AI、物联网等智能化的发展迅速，在进一步待场景和人才，目前也在整合这些能力点，在业务中台化建设的后期，同样会在中台化的基础上融入AI、物联网的基础产品能力范围，在行业中台上面进一步的升级中台业务大脑。