罗小东，软件架构师，多年平台架构和落地实战经验。在目前行为的发展状态下，数字化并不仅仅是一些大厂家可以做的，自己的一直以来的架构经验里面，中台是中小企业或者团队的新型基础设施，提高团队技术能力和竞争力的利器

概念

数字中台、技术中台和数据中台之间有着密切的关系，它们可以相互补充、整合，协同提高企业的数字化能力。

首先，技术中台是数字中台和数据中台的基础设施，因为技术中台提供了通用的技术组件和服务，使得数字中台和数据中台能够更加快速、高效地进行开发和部署。比如，技术中台提供的标准化接口和服务可以帮助数字中台和数据中台实现应用程序和数据的集成和共享，从而提高企业的运营效率和质量。

其次，数据中台是数字中台的重要组成部分，因为数据中台提供了企业内部和外部数据的采集、存储、加工和分析等功能，为数字中台提供了更加全面、深入的数据支持。数字中台通过整合各类数字资源，加强不同应用之间的协作和集成，从而能够更好地满足企业数字化转型的需要。

数字中台通过技术中台和数据中台提供的基础设施和支持，实现数字化资源的整合、协调和优化，从而为企业带来更多的商业价值。

概述

随着数字化时代的到来，企业必须转型升级才能适应新的商业环境。而数字中台作为未来企业新型基础设施，成为了中小企业提高技术能力和竞争力的一大利器。以技术中台和数字中台为基础，建立针对中小企业的数字中台基础设施，可以为中小团队带来技术能力提升和自动化提升的基础，进而提高团队的技术能力、数字能力、竞争能力等。

数字中台作为未来企业新型基础设施，是推进信创、国家数字化战略以及技术高质量发展的重要手段和支撑。中小企业在数字化转型过程中面临诸多困难和挑战，如缺乏专业的信息化团队和资源、信息孤岛问题、数字化转型成本高等，而数字中台可以为中小企业提供有效的解决方案。

建立针对中小企业的数字中台基础设施，可以帮助企业实现信息化系统的整合和管理，降低信息化系统成本，实现自动化和智能化，提高工作效率和生产效益，提升团队的技术能力、数字能力和竞争能力。同时，数字中台也具有开放、共享、可扩展等特点，为中小企业提供了更加灵活、高效和创新的发展机会。

以下为几个方面进行阐述：

1. 数字中台解决了什么问题？
2. 为什么需要建设数字中台？
3. 数字中台的作用是什么？

以下为主要内容阐述，这里主要针对基础设施来进行阐述，而非业务。

内容阐述

在信创、国家数字化战略以及技术高质量发展的背景下，企业内部存在大量的信息化系统，这些系统数量众多、种类繁多，管理和维护起来非常繁琐。同时，由于不同系统之间缺乏有效的交互和共享，会导致信息孤岛问题，影响企业信息化管理的效率和质量。

通过数字中台的建设，企业可以降低信息化系统的管理成本和维护成本，提高信息化管理的效率和质量，进而为企业的数字化转型提供基础保障。因此，数字中台在信创、国家数字化战略以及技术高质量发展中扮演着一定的角色。

它解决了什么问题？

解决了信息化系统的不协同问题：企业内部存在大量信息化系统，数量众多、种类繁多，管理和维护起来非常困难。数字中台可以将这些系统进行整合，实现信息的统一管理和共享，从而消除信息化系统不协同的问题。

解决了信息孤岛问题，使企业内部信息互相连接：企业内部各个信息系统之间缺乏有效的互通和共享，导致信息孤岛问题的出现，影响信息流通和利用效率。数字中台提供了标准化的接口和数据格式，使得不同的信息系统能够快速、高效地进行数据交换，避免信息孤岛问题的发生。

解决了大量重复工作和人工操作，实现自动化：数字中台可以通过自动化的方式完成大量重复工作和人工操作，提高工作效率和生产效益，同时也可以降低相关成本。

解决了企业在数字化转型过程中的技术难题：数字中台作为新型的基础设施，可以帮助企业实现技术资源的整合和归纳，提高技术服务效率和质量，为企业数字化转型提供坚实基础。

解决了企业数字化转型成本高的问题：数字中台可以整合企业内外部各类数字资源，形成一个开放、共享的数字化生态系统，降低数字化转型的成本，并且提高数字化转型的效率和质量。

为什么中小企业需要数字中台？

中小企业在数字化转型过程中面临着种种困难和挑战，而数字中台的建设可以为中小企业提供有效的解决方案。以下是详细描述：

中小企业常常缺乏专业的信息化团队和资源，数字中台可帮助其提升数字化能力：对于许多中小企业来说，在信息化系统的建设和管理上缺乏专业人才和资源，这使得数字化转型变得更为困难。数字中台作为一种新型的数字化架构，能够帮助中小企业实现信息化系统的整合和管理，并提供数字化服务和技术支持，从而帮助中小企业提升数字化能力。

数字中台提供了开放、共享的数字生态系统，支持企业增强产品创新和服务能力：通过数字中台建设，企业可以将原本分散的数字资源进行整合和共享，形成一个开放、共享的数字化生态系统。这使得企业可以更加高效地进行产品创新和服务开发，提高企业的竞争力。

数字中台实现了信息化系统的整合和管理，降低了企业的信息化系统成本：数字中台可以将企业内部各个信息化系统进行整合和管理，避免了重复投入和维护成本的浪费，从而降低了企业的信息化系统成本。

数字中台实现了自动化，提高了企业的工作效率和生产效益：数字中台可以通过自动化的方式完成大量重复工作和人工操作，提高工作效率和生产效益，同时也可以降低相关成本。

