工作两年半的一次复盘

 

一、复盘的目的

　　今天是2021年1月30号了，时间过得真的是挺快的，转眼间就参加工作两年半有余了，回想起来其实感觉就是时间过去了，也不知道自己做了什么，没有记录，没有思考，这样就很难得到个人的成长和提升。前几天在网上看到复盘，可能一次复盘不明显，但是多次复盘，或者一直坚持下去的话，我也会相信会形成一个很好的一个思考习惯，正视自己的缺点和不足，勇于去改正自己的不良习惯，提高学习效率，学会总结，提升自己。工作这么久来也在网上看到过前辈们的总结以及对人生经验的分享。也有很好的文章阐述如何学习？也有不错的文章说如何去复盘。其实回想起着两年半的工作经验，真的有必要做一次复盘。这或许是我复盘的开始，也希望自己能够及时复盘，这样才能够明确自己的目标和发现自己的不足，对思考进行升华，做更好的自己。这次复盘主要是对自己的工作和自己的学习目标进行复盘，不包括其他方面的内容。

　　其实我并不知道如何去复盘，所以第一次应该是属于模仿的过程。希望下次以及后面能够有属于自己的一种方式，由于两年半的时间有点久，所以很多细节都描述不清楚了，所以所有的记录都是基本的一种回忆。

二、想想这些年的目标

　　都说计划赶不上变化，当然我也不例外，还记得去年的年终总结和计划，很遗憾的告诉自己，好像基本都没有实现，所以需要结合自己的实际情况设置合理的目标才对，目标太高完成不了，打击信心，太低太容易完成，丧失了兴趣。所以只有适合自己的计划或者目标，走自己认为对的路，坚持下去，一定会变得更好起来。

　　这些年的学习目标很模糊，从毕业到现在都是只有一个大概的方向，从来没有把目标分解，细化去一步一步的实现，也没有去好好的总结，也没有一个好的评判标准，所以也不知道自己要做到什么样的程度才算完成目标。这些年自己只有学习目标，学习目标也有分歧。因为工作的原因，学习路线分到了两条路线，根据工作内容来就是走运维方向，根据自己目标来就是开发和架构方向，所以有时候这两者都在学习。所以一心二用都不怎么精通，这么说起来其实自己其实就是没有特别明确的目标，毕竟一个人的精力有限，在一段时间内只有集中精力的攻克某一件事情或者某一门知识，这样才能学得更深更好，问题也能考虑周全，处理的有条有理。----目标模糊

　　对于工作上的目标：确实好像都没有好好的思考过，比如一件事情要做到什么样子，一个优化要做到什么程度，如果由我负责一件事情，我会怎么做，怎么做会更好。好像在工作上缺乏一些思考，虽然对于每一个本职内的工作基本都完成了，但是也不知道自己完成的怎么样，是不是还可以做得更好，在细节方式是不是更优，在全局方面是不是更加周到全面。对于自己的下一份工作是继续运维还是做自己想做的开发，也有点拿捏不住。----工作缺乏思考

三、相关工作回述

1、负责zabbix的迁移
　　300+台机器，负责一些item的监控和开发，培训文档的编写，批量操作API的开发。后期负责zabbix server的优化和维护。

　　感受：毕业那会第一次听说zabbix，第一次听说监控，从零开始一边学习一边开发。都是在被指挥下干活，比如干这个，怎么干，一边理解一边尝试，很多都是干着重复性的活，当然弄完之后还是有所成就感，接触到了新的东西，也把整个zabbix的监控系统完善起来了。很多知识只有在不断尝试，不断去思考的情况下才能够做的更好，虽然网上也有很多的zabbix的相关知识，但是都不是很深刻，在做着一块的过程中，会不断的去思考，如何更有效的告警，一些错误通过重启可解决的问题，就使用zabbix监控并重启相关服务或者作业，还有就是如何降低监控开发的成本，开发一个脚本，通过配置相关参数，就可以自动监控所有相关需要监控的项。通过一波实践，写了一份培训文档。但是推广效果并不明显，其他组并不关注告警。后来负责整个zabbix的开发、运维和优化，由于公司网络限制问题，导致zabbix的微信告警有时候发不出去，后来使用haproxy对网络进行跳转。这一步开始对zabbix的整个架构更加熟悉，对公司的网络使用也更加的熟悉，后来就是遇到zabbix的优化问题，一个zabbix server的参数配置，一个是对item的设置，后来也由于zabbix使用的mysql压力大，导致zabbix server查询慢，最后做了mysql数据库的迁移。

