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

背景

网络的一些公知感觉上有些过于浮躁，一些价值观的引导过于片面，从而引发一些误导，这里从另一个观点阐述。一般觉得工作前二三年是一个坎，这基本上很容易决定后面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处理，然后进行汇总。

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

总结

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

在16年的时候开始落地服务化架构在大中小项目落地，到现在遇到过很多次讨论，基本都是使用服务化技术，这里偏向于架构设计阐述，属于个人观点，供参考。

背景

依托于容器化的普及，Cloud微服务技术当前比较盛行，在以前应该是Dubbo服务，后来慢慢建立了微服务体系，注册中心，分布式配置等各类组件，后面Nefix组件有些开始不维护，再到AlibabaCloud组件，现在很多开源框架、培训机构等依然以这些做一些宣传点。然后从自己的在多个大中小项目和落地的情况，企业运营管理，跟进行业先进技术发展，后期运维效果等多个角度思考，这无形中也会引起另一方面的方向失误。

概述

服务化本身是解决以前旧项目大，更新迭代难，耦合度高，管理开发协助难，较难支撑大并发等问题，这个在大项目上简直是福音，特别是初步切入的时候，大家都感觉看到希望一般，对这个架构难得的喜欢。

在后来几代的微服务，从服务组件的不完善到目前国内外开源组件的健全，基本上技术架构和体系都已经不再是什么难点。然而在这两年接触到的其它团队讨论中，却把这个技术架构和方式带到了另一个极端，看到的景象一般如下：

• 每个项目都微服务，业务中使用微服务，为什么要上说不清为什么使用
• 项目超细粒化划分，确实拆分出来是好维护的，而且每个就一个职责
• 架构设计比较高大上，而且看起来很复杂，很完善，devops/容器化/自动化
• 常常要搭配上一些社区很多组件，每个组件都能说一大堆好处（不否认）
• 理论论述很全，组件化，分布式，高并发，消息中间件等名词很多
• 运维管理也一样是生态体系，prometheus/grafana/skyworking/elk等
• ……

无可否认，听起来确实解决了很多问题，云原生的生态体系也非常的全的，甚至刚毕业两三年的，都可以很快的学会这套体系的技术，之前遇到的行业都在微服务（这里指的是Java技术），针对自己的项目经验和接触到的情况，看到的可能跟以上的偏差会不太一致，包含有，有自己的思考方式，从几个点阐述：

• 技术是服务于业务能力上进行阐述，避免脱离业务谈架构
• 考虑是否需要这样的技术架构，解决的问题是什么
• 取长补短，新的架构是否可以解决实际问题和业务架构设计

整体思路偏向于个人经验和落地的思路，重点在于内部的落地，我有我思。

整个过程

这里过程从一开始的业务场景到选型进行阐述观点，即从业务场景，再到团队情况，架构设计，后期维护升级几个主线思路，这里主要以实际项目经验和实际案例为参考。

技术是服务于业务能力上进行阐述，避免脱离业务谈架构

脱离业务谈技术，这个是架构师大忌，无法落地的架构不认为叫架构。

每个业务的场景并不一样，然后需要实现的效果也不一样，在这个过程实际的讨论之后，才会选定解决方案和技术架构，当然这些是基础常识。

这里针对的是团队核心型业务讨论，业务从长远来看，对团队来说除了开发，还有运维，运营，战略产品等后期的发力点，并不仅仅是一个开发框架可以或者一种开发架构能解决的，这个过程至少要考虑到3-5年，其中隐性的就结果在开始的时候不会体现，在后面的时候才慢慢展现问题和架构规划的好坏，这里针对的是团队角度，而非末端执行角度。

从某个角度来说，一般末端对架构设计的理念其实并不是特别明确，执行层需要的是经验和能力，照着顶层的架构设计去实施即可，但是对于业务架构设计的人员来说，需要考虑业务的长久运营和管理规划，包括后期的行业发展跟进，架构的先进性和可持续性，产品性能力等等，以确保团队可以长久的运营下去和保持核心的竞争力。

微服务化可以解决一部分问题，但是不是能解决所有的问题，同时也会带来过程的复杂性和技术的复杂性，同步也包括人员技术的要求等，相对于以前单体应用来说，是一个利大于弊的。

这个过程很偏重于服务划分的颗粒度，服务划分的思考角度，服务的职责能力，服务的维护团队能力，当地团队的人才储备，行业或者说市场的发展方向，内部管理层的人员管理水平，技术消化能力等等，要不然容易形成为了技术而技术，然后整体服务化之后，丢在那里而相对于之前没有太大的提升和意义。