数字中台为中小企业带来了数字化转型的机会，让其更好地适应新的商业环境：数字中台作为一种新型的数字化架构，可以帮助中小企业实现数字化转型，适应新的商业环境。通过数字化转型，中小企业可以拓展市场，提高生产效率，增加收入，提升竞争力，并更好地适应未来的商业发展趋势。

数字中台有什么用？

实现信息互通和共享

数字中台作为一种新型的信息化架构，可以将不同系统的数据存储在一起，实现信息的互通和共享。与传统的信息化架构相比，数字中台能够提供更加灵活、开放的数据交换方式，从而避免了信息孤岛问题的出现。数字中台利用标准化的接口和数据格式，使得不同的信息系统能够快速、高效地进行数据交换，实现信息互通和共享。这样，企业内部各个部门之间就可以更好地协作，避免了信息流通受限、信息利用效率低下等问题。

提高技术能力和竞争力

数字中台可以为企业提供数字化转型所需的技术支持和服务，包括云计算、容器云等多种技术。通过数字中台建设，企业可以更加轻松和便捷地获取到最新的技术服务和解决方案，从而提高企业的技术能力和竞争力。数字中台还能够帮助企业实现数字化转型的目标，推动企业在数字化转型过程中迈出坚实的步伐。

降低成本、提高效率

数字中台可以大幅度降低企业信息化系统的建设和维护成本。在传统的信息化架构下，企业需要投入大量资源来进行信息系统的开发、测试、部署和运维等工作，这些过程繁琐且耗时长，效率较低。而数字中台可以通过标准化的数据交换方式、自动化的流程操作等方式，实现信息化系统的快速开发、部署和运维，从而提高了工作效率和生产效益。

提供创新发展机会

数字中台可以为企业提供开放、共享的数字化生态系统，为企业的创新发展提供坚实的技术支持和服务。数字中台能够帮助企业获取更多的数字资产和资源，同时也能够促进数字技术的创新和应用，推动企业数字化转型的深入发展。数字中台还能够支持企业的新产品开发，优化服务流程，提升用户体验，从而增强企业的竞争力。

支撑企业数字化转型

数字中台是数字化转型过程中的关键要素之一，它能够帮助企业快速响应市场需求，完善数字化转型体系，提升企业竞争力。通过数字中台建设，企业可以实现信息互通、自动化流程、创新发展等多方面的目标，从而推动企业数字化转型的全面发展。数字中台能够为企业提供可靠的技术支持和服务，缩短数字化转型的周期，降低数字化转型的成本，提升企业的数字化能力和竞争力，帮助企业在新的商业环境下实现更高的价值和收益。

企业内部自动化

数字中台实现了自动化和智能化，降低了企业的人工成本，提高了工作效率和生产效益。数字中台通过自动化的工作流程和任务分配，可以实现大量重复工作和人工操作的自动化。数字中台还能够将企业内部多个信息系统进行集成和整合，避免了重复投入和维护成本的浪费。通过数字中台的自动化支持，企业能够更加高效地进行工作，提升生产效益和竞争力。

提高数字化转型效率

数字中台可以快速响应市场需求，提高数字化转型的效率和质量，帮助企业更好地适应新的商业环境。数字中台能够在数字技术、数字服务和数字架构等方面为企业提供强有力的支撑，加速企业数字化转型的进程。数字中台还能够为企业提供完整的数字化转型解决方案，帮助企业快速实现数字化战略和目标。通过数字中台的支持，企业能够更加高效地运营和创新，提升数字化转型的效益和质量。

总结

在目前行为的发展状态下，数字化并不仅仅是一些大厂家可以做的，自己的一直以来的架构经验里面，它是中小企业或者团队的新型基础设施，提高团队技术能力和竞争力的利器，数字中台是未来企业的新型基础设施，对于中小企业而言，建立数字中台基础设施可以为其提供技术能力和自动化提升的基础，进而提高团队的技术能力、数字能力、竞争能力等。

罗小东，软件架构师，多年平台和中台企业建设和落地经验，以下为从工程师角度，第一人称进行阐述，会略带有口语。

背景

阿里走向组织治理的全新阶段——构建‘1+6+N’的组织结构，即在阿里巴巴集团之下，设立阿里云智能、淘宝天猫商业、本地生活、菜鸟、国际数字商业、大文娱等六大业务集团和多家业务公司，会有一些思考。

本文针对的是此类思考做的文字阐述，分以下几个点：

• 思路阐述
• 怎么使用
• 使用要求
• 后期维护

虽然现在很多企业或者团队都已经实践了，自己感觉这个好像并不需要再讨论，这里只做一家之言，我有我思。

思路阐述

中台解决问题的定位不一样，这个概念出来挺多年的，但是见到的解决方案和架构，基本上都是一个套路，一个路数，到目前为止，见到很多解决方案，大部分，很少说见有遇到能讲解或者见到对这块比较有深入表达，或者比较惊艳的理解，这个在很多时候，都是极度模糊的词和边界。

这个表达貌似有点奇怪，如果做过架构的同学会有一个体会，一个架构在另一个地方可以落地，可能换个地方就不行，如果不好理解，再换一个例子，比如软件工程流程，在一般的中小项目基本上很难走通，那套规范，可能还没有开始，项目就线束了，那是不是就否定这套流程，其实不然。

在过程中感受是，关键是否能把这个核心和思路深度消化，然后运用起来。