　　如上是整个zabbix的工作内容和感受，现在说说做的不好的地方。没有把zabbix技术传承下去，还有就是之前开发的批量操作的API没有好好整理，最后整理电脑，失踪了。前期对公司的业务和业务负责人不熟悉，所以在规划机器分组的时候没有规划好，导致后期监控有些混乱。由于公司机器很多都是混用的，所以在控制告警上没有控制的很好。还有就是推广的时候没有写相关的开发和配置规范，导致后期维护比较乱。目前还有些没有做的事情，就是对新来的机器没有一键部署zabbix agent的脚本。zabbix的监控其实是不够实时的。所以这是一个zabbix的缺点，有引进promethues+grafana做监控，但是这块只是简单的了解了下，没有深入的去熟悉。对于监控这块没有很好的去深耕。这块可以做的事情可以有很多，监控在一个公司来说也是很重要的一块，主要可以用于提前发现问题，解决一些可重试的问题，对问题做好足够的防备措施，还可以做根据业务的场景做一些自启动的监控运维，这样可以减少不必要的人工，把繁琐的事情交给机器去做，这样能够适当的解放人工的运维和提高定位问题的效率。

2、数据和调度作业迁移
　　刚来公司，被定位在大数据平台组待着，当时加上我也就3个人，直到后来变成两个人。我的导师安排我去etl组熟悉熟悉业务，在那边弄了快一个月，当时也算是了解公司整个etl的过程，从数据的来源，清洗，计算，落地展示都有了一个大概的了解，也做了一小部分的开发，熟悉了一大波的刷数的感觉。当时因为新的集群和新的调度的网段和机器配置完全不一样，直接把数据迁移到了新的集群，还好当时的数据量是非常的小，现在数据也到了PB级别了，在迁移的过程中整天都是全选复制粘贴，真的 会怀疑人生。数据迁移采用了distcp，数据量不大，所以也会很快。最麻烦的是调度的迁移，迁移可能还好，主要还要做规整，很多命名的规整，脚本统一化，还有就是里面有很多的坑，比如一同事三千行代码的脚本里还调用了一个spark的jar包，当时并不知道有这样的坑，全靠两个集群数据的比较来确定是否正确，同时运行，发现数据有所差别，最后还是把jar包复制到新的hdfs上，配置好相关的路径。最后还辅助做了一波mysql的优化，统一了所有相关表的命名，存储过程等。

　　感受：这个活做的时候真的是打杂的，天天复制粘贴，但是也确实学到了很多的东西，第一个就是对数据的细心，第二就是找问题的能力提高的很快。第三，更好的熟悉了数仓的流程（虽然我们公司的很不规范），最近安排写了一个数仓的规范，分层建表等规范，虽然很多感觉这些都是一些杂活，也能学到很多东西，比如自己在写数仓规范的时候，熟悉了数仓目前的架构，数仓建设的步骤，分层的理念，维度建模和三范式建模等，使得自己对数仓有了进一步的认识。

　　做的不够好的地方：当时有机会接触mysql的优化，但是当时由于自己不是很了解，所以没有加入讨论，错过了机会。虽然后来自己很好的学习了mysql的优化知识，但是都是没有派上用场，有点纸上谈兵的味道。在做迁移的时候没有把脚本规范化，也没有保存下来。没有写好总结，没有做好记录。在调整的过程中，没有大胆的去修改其中的部分架构，选择了保守的方案（提供修改建议）。对于那么多的重复的复制粘贴，后期的刷数，切表等，没有写好规范，自己踩过的坑没有记录下来，很多新来的人可能会重踩一遍。