从核心业务角度考虑，服务化之后为业务带来什么，是复杂度还是维护，或者成本降低，解决了什么问题。

考虑是否需要这样的技术架构，解决的问题是什么

新的技术引入需求，需要解决业务的实际问题，避免盲目引入。

如果某个项目，或者试点项目，建议可以从几下几个维度进行项目结果进行判断。而针对于团队的主要业务或者项目来说，微服务化这类似的变革，一般要落地，更是需要整体公司的推动，整体意识的转变，1年算短的，3-5年算比较正常，这里的3-5年不仅是业务的建设，同时也包括团队的消化和成长，成熟期的判断，需要不断的注入项目进行历练，避免今天微服务，明天单体，对团队和企业的沉淀几乎没有。

在服务化之前，一定要结合业务和场景等，考虑好为什么使用。前期面试过较过的做微服务架构设计人员，在抛出一些技术和场景问题的时候，回应出来的效果感觉不怎么好，比如以下几个问题：

“业务只有几个服务，什么要拆分，拆分的思想是怎么样的，相对于以前有什么好处“

”使用cloud，但是nginx也可以解决为什么还要引入一层复杂的业务“

”项目业务并不复杂，并发的压力可以横向扩展，为什么一定要拆分“

“工程复杂，模块化拆分和开发也可以实现，分开不是还增加分布式事务复杂性？”

“……”

接收到的回应都是五花八门了，有些可能有偏向于执行端有些偏向于技术尝新等，有些可能不了解上层的考虑（比如架构）等，但是从技术设计的角度来说，基本上看到是有些偏悲观的，可能更多的类似于听到的更多的组件化，高并发，易于维护，模块化拆分便利，互相不影响，后期升级便利等等，但是怎么样去组件化，怎么样好维护，拆分就一定方便么，增加的成本怎么考虑，后面说不清如何为业务服务。

技术架构的提升，需要很多考虑点，主流技术并不是代表就是符合。

取长补短，新的架构是否可以解决实际问题和业务架构设计

技术并不代表就是一定要那个样子，其实还可以这个样子，没人说微服务一定要cloud或者alibaba，或者nacos。

架构和业务设计尽量从简化，同时解决业务项目中的痛点和后期维护等考虑，这里提几个点，如果项目和业务来在考虑和设计提升，建议可以考虑：

• 设计的服务中能不使用分布式事务就尽量避免使用
• 把不需要的东西去掉，比如依赖n多的外部所谓好的组件
• 把层级关系尽量标明，调用关系尽量要明确
• 工程划分以业务标准为主，职责明确，模块为主，尽量少的服务
• 涉及到互相依赖的包问题尽量减少，耦合关系要明确
• ……

如果你有过程体验和感受，上面的设计就偏向于宏服务的设计思想，但是并不代表它就有标准，这里没有所谓的标准，如果非要定义一定，自己的理解，符合你的场景的那就是标准，至于使用什么技术，这个相对比较多，也比较成熟，就不过多阐述。

不过有一点滑稽的逻辑是，可以使用微服务架构来实现宏服务架构，类似于以前提到的可以使用微服务架构实现中台服务架构，只是一个架构思想的提升，类似于可以使用单体技术实现微服务架构，工具和架构融合，提升业务。

更推荐根据项目和团队等实际本地的情况，使用单体+业务+微服务架构优势的整合，类似架构如宏服务，但实际深挖远仅宏架构那么简单，一些互联网的名词出现，深挖会发出它会解决掉一些场景和方向，类似于以前的关系型数据库一样。

取长补短，来获取到符合实际业务的架构和方案，得出最优解。

总结

并不否定微服务技术，这里是不建议你盲目使用微服务，微服务技术已经有很多年，在架构设计和技术方向上，不要盲目推崇使用被技术绑架思维，而是在了解之后，以技术解决我们的痛点问题。

以实际情况为主，以团队实际能力为主，以项目实际运行情况为主，在以前没有体系之后，依然也是可以有技术方案可以实现，使用springboot/nginx/k8s一样也可以实现类似的效果，只是看项目大小还有运维管理的成本。

不希望动不动上来就是一套体系，一套方法论，而是针对问题的痛点，去选择合适团队的技术选型和技术方案，并不是方案有多优秀，而是方案有多适合，这是架构能力的体现之一。

以上为微服务技术使用的一些看法，希望可以给不一样的参考和建议。

在IT行业，自己应该是16年开始带团队，应该来来往往也有有一些团队，包括校招、社招、体系培养等，这里主要从自己带人的角度来进行阐述一些经验心得，经历有限，个人观点。