在前几年讨论过很多回，也在很多团队接触过讨论，在这个过程中的感觉好比别人送给你一个屠龙刀，会使用的人可以扫四方，但是不会使用的，可能会惹火上身，甚至会发现，还不会以前菜刀方便，关键是怎么使用。

怎么使用

我是怎么使用中台的，这里只是一个参考，除是产品型输出打造以外，主要使用在几个方面：

• 我需要快速创建业务应用，解决掉创建应用过程中的问题
• 我需要做数据仓库和挖掘，数据以更好的辅助应用的建设
• 我要运维和监控这套平台，解决应用过多的问题的问题
• 我需要快速跟进行业的发展，提供出更好的解决方案
• 我需要一个稳定可控的平台，来支撑我的解决方案落地

日常使用过程的方式，管中规豹，需要一些团队管理的想像而扩大到团队。

解决掉创建应用过程中的问题

比较不喜欢一上来就提n多好的技术和业务无关的，有个文档告诉1、2、3点，然后就实现这部分就可以，其它的不想关注。

创建业务应用到底有什么问题，怎么就能快速创建业务和应用。

这里定义的业务不是所有的业务，也包含当中的某一个模块或者某一个功能，这主要还是依托微服务架构，首先，在开发过程中，对我来说，最注重的是成本，主要偏向于时间成本，开发成本，维护成本，升级成本等上面：

• 目前行业不断的架构和技术变化，这个过程需要不断的消耗时间
• 每个模块的规范不一样，无法共用一些功能，每个都需要消耗时间去调整
• 非功能性需求不稳定，CURD的常用功能不稳定，在调整这块上一直消耗时间
• 简单和重复的功能每次都需要复制编写，在稳定性上测试也消耗时间
• 运维监控和日志监控这些我需要做监控，在排查问题上消耗时间
• 在交接需要跟别人解释这个怎么集成，主要在非业务解释上也消耗时间
  …….

以上制约了我很多无用的时间，一个是影响效率，另一个是消耗时间，做的大多是重复工，进而影响成长，我想要的是生成大部分代码，只保留业务逻辑部分，我只需要考虑这部分就可以。

解决掉以上的问题之后，我的组件只需要做好，然后配置丢到容器里面就可以，操作过一两次熟悉之后，就不再形成瓶颈，而我需要的实现业务逻辑就可以，而且大家都统一，沟通成本也没那么麻烦。

这样可以把精力在这块上面，包括文档和处理思路，出来的编码还有文档，质量会更高很多，而不是需要我再整理N多的东西，统一发出，再搞很长的解释，还有后期不断的咨询到这里。

数据以更好的辅助应用的建设

一样不喜欢一上来就讨论n多的技术和业务无关的，有个文档，简洁的告诉1、2、3点就可以，其它的不想关注。

应用跑的过程，会产生日志，包括请求、用户访问，有些表的数据过大，而又非业务数据，需要定时删除，报表统计过程中，应用过程中表结构已经定了，不好再对表进行修改，除了报表还有运营的数据，这些指标需要定义，还有过程数据需要采集回来再运算等。

这些都是数据层的处理，在没有数据仓库之前，无法挖掘，或者这个成本较大，另外数据存储问题也比较大，再然后就是数据计算出来之后，又需要提供给业务，两者互相并辅助。

还有就是想做一些机器学习，挖掘业务使用场景，创新业务和方案的查询，同第三方系统，多个系统之前的交互，也无法做到，也就是常见的数据孤岛问题。

还有等保安全要求等等。

这些还需要思路放哪里，怎么放数据，还有这些流程怎么样，规范是怎么样的，需要的是，生成对应的初版脚本，我只需要修改我的逻辑部分就可以，然后数据自动采集到数仓就可以，按规范来处理。

在挖掘上，我只需要拖动每个数据处理流程，形成工作流输出就可以。

支撑我的解决方案文档落地

写方案，非业务的，不想再找n多的文档，而且找不到稳定的方案在哪里，需要到底问人等材料，需要快速铺商务

在解决方案上，需要一个强有力的平台进行支撑，针对不同的业务，需要集成的不同能力，进行各个服务或者应用进行整合和支撑，拼凑起来就可以，而不需要到处询问，或者说到处查阅这个组件在哪里，怎么支撑。

能有演示，可以让整个串并跑起来，而且我也能看到，确定可用，这为后期商务上做好支撑，同时也是给客户商务过程提供信心，以提高在各个过程中的竞争力。如果业务应用没有怎么办，跟ISV整合即可，即使一下没有，那也只是单独处理的模块，并不需要我再从零考虑这个方案落地过程中的太多问题。

而且这个过程，报价居高不下（除了商务策略以外），内部成本也无法评估，让利部分也没底，整个下来，跟竞争对手对比上容易底气很不足，更别说打动客户了，可能打动自己人都比较难。

比如一个简单的场景例子，应用上的沉淀和数据的沉淀，这两块在规范上形成自动化，这个成本上基本上就低很多，另外在客户演示或者项目前期，基本上就可以马上搭建部署进行一期，各个申请资源还有管理就走下来，推动项目的进程，难道还需要考虑等开发出来才能实施，这个交付周期就拉长了。

后期维护

需要的是不断升级和维护一个中台，集中精力在这个上面

我不需要迭代今天一个明天一个技术框架，也不需要每个都要重新建设一次，走一次流程，需要不断的迭代，一个是熟练，另一个是大的流程不变，当中可能升级某个点，但是升级之后，需要兼容前期的接口还有框架，这个在高级工程师和熟练的情况下，问题其实并不大。