3、greenplum数据库的推广

　　为什么要推广greenplum呢，我所知道的只是因为es的聚合能力比较差，刚好我们的业务场景是高聚合的查询，所以大佬们探索数据库，好像研究过好几个，比如tidb，最后选择了greenplum数据库作为替换es部分业务的技术。这个确定技术的选型我是没有参与，毕竟当时刚到公司半年，最后就是通知好好研究下greenplum， 以后准备推广。当时弄的时候greenplum6的版本还没出来，所以用了版本5。在greenplum的研发过程中，主要涉及到前期对表的设计，建表参数如何选择，比如是否压缩，压缩率，追加表，还是堆表，行存还是列存。都要根据实际的业务进行测试并选型。还有就是如何设计表的分布键，这个很重要，决定后期数据是否分布均匀的问题，会影响到查询的性能。对生产环境的安装我没有涉及，不过测试环境是装了一遍，在刷数的技术选择了外部表的构建，把外部表创建好直接读取hdfs的目录，这样速度是很快的。后期主要负责的开发是整个调度流程的开发，以及一键刷数脚本的开发，这里使用了shell中并发跑数，提高了效率，还有就是后期的数据展示，前端sql的编写，以及对greenplum集群做了监控的开发，例如对其中的一些超时的查询监控并kill。在这整个gp的上线过程中，有函数，权限，业务方向拆表建表设计，以及greenplum集群优化没有去接触。整个greenplum的推广时间比较长，主要是涉及到公司各个部门的合作，其实从探索，集群安装，数据导入，前端sql、测试都是我们几个人弄。所以推广的速度也比较慢，一个以业务为主的公司，推动技术是真的比较难，除非业务人员是完全受不了，才会配合我们这群“程序员”推动技术。

　　 感受：这个greenplum的推广也是从头跟到尾，学到了很多的东西，比如，需要引进一个新技术的时候，先要评估可行性，结合自己公司的业务场景，因为是真的没有最牛的技术，只有更适合公司业务场景的技术，在技术选型确定后，如何利用业务的场景来很好的利用技术。比如，如何设计表，选用哪些字段作为分布键。如何从全局考虑对技术的设计，在数据导入和设计好之后，如何对其进行性能测试，然后根据测试结果进行相应的调整。虽然从头到尾很多都有参与，但是对于集群的优化是没有参与的，greenplum的集群是有很多的坑的，可能动不动就会启动不起来，所以在自己不熟悉的情况下需要对其一个一个参数的调整。还有对并发测试那块没有参与，虽然知道使用的是JMeter工具，可以用于很多的测试jdbc，网络请求等，可以对其做并发和压测，很遗憾，这点没有参与。感触最深的就是学习不是闭门造车，而是一群目标相同的小伙伴一起讨论，才能更加深入深刻，考虑问题也会更加全面。

　　做的不好的地方：没有整理出文档，知识点都很凌乱，很多greenplum的知识有一点似曾相识的感觉，但是现在基本要去查资料，不利于后期管理和运维。还有就是自己在整个过程中缺乏的那一些经验，没有在后期补上来，所以对于自己来说这是一个不完整的项目，还有就是对于自己涉及到新的知识没能好好的总结和深入的去熟悉，比如从greenplum到postgresql，这些数据库可以怎么玩，架构方面有何优缺点，适用的场景怎么样，以后这些技术发展的前景如何，缺乏对新接触技术的深究。

4、流平台的开发

