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

前言

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

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

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

此为数字中台的整体设计文档: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的项目也越来越多，推动国内软件的进步，这些是值得尊重和致敬的。

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

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

这里针对的是一般的开发类人员，从业以来看到的场景，并非针对所有，之前在一线和二线都遇到过多的类似的情况，这里表述，供一些参考。

背景

网络的一些公知感觉上有些过于浮躁，一些价值观的引导过于片面，从而引发一些误导，这里从另一个观点阐述。一般觉得工作前二三年是一个坎，这基本上很容易决定后面3-10年的工作状态和生活状态。前两三年决定的基础的能力还有思维，格局，方向还有后面的晋升等，前面开发的工作过于局限，容易导致后面的迷茫，焦虑，还有危机，如果做好自己的规划，会有比较大的转变机会。

这里所说的996并不是天天上班如此，而是在某一个时间段的高强度工作，企业对员工的一些工作要求，这种情况是很难避免的。

概述

这里并不是推崇这类似的工作状态，而是针对于自己的情况，需要进行的一些过程历练和自我驱动成长，达到自己的目标和生活状态，工作状态还有人生状态。

这里理解工作需要一定的个人喜爱，符合自己的意向，生活需要达到自足，在合适的年纪，可以有合适的生活，得到行业的尊重，工作获取到匹配的岗位和角色，但是这些获取的方式是怎么样的，一路跳槽还是有比较大的机会才能有获取，这里针对的是普普通通，按正常的，稳妥的方式考虑获取，以下从几个维度思考：

• 在职场中沉淀自己，前期做好基础能力的打磨
• 学会处事，沟通，工作，获取自己需要的经验
• 学会利用自己的优势进行晋升和高一层级脱变

这里从另一个方向进行阐述，主要考虑的是开发人员自身的发展和方向，避免在工作或者生活中产生无谓的内耗，我有我思。

过程

这里主要针对的是国内的大部分情况，IT行业当前在国际上还偏向于中低端，在这样的行情和国内规则下，要无法改变的前提，考虑运用规则转成符合自身的利益。

在职场中沉淀自己，前期做好基础能力的打磨

这里可能提到就是当前互联网中提到996场景，主要针对这个场景进行解析展开讨论。

并不是每个人都是如此，但是它确实是代表了一种现象，但是并不能代表所有，避免以偏概全，听到比较多的场景而且带有情绪特别严重的，遇到类似反馈比较多的偏向于新人或者工作生活不如意而引起的侧面情况表现，另外一种是一些公知引起的价值观偏差，比如团队内部对抗过于严重。

如果真的确实无法接受，可以换团队或者离职，现在工作机会是比较多的，并不是类似于无就业机会的情况，如果真找不到，建议先考虑一下自己的原因，又不想努力，又想要高工资，还想着责任轻松，离家15分钟等，这些先考虑下自己的情况。他人一般要么接触高一层的思维，比如博士、一流大学，要么就是在努力你没看到，这类型的人很少会有天天抱怨的，他们会朝着方向努力。

上面说得有点模糊，这里一个例子，也是常见提到的，阿里的996，层级差距也是很大的，相对来说，如果说以阿里的技术实践还有薪资待遇，还有给个人带来的社会影响力，这个过程来说，对新人的成长和提升是有一定的帮助的，应付一般的中小公司高管岗应该是没什么的，自己并不建议刚毕业两三年的人就开始养老状态，而且要了解，阿里的IT待遇远超同行的。其它类似的公司，类似于上面说的，看其它，比如晋升的机会。

这个过程是有一定的必要的，如果说，这个人刚毕业就9点上班5点下班，然后工作容易，这个也有，比如说国企、事业单位等，这些的信息部，相对会轻松很多，可以去，但是看到的，只要待个两三年，一般在IT这个行业已经很落后的了，感觉人也基本上差不多废掉了。也不反对，那你就自己努力去考公，既然又不想考，又想待轻松，遇到事情又抱怨，这类似的内耗，比较难接受。

这个过程我们需要沉淀自己，利用这个过程做为工作或者生活中的一些过度，同时获取到自己能力的提升。