这样在过程两三年的迭代中不断的优化，稳定性更强，健壮性也更强，类似于一辆车，单独换发动机并不影响，可拆可合，根据不同的场景进行不同的沉淀，以达到更强的配置。

其它

到这步，其它人怎么使用其实在我这里关联并不大，而我需要的是解决我的问题，而中台架构并不代表说它是一个死的架构，这个可以根据过程不断的调整和优化的，这个概念和架构的提出，会更加明确搭建和建设的思路和方向，但是怎么实现，需要架构师根据团队来进行优化处理。

在这个过程中的感觉好比别人送给你一个屠龙刀，会使用的人可以扫四方，但是不会使用的，可能会惹火上身，伤到自己，甚至会发现，还不会以前菜刀方便，关键是怎么使用。

罗小东，软件架构师，多年平台架构和落地实战经验。

前言

开发平台搭建是前几年的技术文章，可以从这篇文章获取内容：

开发为什么要从零开始搭建属于自己的统一研发平台和中台架构

研发平台和中台架构是前几年的走向，基于一套平台和中台的搭建提升基础能力和业务的创新、创建能力，但是在目前数字化的战略下，仅仅这以上的平台是无法进行支撑，而且无法满足个人或者团队的发展。

此为数字中台的整体设计文档:http://alinesno-platform.linesno.com

整体文档是开源的。

什么叫数字中台

先了解什么叫数字中台，跟技术中台（还有AI/IOT等，这里不做阐述）和数据中台有什么区别。

数字中台架构主要是针对数字化转型而言，它是以数字技术为核心的中台架构，主要服务于企业数字化转型和业务创新，数字中台架构主要解决数字化转型中的技术问题，如数字化平台、数字化技术和数字化数据等。

技术中台解决技术架构、技术标准和技术管理等问题，数据中台架构主要解决数据质量、数据标准和数据共享等问题。而技术或者数据只是当中的一部分，无法形成串连，各个中台依然还是属于孤立状态，在运维管理上还是单独的一层，而数字中台是一个从技术到业务再到数据串起来的一套中台架构。

在前期，这些都是为了提高企业的业务效率和创新能力。

为什么要搭建数字中台

在行业数字化浪潮的发展下，数字化已经很多企业和各个行业的发展方向和目标，依赖单一的中台架构很难形成数字化的能力，无法串起形成一套数字化平台，过程衔接依赖还需要大量的人员和成本投入，技术和业务、业务和数据、数据和技术衔接还需要投入大量的成本，比如仅仅一个数据中台的投入，就达到几百甚至上千万。

而且这个过程存在较多的问题，比如常见的：

1. 技术人员成本：需要一支专业的技术团队进行规划、设计、开发和维护。企业需要招聘具备相关技术能力的专业人才，或者通过外包等方式获得相应的服务。
2. 技术设备和基础设施成本：需要一定的硬件设施和软件工具来支持数据集成、存储、分析和展示等功能，包括服务器、数据库、存储设备等。
3. 数据整合和清洗成本：需要对企业内部的各种数据进行整合和清洗，以确保数据质量和完整性。这需要一定的人力成本，在数据处理过程中可能需要进行手动清洗和处理。
4. 认证管理成本：需要具备一定的安全认证管理能力，身份认证方面的保障措施。这需要企业投入相应的人力、物力和财力来保证中台的安全性。
5. 运营和维护成本：需要定期更新、升级和维护，确保其长期运营和稳定性。这需要企业投入相应的人力和财力来进行日常的管理、维护和技术支持工作。

仅以上问题点，制定相应的预算计划困难就比较大，另一个是周期时间成本、还有是否可以落地成本都是问题，这些可能还没有开始，就已经是夭折的状态，即使往下，无形的成本，沟通的成本，内部矛盾的成本也是非常大，最后还有可能落空。

这个过程的解决需要的是一套数字中台架构，而不是单一的中台架构，而且可见到，可落地的数字平台。

数字中台架构需要和保障落地

数字中台是一种提供数字化服务的能力，是数字化转型的基础和核心，可以提供各种数字化工具、应用和服务，支持企业数字化转型和业务创新。

当前搭建主要包含以下几块：

1. 应用开发平台：应用开发平台提供应用开发工具、平台和服务，帮助企业快速开发和部署应用程序。应用开发平台可以支持多种开发语言和技术，如Java、Python等。
2. 数据平台：数据平台提供数据管理、数据治理和数据分析等服务，帮助企业管理和分析数据，支持数据驱动的业务决策。数据平台可以包括数据仓库、数据集成、数据挖掘、数据可视化等功能。
3. 云平台：云计算平台提供云计算服务、工具和资源，帮助企业快速部署和管理云计算环境，支持企业数字化转型和应用创新。云计算平台可以包括计算、存储、网络等云服务，比如K8S、政务云、虚拟机等。

当然，还有AI和IOT能力平台，因为这块搭建还在建设，这里不做阐述。

而在数字化落地过程中，常常或者一般情况下，需要达到以下的几个点：

1. 降低数字中台建设的成本和门槛，采用云计算等技术手段，或通过外包等方式来降低数字中台建设的成本。
2. 引入数字中台的知识和技术人才，专业团队可以帮助中小企业在数字中台建设方面更好地规划和实施。
3. 从业务流程出发，深入了解中小企业的需求和特点，定制化开发和调整数字中台，以满足中小企业的实际需求。
4. 推动组织变革和文化转型，加强对数字中台的宣传和培训，提高员工的使用意愿和保障数字中台的推广和应用。

企业落地数字中台需要克服多种难点和问题，并根据自身情况选择适合的方案。数字中台需要从业务需求出发，注重定制化服务，并结合内部文化和管理方式进行规划和实施。