　　18年的时候有同事就想着搞流平台，当时是没有业务支撑，所以得不到领导的支持，都是有两个同事利用“业余”的时间“偷偷”的开发，当时由于一个同事对spark比较熟悉，所以刚开始引入的是spark的技术为主，flink作为另外的一种实现方式，当时我一直都没有参与，一直都在推greenplum，后来又换了同事搞flink到了2019年年底，都是没有业务的支持，所以没有很多的人力，也就是利用工作剩余的时间去搞的，直到2020年1月份，当时拉了几个人搞流平台，刚好回家之前大家都是探索，遇到了疫情都是线上开会，总是有那么一群人想法很简单，就是对自己想做的事情充满了激情的人，记得当时每周开会讨论，交流想法，当时是真的找到了作为程序员的乐趣，找到了作为程序员的激情，一群人做自己想做的事情，一起探讨一起进步，真的感觉很爽。当时主要负责是集群的安装，参数的调优，以及参数配置的开发，后期由于前端开发人力不够，做了些前端的开发，这真的是面向百度开发，从零开始，做了好几个页面，虽然不是很好看，但是还是很有成就感，毕竟做出了实实在在的东西（视觉感），还开发了一个前端sql的编辑器，包括sql的格式化，自动提示等功能，一半的时间做开发，一半的时间处理大数据平台运维的事情，所以有时候会跟不上小伙伴的节奏。足足弄了6个月，我们的流平台上线了，我觉得真的做的挺好的，很多的功能都有，程序的暂停，sql的校验，sql预览等功能，都是几个小伙伴共同努力的结果。不好的事情是第一版上线后，在产品推广的时候遇到了困难，因为公司很少有实时的处理场景，所以就是英雄无用武之地的感觉，很长一段时间都没项目，所以也搞得没什么激情了，因为人员没产出，所以我这个半个开发的人就主动出来继续运维了，接着研究elasticsearch了，因为公司需要把elasticsearch从2.4升级上来，期间只要研究了es优化的点，集群的安装，权限的控制以及备份和还原，以及顺带研究了一把ELK，研究了一个月，说暂不升级，心态炸裂，直到今天，开始开始评估升级。所以需要我做技术储备，从7月份开始流平台我就没参与了，有些遗憾。今天，好消息听到集团有项目要打造流平台，需要我们开发，感觉又活了，又可以继续做流平台了，很高兴又有点忧愁，因为落下了很多，所以很多会不懂吧。

　　感受：由于小伙伴在流平台以及flink的知识上是远远胜过我的，很多都早我一年接触或者半年多接触，并且也是全职搞流平台，而后期的我接触的也比较慢，而且也是半值做流平台，所以很多任务上会拖一些小伙伴的后腿，这里怪不好意思的，所以在后来流平台上线后没有推出去，所以我基本上主动退出来了，因为公司是不允许这么多人去做一个没有目前没有产出的开发的。在刚开始接触到flink的时候会有点点的觉得这是个新的东西，因为就算以前接触到的spark也是小批处理，所以也算是一种离线的运算，但是到了flink就不一样了，所以刚开始理解起来有没那么容易上手，不过后来接触多了，就自然而然的熟悉了，虽然看过一些flink的源码，但是看得不够深入，和小伙伴讨论起来完全就搭不上话，很遗憾没有像小伙伴那样学的那么深入，细扣一块源码。

　　做的不好的地方：刚开始就是从零开始，在flink的知识上落后了小伙伴，后期也没有全职投入，所以跟不上小伙伴的步伐，有时候自己想着尽快赶上小伙伴，这样反而使得自己静不下心来，所以自己钻研的也不够深入，很多都是浅尝辄止，虽然看了些源码，但是很多都是一知半解的，在整个的架构上也没有好好的去熟悉，自己也是不够主动。在开发方面还是欠缺很多的基础知识，所以有时候会无从下手，对flink理解的不够深入，也没有把flink应用起来，没有自己的flink文档体系。希望这次有项目支撑的流平台开发，自己能够更加的主动，更加的深入熟悉flink，做好文档的记录，形成一个队flink把握的全局体系，更加的熟悉实时数仓，比如如何建设实时数仓。

5、大数据平台的管理和运维

