月度归档：2023年10月

我从中台化到产品化的一些总结手稿

罗小东，多年平台架构和落地经验，在中台产品化建设方面有一些经验。

背景

在2018年，中台概念风行，那时尝试进行了一些spring cloud和k8s的研究，带领一些成员进行培养，同步启动了alinesno-cloud的开源项目，后来该项目形成了具备产品状态的商业运营，这个过程属于中小团队(即几人或者百来人之间的技术团队)落地的范畴。

注:这并不是书籍，也不会出版，只是以书的形态进行维护。

目前，由于其它因素，个人已不再参与商业运营，转而组建社区团队，运营开源项目，这里将对前期建设过程进行手稿总结和归纳。

手稿内容

手稿的相关资料和地址，配套的开源项目地址，主要形成的是一套落地手册和理念，从设计、研究、产品、运营形成的一套材料手册。这里做的主要是技术中台、数据中台、运维自动化、以及运营管理的一套中台产品套件，

期望可以为一些企业团队打造中台产品提供参考。从2018年设计alinesno-cloud开源项目的第一版本建设开始进行记录编写，整个产品输出过程大概是建设初版本到产品化运营，主要包括以下内容：

  1. 中小微企业数字化转型的现状和挑战；
  2. 数字中台的概念、意义和构建方法；
  3. 中台产品设计与开发的流程和方法；
  4. 中台产品运营与管理的策略和技巧；
  5. 团队中台化转型案例和落地经验分享。

结合在中台化转型领域的实战经验，从实战落地出发地介绍了中台产品建设过程、意义和建设方法，并分享了实用的案例和经验。读者可以通过了解如何打造中台产品，提高企业效率和竞争力，同时也可以学习到数字化转型的相关知识和技能。

手稿说明

中台化是很多企业在解决针对于传统系统中一些问题的方案，在这个过程中接触过很多团队在做，实际上落地下来的团队较少，遇到的很多还在PPT层面的比较多，方法论的比较多，但是只要深入解析还有进一步落地，后期升级还有运营等状态比较少。遇到的更多是中间就放弃或者没有形成后期的运营升级等状态。

有很多听说过建中台，然后又听说拆中台等名词，在这个过程中，也拆过原来搭建的中台，但是拆是为了更好的建设和落地，以达到匹配团队实际情况的目标而不是不用。

过程的落地需要很多的因素，反而技术的因素是最好把控的，其它的因素比如团队技术能力情况、组织情况、人员情况、项目情况等等多种因素的存在。还有长期的运营升级等，才能形成的产品化的状态，还有项目过程中不断磨合等。手稿主要从以下几个章节:

  1. 行业发展思考与发展
  2. 产品思考与规划
  3. 团队建设与管理
  4. 产品架构与研发
  5. 项目实战与运营
  6. 产品优化和输出
  7. 中台产品化心得

这个过程比较长期的投入还有不断的实践摸索，形成团队自己的设计理念，落地理念等，避免一半一半的信息，最终很难落地。这里整理了过程中的手稿，对外展示在这个过程中项目还有问题等，还有产品形态等。从上面进行的阐述，每个团队和场景不一样，组织结构也不一样，这个过程只是说这边的落地和产品化过程，期望给一些参考，有自己的设计。

总结

中台化是解决针对于传统系统中一些问题的方案，在这个过程中接触过很多团队在做，遇到的很多还在PPT层面的比较多，要深入解析还有进一步落地，每个团队和场景不一样，组织结构也不一样，这个过程只是说这边的落地和产品化过程，期望给一些参考。同时也非常感谢一些开源项目，在鸣谢章节进行了说明。

下面是相关的链接：

  • 手稿地址：http://alinesno-book.linesno.com/book/

我在超化研究上的日志采集架构设计

软件工程师罗小东，多年平台架构和落地经验，在与社区团队研究超自动化方面的设计和产品方向。

背景

以下是针对超化管理超化的设计，因此会偏向技术方向的阐述。

目前对于超化的关注点似乎更多集中在方法论方面，而较少关注具体实现，目前仍处于探索阶段。我们的编码工作目前在 Github 上进行，以便与对这个领域感兴趣的同学进行更好的交流。

在进行超自动化研究的过程中，我们遇到了数据采集的问题。在上层自动化过程中，需要大量的数据支持，因此需要采集大量内容。由于缺乏业务场景，我们在这方面的研究考虑是先使用超自动化来管理超自动化（即自己管理自己）。这里主要针对日志采集设计。

概述

我们原来的整体设计方向是朝着数据支持方面发展的。根据一定的规则和判断条件，结合 AGI（人工通用智能）的推理判断，形成智能化的操作。在日志的采集和管理方面，我们需要采集完整的数据链，进行判断、管理和预测。在确定采集哪些数据时，我们参考了许多开源项目，但也发现了一些问题。各个开源项目过于分散，无法形成组合，数据分离也比较麻烦。另外，技术迭代速度较快，有些项目没有很好地跟进。综合考虑后，我们需要进行部分重写和整合。这里主要采集的内容包括：

  • 前端日志：包括 UI 事件、访问日志、操作日志、热点日志和 IO 日志等。
  • 自动化日志：镜像日志、构建日志、过程日志和操作日志。
  • 安全日志：代码、质量、版本、漏洞安全、容器漏洞、密钥日志和 Git 提交日志等。
  • 应用日志：运行日志、运行状态、请求日志、运行情况和链路情况等。
  • 系统日志：操作日志、历史日志、IO 日志、网络日志、请求情况和运行情况等。
  • 操作日志：操作记录、SQL 操作和审计操作等。
  • 登录日志：登录的所有信息和请求，例如 IP、地点、位置和账号等。
  • 项目日志：任务操作日志、变更日志、审计日志、人员变动和状态变更等。
  • 链路追踪：请求链路、操作链路、日志链路、SQL 链路和阶段链路等。
  • …

