技术组件
我们这里探讨的是中台能力不是只堆砌技术组件，不是缺消息队列和定时任务调度框架就装一个RabbitMQ和Quartz，然后就抛给业务开发去使用，我们而是思考如何让业务开发更好更快速地上手使用，如何让多个项目组使用时保证组件的稳定和可用性。比如项目需要使用某个技术组件，我们可以经历以下几个步骤：
写一个文档，告诉开发需要哪些依赖，引用什么样的配置即可。
发现每个人都要这样很麻烦，我们即把依赖引入父工程或公共依赖。
发现每个人还需要配各种配置后，我们可剩下不能减少的配置，如服务名，其他的都放在远程配置中心或环境变量或其他地方。
增加UI可视化能力，可视化管理能力。
标准化，微服务化，业务域、系统级、公司级别统一微服务，多租户能力，如给每个应用分配权限，单独的进行数据操作，维护，管理。
发现需求，优化迭代。
通常一般的只是做1,2,3点，稍微好点的可以会增加第四点，如果真正的落地技术中台，应该在第四点，第五点和第六点发力，进行能力的抽象，进而形成标准化的能力，还能非常快速的提供给业务和其他技术部门使用，维护成本也低，这才是真正能为团队和业务带来价值的地方，也是提高研发效能和组织效率的途径，这三点就需要单独去开发和建设了。
这部分的能力就是让我们开发、测试、运维人员能快速的使用这些技术组件帮助我们解决特定问题，并且利用这些能力开发出公共微服务，提供给公司使用。
公共基础服务和技术服务
对于公共基础服务和技术服务其实包含的东西也很多，只要能抽取出公共能力的服务或技术，都可以单独拿出来进行操作：
公共基础服务：用户权限服务，业务配置服务, 通知服务，数据分析服务等。
技术服务：缓存服务，分布式ID服务，消息队列，分布式任务调度服务等。
比如权限服务，那么是否考虑整个公司或者大的业务域是一套权限中心，这个权限中心应当是多租户的，传统的老架构很多是各自独立的，那这里我们就考虑是否可合并。我这里没有列完，这部分内容其实是非常多的，也是非常重要的，是真正提高开发效率和效能的地方，往往也是很多公司欠缺的部分，有些公司可能有部分能力，更多的时候还是像我们之前说的，只是纯技术组件，而不是服务，耦合度也较高，也没有真正的支持多用户能力，使用起来也很繁琐，这样的东西和传统的架构方式并没有太大区别，也没有真正的为业务和开发去考虑，很有可能还是各自为政重复造轮子，最终造成流程的繁琐和数据的不一致。
技术组件、公共基础服务、技术服务这三块是真正需要公司下大力气去规划实现的内容，也是比较容易把控和落地的，这里面操作的空间非常之大，做好之后给业务带来的好处是直接可见的。
DevOps\u0026amp;\u0026amp;AIOps
DevOps层面，我们这里讨论的可能不是技术层面的实现，如如何使用jenkins，写好pipeline进行CICD，也不是如何利用docker + k8s+Jenkins做到动态CICD等，也不是如何做好DevOps模板，而更多的是DevOps现状做一些思考。
首先在实施DevOps时候，我们发现很多项目组只是在DevOps工具链方面做了很好的处理，比如采用CI/CD方法论，加上git, Gradle, maven ,jenkins，jacoco, sonar, CodeDeploy, Ansible,docker等等工具链，已经让CICD在企业和公司里实行了起来，并且还能运用好运维平台，在自动化方面做了很多工作，这些都给企业带来了好处和效率的提升。
其次，DevOps是可以贯穿需求，设计，开发，测试，上线，运维等多个方面的，它应该是要以应用为中心，以组织作为依托，来促进公司整个效能的提升，进而还能推动创新能力的增强，和促进人才、组织的优化，这才是有价值的DevOps。
不足的方面是文化、组织、流程方面，我们发现技术方面很多问题其实是管理的不足带来的，DevOps为了打破开发和运维墙而产生的文化在传统企业的组织层面还比较难调整，泰勒的金字塔管理结构还是持续发挥作用，部门墙还是继续维持，作为技术实施方的我们，肯定是希望完美的解决问题，在一开始就让团队或者组织进行调整，其实这对于很多企业来说是不太现实的，但我们发现随着CI、CD、CO能力落地，组织间的配合越来越多，人员的技能在逐步渗透，这时在无法立马解决组织层面问题的时候，可以逐步的让团队发生技术融合，职责传递和培训，从而推动团队的整合，形成我们期望的，融合的2个披萨团队，完成真正的DevOps文化和工具的全面落地。
AIOps层面：
在我们Ops运维方面，我们已经从过去的人工运维走到了如今的自动化运维，但我们发现这里的自动化只能是管控台，工具和脚本层面，如果在人的思想方面做到自动化其实是比较困难的，那也必将造成我们人工的进行分析和决策，也需要人工的进行检测点及规则点的录入，所以这也是AIOps能帮我们带来的好处，AIOps主要还是在AI层面发挥它独有的优势，在数字化运营，智慧运维这块发力，这部分内容也是建设中台可以考虑的部分。
效能：
我们的目标是持续的交付有价值且稳定的软件，效能方面其实是贯穿整个项目的，我认为它不单单指研发效能这一个点的，我们应该是思考如何站在整体的角度上去衡量团队和项目效率的提升，犹如坐在飞机上俯瞰大地，这里一个好的做法是成立一个平台型效能微团队，能定期的对项目和团队进行梳理，可以是任意方面，并可以借助一些产品和方法进行辅助，如利用看板，限制在制品数量等。另外这个团队重要的工作是能抽时间和站在更高的角度去发现整个中台的价值，改进点和缺陷，如形成好的公共支撑服务和标准化的服务，对中台进行不断优化和迭代。
时间仓促，涉及的东西很多，我们这次只谈论了技术中台的部分内容，当然整个的范围远远不止这几部分，抛砖引玉，希望有机会跟大家一起交流心得。 |