　　这块是最杂的，也是花时间做多的，基本贯穿了目前我的整个工作生涯。刚毕业就进入大数据平台组，当时是三个，不过自己在数仓组搞了差不多半年，主要是为了让我熟悉公司的业务，才能更好的做平台运维和设计，也是对我们主导的业务，处理流程熟悉的七七八八了，后面就进入了大数据平台的运维了，运维的组件比较多CDH集群，kafka，streamsets，redis，elasticsearch，hive，hadoop，spark，mysql等，以及后期推广的greenplum集群，还要管理300+服务器，还有1000+台vps，以及公司的调度系统，说实话在这里的运维就是既当爹又当妈，做业务开发的作业报错了，基本刚开始是把问题抛出来，为啥跑不动了，也不知道怎么排错，一个简单的数据倾斜，就是要说集群问题，说跑不动，最后是数据重复引起的，还是我们找出的问题，我终于知道为啥做运维之前，让我去熟悉业务了。到了19年年底，有个小伙伴跳槽了，所以只剩下两个人了，天天做着那些无聊的人肉运维，又没足够的人力去开发自动化运维。 在运维期间没犯过什么错误，也没干什么大事，就是零零碎碎做了一些事情，感觉没有什么产出，没有成就感（所以在领导心里以及其他的同事眼里，我们就是闲人，没有项目，工时都没地方填，一个只有业务运维的项目，没有技术运维的项目），想想自己在运维期间遇到两个大问题，一个kafka类似脑裂的问题，一个是hadoop集群看起来吵架正常，就是不能提交作业。不过后来都算解决了，可能解决方式不是很优雅，在运维的期间，主导了一些hadoop的扩容，elasticsearch的升级（2.4-7.8），不能平滑升级，简直就是重新设计。hadoop的集群的优化，在这个还是有点成就感的，elk平台的搭建，zabbix监控系统的优化和完善，部分hive作业的优化，streamsets的升级，当然还免不了一些集群的安装，反正大概就这些，记忆模模糊糊，因为比较零零碎碎。除了这些，大概其他的都是打杂吧，比如，写个什么数据仓库的规范文档，新来机器了，初始化下机器，申请开通什么什么端口。给同事提供下技术建议呀，有什么问题处理下啊，优化下啊。为什么跑不动啊，定位下问题啊，提供下解决方案呀，每年从头到尾都是片段式的，没啥成就感，公司资源也紧张，也不能去搞什么大事情，什么新技术，一心想去搞，又老是一些繁琐的事，很容易打断思路，目前hadoop都80%磁盘的占用率了，再不来机器就天天告警了。

　　感受：在公司做运维有点像打杂，哪里需要往哪里打，从来都没规划如何去做运维规范化，自动化运维，主要还是公司定位问题，觉得人肉运维就可以了吧，随着平台的逐渐扩大，PB级的数据量，服务器也增加，业务也一直在增加，平台的健壮性、文档化，规范化显得越来越重要，我敢说，如果是我一个人处理平台，里面还有很多的一些历史的坑，我也是不清楚，毕竟这些都是单点的问题。做运维就是要耐得住寂寞，就算别人觉得你们很闲的样子，就算领导说你们没产出，也要沉住气，因为他们没做过运维，不知道运维的产出怎么评估，所以我做运维基本是没绩效的，公司是一个业务为主的公司，搞业务的完全压着搞技术的，上次职级竞升答辩的要求，从来就没提到过要会什么技术，全都是对业务的要求，我当时都很怀疑我还有资格申请吗？其实有时会无奈，至少后来的海航申请我是没有报名，因为我不是很懂业务，要求就是明确要超级熟悉业务，就是没有熟悉技术的选项。虽然在公司打杂，但是零零碎碎的时间比较多，可以很好的去学习一些技术，经过两年半的积累，对整个大数据的一些技术还是比较熟悉了的，整个大数据的架构也ok，离线数仓的设计也有一定的理解，实时数仓也有些了解，对监控系统和linux，shell编程都比较熟悉，找问题和解决问题的能力还是得到了很好的提升，权限越大，风险也越大，也学会了小心翼翼的操作，敲好的命令都会去检查几遍。养成好的习惯，避免给自己挖坑。