此文主要是给后期团队成员带人的参考思想和方向。

价值观

核心思想是协助和帮助他人成长，帮助团队成员创造价值和提升，激发团队成员自身的能力和潜力，保持和发展团队成员本身的善意和原则，认识现实和看清事件的本质，学会给自己做最优解。

概述

每个管理者都有自己的成长经验和带人经验，这里主要是从IT行业的进行分享，不同的岗位和角色对团队有不同的要求，不同的场景会有不同的情况，阐述主要从团队新人入团队为出发点阐述，为后期多种带人的经验输出，整体思想脉路如下：

• 了解和熟悉成员特点，包括优缺点；
• 协助成员建立正确工作观和价值观；
• 协助成员进行职业成长规划和指导；
• 协助成员提升自己对事的思想格局；

期望对他人有一定的参考价值和经验，我有我思。

过程

团队成员的融入过程，并不代表你一定要留下他，尽量协助他找到他自己的定位和方向，然后在团队中协助他进行突破，找到他在团队中的亮点，如果一点亮点都无法找到，无法能协助他人的，这个时候考虑是否需要这个人，或者他是否需要团队。

能长久的合作下去，需要有共同的支撑点，大家互相考虑取舍，会更加稳定。不希望出现公司是我家，更希望出现公司能为你带来什么的个人角度考虑，至于团队是否需要这个角色，会有负责人考虑。从自己的角度来说，更希望知道成员来工作的目的是什么，成长的愿景是什么，在一定场景下明确说明，这点是想要了解的，大家双方达到一致点，会更好合适，当然，前提是能力合适的情况下。

了解和熟悉成员特点，包括优缺点

人对外的体现是一个多种因素包含的体现，包括性格、成长、环境、家庭、教育等，最终形成他自己的特色风格，不要试图改变他，而是学会接受他。

每个人的成长经历不一样，在管理者成长过程中，有更多的经验，会更加容易判断一个人的各种因素下，针对不同的事情，可能会形成的不同的结果，或者多个结果的判断。通过这点，安排怎么样的工作和怎么样的合作，会有可预见的结果。

一旦操作不当，优点可能会变成缺点，如果安排得当，缺点也可能会变成优点，管理者要做的不是去强制性的安排，而是更加柔和的，顺其自然的按自己的预期计划去实现，这个是最好的，这个过程，成员往往是无感的。

这个需要在一定程度上观察和了解成员的特点，而这个过程不能太短，需要在一定的安排之后，查看成员的反映，根据他个人的情况会有不一样的效果，通过几次的安排，基本上就了解得差不多。

建立成员的工作观和价值观

在这个环境里面有一个规则，在你无法改变这个规则的情况下，要学会运用它，鼓励尝试使用现有的规则根据自己的情况调整成合适自己的规则。

什么叫工作观，一个例子，自己一直不鼓励所谓的“00后整顿职场”，也不建议这么处理，而是找到沟通方式，直接表达，鼓励的直接沟通，沟通不来，建议合适的时间点离职或是说明离职，道不同不相为谋而已。工作对于很多人来说，特别是工作几年的人来说，可能都已经形成自己的工作观，但是也发现很多新人和工作几年的人没有明确合适的观念，这里主要提供参考。对自己来说，很主要的一点就是能实是求是，这是对自己团队来说，很重要的一个基本素质。在不影响到个人隐私和道德观念情况下，在团队中，第一个需要的是能按实际说明，实事求是，脚踏实地。

鼓励成员能如实表达自己，这个看起来非常简单，比如在日周报里面，如实汇报，在对工作不会，如实沟通，对于不喜欢的内容，如实说明，在会议上针对问题，如实阐述，或是在对团队不满的时候，能如实说明等，需要能说出来，这个是自己所鼓励的，这样的团队相处，规避掉内部的勾心斗角，底下拉帮结派，大家相处很自然，这个是自己的团队基本原则之一。建立能表达真实的自己，而不是口是心非，当面一道，背后一面的的情况，这个是自己比较难接受的，也是不太愿意看到的。自己比较推荐的是先礼后兵的方式，在这个社会化的国情下，遇到事情以沟通为主，在无法进一步解决的情况下，再根据实际情况适当升级，怎么升级，是否一定要自己在前面，这个就比较看技巧。在没有任务技巧的情况下，建议是按实际情况表达即可。在生活各各方方面面都需要做最优解。在团队里面的发展，还有做的事情，自己要懂得为自己负责，如果自己都不关心自己，那可能更为困难。

