分类目录归档:生活

我在产品研发中用到的基础设施工具

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

背景

内容针对的是社区产品建设新人切入的指导性思路,目标是打开自我思维,有基础,能设计,能思考,能实践,会自我价值体现。合理利用社会资源工具,将时间和精力放在最有价值的地方,创造价值,提升价值。

产品是以开源状态进行开发管理,当前社区团队在接纳新人,有部分还是大二大三学生,有一些可能没有接触过设计体系这块,考虑更系统的体现基础层,这里进行阐述说明。针对于新人来说需要一些方向的引导,以快速的进入状态,跟上梯度成员,便于他们有方向的成长和学习方向,也是规避迷茫,缺少方向感,导致负面和误导,消耗无谓的时间。

当前维护的社区团队非常小,还是兼职,自动化和低成本的基础设施对团队来说,会比较看重,应用最少的人力去维护好产品,同时为了更方便的办公。工具的使用,可以让新人和加强的技术理解、架构思维、使用场景、解决能力、还有方案输出等能力。

设施包含

这里的基础设施工具,主要是使用开源和常用的SaaS化工具来进行平台产品研发的管理,以减少成本和学习路线,可以有大量的学习内容让团队可以快速解决问题,如下图中的这张架构内容。

基础层主要是包括【基础设施、代码级、模块层、应用级】,这个主要是基础环境设施,上面系统级主要是软件服务应用。在基础层,基本上使用的都是免费工具类型,包括免费服务器,免费的DevOps套件、免费的代码检测、安全检测等。每个人都可以使用,开个账号就可以学习,可以使用一些效能工具更快的提高自己的效率。

有一部分是现成的,有另一部分的自己设计的,总的来说,类似于PaaS层,但是又高于PaaS层,最大化的贴近于应用层,以减少底层的建设,确定好规范之后,外加GPT的加持,会更加提高效率和输出服务能力。

这里主要的内容包括几个主要部分:

  1. 基础PaaS层:阿里云ECS服务器、Kubernetes、阿里云ECS网络安全、阿里域名
  2. DevOps套件:Github、GithubAction、阿里云效Maven私服、阿里云ACR镜像
  3. 中间件层:Redis、阿里云MySQL、七牛云存储、Clickhouse存储、Kafka消息、Nacos等
  4. 基础服务层:Infra核心包、Infra单点登陆、Infra代码生成器、Infra权限引擎、Infra网关服务等
  5. 质量管理层:SonarCloud、GithubSecurity、墨菲安全、ApiFox
  6. 自动化层:GithubAction、Ansible
  7. 项目管理层:阿里云效项目管理、阿里钉钉、WPS、腾讯会议
  8. 项目预警层:Prometheus、Ansible、阿里钉钉
  9. AI智能层:Hugging face、百度飞浆、阿里云AI系列
  10. 数据治理层:阿里云DataWorks、Infra数据治理套件
  11. LLM大模型层:ChatGPT、星火大模型、百川AI、Infra智能体服务

这些大部分社区工具和云服务平台,作为入门的基础内容,难度系数并不高,要求只是基础能接入使用就可以,另一部分是基础架构里面进行补充的内容(以Infra开头),这些都提供出对应的接口和使用说明文档。当中有一部分会混着用,比如数据治理层,后期做为平台型产品会做一些场景进行针对性替代的研发。

上面这些,在这进里统一规划层基础设施层,这些会考虑使用低成本的方式去运营管理,方便产品的正常开发和演示运营,同时确保可以新人更好的针对性的自我学习。

学习路线

在工具选定之后,针对新人来说,怎么接触练习,这个可能来说,先对比较简单一些,对于线上可以注册的工具,基本可以自己学习就可以,学习主要通过以下路线,先熟悉工具,在进行应用层服务的开发。

学习路线主要是下面:

  1. 了解开源工具:账号的注册和示例的学习,了解这个工具是做什么的。
  2. 了解服务能力:了解Infra组件提供的基础能力有哪些,怎么使用当前的服务模板。
  3. 熟悉研发流程:了解产品的项目管理流程,敏捷开发流程,知道从哪步到哪步。
  4. 创建服务能力:能根据需求自主创建出服务并提供出服务能力,价值体现。

学习工具主要是了解怎么使用,这里使用的层面就是自己注册跟学习了,然后自己关联自己的demo进行学习。这个过程看个人,不合适人员并不会要求往下,合适人员接触起来,其实也比较容易,大部分就是看教程或者视频操作。