　　做的不好的地方：以前没有主动的去思考把平台怎么做的更好，或者说是如何把运维做的更好，做的更加标准化，自动化，把平台做好不仅仅是简单的技术升级，要如何去考虑全局性，结合公司业务的特点，做好合理的技术选型，由于在给自己设置了一道墙，自己对业务不是很好理解，所以就觉得很多事情不好去做，没能够把人员组织起来，毕竟是一个团队，很多事情都应该是一个团队进行的，不是一个人单打独头能够完成的事情，做业务的不懂技术，做技术的不懂业务，如果不好好沟通一起交流，压根就没法把技术推广起来，这样很多技术可能只是自己学习了一下，没能够实践起来。还有就是我的这个岗位定位不清楚，一部分开发，一部分给etl那边解决问题，一部分做平台运维，所以在很多方面都知道一些，但是都不是很熟悉或者精通的那种。缺乏主动性，没能主动和业务人员沟通，理解技术需求，所以他们为技术而烦恼，我们为技术不能实践而烦恼。还有就是给自己的定位一直都是类似于二把手的感觉，没能主动去突破，承接起一把手的感觉，这是一个错误的主观意识，就像我小伙伴说的，很多事情让我们去负责，去干也能干出来，只是缺少这样的机会，但是这些机会首先都是自己的主观意识，如果自己认为自己就是主角，自己就是这个项目或者这个平台的负责人，秉着这样的身份去干活，效果肯定会不一样的。工作了两年，思维出现了错误，这也是致命的错误，很多事情不去采坑，不去亲自经历，永远都不知道有什么细节，要考虑哪些方面，要怎么配合各个部门的人。这样遇到问题也会临危不乱。所以自己给自己的定位超级重要。这也是恰恰做的不够好的地方。

四、工作思考和总结

　　如果从单独做好某一件事情去说，或者是别人指挥你做成什么样子，怎么做来说，也就是不用思考的那种做事情的角度，自认为做的挺好，细心，积极沟通及时汇报，但是如果说是一个人负责真个一块的设计，目前还是会缺乏一些考虑，可能会考虑的不够周到，就说目前负责es2到es7的升级，前期做一些技术的预研，从集群的角度出发，做好集群的设计，安装和参数优化，从权限控制到备份还原，以及一些相关组件的选型和安装。 再到安装文档，权限控制文档，备份还原文档等，还有就是结合目前的业务做一个合理的索引的设计，如何设计分片以及其他的一些相关参数的控制。怎么去规范化以后索引的设计和新建以及后期的运维。如果说从集群的角度来说，这么考虑至少七七八八了。但是从真个项目去考虑呢？比如是什么驱动升级，一次es的升级会涉及到多少人，一次这么大跨版本的升级对目前的代码改动有多大呢？一次升级需要多少人天呢？升级后能够带来多大的好处呢？是不是这次升级了就能避免以前的设计不好的地方呢？能够持续解决问题还是只是解决当前的问题呢？或者说不做ES升级，有没有其他的更好的解决方案呢？如果是自己作为整个ES升级的一个把控，如何调节各个人员之间的协作呢，如何去评估这次升级呢。如果是换做其他项目或者新技术的引进呢，那又该如何立项，如何升级或引进新技术，如何去推广呢？后期怎么样 能够更好的维护，开发是不是要有符合公司的开发规范，严格控制流程和生产评审呢？