学会处事，沟通，工作，获取自己需要的经验

除了上面提到能力技术以外，那部分属于硬技能，但是软技能更是磨人的，这部分人情事故，做事方法，在国内这些基本上少不了的，或者说很难避免掉，几乎在任务场合都会遇到，只是说重视的程序高深与否，小城市更注重人情，大城市可能味道没那么浓，这些基本上决定了在有技术的情况之下可以走得多远或者多高。

要了解一点，这个996有很多情况下，它是有一些附加值的，但这并不代表所有，但是在自己遇到的公司里面，都多少带有附加值，所谓的附加值有很多种，比如经验、资金、待遇、机会还有各种地位等，特别是项目初创期状态。在遇到的很多经理级和高层都是通过这层起来的，对遇到的很多中高层来说，你所说的996对他们而言，只是普普通通的工作状态，但是并没有遇到过常年996的，只是有一段时间在项目或者比较紧张的时候出现，常年类似情况的，建议换团队，太伤身了，另外一个主要的方面是过程缺少思考，对自身的提升益处并不是特别大。即使是有背景的，他同样也需要这个过程的，朝9晚5又想遇到机会，遇到的除了熬资历和真的超强以外，身边遇到的还是比较少。

为人处事的沟通和工作的沟，也只是在一到两年中遇到和学会入门，为后期的运用进行加深，在自己的理解，这些坑点遇到的越早越好。

在工作的前两年遇到类似的事情并非坏事，工作中的人情事故其实有很多门道，在前面的学习阶段，公司一般会带有容忍度和指导程度的，比如应届生在某些情况下是允许有错的，但是如果工作5年左右的，出现低级错误有的时候是很难承受的，更何况，对刚开始的前两年来说，有组长兜着，可以在思维上“放肆”一些。

这个过程往往会遇到很多人他们的为人处理思维和思路，平时多关注一些优秀人员的处理方式，类似于遇到的，很多时候，一顿饭真的可以解决很多事情或者打通一些思路，这类似的东北的一串烤串，一杯酒之类的，优秀的管理者很会利用道具来打破一些开局，这里可以注意下他们的举动，选择符合自己的方式。

学会利用自己的优势进行晋升和高一层级脱变

在前面的硬软技能之后，一两年内基本上就入门了，其它的就是加深和脱变。

经过一两年的历练，相对于一般的开发来说，是初步具备有一些技术能力和事情的处理能力的，虽然部分自己的羽翼未丰，但是也可上路。这个时候，可以根据自己的业绩或者争取到一些带有业绩的事情工作。

创造业务需要的不是一个人，而是团队一起去实现，在自己的岗位上发挥自己的能力和价值，这也是跟上面的为什么处事上需要做到一个具备条件，要得到这个主要的岗位角色并不是说自己的关系就可以，还需要一种职业素质的体现，前面努力的过程（比如某个时间段的996状态）和良好的状态过程这些都是自己最有力的证据，这些很快就会得到同行和他人的认可，即使不认可，但是面对这经历面前，一般人也会有一定的认可。

在经验和素质条件具备，这些硬实力的体现下，还有过程的沟通处事能力的自我要求下，这些是对下属还有同事具备有影响力，也是有说服力的，特别是在软件行业，在这个条件下，是很容易争取到他人的认可和信任的，包括上级或者组长，包括一些看好这个的人，即使说这家的不认可，另一家也会有认可的人（当然，这是一个机遇事件，不能说百分百，但是概率会有提升很多），常常在一个组里面，都会有一个主程或者大家认可的高级人员。

在具备这样的条件下，是具备有做事的条件和一些有能力的人共事的条件的。争取到一些团队和项目经验，提一步的提升自己，为自己的下一步的晋升做准备，这个过程往往一到两年的时间，一年是做成果，另一年是晋升适应，这样三到四年之前基本上是可以往上一个层级提升，根据自己遇到的多个团队或者企业情况，类似于这样的机遇是比较多的，比如经理级、架构级、组长级等这些是有比较大的可能性，也是符合工作年限。