鼓励成员能更好的尊重自己，这个听起来好像是比较不太可思议，这是相对于来说，这里可能更多的是自己看到的。职场上下级关系里面比较突出，还有新人过程比较突出，常常出现讨好型的情况，缺少主见性，过分的注重上下级的权威型，说得直白一些，带有一定的官僚气派，这个应该在实习生应届比较多。在工作里面，某个角色他所在的只是负责那部分的角色，并不是代表这个他就高高在上或者怎么样，只是在那个岗位那里，他有工作执行的权力和责任，两者是并存的。相对于自己来说，更多的会尊重团队的意愿，尊重每个成员本身的考虑点，也需要你对他做一定的尊重，这是一个平等型的关系。在自己看来，职位并无高低之分，更多的是职责，在那个职责里面，某些专业的人员他能做更明确的决定而已，认同成员需要尊重专业和技术。

鼓励成员追求自己的利益，并不需要你对工作做到什么样的付出，只需要在自己的能力范围内，完成自己的工作即可（能做好这点就很不容易了）。学会平衡自己的工作的利益关系，学会保护好自己的工作中的成果点，团队合作过程并不需要成员一味的付出，更多的是期望能听到成员的追求和期望，最简单的，比如追求高工资，追求更高岗位，这个是人之常情，也期望能表达出来，这些并不是什么难以启齿的事情。只是说要达到这个目标，怎么才能实现，方式是什么，方法又是什么，这个需要有正确性指导。比如见到有一些是觉得工龄到了就应该跟其它人一样提高，另外有些是觉得别人家的那么高，我们家的就那么低，就觉得自己理应该提高，这样的提法显然是不太推荐的，有些时候是可以，但是会有一种勉强“提高待遇“的感觉。这里比较建设的做法是把自己的业绩做出来，然后拿着业绩去做跟上级谈，做了哪些1、2、3点，有什么作用，达到什么效果可能更加合理，如果说确实达不到，这个时候是否可以考虑跳槽了。

当然还有很多点，以上只是当中很小的一面，比如遇到不公平对待，人际关系，晋升关系等，面对工作中很多的会体现出你的工作观还有价值观，这些都需要一步步的建立和提升，同时过程中的原则和底限把控，边界的把控，还有很多的。

工作观和价值观的建立，培养的是人员的品德提升和素质提升，有自己的原则和底限，团队中保持一定的原则和底限，这样能赢得团队和他人的尊重，是为日后的进一步打下基础，为后期团队成员的发展打下铺垫，也是合作的第1步，除了有背景外的，相信95%的人是在同一起跑线的，为什么有些人就是比别人快一步，自己感觉是他本身就有某些值得别人看重和欣赏的地方，可能同龄的人，没有这个体会，最后的落伍的往往就是觉得命运安排、抱怨这个那个的不合理，这些是自己所带的团队不愿意看到的。

协助成员进行职业成长规划和指导

经历和经验的限制会让成员关注点不一样，同时对前景的迷茫，需要协助他找到达到成员愿景的条件，还有过程指导，授人以渔而不是鱼。

遇到的很多开发类的人员不懂得什么叫规划，或者说怎么样进一步的给自己做好成长路线，听到的大多是跟周边的同学、朋友之类，然后口舌出来的结果，然后便去执行，亲身去验证了这个过程。好的，可能会比较有好的结果，不好的，可能就是后悔，抱怨之类的。比如一定会有人说要去考公，或者说跳槽要高工资，另一个是哪家工资高就去哪家，或者去北上广深一线就业，这些都是很多人的方向，之前遇到成员就做了，包括我自己也是一样的。

从两个方面看，其实大的游戏规则已经划定了，这个是社会资源的分配，就比如你正面跟清华北大的拼学历，一般人是拼不过的，去跟富二/三代类型的拼财富，这也是不现实的。每个人的人生出来就是一张自己的牌面，怎么样把自己的牌面打好，这个我对规划的理解。

针对于团队成员来说，在没有充分的判断力之下，针对于管理者来说，应该针对于成员的情况，给适当的职业成长规划建议，这个听起来有点类似于别人说画饼的感觉。其实没错，就是在规划，从成员个人的意愿提供更好的机会和建议，同时提供合理的操作空间，在遇到一些问题的时候，能给他们思考的时间和成长消化的周期，这个在接触的很多项目里面，是有这个机会的。