这也是进入产品维护的一个简单门槛,基本工具使用的还是helloworld级别,深入会过程再慢慢沉淀这样。在长期接触过程中,其实大部分场景都是可以满足,即使不满足,也不会达到多难的程度。

这里除了编码层面的,其他都是自动化,编写一套之后,留着自动任务执行就可以,根据预警情况,看是否需要处理,其他的,出问题再需要人工介入。

编码层面的,这里主要是通过结合代码生成器,GPT和定制的Prompt来进行,因为是产品型和服务型应用,逻辑还是先出一般本,先可以看到,然后后续根据产品功能,进一步的完善。先用起来为主,这部分对一般没怎么接触过的人员,先做一个功能就可以上手,因为规范都统一化,这些入门成本会比较低,参考着复制粘贴就可以。

另外就是Agent智能体服务的,这个整合起来就是调用GPT的接口外加基础服务的接口,当然,这个需要一些规范,前期已经解决了这个问题,目前主要是根据规范,结合工具API接口写Agent插件就可以,集成架构也已经集成。

能力输出

这部分重点还是在需求和设计上面,到进入服务输出来说,到这步已经很容易了,服务能力的输出,才是最贴近业务层的,这里会把精力放在这块上面,时间成本最大的,也是在这块上面。这部分可以花时间在需求和设计上面,后期通过AI编程和微调整来实现,另外就是参考其它网上代码或者开源项目。

自我能力提升,还有AI的引用也是在这块上,这块要考虑的编码,但是更多的期望可以使用现成的代码,可以复制或是开源的,符合的拿过来就可以,没有的,使用GPT协助建设也可以。这部分偏于码农路线,但是我们能做但是不代表一定需要做。

时间精力放在优化,某个框架深入,思维的理解,场景的运用,解决方案沟通上,这个是目前团队特别关注也是重视的。

总结

上面是当前产品研发过程中,使用的基础设施工具,有部分是使用现成的,有部分是结合开源项目进行的研发,有部分是自主开发,通过设计整合起来的基础设施能力,为上层服务建设提供良好的条件,也可以让新人更专注于场景解决方案和业务能力分析设计上面。

这里提出了一套基于开源工具和社区资源的学习和实践方法,强调了基础设施、代码级、模块层、应用级的基础知识,以及使用免费或低成本的工具和服务的重要性。并给出了一个学习路线,包括了解开源工具、了解服务能力、熟悉研发流程和创建服务能力等步骤。强调了能力输出的重要性,包括业务能力、AI引用、编码能力、优化能力、框架深入理解、思维理解和解决方案沟通等方面。

我对一些技术架构设计的经验记录

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

背景

背景交待,设计无法脱离背景,经验偏向于中大型业务应用,重业务和落地,偏于ToB体系,也有互联网经验参合。中小型团队(比如几十到几百人)类型,会有一定的资源缺乏,偏于业务应用层面。

以前也会太过于理想化的设计,经过遇到的和接触过到很多团队,反而更加相信自己的设计,或者说每个设计师有自己的思路。

概述

接触过很多做架构设计的团队,也在架构部门(专门做SA的团队)有很多讨论,临时记录的笔记,一家之思,做一些经验参考。

在以前接触的项目中,会跟很多架构师,技术经理,总监等做过很多讨论,很多感受到的一点,在整体型的平台架构设计上,能落地的团队偏少,小的设计上往往难统一意见,很多不同经验的人员,会带来很多不一样的想法,走向极端和误区性的也比较多多,过程放弃跑路的,做到一半一半的也不是没有,有些每一两年换一个架构方向也遇到。

这里主要做一些记录过程问题,架构的方向和设计,往往会决定企业或者团队未来3-5年的发展情况,做得好,商务和市场上的配合,可能达到事半功倍的情况,做得不好,可能就是其它地方事倍功半。这里以小团队做中台化产品的一些记录,同时结合其它团队沟通和接触过程中见到问题。

  • 团队基础条件: 每个团队有自己的情况,有自己的能力,有自己的缺点,不要过分否定自己,也不要过分抬高自己
  • 规避技术成本: 不要过分的引入以为好的技术,以合适为主,以简单为主,以容易上手为主,避免过度封装
  • 规避学习成本: 尊重开发人员的习惯,尊重行业的发展现状,部分人会不代表其它人就可以,习惯自然而然最简单
  • 敢于做决策: 在没有结论或者结论自己无法把控时,相信自己的想法,即使是错的,先做,重点是要能自己把控得往
  • 顶层思维思考: 从顶层思维看问题,规避过份纠结细节,整体能正常,不追求100%,保持后面有持续优化的心态
  • 其它 ……