在这些层级的团队和人员一起做事，做出的业务往往是容易出成果，容易成功，最后大家分享成果，不是你想这些业务成功，是这帮人一起做时候，他们有比较强大的经验，他们也考虑不能失败的，他们会过程协助你，同时指出你的问题，还有提升更好的方法和方案，会迫使你也会产出结果。

反之，如果三到四年还处于初中级开发，而缺少团队管理经验和主要的个人业绩，在某个程度上，再往上一步，可能会比较困难，一个是机遇，另一个是新人的切入，另外一个是这些过程需要的时间，太短业绩是不牢靠，而且自己的根基不稳定，很容易在后面的过程中迭倒，另一个是需要承受很大的压力。如果5-10年还属于这个状态的，一般来说基本上会遇到很多问题，比如生活焦虑、职业焦虑、待遇水平、工作压力等等。

在进入到一步点的时候，需要产出的成果点和个人业绩点，给自己晋升和提高的机会。

最后

自己并不鼓励一直高压力和高强度的工作，但是团队或者企业需要的时候，会出现类似的情况，而在这个过程中，也同步给了自己机会，给了自己的一些条件，运用这些机会和条件，给自己做好规划，转变成自己消化，是比较鼓励的。

工作前两到三年是有这个机会的，而且这个时间段做这个事情是比较合适的，就像读书是在青年时期一样，而不是跟随互联网上的，出现一些过于偏激的想法，引导，从而产生一些不好的社会现象。

以上为个人在行业见到的情况和一些见解，供参考。

这里针对的是大中小型项目的业务系统运维架构的设计，非互联网型项目，一些个人经验和思路，抛砖引玉，供参考。

背景

对一般性的运维来说，自己应该是接触几年，一二三线多个城市，政务互联网行业等都有，服务器基数在几台以几百台不等，业务微服务规模在100到几千不等，本身并不是专业做运维的（比如数据库DBA、网络DBA等，这些有专业人处理），偏向于业务服务模块的运维设计管理，以下为一些设计经验。

概述

对于长期运行的业务，有好的运维工具，更有利于业务的稳定。一般来说，业务性的运维管理从几个维度，主要是IaaS层，中间件层，业务层，运行状态层几个进行的监控管理，结合人工，手工，自动化能力角度进行设计，去掉重复的手工和低阶的运维，使业务运维偏向于高阶的思考，提升整个运维的管理能力，整体思路从以下几点，我有我思：

• 基础环境搭建
• 运维采集监控
• 运维平台维护

以上几个点为基础的能力，中间还有很多，这里偏向于设计，具体细节由专业工程师去实施即可。

架构设计

这里是整体运维管理的架构设计，从多个角度和自动化能力的管理，架构如下：

针对大的方向上面，不同的团队和业务场景会有不同的业务方案。

基本上当前主要用到工具为以下工具，其它主流性的，用起来并不觉得多顺手，比如蓝鲸，自己偏向于脚本型管理，相对比较方便，主要使用技术工具如下：

• Jenkins: 自动化能力引擎和调度工具，建议装好插件，比如Dingtalk；
• Ansible：自动化能力引擎和批量操作工具，服务器默认安装的
• Python: 一些复杂的任务脚本，可编程方便，个人感觉是对shell的一种补充
• Excel: 这里主要是对服务员和资产的管理（用过较多可视化工具，效果一般）
• Gitea: 脚本管理和运维审计，这个比较小型方便
• SpringBoot: 自定义的一些个性化功能，比如数据统计；
• Plumelog: 日志采集和统计分析（用好的话，是很强大的，也可以使用ELK）
• FileBeat: 日志采集工具，主要偏向于本地日志和物理日志，比如nginx
• Kafka: 日志数据的缓冲工具，比较强大，但是也比较消耗内存
• Prometheus: 各个监控规则和细化工具，阀值管理，这个维护rule比较长期
• Grafana: 实时统计工具（实际上Kibana也可以把它替换）
• Dingtalk: 移动端跟进和IM通知工具（内网使用grafana即可）
• Pinpoint: 链路跟踪工具（这里不做介绍，也可以使用sky，也可以不使用，其实cat更好）
• MySQL: 报表和周日报统计记录工具，也包括业务统计
• Zbox(禅道）: 工单跟踪工具（Jira也可以，比如小的团队可使用gitea的工单）
• JumpServer: 堡垒机（这里不做介绍，主要看业务场景，效果其实跟运程登陆是一样的)
• Kubernates: 容器管理工具，看团队，小项目docker-compose更建议
• Kuboard：k8s的管理工具，这个比较轻量级(kubephere太重了些)