比如一个简单的例子，接触到很多开发想做架构师，但是怎么做到架构这一步，实际上他是不知道的，或者有些成员想走管理者，但是管理需要哪些条件和素质，很多他也是不清楚的，这个时候，根据项目的过程，提供一定的机会安排，这个对团队负责人来说，是很容易的，只要稍微的调整一下角色的分工，还有人员的跟带，就有可能提升成员一个较好的成长土壤，在这个过程中同步做些协助和指点，一般来说，只要他有兴趣，加上过程的成就点和鼓励点，他会主动积极去做的，成长起来是比较快，这个时候你会发现，一些优秀的人他会自己管理自己。但是这也是一个双面，如果想要让成员走入另一条路线，也同样可以做到，这就需要管理者需要一定良好的品德（也就是第1点提到工作观和价值观），切勿有害人之心。

当然，并不是每个Leader都有照顾到所有人，同时了解到每个人，这也是上面提到的，更希望成员能自己提出自己的期望，然后协助他做好这步。这步是有几个比较突出的点，一个是培养他的感恩之心，另一个是有助于自己的管理，同时也可以协助他更好的融入团队等.

所以为什么第1个章节提到培养工作观就是这样，这是互相促进的。因为我帮助了你，你有提升了，更好的帮助到公司，心态上就会有一定的改观，在做事情上就慢慢融合，事情就会做得更好，做更好了，然后共同进步发展，这是一个互相成就的关系，管理者在成就他人的同时，他人也在成就他。反之例子，很多成员在困惑中成长，工作的职业道德和他本身生活的限制会让他在这个环境里面1、2年，这段时间里面会迷茫不知所措，形成他本身自己的戾气，表现出来就是这个不满那个不爽的，自己成就感不强，甚至带有怨气，最后无法找到自己的定位，然后就不断的跳槽或者说生活没有成就感，存在一些消极等，这最后形成的只是说是团队和他本身的双损，这是不建议的。

协助成员提升自己对事的思想格局

协助成员接纳自己和认清一些行业发展，从多个角度去思考，获取到自己的最优解，建议要考虑是否是做这个角色，是否能区分角色。

工作场合从自己理解的角度出发，本身偏向于利益关系，在遇到问题的时候，自己要能为自己选择到自己最合适的路线和解决思路，获取到自己的最优解。这好像是很多人员都会，或者很多都在做，但是发现，在付出和收益成本两条线上，缺少一些更深层的思考。

这里主要从IT行业的角度来说，其它的行业自己也没有思考过。会发现，很多成员的认识里面，只有前端、后端等角色之分，但是它本身的作用是什么，为什么要这么做，然后这么做有什么好处，然后目前更好的解决方案是什么，现在主流的方向和技术是什么，并没有更多的思考，然后就是张口Java，闭口vue之类的，在沟通处理问题的总会绕不开这个话题，当然，这个也对，每个人都有一门是精通的，但是什么叫精通，并不是是每个人都会说得清楚 ，或者理解。怎么样才叫专家，自己要学习到什么程度，这些很多都没有进行过思考。最后的体现呢，更多的是在某个岗位上陷入一个死角，然后只会这个，其它的就谈不了了，这里所说的其它，指的是同一个IT领域的。

上面说得可能有些抽象，我们来个例子。最近在关注测试这块，在准备进一步的优化测试流程，所以我们就拿测试角色来说。可能是自己在二级城市，遇到的测试偏向于业务型测试，说白一些的就是点点，然后进行业务测试功能测试，然后测试除了点击以外的呢？还有哪些？有些可能会说，还有测试报告、测试用例、bug跟进反馈、环境管理、版本管理等，然后呢？

到这步的时候，应该很多部分人员都不会再有进一步的思考，好像上面都已经很多了。换个角色，期望看到成员思考的角度是从怎么进一步优化测试的角色，比如怎么优化测试流程，进行整个流程的梳理优化提升效率，进行一些自动化脚本的管理，然后解放手工，另外过程中保存下文档还有使用示例，方向后期人员的学习的培训，同时找到过程中的卡点和重复工，形成基础的公共模块，在这些工具都整理之后，思考别人怎么快速上手（先别说他人，先思考自己怎么管理和方便后期），然后把规范梳理出来，形成一套测试流程和测试脚本，同时测试示例，方便自己后期查找，再在这个过程中记录下问题，项目中实践，一步步的整理出可用的内容还有过程中的问题点，再看看别人怎么做，优秀的团队怎么做，再进一步的进行优化整理测试方案，形成一套自己的测试标准和工作流程。你会发现，慢慢的会了解行业的最先进技术和方案，这样会发现行业测试发展的痛点，在没有解决方案的情况下，自己尝试查找自己的解决方案。