怎么搭建数字中台和可落地性

搭建数字中台需要注意以下几个点：

1. 明确团队目标和需求：搭建数字中台前，必须明确团队的目标和需求，并根据实际情况进行规划和设计，避免盲目跟风和过度扩展。
2. 制定合理的架构方案：数字中台需要制定合理的架构方案，包括数据管理和分析、应用集成和开放接口、业务流程优化和集成、安全保障和风险控制、用户界面和应用和自动化等多个方面，同时要考虑到可扩展性和灵活性。
3. 选择适合的技术和工具：数字中台需要根据企业实际需求和预算，选择适合的技术和工具。例如，数据库、数据仓库、API网关、消息队列、身份认证、机器学习等工具和技术都需要根据实际情况进行选择和整合。
4. 实施适当的数据治理和运营：数字中台需要实施适当的数据治理和运营机制，包括数据采集、存储、处理、共享和传输等方面的问题，以保障数据的完整性、保密性和可靠性。
5. 注重团队建设和管理：数字中台的搭建需要注重团队建设和管理，包括人员招募、培养、管理和绩效考核等方面，以确保数字中台的开发和运营质量。
6. 完善的测试和上线流程：数字中台的搭建还需要完善的测试和上线流程，包括功能测试、性能测试、安全测试、部署和发布等方面，以确保数字中台的稳定性和可靠性。

搭建数字中台需要明确企业目标和需求，制定合理的架构方案，选择适合的技术和工具，实施适当的数据治理和隐私保护，注重团队建设和管理，并完善测试和上线流程。只有在这些方面都考虑到位，才能保证数字中台的建设和运营质量。

基于以上，整合起来的数字中台形成一个基础的平台化架构，为数字平台和业务中台做基础，包括后期的业务创新形成统一。

数字中台怎么保障后期的运营和维护

数字中台在搭建完成之后需要进行运营，整体运营和治理升级，以跟进行业发展和企业战略发展。

以下是数字中台运营需要关注的几个方面：

1. 监控和维护：数字中台需要进行监控和维护，包括系统性能、数据质量、安全情况等方面。对于异常情况需要及时处理，确保数字中台的稳定性和可靠性。
2. 数据更新和迭代：数字中台需要不断更新和迭代，根据企业需求和市场变化来优化数字中台的功能和性能。更新和迭代需要考虑到技术成本、人力投入以及用户反馈等因素。
3. 服务管理和支持：数字中台需要提供良好的服务管理和支持，包括培训、技术支持、故障处理等方面。要确保能够熟练地使用数字中台，并能够及时得到帮助和支持。
4. 数据治理和隐私保护：数字中台需要进行数据治理和隐私保护工作，包括数据采集、存储、传输、共享等方面。要确保数据的完整性、保密性和可靠性。
5. 团队的推广和宣传：数字中台需要进行市场推广和宣传，扩大数字中台的影响力和用户群体。可以通过各种渠道宣传数字中台的优点和特点，例如内部培训、外部媒体报道等。
6. 业务拓展和合作：数字中台可为企业带来新的商业机会和模式，需要进行业务拓展和合作。可以通过开发新的应用场景、寻找新的客户群体、与其他企业进行合作等方式实现业务拓展和合作。

数字中台在运营过程中需要关注监控和维护、数据更新和迭代、服务管理和支持、数据治理和隐私保护、市场推广和宣传以及业务拓展和合作等多个方面，以确保数字中台的稳定性、安全性和发展性。

总结

以上为个人在搭建数字中台过程中的过程考虑和一些总结，形成一套数字中台架构，为后期的进一步发展做准备和扩展。

如果你是程序员新手，更推荐和建议看一下，某个角度上来说，会让你走上老手的道路。

概述

对于一般来使用自动化的团队来说，Jenkins是少不了的这个工具，使用的姿势有很多种，之前也尝试使用过多种其它的自动化工具，比如github-action/gitlab-action/Travis CI,感觉能与之匹敌的应该就github-action，其它的都可以比较专门和针对化。

使用场景

自动化能力平时用得比较多，比如最常见的IT方式，比如开发，构建，测试，运维等，基本上感觉这东西几乎无所不能的感觉。包括自己一些生活的锁事，比如电脑自动清理，某个文档的定时发布，然后做一些文档材料的定时备份，还有定时同步更新网盘，平时自己学习任务的提醒等，这东西都能成为一套东西。

总的给我的感觉是，包括自己生活也自动化起来。这里阐述从几个角度进行说明，结合自己的平常使用：

• 生活和学习中为什么要选择一款自动化工具
• 使用Jenkins提升自动化的操作过程

通过过程一切自动化能力，你会发现，开发人员一个人可以做项目管理中的很多事情，比如测试、运维、管理、运维、提醒等各种各样的能力。

过程阐述

目前来说，我们需要考虑时间成本和学习成本，还有管理成本，对于开发人员来说，这些是很容易做到的。

生活和学习中为什么要选择一款自动化工具

为什么要选择一款自动化工具，对于来说，节约成本，不是对公司的成本，而是对自己的成本，让自己提升更高一阶层的思考。

什么叫高一阶层的思考，比如不会再对于一些重复性的工作来来回回倒腾，不会再对以前的一些工具来来回回的倒腾，不会再对以前自己的手稿或者代码来来回回的倒腾。那其它的时间做什么的呢，主要是做架构设计的思考，新的技术点的思考，优化点的思路，这些过程从传统软件模式来说，都是成本。那我们用自动化工具做哪些事情，自己常常使用的作用是这样的：

