一、覆盤的目的
今天是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升級、流平臺開發、大數據平臺擴容和優化、運維規範化、流程化、文檔化，永遠都不會做到最好，只會越來越更好。也希望自己能夠越來越優秀，考慮問題越來越周到全面，仔細，能夠獨自扛起一面大旗，遇到問題不慌不亂。技術方面更加深入，更加系統化。加油！！！打工人！！！