以上为一些或者前期遇到的,很多都会有类似的问题,来来去去围绕的很多,设计开始否定的人一般会很多,甚至很多年经验的架构师一眼就会否定,觉得都不是问题,重点是个人有没有自己否定自己的设计,是否相信自己的设计,是否可以坚持自己的设计,每个设计师有自己的思路,我有我思。

经验内容

以下为一些具体遇到的问题和场景展开的分析说明,结合实际场景遇到的情况。

团队基础条件

设计不仅仅只是设计,这里业务架构设计层面不包含

在考虑团队基础条件时,我们必须理解每个团队都有其独特的情况和能力。这包括团队成员的技术水平、工作习惯以及团队内部的协作方式。不应过分否定团队的能力,也不要过度抬高。相反,应该在现有条件下寻找最佳解决方案,并努力提升团队的整体素质。

不仅如此,还有包括后期的招聘,管理,成长,城市环境等多重因素,做好一定的预案处理,这些好像不是本身的工作或者其它部门的考虑,但是存在的风险依然会需要考虑到这块的内容点上。在非大集团的情况下,或者中小团队,或者说二三线城市,或者一线城市特殊约束,都会有各种可能性,不仅如此,还包括商务、销售、市场、营销等等符合性的设计,以渐进式的方式进行的推进。

设计岗有一点类似于不上不下的角色,但是要落地,怎么推进,沟通,向上向下管理,输出都需要精细的考虑,看似跟这个不相关的事情,但是依然会带有一定的关联,在设计层面,会尽可能考虑到因素,以确定设计可落地,以保障架构的实施和后期的发展,这些都需要考量团队的基础条件。

这并不是为其它角色或者部门考虑,而是在本身的范围里面确保自己的设计可正确的实施,到这步,某个角度上,跟技术的关联性其实还比较小。不代表没有土壤就无法种树,同样需要考虑在各个部门当前的条件下,怎么创建土壤和培育。

规避技术成本

对技术的尊重和敬畏,但是不崇拜

对技术来说,不再过度去崇拜技术,而是尊重技术,尊重它带来的成果。在很多场景上的解决能力。

很多设计人员一上来会有高并发,分布式,微服务,容器化,人工智能,或者大数据等等很多的设计名词,这些并不是在每个项目上使用得到,有大有小,有高有低,并不代表它就会使用到。其实并不代表这些新的技术就是怎么样的,主要还是建立在业务和团队基础之上,以落地为主。

后来发现,这并不是一个好的事情。新的技术引入,以选择合适为主,简单为主,比如微服务,以前会听说很多springcloud技术,还有多个变种,官方版本,阿里版本,腾讯版本 … 还有k8s版本,在前期过程中你会发现,有可能会喜欢将“好”的东西运用上去,会成为一个臃肿的设计,或者追求各类型的过度封装,觉得这样会给开发过程带来很多方便。优劣好坏某个角度来说,很难区分,怎么选择。

后面发现,过重的微服务设计,使用的东西并不多,过多的设计理念,过分的封装,会带来后期很多无用的成本,后面的设计将springcloud组件能去掉的就去掉,保留最基础的springboot版本,其它按需引入,将非业务下沉到PaaS层,能轻量就轻量。

规避学习成本

尊重习惯的同时改变习惯

推行新的设计,以前很多情况下会走一到两个项目或者前期小团队试行,以积累后带大团队进行,这是一个常用方式之一。但是在不断的接触和积累过程中发现,这部分的成本也是非常大的,包括时间成本,学习成本,培训成本等。有时候需要找到新的血液进入,这个就更不用说了,周期往往一来就是半年以上,团队完全消化,甚至有可能1-3年。

尊重开发人员的习惯和行业的发展现状是至关重要的。虽然部分人的习惯可能不符合我们的预期,但我们应该尽量与之和谐相处,避免强行改变。同时,我们也应该意识到行业技术的更新迭代是不可避免的,但不是所有新技术都值得投入大量时间和精力学习。应该谨慎选择学习的方向,以避免浪费时间和资源。