• 【编码】做一些练习项目工程的打包和发布，版本的发布管理；
• 【运维】做一些常见的运维管理，还有学习示例运行，包括调用一些第三方云平台接口；
• 【数据】做一些常见的数据抽取，汇总，统计结果管理，如每周时间段汇总；
• 【运维】做一些自己在跑的服务检查和巡检管理，然后出现异常之后，给我报警；
• 【测试】做一些测试用例和测试运行效果管理，类似于自动化测试之类的；
• 【运维】做一些邮件定时清理，应用数据定时备份的管理之类的；
• …..

编程工作中很多都需要很多，这些过程都可以变成自动化，然后自动执行，想到哪些就调用哪些，比如服务器密码修改，开始并不频繁，这个后来变成自动化，每月定时修改一次，然后自动重启服务，然后自动把新密钥发送邮箱里面，然后钉钉会告诉我这个完成了。

这些节省了我很多时间上的成本，而自己也不想在这个上面浪费太多的时间，整个过程下来你会发现，学习和生活过程中方便了很多。

当然，开始的时候可能会觉得这个怎么可能要去做那么多的东西，开始也这么思考，类似于学习Vim工具，这个开始也很难用，但是发现克服之后，你会发现工具使用效率非常高，类似于使用Markdown写文档，速度会比Word快很多，目前最多的是结合Vim+MarkDown一起使用，你会发现编写文字会是另一种享受，所以工具的使用，只是前期稍稍有一些困难，但是走下一个Demo示例之后，整个流程会顺利了很多。

对于新的开发人员来说，学习使用自动化工具，会让你方便很多，同时心理上会有一些莫名其妙的安慰感，比如你会发现很多开发人员还是手工的形式，心里面可以这么考虑，“都2023年了，怎么还是这么手工操作，效率低下。”，心里默念即可。不过对于新手来说，这的的确确增进了你很多的效率。

使用Jenkins提升自动化的操作过程

注意，以下的环境搭建是基于内网环境，注意不要暴露在公网上，我这里是在淘了一台主机回来单独放置的。

先看个简单的数据，几年沉淀下来自动化数据，目前是稍微统计的：

• Git自动化脚本仓库有4个，自动化脚本数最多的库中有近百个脚本；
• 积累使用的镜像容器有150个左右，包括基础镜像和学习镜像；
• 学习安装和调试使用过的软件，在库有90+个；
• 在过程中及当前在运行中的自动化任务有300+个；

以上自动化任务也只是管理我的学习环境，方便我自己生活中的一些自动化能力，远超我自己的想像范围。

在选择性上，老实说，自动化工具目前市面上免费的（肯定首选免费）比较强悍稳定的还比较少，我们过程需要比较高度的制定化高一些，同时会兼容很多第三方的工具和插件，这个自己相对来比较喜欢的是GithubAction，但是发现本地化和定制化能力比较强的，还是Jenkins，本地化方便放我们的隐私，而且没有约束。

那这些过程怎么做的呢，怎么实现我们自己生活和学习中的自动化呢？

准备一下脚本仓库，这里的脚本使用Git做的管理，这里选择性比较多，然后每个脚本都定时更新到Git上面，分配好目录即可，或者分配好每个Git基线的权限和职责，这个应该是比较容易做到，开始乱一些也没什么问题，后面再规范也可以。

过程方便的时候或者有灵感的时候都可以随时提交你的记录，方便后期的管理，这个基线库就会形成你后面的通用脚本库。我开始也觉得不会有多少，但是几年沉淀下来，有上百个脚本，这些都是前期学习和过程中坑点的积累，通过这些脚本库，就类似于我有一套较为完善的软件开发自动化的能力，应付一般的项目和管理完全是没啥大的问题。

比如自动化软件的安装，然后我把它放在网盘做个软件库（网盘是备份，下载使用的是七牛），沉淀几年下来的，有几十款软件，而且都是学习验证过的：

另外一个例子，在容器打包上面，平时生活中打的容器也有多个（这些只是过程中的验证，而且这些都积累成脚本），这些都是在使用过程中的坑点，一点点积累的优化完善，而且有完整的修复和优化记录，完全可以查询痕迹的，下面这些只是目录，目录下面还有多版本，包括服务器环境等。

如果你平时把自己积累的一些学习脚本还有练习脚本积累下来，两三年左右，基本上就成套了，这些规模远可能超过你原来的想像的。

所以这些自动化的脚本基本上都我都打成一套脚本放在Git管理，同时不断的优化完善，然后通过Jenkins的自动执行操作，而整个下来的Jenkins任务下来，到目前为止，也有300多个自动化任务，这些只是我一个人在过程中的自动化操作任务。

在集成脚本管理之后，各类型的定时化管理，比如一些可能需要调用的第三接口，如果比如集中的，这里采用Python脚本或者Java脚本进行编写，一些简单的脚本编写并不难，只是简单的调用，然后集成自动化发布和版本更新管理，这样在任务里面就可以调用这些脚本。

这类似的场景并不是特别多，也考虑过做成Jenkins插件，但是感觉没啥必要，维护这个插件成本也不低，另外兼容性等成问题。

有了脚本库还有定时化解决之后，任务的排版目前使用是Jenkinsfile，即Pipeline进行任务编排，这个方式效果会好很多，至少在打包上，几乎可以做到一种无所不能的感觉（当前，你也可以理解成它就是一个执行器），但是整合起来效果就非常强大。