这只是初步设计，后期还会继续添加。目前按照上述设计进行集成，采集回来的数据使用流水线方式进行判断和处理。在这个过程中，我们主要使用了 GPT 的推理结果作为推理能力的基础。当前的原则是尽量使用流水线和自动化，在特定阶段使用 GPT 的能力作为辅助，以提高过程的稳定性。实现的超化能力演化效果类似于以下示例：

  • 在云服务器准备到期时，自动采购或续费。
  • 当功能准备延期时，自动通知并向指定人员提供合理建议的方案。
  • 每月或每周自动生成报告结果，并给出合理的建议。
  • 自动检测和构建验证过程中的漏洞，并生成分支。
  • …

在这些过程中，我们使用规则和推理能力进行简单的判断，协调这些自动化流水线，类似于自动驾驶，但也有辅助驾驶，推理能力就是这个协调的大脑。为了实现更便捷的操作，我们还添加了语音交互，以便更好地进行操作，并将结果通过 SSE 推送到系统界面或进行语音播报。

下面是当前设计的整合思路，这仅涉及日志采集方面的设计，其他自动化内容不包含在其中，我有自己的思路。

过程设计

相对而言，采集的设计是相对简单的。目前有许多开源工具可用，但搭建起来可能需要较长时间。然而，由于 AIGC（人工智能生成代码）的能力，我们可以使用生成式代码和单元测试，效果还是不错的。

采集工具

我们的采集工具主要使用了一些开源工具，并结合了 Maven、Shell 和自研的流水线进行改进。在选择工具时，我们考虑了定制化的需求，并综合考虑后决定自行开发。下面是我们主要使用的采集技术：

  • 前端采集：log.js、filebeat 和 nginx。
  • 自动化采集：Python + shell，并将数据发送到 Webhook。
  • 安全日志采集：Trivy、Checkstyle、Murphysec、SpotBugs、Gitleaks 等工具。
  • 应用日志采集：自定义的 logback、OpenTelemetry、AOP、Nginx 等。
  • 系统日志采集：Ansible、Shell、Python，定时采集结果并结合 node-exporter 返回。
  • 操作日志采集：AOP 和自定义的 logback，自定义的 MDC 参数。
  • 登录日志采集：Nginx、AOP 等。
  • 项目日志采集：通过调用 API 进行定时采集，并有一些会接收推送结果（例如禅道）。
  • 链路追踪采集：OpenTelemetry 和 agent 的方式。

对于数据量较大的情况，我们使用 Kafka 作为数据缓冲。为了方便交互和安全性，我们在 Kafka 前面加了一层控制器层，提供了 HTTP 接口，并使用自定义的令牌进行拦截。目前还在研究过程中，尚未添加 HTTPS。

有些 Webhook 提供的是一个前端系统，例如 Spring Boot 应用或 gRPC 应用，它们接收数据后将其输入到数据仓库中。我们使用 ClickHouse 作为数据仓库，因为它能够保存多种数据结构。一些日志会在实时计算后保存到数据仓库中，另一部分会使用数据进行离线计算。我们对 ds 的 2.0 版本进行了二次开发，以适应当前的工程结构并更好地维护。

维护平台

采集之后，并不仅仅是结束了。我们还设计了几个平台来管理数据，以应对不同的应用场景。这些平台类似于数据的前端和展示，便于管理过程流程跟进，并提供更好的可视化。我们基于 Ruoyi-Plus 进行了改造，主要产出了以下平台，便于维护管理，比如自动操作服务、安全感知服务、持续集成服务、日志审计服务、容器管理服务、监控预警服务、链路追踪服务等。

这些服务功能主要是在数据上展示和管理，便于超自动化的管理。一些数据来源于 ODS 层和 ADS 层，目前的流水线集成还在 GitHub Actions 上，但数据应该已经采集到了。后续需要进行验证，并进行多个自动化流水线的验证处理。这个过程可能需要进行调试，当前的功能点已经规划和编码产出。

总结

以上是我们在研究超自动化过程中关于日志处理的思路和结构。目前还在进行调试和验证。除了日志的自动化处理，还有其他方面需要结合超自动化，例如项目管理、产品市场营销、流水线自动生成等。希望对从事这方面的同学提供一些经验参考。

鸣谢

在处理日志的过程中，我们参考了一些产品，主要包括以下内容：

  • GitHub Security 服务
  • 阿里云分布式链路
  • AnsibleTower 自动化操作
  • ELK 套件
  • PlumeLog 开源日志工具