过程会发现，涉及到架构、团队、规范、自动化、平台、解决方案等，整体考虑的格局就已经突破了一般测试人员，在最佳在实践下，就会在某个场景下有自己的测试最优解决方案，向行业进行输出自己的实践经验。成员在过程中会说自己不会或者没有时间，其实这点是可以解决的，这个时候需要懂得利用管理资源，如果上级人员不会，那就好办了，你会了，那机会就更多了。这个过程基本上前面1-2年可以把技能（也就是所谓的技术能力）和工具熟练，同时积累一些项目经验，后面3-4年进一步加深了解，形成资深，那后面的几年就是晋升和更高级的打怪。

再回到我们的话题，上面的只是测试的例子，还有开发、运维、项目管理等等，这些其实都可以进一步的加深深入思考，规避掉自己范围的局限性，无形中会提升自己。而做为团队的管理者来说，这是一件高兴的事情，也就是上面提到的第2点，协助成员的提升和规划还有发展（前提是他有意愿或者潜力的情况下），这会更好的促进团队的成长和发展，同时促进大家的提升和公司的发展。

总结

以上为带团队的一些经验总结，不同的场景不同的经验不同的方式，工作并不是主从关系，本质上是合作关系，主从关系是表现，是为了更好的合作和更好的配合，达到团队目标的更好的方式。然后再配合上各种管理手段、工具等，比如软件工程、Scrum、一些考核机制等，这些相对来说，只是工具手段，运用起来不难，只是有工具了，他会协助管理，形成一种流程和规范，这些就比较简单了。