效能工具方面,新的设计应该带来更好的效能,更好的减少学习成本。假如说将工作比作开车,前期可能大家习惯的手动档,在新的设计上,应该是提供出自动驾驶,或者自动档,依然是开车,提供更好的工具,以确保习惯的同时,提供更好的工具,在后期转变过程中,通过工具升级进一步的升级习惯,在过程中进行转换。

敢于做决策

决策有对跟错,没有决策往往是最大的错

前期带过很多Leader型的角色,新Leader有的时候,不太敢于做决策,包括我自己也一样,没做过,别人也没有类似场景,在决策时心理会有多个打鼓点。

在后面发现,在面对没有明确结论或自己无法完全把握的情况下,我们必须敢于做出决策。尽管决策可能是错误的,但关键是要相信自己的想法,并且能够承担后果。即使决策出现问题,也可以从中学到经验教训,并不断优化和改进。

这个的效果会带来一些误伤,但是错误和修正的成本相比于没有明确决策成本,会更大,而且后期成本相当隐形。

以前在做一个SaaS型平台产品,有上百个基线,同类的设计场景团队有时候也没遇到,但是先走,错了就调整,做好风险把控,结果在半年时间产品成型,形成团队转型基础,当时3个月出演示,半年成产品,后面都是接入项目。对比另一个公司团队也在做,2年基础版本才刚刚体现,基本上很难跟上市场和行业发展。设计 在决策上很多时候(注意是很多不是所有)不怕出错,就怕没有结论。

顶层思维思考

从顶层往下看,规避一叶障目

遇到的,不管是哪类型的设计,即使考虑是最好的,是减轻或者有利的团队或者发展的,依然很难达到100%的愿景目标。

这类型问题出现比较多的情况在于细节性的体现,管理太细或者太粗都不太合适,需要适当的下发权限,在一定的规则范围内,形成一定的容错性。在一开始的时候,同样也会纠结很多细节,这个不好那个不对,过分的追求理想化,常常导致的消极的反噬。

在设计时,从顶层思维看问题,避免过分纠结于细节。重要的是要确保整体系统能够正常运行,并且有一定的容错和恢复机制。不应也不要(以前可能犹豫,现在是明确不要)追求完美,而是要保持持续优化的心态,随着系统运行和需求变化,不断进行调整和改进。

高工跟设计的思考区别会比较明显,特别在处理在高工阶段的时候,这也没有问题,但是在设计层面,更多的思考全局性的,保持良好的扩展和耦合管理机制,在之前遇到的,先能用,最坏的就是模块重构一下。

总结

以上是前期设计的一些经验,可能会跟遇到的理想化或者架构模式会有一定的区别,但是总的来说,是过程遇到的问题和一些经验记录,期望给一些同学进行参考。

在设计架构时,应该注重适应实际情况,避免过度追求新技术和复杂解决方案。尊重团队成员的能力和习惯,勇于做出决策,并确保系统具备一定的容错和风险保障机制。通过不断总结经验,并持续优化改进,实现架构设计的有效落地和业务发展的持续增长。

注:文章图片由讯飞星火大模型生成

我在三个月的热辣滚烫过程经验

软件工程师罗小东,多年平台架构设计经验,目前在研究平台与新技术结合中。

概述

做开发久了,发现身体的变化管理也是开发工程师的一个部分,貌似很难脱离这个话题,做了一下笔记。


三个月指的是23年9月到12月期间,原很早想记录做下笔记,过于零散,刚好跟新年的电影有类似(电影角色100斤的掉秤是很厉害的)。便做了梳理记录输出,下面以程序员的角度进行的阐述。

起因是行业的快速发展,会导致方向感的缺失而产生迷茫感,方向定位的不明确,在思考但是无法找到自我破局的方法, 干脆不思考进入机械式的生活,

大致是对生活缺少激情,处事机械式,不愿意思考,也不愿去讨论… 带来的负面就是会消极,失眠,夜宵,抽烟,熬夜,精神不振 … 除了躺着,对很多事情缺失兴趣。前期有过一些心理准备,但略微超出预期,带来了182斤的体重 … 开始进入胖子大军行列。

经过2-3个月的调整,大概减重33+斤左右,进行的整体改造的变化(第一张是减前的变化,第二张是减后的变化):