不过就是工作流的执行上，当前比较差强人意，目前Jenkins的编排还是硬编码的形式，还不能有可视化拖拉，多个任务形成原子性，不过基本上也可以达到效果，就是简单的流程还行，多个复杂的流程就有点难，整体下来结合使用的效果还是不错的。

这些任务常年累月下来，形成的自动化能力基本上已经覆盖了平时编码和学习的场景，节省了我很多的时间和场景。同时自己也在不断的优化找更好的方案提升本身学习环境的效能，目前使用的方式都是有现成的脚本案例参考还有调优模式，然后不断的优化查找更好的方案，尝试使用过其它的自动化工具，但是还是缺少很多的能力和稳定性。

这些对于开发人员特别是新人来说，相对来说，会节约很多的时间成本和学习沉淀，不管是在后期工作中还是管理中，自动化的能力都是很普遍的，比如对于中小型公司来说，这基本上整体的效能会提升很多，对于个人来说，积累下来的东西是在某个程度上，也是经验的积累，在一些工作上是远远超过资历年限的积累的，修改一下就可以使用，会解决很多问题。

总结

自动化能力在IT领域是普遍的能力，工具的使用和场景的覆盖面，还有效能的提升相对来说对个人是一个非常大的帮助，也见过很多在使用自动化能力的，在很多场景下是可以优化的，同时提高效率的。

以上是自己使用Jenkins自动化操作的一些场景和经验积累，提供做下参考。

致敬那些可以保持初衷的软件开发者，推动国内软件发展的开源社区者，这也是自己的愿景和努力方向，在这个过程中追求和寻找软件技术的乐趣。

这里不提项目和软件的名称，只考虑总结心得。

背景

目前最多的技术依然还是从国外传入，国内的更多是的翻译还有培训传播，国内的基础软件并不是很发达，还有很多进步的空间，自己接触的软件这十年并不长，见到现状有改变，在追赶，过程是不断的突出和展现类似于阿里、百度、腾讯等这些对国内社区产生影响力的产品，同时很多优秀的开源项目，推动国内软件的进步，这些是值得尊重和致敬的。

自己原来的初衷也是把过程的一些研究成果贡献和体现，在这个行业中，以自己的一些经验，给一些团队或者个人提供参考经验，同时可以和国内知名的技术团队或者个人进一步的交流沟通，自我提升，这是开始的初衷。过程也困难很大，而对于自己来说，前期最大的是能让自己的设计理念活下去，不烂尾，不间断，可持续，这是一个过程的完整体现。同时，自己提供了完整的手稿和设计思路开源，希望可以给这块做设计的人员一些参考。

概述

对于软件产品来说，自己开始遇到的概念更多的是项目，或者开发技术，并不是理解一个产品的概念，同时对产品经理或者设计的角色理解比较片面，并不是真正一款产品本身的意义，也是在这个过程中，不断的加深理解，不断的学习。

针对于当前社区的产品，真正的来说，推动行业的进步和发展，解决过程的很多的痛点（这里指的是软件产品），比如Nexus解决了包的问题，Docker解决了容器化管理的问题，Hadoop解决了企业落地大数据的问题等等这些，Jenkins解决团队DevOps的问题等，推动软件行业的进步，同时这些都是国外的社区产品，国内也有类似于Skywalking、Kubeshpere等。自己本身是软件工程专业，对这块的痛点和进步，是更多的理解和体会。

后来发现，每一款产品的背后，都是一个团队很大的付出和努力，过程更多的也需要承受很多的未知挑战，怎么让产品能活下去，而不是变成烂尾，持续输出应该有的能力，类似于ElementUI在前段时间没有维护，很多人也是觉得可惜，以前Dubbo在国内是服务化的代表，各种方面都不比Cloud差，但是前几年突然停止维护，很让人可惜，如果能持续进社区发展，可能Cloud就很难切入，开始也觉得奇怪，但是自己在做的过程发现，要真的去维护一个产品，需要消耗很大的精力，特别是在前期没有任何收益的情况下，能支持下来真的很难，在跟挺多开源项目的作者聊，往往下班或者业余的时候都是排得满的，这里也是致敬国内社区的开发者。

这里阐述从开始社区的开源产品说起，这个过程是怎么建立项目，然后再到新版本闭源，再到商业化，再到目前可以持续输出我们可以输出的产品设计稿一些心得总结：

• 基于一些方法论的自我探索和产品型规划
• 开源到商业化的转变，团队运营和促进可持续性
• 团队后期一些坚持的理念和一些初衷还有输出

从以上几个点进行一产品建设总结，我有我思，以供参考。

过程

过程并不是特别顺利，会遇到很多的问题，也会遇到很多困难，还有很多失误，但是从18年到现在，欣慰的大家还是可以现在，并且还在发力发展期。

基于一些方法论的自我探索和产品型规划

建设产品型软件的思路来自于服务化的一些困难，同时方案查找，发现缺少的挺多，而基于很多企业还有项目的限制，同时也包括自身的限制，进行了产品的定位，把自己的一些经验通过文档和编码和形式进行沉淀和输出，期望可以和同行进行更多的交流，同时也想促进自己的进步。

进行了整体的从产品的方向，架构，技术，编码，前后端，运维，测试，自动化等等进行了一系统的规划，基本上第1年的时候，

这个时间通过结识是一些对软件有兴趣的人，包括一些社区的人员，整体聚合起来的人，都以兴趣为主，本身就是编码出身，开始并不喜欢接触一些商业化的内容，通过前期的容器化还有服务化，同时各类Ops的研究，结合自己本身的经验进行的产品化架构。开始产品化的思维并不是从一开始就存在，而是以前的项目经验和编码中，对自己的一些经验总结和案例总结，包括大学时期的一些经验总结，重复性的编码确实消耗了很多时间，组件化和产品化的能力，会节省很多的时间，不需要重复的建设，这些基本上都是传统项目的痛点。