在这个过程中，会有约束和规则，学会运行现有的规则和环境去操作，符合大家的利益，这是管理需要考虑的部分，而个体上需要考虑自身(管理者也包含个体）。每个管理都有自己的成长经验和带人经验，这里主要是从IT行业的进行分享，不同的岗位和角色对团队有不同的要求。

以上为自己的经验分享，希望能给一些参考和建议。

此文为国庆主题，内容是在工作和当前行业接触过程中，在十四五发展的规划，还有当前国内外行业环境下的一些心得体会，这里属于自己个人观点。

背景

这个是一个国内外发展变革的时期，这里从两个维度交待背景，分别是国际和国内。

当前国际环境格局变动，俄乌战争，美国技术封锁，中国一路一带发展等，这些大国的发展，影响着整个国际社会的变革。乌克兰战争的爆发，欧美的对俄的制裁，对俄的封锁，更是体现出国际环境技术自主发展的重要性，各个国家意识到和平统一，谋求共同发展，光刻机、芯片等限制，突出体现基础核心产业的重要。中国一路一带的发展，朋友圈在世界扩大，前期上合峰会的发展，更体现出亚太地区的经济的发展变化，整体亚太版块的结合更加紧密。

国内而言，中国制造业、互联网在国际名列前端，核心技术不断突破，数字化和AI的发展，更加将技术自主更加深入人心，国产化的技术在国内兴起，已经形成趋势，云技术和数据治理技术的普及，使得当前平台化，自动化成为主流，核心的技术产品和业务的中台化，在国内已经形成不可挡的方向，形成平台化的产品在各个头部互联网企业体现，比如物联网、人工智能、数据中台、城市大脑等，阿里云、腾讯云、华为云的云计算发展为各行各业赋能，形成大中台提供技术，前端团队形成交付模式，新的软件发展模式已由传统进一步转变提升。

概述

在国家崛起的这个时期，输出自己的技术能力，贡献自己的能力，这是自己对强国的一种体现。

基于以上背景，国家政策的实施，身在软件行业中的个人或者团体，都有体会在国家崛起的时期，针对于我个人的定位和发展，输出自己的能力和一些力所能及的发展贡献。在这个过程中，虽然国内有一定的发展，但也会体会到国内外软件的差距，不仅仅是芯片，在基础软件的建设，行业软件的建设同样还需要努力，互联网还有各个技术依赖于基础软件，行业软件需要各个高新技术的支撑。

自己本身处于行业软件，在这块上的体会比较深刻，国内千万个行业的发展，每个沉淀需要很长的周期时间，需要不断的去提升，打磨提升行业软件的服务能力，解决方案能力，结合更多的主流技术进行提供出更好的解决方案和用户体验，科技创新，提升业务本身的价值性和软件服务的优势。

当前专注在公积金发展上，自己从自身的了解和体会上，从三个角度和多个思考体会点，阐述自己的观点，我有我思：

• 公积金行业的发展：行业的发展和现状的思考，了解当前的问题和现状，明确本身行业的需求和发力点。
• 企业团队的定位：团队角色的定位，自力能力的认识，明确自己的角色和适合自身的发展点。
• 发挥自我价值的思考：需求和自身的匹配，让自己更加专注和发展，提升自我价值和更深入行业思考。

为了更好的描点阐述和自己从其它行业的思考，下面的标题做了缩减。

行业发展

行业和发展需要新一代人的深入，新的思维和新的理念的介入，体现行业的创新和服务的提升。

公积金行业自己接触的并不是特别长，但也不是很短，总下来的几年，看到的了解的，多少有些体会，这里陈述自己的理解，同时也结合自己在其它行业经验进行的陈述。

相对而言，行业软件的发展由原来10年前的单体架构已经提升到的分布式架构，公积金本身大部分或者多个城市属于传统现状，而这也是本身业务性质的稳定性要求，还有业务范围本身等原因。公积金的业务属于比较稳定型（这里的稳定指的是核心业务）和各个对接的第三方、外围等，而个性化的区域和业务，还有流程等，偏向于局面地区，而这个也形成了各个区域不同的门槛。同时业务的复杂性还有行业的沉淀性较强，对一般性的人员接触，都是在有自我公积金之后才进一步的初步了解，基于这个，人才的积累还有资深层面上，是有可预见性的，人员并不多，类似于电商行业，可能很多人都特别了解它的业务，而相对理解公积金业务的，达到资深的，其实行业内还是比较少的。

基于以上种种情况来说，政策、区域、人才、还有个性化等特殊性，造就一个局面，就是公积金业务相对传统，大部分来说，使用的软件技术还有创新性上就比较少，整体偏向于传统行业。

另外在行业竞争的这多家里面，能有大城市大项目经验的还是数得过来，而这个针对当前团队来说，是有一定的优势的，而基于以上的局限性，也有对手尝试打破的，比如产品化的提升，产品化的输出再加上互联网的思维打法，在全国性铺开。当然接触并不是很深入，但是从整体还有各个反馈来说，虽然铺开，但是也同样分散开来的手掌，在一定程度上，也会有受限，毕竟全国的业务就是那么多，那么大。在江浙一带的，由于互联网的优势，有一些突破，但是表现貌似并不是那么突出点。

近几年软件行业的发展非常迅速，人工智能场景的不断突破，技术还有数字化的不断加持，传统的公积金行业受到刺激，大家都在不断的找方向，这个过程中，也是期望能看到不一样的试点和服务突破，很可惜，当前还没有遇到。

针对于以上种种，也许还有很多。结合我们团队在做公积金业务中台，中台化的建设和思维，这个是自己特别看好的，看好的原因并不是单纯的架构，而是一种行业的变革，一种全新的软件模式。

这里也提出自己对业务中台的理解，中台化的思维更像是一种公积金操作系统，进行基础的操作系统安装，把公积金的核心业务的元数据和主数据进行沉淀，其它的软件像搭建积木一样的让各个团队去建设，形成一套公积金业务中台产品，而这个就是产品能力的输出，把这个概念传输到全国，加上一线城市大项目的落地案列，在可把控的操作下，形成产品化，形成一体化，加上中台特有的架构形成数据沉淀，形成标准，更好的输出到全国，有数据，有AI，有场景，形成进一步的公积金业务大脑，形成新的服务概念，新的业务创新输出。

业务中台是一个土壤，在这个上面积累和形成人才、业务、新产品、人工智能等的成长，最终形成行业多个插件或者产品形态的插件，形成一套行业解决方案，甚至后期可以结合元宇宙，足不出户，就可以办理公积金业务。当然，这套也可以复制到其它的行业，促进其它行业的发展，或者扩展到海外（就是不知道海外有没有公积金）。

整体行业的现状，结合自己的理解还有对行业发展的期望。

团队定位

一个人有自我清晰的认识，就能在团队找到定位和促进团队的进步，发挥自己的优势。

行业的发展需要人才的支撑，这里的人才并一定要达到什么条件，这里主要是表达符合时代的发展需要，在对应的岗位，对应的工作，对应的能力范围内，力所能力的输出自己。

在对行业的现状的做的同时，清楚的定位自己，能了解自己的能力还有所擅长的，喜欢和热爱自己的工作，在这个点上发光发亮，能我所能，达我所达，促进某一项的发展，在国家发展和崛起下，也是一种价值体现。在软件行业接触差不多近7年，在接触的团队还有方面的认识下，自身也有不断的认识。从初始的兴奋，到迷茫，到发现不足，到努力，到再认识自己，在这个成长过程中，需要感谢到很多，也同步建立自己的工作观和人生观，学会面对，学会去做好一件事，同时也学会团队的相处，更加清楚自身的限制。

这个过程中的打破，更多的是在公积金行业，首信团队中的体会，团队的互相成长，包容，还有协助，同时还有互相感恩，当然，还有硬技术，这些有部分除了自己有努力和领会，但是在我的感觉更多的是团队给的，对首信公司，对我自己而言，本身就带有比较浓厚的个人情感，在这个基础之上，会更多确定自己的输出还有团队定位。

在一个人拥有的一个热爱的心态之后，在对事情还有做事上就会提出自己的想法还有主动性提升，这点自然自己也有。我更期望的是能在团队中发挥自己，更多的让大家看到，看到的不是我，而是为团队推进出成绩，让大家看到我们的发展，提升热情，提升目标。我始终相信在这样的氛围下，大家会共同进步，共同努力，一起发展，进而推进公积金行业的发展，这是我所想看到的，也是想做的。成果是团队的，大家的，也是我的，也许这个就是自己所追求的定位。

有了方向，定位然后就很清楚，在未来的3-5年（自己只能看到这么远）中，当前技术还有中台产品建设输出的情况下，我更多的是协助和提出自己在过程中的经验，在团队大的目标下，结合自身具备的一些技术优势，一些成长经验进行传输他人，发展和落地中台的内容，协助两广区的同事解决过程的技术问题，也在过程中自我学习新的技术内容，新的解决方案，推进和解决我们的问题，提高前端业务的技术能力，同时也期望自己的本身经验，对中台产品的进一步打造和输出，形成我们公积金业务的标识和品牌，这个是我们的进步，这是行业的发展的一个进步。

即是自己所喜欢的，也是自己所热爱的，更是自己所期待的。

自我价值

每一代都有每一代特有的使命感，期望能为团队做好一些成果，在回想的时候能自己回味下。

能有所期待，即有目标，同有方向。在公积金行业的发展历程上，也许我们只是一个过客，一个不会有人记得的角色，更是一个默默无闻的程序员，但是这并不影响我们对行业输出我们自己，并不影响我们自己的价值，在对应的岗位上，做好自己，做好我们这一步需要做的，承接上一代人的理想，承接上一代人的精神，我们有自己特有的角色，特有的使命。

在中华民族百年复兴里面，中国改革发展40年，已经建立了一个又一个奇迹，这个过程，一波又一波的洪流，一代又一代人的推动，他们在兢兢业业的岗位上，付出自己的青春，付出自己的汗水，付出自己的知识，成就新一代人的梦想。

在前一代公积金业务中，无数的公积金人给我们建立好了基石，他们打下了公积金行业的基础，从公积金的制度初起立，在这个制度还有国民住房中发挥着重大的作用，解决了一代人的住房问题，这是我们所能看到的，也是全国在受惠的，正是他们的努力，开创了行业，推进了行业，促进了国家的发展和进步，促进了中华人民的安定和繁荣。这些成果和业绩，是值得我们尊重的，也是值得我们学习的。

而在我们这一代，不管是技术和经验，能力都在稳定的阶段，也是发力的阶段，更是在创新的阶段。在新一代公积金业务中台的建设，结合当代最新的技术还有科技使命，在国家的数字化，还有科技进步发展下，融合更多的新技术，比如云计算、大数据、人工智能、自动化能力等等，为业务的发展和创新提供了条件，新一代公积金业务中台为这个打下了基础，促进了行业的更进一步的发展和提升。在这个建设过程中，不仅仅是一份工作，更是一份事业，一份使命感的存在。在只是这一波洪流里的，在未来的5年里面，自己也在思考输出自己的力所能及，促进新一代中台的发展，进而公积金行业的发展，这是自己想看到的，也是想留下的。

总在有一天，回想后面的5年，自己曾经做过这样的一个事，可以有自己单独的回忆，自己能回想或者说得出来的事情和成果出来，这也许就是自己追求的价值。

收尾

以上是自己的过程和思考，仅以此文进行自我勉励，自己可以得到更多的认识，吸引更多同类型的人一起共同努力，共同发展和创造价值。在自己这勿勿的三十年里，在软件行业里面，我们需要很多突破，同时也更加需要有人可以提出自己的观点，尽自己微薄之力推进行业软件的发展。

在国际大变革的情势下，我们在软件技术的自我发展，国家在不断的输出自己的国际影响力，一带一路建设，上合组织的影响力，整个亚欧大陆正在连接，中国正在崛起。千年华夏，百年屈辱，党改革开放40年，中华民族伟大复兴的时期，在国家不断前进的同时，身处这个时代的我们，在自己的努力和行业岗位做好我们自己，通过这样的方式表达是自己对复兴强国的贡献。

最后，在这个发展的过程，同时也是对我们首信人的期望，不会遗忘自己是国人在当代的使命，输出自己的技术能力，贡献自己的能力。