　　如果从心态上去思考，给自己找个借口（由于自己毕业没多久，其实很久了，老油条了都），一直都没有把自己放在一把手的位置思考，很多事情都要征得带我的导师的同意，毕竟是高级架构师，整个平台从零开始搭建的，还熟悉整个业务流程，公司元老，怎么说都有一定的权威性。但是想想，每个人都有自己熟悉的一面，都有自己的优势，为什么在自己有优势的地方还不把自己放在一把手的位置呢，在工作经验和考虑工作全面性的角度来说，确实很多都值得我去学习，但是从激情方面来说，我觉得我不会差，有过之而无不及吧，有些事情往往考虑太多了反而成为了自己进步的绊脚石，所以自己应该利用好资源，不应该只是跟着大佬的步伐去思考，而是要有自己的独立的见解和看法，然后和大佬们沟通，吸取大佬的建议，尽量做到考虑的更加周到，能够在稳中去创新去进步，而不是在大佬们给你铺的稳定的路上悠闲的走着。还有就是自己没有利用好领导这个角色的资源，很多时候自己有想法，没人支持，也调动不了人，也是没有和领导商量，可能很多事都不了了之了，所以在公司利用好资源很重要，毕竟一个人的能力是有限的，每个人擅长的东西都不一样，自己不说出自己的想法，别人怎么知道呢？想去做，就勇敢的说出自己的想法和做一些可行性分析，得到有共同想法人的支持，这样就可以一起搞事情。不然的话，自己只能在自己心里和自己过招，最后打败了自己。

　　从个人总结方面去考虑，很多时候其实解决了不少问题，但是都没有很好的记录和总结，这样自己也会缺乏成就感，感觉自己一年又一年，只有年纪大了，好像啥也没有，所以在工作的过程中，一定要记录自己的工作内容，遇到什么问题，是什么原因造成的，最后如何解决的，如何预防这类问题的再次发生。还有就是自己的知识体系没有串起来，缺乏联动性，有些散乱。没有很好的总是文档的总结，就算在总结的过程中都是一些基础理论架构的知识，也很少去考虑这个框架的应用场景是什么？类似的框架有什么？相互可以代替吗？它们之间的优缺点比较是什么样子的。如何把这些框架应用到现有的大数据平台中，在一个新的方案和一个旧的方案如何抉择，效率？还是成本？或者如何考虑效率和成本之间的权衡。虽然之间也写了一些文档，但是都比较浅显，不是特别的深入，只有更加明白技术的特点和使用场景，才能更好的做技术选型，如何使用，如何更好地使用，如何更优的使用，如何符合当前业务场景的使用。

五、工作展望

好久都没认真的思考过了，累了就要好好的思考，看清方向才能更好的前行，经过这次的思考，也知道自己的很多缺点和不足，所以也希望自己在以后的过程中能够做到如下几点：

• 不管自己被领导定位成什么角色，自己一定要自信，勇敢的把自己定位主角，做更好的自己
• 不管以后工作多忙，一定要有文档产出，流程要规范化，工作要有相关记录
• 多思考，为什么是这样？怎么样会更好？还有没有更好的方案？如何做的更好？
• 多总结，正视自己的不足，勇敢面对，肯定自己的优势，调整自己的不良心态和习惯
• 切勿浮躁，静下心来，努力研究技术，对于前辈们好的思维方式，处理事件方式虚心学习
• 自己的任务切勿以完成的心态去做，而是要多思考可以如何去做，怎么做更好，是不是可以做的更好。别人的问题耐心的指导，积极提供技术建议。
• 不管是什么任务，遇到问题就应该抛出来讨论，可以把任务发散出去进行思考并解决，从点到线再到面，做全局的思考者，架构者。
• 不要闭门造车，没有最优秀的自己，只有更优秀的自己
• 要相信量变到质变，不要好高骛远

接下来的工作：ES7升级、greenplum升级、流平台开发、大数据平台扩容和优化、运维规范化、流程化、文档化，永远都不会做到最好，只会越来越更好。也希望自己能够越来越优秀，考虑问题越来越周到全面，仔细，能够独自扛起一面大旗，遇到问题不慌不乱。技术方面更加深入，更加系统化。加油！！！打工人！！！