在本身工作后不断的提升，不想把时间消耗在基础能力的建设上（类似于发布很麻烦），当时在找了很多方案之后，在社区上找不到合适的，另外就是方法论较多，缺少实践的过程和能力，类似于中台、微服务、数据治理等，很多偏向于表面层，网上的资料偏向于demo整合或者一半一半的，没有完整的体系（现在应该比较成熟了）。

基于以上，只能基于各类开源项目还有自身的经验，进行的产品化的建设。

开源到商业化的转变，团队运营和促进可持续性

在前期建设的一年多，手稿和形态基本上已经形成一稿，同时也会发现很多的问题。

一个最明显的问题，可持续性，后来发现，很多开源项目同样面对此类似的问题，可持续性来说，对于一些来说，可能是一阵热风，这个时候兴起某个技术，就会去做这个，然后过了之后，这个就没有了，或者放弃维护，自己同样也面临这个问题。

当然，自己本身来说，并不是特别期望的商业化运作，直白一点的，这个只是业余的经验总结输出和研究，开始并没有需要一定是需要商业化，更多的是经验的分享和社区的交流目的，自己本身的生存收益并不是来源于这块，同时也并没有说这块特别困难。

后来发现，其实坚持做一件事情的，而且能持续的投入的人员是很难的，很多可能面临生活，工作等问题，久了很快最后提交代码的，就只有我这边，社区的会议也减少到几乎没有。在不断的寻找他人一起互相分享学习的时候，基本上都是被冷脸或者闭门的，本身会不断的发展和提升产品的成熟度，过程中接触的人群也普遍不同，但是这个找兴趣团队的过程，确实很难，培养他人起来也很难，一个人孤军会存在莫大的孤独感，大半夜往往也只有你一个，后期也有很多人兴趣的朋友加群加微信讨论，大家没有前期的基础，也很难跟上，基于项目的不断完善，进步过程还需要接触很多架构和思维。

这个状态持续了近大半年，发现这样对原来的产品化和发展形成极大的影响，是在维护，但是这并不是一个健康的发展状态和维护状态。

这个过程意外的是，免费分享的很多并不太喜欢，但是需要商业化支持的却有挺多的，常常会收到一些社区或者厂家的联系，进一步的商业化支持的倒是挺多的（即投资），开始是拒绝的。因为我并不想拉扯上太多的关系，简简单单的互相分享，业余时间的沟通感觉会更好，后来发现，这个太难了。基于上面的情况，自己也不得不反思如何后期如何做这个项目。

在看到其它的开源类项目，为什么可以做到，也想学习，不断参考，后面明白，你并不是那个项目的负责人，你也不是他，每个的条件和环境是不一样的，不能说别人做了淘宝，你也复制他的模式也会成为淘宝，你很难跟得上，需要考虑另一个模式，比如拼多多模式。考虑到项目的持续性和可用性，在跟多家团队负责人商谈后，不断磨合，考虑良久，进行了商业化改变，通过投入人员和项目，进一步的促进项目的可持续性和成熟。

再进一步的产品化能力和团队运营管理。

团队后期一些坚持的理念和一些初衷还有输出

在后期建设的过程，自己要承担的角色和责任可能会有一些变动，但是推动产品化的进程是加速了很多，从0.0.1版本不断的提升到2.1.3版本，不断的跟进当前行业的发展和技术整合，也是做了很多的调整和升级，当然，也做了很多的减法。

与运营团队的配合操作，有一些是远超过我的想像之外的，也消耗了大量的精力，后面有一段时间全身心的投入到里面，开始有考虑过这个过程，也有一定的预期心理准备，同时也需要做很多方面的管理，当然，本身也提升了很多，产品化和项目化也基本上符合预期实现，在这个过程中遇到的问题点，团队的成长还有产品的成熟都基本上能达到预期效果，而且后面维护可以做到保障，这个是自己特别关注的。

在接触的过程中，这几年，也遇到很多中小团队在做类似的内部项目，可能更偏向于内部，这些也是原来的自己想做的经验分享，在当前的网络环境上，也已经有很商业的化的产品，同时也提供了很多方案，但是全套型的依然很少，即从0到1的过程还有最终的效果。

当前在各个方面较为稳定的情况下之后，针对于自己的初衷，考虑左右，梳理了很多过程中的手稿内容，同时梳理了很多过程中手稿，包括产品化设计、架构、思路等，进行输出，希望可以给一些建设过程中的团队一些参考意见，规避过程中的一些坑点，有个方向参考，即从政策、产品、团队、管理、方案、架构、自动化等形成的一套参考方案，当然，每个团队不一样，但是有方向就会规避掉很多的迷茫点，至少会快很多，毕竟这些积累了很多年的架构经验和项目实践经验。

这些是我所带团队能对自己原来初衷的保持和最大化方式，毕竟在涉及到多方之后，你需要考虑很多很多。

收尾

在建设过程中，会遇到很多问题，同时看到国内技术社区的推动，国内社区产生影响力的产品，同时很多优秀的开源项目越来越多，提交到apache的项目也越来越多，推动国内软件的进步，这些是值得尊重和致敬的。

也许在这个过程中，本身并没有达到他们的层面，但是在本身的经验里面，可以做出一定的分享，这是个人能做的。

以上为从零建设软件产品的一些心得总结，以供自我复盘和勉励。