基础环境搭建

这里根据本身的业务场景需求进行取舍，并不是一下就要上全套，毕竟资源等各个方面会有一定的限制，这里基础环境是整体的基础，包括以下几个点：

• 自动化操作引擎的搭建
• 运维日志的可视化
• 工单管理工具的安装
• 规则引擎的安装

上面的工具注意配置下unit自动启动，当然也可以使用容器，但是过程发现，有的时候容器并不是特别可靠。

自动化操作引擎搭建

自动化操作是所有的运维管理的基础能力，也是一个统一的管理思路。这里的需要安装好jenkins和gitea，这个是基础。

自动化操作主要是结合pipeline+Ansible进行管理，通过ansible的host进行的各个服务主机的操作，这里建议的变量是存放在host当中，针对不同的业务场景替换host即可，在下次另一个环境的时候，直接导入jenkins备份文件即可。

ansible的hosts可配置比较多的变量，这些方便多业务场景的改变和运维环境的迁移。

运维日志的可视化

所有的运维工具还有业务运行都需要把日志文件进行可视化统一管理显示，前期需要先搭建好日志平台，这里主要是偏向于ELK+Kafka，小项目PlumeLog替换掉kafka更合适，因为他也可以不使用kafka，比如redis等轻量型队列，不过还是比较推荐kafka，稳定性还有日志收集一流，装个单节点就可以。

也可以针对PlumeLog进行二次改造，之前就是进行了改造，毕竟Kibana的学习成本还有es的学习成本并不是每个运维人员会做的。

工单管理工具的安装

这里的管理工具指的是Zbox，即将各个工单进行安装配置和跟进，这里建议是结合Dingtalk一起，新版本Zbox对这块的支持挺好的，可实时跟进，便于项目经理和运维经理实时跟进工单的处理状态，这里比较推荐的，省去很多无谓的沟通成本。

当然，有些是不需要这个模块，比如一些比较小的项目，但是中大项目或者需要长期跟进的话，建议这块，也可以采购，之前采购过几款，费用不少，但是效果貌似还没有Zbox好。

规则引擎安装

这里规则引擎主要是prometheus（貌似目前还没有发现比这个更好的），比较轻量级，安装起来也比较快，也可以安装grafana，这里我自己不太喜欢grafana可视化，有空细调整的话也可以把grafana做得挺好的，但是自己一般是在它的官网上找到模板，没什么空去看这个“好看”的大屏，平台工具多就意味着入口很多，这也很麻烦，所以针对于自己来说，会更关注Dingtalk的信息，因为可以把这些状态统一发到上面，如果是内网不能使用Dingtalk的，Grafana是一个不错的选择，或者说Prometheus的Alerts也可以，预警信息也是一目了然的。

运维采集监控

监控采集功能即是上面工具的使用管理，主要的设计思路如下：

• 运行环境状态的采集
• 业务运行状态的监控采集
  • 运行状态巡检的管理

环境状态可视化

环境指的是服务器、中间件、容器，这里集成的主要是prometheus的功能和node-exporter等，这些使用起来较为方便，基本上会把服务器的基础状态进行采集管理，普通的状态基本上会满足，包括中间件层和容器层也一样，基于exporter进行采集， 输入到Prometheus当中即可，这里rule规则主要引用git进行版本管理，同时使用prometheus的热加载管理，结合jenkins+ansible脚本进行在线跟进更新发布。

rule脚本的管理根据运维的需求进行调整更新即可，可定时在线更新。这里的rules注意下规则的管理，一不小心有可能会造成N多的信息爆炸，那也是很恐怖的事情。