好吧,最大号的T恤也被撑满了 :-(

计划是23年9月底,这里的改变会带来一些侧面的生活改变,属于积极的一面。大概有2-3个月的调整,改造的前提是自己在把控体质还有习惯,还有部分坚持方面自己可以把控,前期是带有一定的信心,也觉得是可行,每个人的体质和习惯不一样的,这里给出一些经验的参考。

调整方面

这里调整的方面,主要从几个角度来进行的进行的整体调整,包括以下的方面:

  • [运动]生活节凑
  • [运动]饮食情况
  • [方向]衣服外表

以下是主要调整的内容点,细节较多,这里主要描述主要点。

生活节凑调整

一定要动起来,尽量(只能说尽量)正常作息。

职业还有本能的习惯,会在长期的电脑面前,还有各类电子设备,包括多种思考处理问题都在电脑面前,这导致一个非常明确的问题是不知不觉的熬夜,大脑会长期处于高度集中的状态,再加”来一根烟”,一下就到凌晨,自然而然的外卖就点了 …

再看时间已经到凌晨1-2点,但是大脑还没有休息的意愿,带来的结果就是第二天的精神不振,后期的注意力可能不集中,体现的外在就是皮肤、眼圈、形态、体重、沟通、思维等等方面的问题等 … 会有一种感觉怎么休息总不够,动的方面就不太好说了。

这并不是一个良性的习惯。

在9月底的前一个星期,主要调整的就是作息,所谓的作息就是尽量早睡,控制在电脑面前的时间段,晚上处理不完的,放到第二天早上,解决生物钟的问题,将身体机能恢复到正常的生物状态。这个过程大概是一个星期左右,你会发现精神会好很多,早上6-7点会自然醒,皮肤会好很多的,当然,这个过程主要是想把身体的代谢以恢复到正常状态,这个是减下去的关键。

运行方面,每天早上10-15分钟的运动,跑步就可以,先动起来,自己开始只是5分钟不到就累得不行不行的感觉,后面慢慢到20分钟,有个过程,这里因为前期有规划,在节凑上并不是特别的着急,按计划。甚至时间方面,在放下手机、电脑、早起的时候,会发现,时间会多很多,因为熬夜少,上床的时间早,早上一般是6点半到7点左右自然醒,跑步运动回来再洗个澡,也不到8点这样。

这个重点还是在于计划和坚持上面,有个过程。

饮食情况调整

尽量不要点外卖,能自己带就自己带。

吃的方面是重点,自己走的比较极端的路线,原来的计划是快速减体重,再保持,再塑身。前面两个月基本上严格控制:

  • 水煮菜、鸡蛋、晚餐不吃或者说在6点前吃,吃也是水果蔬菜
  • 大部分情况是早上吃1-2个鸡蛋,再加一个水果,有时候是瘦肉和荞麦面
  • 中午还是两个鸡蛋,晚餐不吃或者一个鸡蛋,不吃米饭
  • 饮料不喝带颜色的,只喝热水或者温水,保持肠胃的正常
  • 每周吃一个大餐,就是那一天你想吃什么都可以,下馆半只文昌鸡
  • 其它特殊情况较少,并不会影响

重点说明,这里需要根据每个人的体质去做调整,看视频一直听说这样会伤身,还有抑郁的可能,但是个人并没有什么感觉,而且会发现精神状态会好很多,不会带有以前外卖暴饮暴食的那种压力感,除了前一两周会晚上肚子特别饿以外,其它还好。

运动外加饮食的调整,这个基本上每天会按减1斤的步子走下去。好了,这便是想要的效果,找到减下来的方式,按每天1斤,这样第1个月基本上达到20+斤左右的减下来,开始会体现衣服的已经宽松了很多。

在第二个月的时候,中下旬已经达到近30斤的效果,下面的就是慢慢调整饮食到正常,还有保持运动下去,这个过程基本上饮食需要慢慢进入正常,对油腻的食品已经没有什么欲望,明显会感觉胃小了很多,吃饭可以达到七八分饭,对所谓的美食基本上只是觉得是一个份正常的餐饮,也不会特别强的食欲。

在第二个月底的时候,基本上达到预期,后面的几斤上下基本上就没啥感觉了,整个过程大概是2个月的时间。


后面一个月是预留下来的计划,想看一下1个月的情况是怎么样的,是否会反弹,还有如何自我控制,是否能控制。目前效果还比较理想,体重保存到144左右,有上有下,但是并不影响。

衣服外表调整

注意一下外表,除了爱自己也是尊重别人

在减到差不多35+斤的时候,你会发现,各个方面都会有较好的情况,包括心态、思维、还有生活等,特别是信心的提升。

下面是运动前后的形态对比,第一张是运动前的,大脸,眼神空洞,精神不振。另一张是调整后的,会体现干净和少年感。

好吧,状态确实不好,跟长期没睡眠似的 :-(

运动之后精神会好很多,而且脸型棱角也会体现,合适的衣服会让人更加立体,选择合适发型很重要,适当做好定型。

会体现一些少年感,进行外表的一些改造,原来是考虑走一些干练的路线。

  • 衣服方面:尽量减T恤换成合适自己的,定制和买一些符合自己的西服,整个人会立起来,旧的衣物需要替换掉
  • 发型方面:选择好合适自己的发型,做一下定型处理,定期或者每月进行一次修理,以干净即可
  • 鞋子方面:基本把以前的鞋子都做了替换,选择合适自己的鞋子,这样结合上衣服,会立体很多,至少看起来
  • 其它方面:比如生活不邋遢,经常倒垃圾等,这些看个人习惯

以上主要的调整方式效果还算较为理想,以前可能做一些连自拍的角度都找不到,现在还可以给自己留下一些自己的回忆纪念。

调整前后的对比

会出现各种心态的变化,这里改变的主要从体重身材、思维心态、生活状态等,从这几个维度来进行一些阐述和对比的状态其实还是达到预期的,而且各种方面会有一些负面的影响:

  • 体重身材:身高不高,体重在182左右,三高开始出现,类似于你每天扛着三十几斤的肉在身上
  • 思维心态: 带有一种习惯性的操作,很多操作都带是前期经验的习惯性,思考性的比较少
  • 生活状态:比较消极,圈子也比较少,带有比较大的焦虑感,易燥情绪把握感并不是特别强
  • 其它: 结构化思维不突出,出差或者沟通层面上略有疲倦感,缺少说服力
    …..

后期的改变状态,效果略带有明显,效果还是达到预期:

  • 体重身材:体质恢复正常,144左右,各项指标开始回到正常,类似于把三十几斤肉从身上去掉
  • 思维心态: 心态上会较为平稳,急燥的心态很少出现,同时在新设计方案和思路上会比较稳些
  • 生活状态:会更加积极,结合经验会做好更好的自己规划还有落实,心态上会更偏于平衡
  • 其它: 会更乐于沟通和交流,对外展示一些生活方面
    …..

上面的内容点身边遇到的人很多都遇到,毕竟圈子氛围比较明显,一些调整的经验,以做为参考。

总结

这个是在三个月的自我调整和改造,原来很早想做一下笔记,调整后会前期是带来一些生活的自信,每个人的体质和习惯不一样的,需要针对性做一些定制计划,这里给出一些经验的参考。

我在年度输出内容和学习的规划

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

概述

年度输出规划会偏向于主动表达的意向,主要的目标让更多的人了解一些研究的方向,期望可以认识这方面有兴趣的朋友和交流,共同推进一些愿景,促进交流。

遇到问题

在前期研究和输出的方向偏向于中台或者中台产品化一些设计和在过程中的实践心得,主要遇到的问题比较多,原寄托的解决方案是超自动化理念,想结合类似于自动驾驶的概念,实现是中台自动驾驶的能力,类似于基于中台产品基础设施之上,进一步的实现更简便的落地的能力。

前期的产品化经验,基本上中台达到标准架构,标准接口,从技术、数据、运维、自动化、商务、支撑等几个维度的融合,服务的可折可分的模块化,可减可加的能力。但是依然在落地过程依然需要比较多的经验、架构师、团队、培训等磨合等,落地和建设成本依然较高。即使有一个技术中台,并不代表团队就可以用起来,用好,结合业务、企业方向发挥出能力。

原考虑通过研发中台自动驾驶操作模式进行管理。使该中台可以管理项目和软件的底层基础设施,能在不干涉的情况下生成优化中台。自动根据多年的中台研发和产品化经验,运用经过实践检验和强化的最佳实践来管理和维护中台,特别是优化在最低级别的场景方面。这些工作有助于保护中台,提高基础中台的稳定性和可控性,使中台管理更加自动化和智能化,结合实践过程中的指导和管理的最佳实践。

输出内容

输出部分主要是针对以上问题的解决方向,结合大模型Agent一起,将整个中台进行重新调整,结合未来3-5年的技术,还有AIGC的能力,结合LLM的推理能力,实现更加智能化的中台。

以下是整个架构图:

这里的处理思路是在原来的中台上面加上一层LLM的推理能力,通过Agent来与中台进行交互,中台类似于沙箱,来进行整体的执行。

可以理解成LLM的推理是一个协调的大脑,而执行的操作,视觉,触觉,感知等,由中台来进行收集处理,这部分怡好是技术中台的强项。不断新增加的能力会沉淀到中台(按中台标准化)进行管理和输出,Agent通过上层进行交互管理。

在积累沉淀的Agent和团队实际情况结合,经验以Agent和知识库进行沉淀积累,不断下沉行业的内容,做加法。当然,也可以配置出Agent来不断的自动增加服务能力,比如自动生成代码生成器的插件。规避掉落地的成本,毕竟Agent是可以复制的,角色也是可以复制的。

前期架构于23年搭建,当前整体架构设计已输出一版本,前期做了部分工作,今年的主要的目标是调度和优化交互,还有完善底层各个服务组件的内容。在这个过程中,同步以电子书的形式做为记录。

这个过程以github开源和记录的形式进行内容输出,通过对自动化技术和多Agent协作的探索,希望能进入另一个产品和智能化产品开发时代。此为业余时间研究内容,只为学习使用,暂时不涉及商业性的,后期会跟一些朋友公司进行一些探索和内部团队落地测试,以技术讨论交流为主。

总结

以上为年度输出规划,过程会有细节性的调整,会根据一些交流的意见还有建议等进一步的优化,包括更新,升级等,总体架构基本不变。每个架构师和设计人员都有自己的思路,我有我思,期望可以认识这方面有兴趣的朋友和交流,共同推进一些愿景,促进交流。

个人知识和经验有限,为规避误导,过程以原创和实践操作过为输出的基本要求。

相关地址:

电子书同步开源项目: http://portal.infra.linesno.com

我自定义k8s运维Agent插件:仿k8sGPT设计

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

回顾

书接上文。

这些的设计都是在有一个基础平台之上,这里并不会过多阐述平台型的建设或者中台型的内容,前期在AIGC交互组件设计上,已经集成了交互的模块。

形成的管理模块已经集成到到几个点:

  • 自定义Agent的聊天窗口和多频道设计
  • Agent角色的流程化插件化配置,可控化
  • Prompt的定义和分离和结果补偿机制

这些交互组件基本上确保了角色之间的交互达到一个比较稳定的状态和结果集可视化的状态,当然,还有一定的优化空间,但并不影响进入下一步Agent角色插件的自定义。

概述

参考集成类k8sGPT的原因只是做一个插件角色的示例,原来的k8sGPT集成较为简单,这里参考设计一个类似的Agent角色,一方面是熟悉了解Agent插件的自定义方式,另一个是方面是与实际的工作中结合,体现出价值性。
这只是一个单Agent角色的角色定义,当中包含多个Prompt的配置和数据接口的提取,多Agent、闭环Agent和复杂Agent暂时不属于本章节内容。

Agent角色的定义从设计维度进行阐述,如下:

  • 角色设计: 定义Agent角色和作用,解决场景,Prompt等。
  • 数据来源: Agent数据来源的处理,比如API、知识库等。
  • 交互模式: 定义角色的交互方式,数据返回的格式等。
  • 集成平台: 比如集成预警还有生成相关解决方案文档等。

前期也遇到比较多的设计思路,插件化每个角色都可以定义比较个性化和较强的交互能力,上面是我们在这个过程中的一些设计经验,每个架构师有自己的思维,我有我思。

Agent角色定义

这里角色的定义根据自己工作的性质和内容定义,包括一些流程配置(这里是liteflow框架,并无界面),角色多跟少由团队自己团队的情况设计,一般来说,都会有比较强的个性化要求,这里设计目标重点还是形成工作闭环或者减轻
一定的重复工作,形成团队和企业自己的Agent能力沉淀,解放上层人力进而可以思考更有价值的事情。

角色设计

定义Agent角色和作用,解决场景,Prompt等。

在这里设计了3个角色,同时注意并不是每个角色都跟LLM交互,理解成一个虚拟的员工或者能做事的角色即可,比如自动化也是一个角色,类似于ChatOps,角色定义如下:

  • K8S问题收集Agent: 主要用于收集K8S问题,与数据接口接口进行交互的,这个比较容易理解,只需要分析好问题就可以
  • K8S问题分析Agent: 针对获取到的问题分析出结果,然后给出合理的建议和处理脚本等,当然也可以结合知识库来处理,这个看怎么定义
  • 问题报告生成Agent: 根据问题处理结果生成报告和每日或者每周运维报告

暂时定义那么多个,当然你也可以定义一个发邮件的Agent,或者说管理的Agent来管理上面的Agent,这里为了确保结果和可控性,会由人工对结果和审核和校验。

在定义好角色之后,再进一步的定义每个角色的Prompt,这里一样返回的是yaml格式方式,便于跟其它的平台进行交互。这里问题分析的Agent解决问题的思路来源于多种方面,比如自定义沉淀的知识库,
使用机器学习获取到的分析结果等,会根据结果和沉淀,还有反馈机制,不断的演化形成更符合团队的处理结果,当然这里属于另一个范围,这里不做过多的阐述。

插件化的机制,可以不断的优化插件和Prompt形成最优化的输出。

数据来源

Agent数据来源的处理,比如API、知识库等。

数据来源的处理参考的是k8sGPT的Analyzer,这里是在原来的k8s管理平台进行的升级,添加了一个分析的模块,提供出api接口,便于插件使用,插件通过参数调用api来获取到结果参考,返回结果解析。

下面是Pod解析的相关代码,原来考虑使用LLM将golang直接转换成java的,但是效果并不是很明显,转换了一部分,然后进行人工改造,跟原来k8sGPT接口有一定的差别。

为了做出交互,暂时接口数据做了一些简化。在插件节点定义的时候,通过http调用接口数据即可,以下是节点的定义。

交互模式

定义角色的交互方式,数据返回的格式等。

交互有一种,一个是Agent之间的交互,另一个是与人的交互。

Agent之间的交互依然是上文的内容是下文的输入,使用yaml来进一步规范的定义格式,如果异常会在Prompt组件进行补偿重试机制,也会有一定的定时监控通知机制。另一个是与人的交互,会相对比较简单,
这里主要参考的是平时工作的模式,考虑是组建一个k8s排查运维的团队,将上面的Agent拉入,专门针对k8s问题运维排查处理的,方便后期agent的复用和其它团队的共享使用。

定义的k8s排查运维团队如下:

可能后期工作过程中,还可能会缺少角色,不断的往上增加即可。下面是交互的情况还有多角色上下文的交互,界面还是简陋了些,后期还会进一步优化。

集成平台

比如集成预警还有生成相关解决方案文档等。

交互的yaml格式化,在集成平台上会相对比较容易,类似于开始的数据来源也是集成平台的一种方式,集成平台的主要目的是方便内部团队第三方IM或者通信,目标是做几个:

  • 发送通知给钉钉,让群里直接看到看到word或者Excel结果,达到可评审的目的
  • 每周或者每个时间段,给出问题的结果和每日的运维周报或者日报
  • 抽取出重要问题事件,形成运维事件进一步的处理
  • ……

这个会比较个性化,针对于团队自定义的情况来处理。到这步结束之后,基本上整个Agent角色定义就形成一个阶段,提交插件的代码到基线,通过CICD会自动构建和更新插件,
后期的调试和优化通过调整Prompt或者插件即可。

总结

在插件化和可控化的处理,完成上面的Agent角色与交互,会有比较大的想像空间,比如k8s可以,那SpringBoot程序是否也可以参考(数据通过脱敏组件处理),只需要定义插件好可集成,在其它的场景下不断加入,形成新的工作模式。
上面是集成简单的Agent的设计和方案,期望给一些同学参考,也期望有兴趣的同学可以一起讨论,分享经验。

鸣谢

这里的设计思路参考以下开源项目:

  • AgentGPT: 基于AutoGPT的可视化版,参考其交互UI
  • k8sGPT: GPT结合k8s运维工具,参考其处理思路
  • Langchain:,LLM框架,参考其架构思想
  • Jenkins: CICD工具,参考其插件思路