这里注意一点是，kuernates内部一般也会安装1个prometheus会更好的管理，注意不要跟物理机上的prometheus冲突就可以，当然，你也可以只用1个，但是k8s里的规则更新貌似不太好处理，会比较麻烦，之前的处理思路是jenkinsfile重新发布一下proemtheus，然后日志数据持久化。

业务运行状态的监控采集

这里主要分为两部分，一部分是前端，另一部分是后端，还有一部分是关注的业务指标。

这里前端的采集主要是nginx的采集，处理好日志的json脚本，然后通过filebeat进行采集发送到kafka中，这里的数据量大的话，推荐kafka集群，同步通过elk进行展示，这里展示的效果因人而异，实际的效果可以很酷，但是我一般比较喜欢列表展示日志。

然后就是后端数据的处理，也可以使用filebeat进行容器采集，但是k8s也会带有日志系统进行发送也可以，之前没怎么用过，对于后端的数据，使用的是springboot的配置，进行动态的环境变量处理，即配置logback-spring.xml配置，添加多环境即可，这里有一些会考虑sky，可以结合链路跟踪还有前后端请求状态，这里也比较偏向于业务项目。

有的时候，工具太重了会比较影响，所以在业务日志采集这里，会采集关注的业务服务日志，并不是所有的都会采集。另一种方式是使用容器的nfs映射能力，映射到本地存储，进行二次转移，这些主要是看项目情况，大项目的采集会比较多，同时造成很多日志压力，配置也比较高。

最后有一部分是业务指标的问题，业务指标的产生并不像日志那样，会触发错误。这里推荐根据业务情况然后进行一定的逻辑判断，这里用得比较多的方式是定时的业务计算进行业务指标输出，放到中间库里面（比如mysql），触发自动化定时巡检获取到，业务指标的监控偏向于业务运行时的跟进。

运行状态巡检管理

运行状态巡检是一个每日进行的工具，比如异常容器有哪些，异常的nodes有些，异常的链接还有端口是否开通等，一些重复性的工作而且监控工具无法触达到部分，可以通过pipeline+ansible结合进行自定义处理，比较个性化，也是有必要的。

ansible运行的结果是可以输出json的，这个方式更好的汇总的集成平台上面（集成平台这个是基于springboot开发的一个集成系统，比如简单），用于收集一些运行时状态，包括异常的统计，巡检的情况反馈等，便于下面进行周日报的输出。

运维管理平台维护

维护主要包括脚本的管理和更新维护，巡检之后进行的数据汇总和汇报，还有过程工单的跟进管理。

脚本的管理和维护

这有点个人喜好，为什么不喜欢使用一些管理平台（比如蓝鲸、ansible tower）即是如此，没有统一的运维脚本管理，包括版本的管理，操作人员的审计，权限的配置管理等，对于上面的运行来说，过程有一套脚本可个性化的配置，是有这个必要的。

这里的维护主要是结合git版本管理进行，通过pipeline来进行脚本进行任务的编排管理，基于jenkins的调度和模块化处理，基本上是满足平时的90%的管理了，平时10%的可能遇到的机率比较少，另外可移交到人工管理上。

周日报的汇总管理

汇报机制和统计机制是运维改进的一个保障，通过统计发现问题频率高的地方和影响业务地方。在收集到json数据之后，进行数据的统计分析管理，然后通过springboot自定义开发，获取到统计结果，自定义周期发送出统计结果，可按天、周、季、年等方式。

这里的开发难度并不是特别大，实际也可以通过pipeline+groovy脚本进行统计处理，但是这个必要性并不是特别大，而且安全性不是很高，成本略高，建议写个集成平台程序就可。

过程工单的管理跟进

管理制度和过程主要还是看团队的习惯还有实际情况，这里提的一个能力是工单的跟进集成，主要是zbox+dingtalk处理，然后进行汇总。

但是这里注意的是建议不要使用外部邮箱，因为发送记录会存在外部邮箱一份，而且是运维内容，这比较不安全，当然也可以申请内部邮箱，这样会更安心一些。

总结

以上为业务系统进行的运维管理架构设计，偏向于应用层，主要目标是达到可跟进，可管理，自动化等能力。以上为一些经验参考设计。