架構(gòu)師工作總結(jié)述職匯報(bào)模板

1、架構(gòu)師工作總結(jié)述職匯報(bào)模板眼看著又一年結(jié)束，想想今年過的還真是快，上個(gè)畫面還是去年年末各種處理故障的場(chǎng)景，一眨眼一年就過去了。既然過了一年，還是得留下些思考和展望，否則就有些太無趣了。還是套用那個(gè)老的不能再老的梗吧，the good,the bad andthe ugly 。The Good今年職位從高級(jí)碼農(nóng)變成了看上去很忽悠人的”技術(shù)專家 “，雖然按專家的頭銜來說應(yīng)該做一些更深入的研究工作，不過受限于身體狀態(tài)一直不好，一認(rèn)真的思考問題就會(huì)頭昏腦漲，只好做了很多給團(tuán)隊(duì)打雜的工作，所以好的部分大多數(shù)不是我個(gè)人的貢獻(xiàn)，而是團(tuán)隊(duì)的功勞。今年最主要的成果，應(yīng)該是跟團(tuán)隊(duì)一起在很多事情上兌現(xiàn)了之前一直念叨

2、的“應(yīng)該”。應(yīng)該從現(xiàn)在開始做重構(gòu)，而不是“到時(shí)候”從去年接手團(tuán)隊(duì)之后就一直在跟歷史代碼做斗爭(zhēng)，在做了很久看似出工不出活的 “代碼 review ”、 “重構(gòu)” 、 “增加測(cè)試”、 “刪代碼” 之后終于有了回報(bào)：我們的代碼質(zhì)量可以讓我們?cè)谄渲姓９ぷ鳎?不再需要為了一個(gè)看似簡(jiǎn)單的功能而大動(dòng)干戈的在 “屎一樣的一大坨代碼”里糾結(jié)半天了。我們?cè)囘^很多辦法提升代碼質(zhì)量，包括強(qiáng)制code review 、專門抽出時(shí)間重構(gòu)、周會(huì)上的代碼評(píng)審等等。每一種都或多或少但最有效果的做法是引入自動(dòng)化的代碼風(fēng)格檢查工具， 可以發(fā)現(xiàn)大部分代碼細(xì)節(jié)問題，并且很容易量化，對(duì)于 “質(zhì)量” 這種沒有實(shí)感的東西，量化是能夠讓你持

3、續(xù)投入很重要的一個(gè)方面。而最終的收益不僅是開發(fā)效率的提升，更重要的是，一個(gè)不斷進(jìn)化的團(tuán)隊(duì)中的一員在看到爛代碼時(shí)，感受到的是 “如何解決這些問題”的挑戰(zhàn)， 而不是” 這些代碼再也不會(huì)好了 “的無力感。應(yīng)該通過提升開發(fā)效率完成工作，而不是靠加班有代碼不斷優(yōu)化的基礎(chǔ)，我們也很自然的把服務(wù)過渡到了微服務(wù)架構(gòu)。微服務(wù)架構(gòu)讓我們能夠更敏捷的工作，不再需要忍受單體架構(gòu)帶來的“一個(gè)巨大的黑盒”帶來的不便，我們可以對(duì)性能做更細(xì)致的分析，對(duì)問題做更精確的定位，對(duì)技術(shù)選型也有更多自由。 在此基礎(chǔ)上建立起了持續(xù)部署系統(tǒng)終于把上線變成了一件日常工作， “等我 5 分鐘，我review 代碼的時(shí)候發(fā)現(xiàn)個(gè)bug，上個(gè)線就去

4、吃飯”。我跟很多人談起這個(gè)“5 分鐘上線”的時(shí)候，他們都覺著我是個(gè)不負(fù)責(zé)任的人，并且一遍又一遍的問我： “上線上出問題怎么辦？”問我這個(gè)問題的人一定是沒有考慮過 “復(fù)雜度”本身就是一個(gè)巨大的問題源，當(dāng)代碼足夠簡(jiǎn)單、依賴足夠清晰時(shí)，很多問題就自然的消失了。實(shí)際上， 我們現(xiàn)在的上線次數(shù)從每周兩次提高到了每天十幾次之后，上線產(chǎn)生的問題已經(jīng)幾乎不存在了。應(yīng)該通過報(bào)警發(fā)現(xiàn)問題，而不是用戶投訴我去年用幾天寫了一個(gè)報(bào)警系統(tǒng)，團(tuán)隊(duì)又在此基礎(chǔ)之上建立起了一套特別靠譜的報(bào)警服務(wù)，不再依靠 “檢查系統(tǒng)內(nèi)部有沒有問題” ，而是站在用戶的視角，依靠探測(cè)程序檢查“用戶在使用時(shí)是不是有問題”。站在用戶維度報(bào)警的好處是，只要

5、有報(bào)警，那么就一定有問題。 于是我們終于從每天轟炸式的報(bào)警短信中脫出身來，不再需要“按報(bào)警頻率估計(jì)服務(wù)有沒有問題”這種無用的工作，也不需要面對(duì)boss “怎么用戶都投訴了你們還不知道”的尷尬問題。只要有報(bào)警，那么就需要處理；反過來，只要沒報(bào)警，那么絕大部分用戶使用也不會(huì)有問題，我可以放心的玩守望先鋒而不用擔(dān)心 boss 會(huì)突然來電話。最終，有驚無險(xiǎn)的，我們做到了服務(wù)全年無故障（雖然還有幾天才過完今年，希望這不是一個(gè)flag）。應(yīng)該通過技術(shù)解決性能問題，而不是堆機(jī)器微博的訪問量極大，做個(gè)方案動(dòng)輒要支持百萬并發(fā)、千億數(shù)據(jù)，但奇葩的是公司又很窮總是買不起新服務(wù)器（-_-） ，性能優(yōu)化就變成了極其重要

6、的工作。我們今年做了不少應(yīng)用的性能調(diào)優(yōu)，把每個(gè)服務(wù)的性能指標(biāo)都提升了幾倍（還有幾倍是留給明年的KPI 的 -_- ） 。 性能調(diào)優(yōu)是一件有挑戰(zhàn)又有成就感的事情，而且比較有意思的地方是，無論程序員的水平是好是壞，總是有調(diào)優(yōu)的空間。水平弱一些的同學(xué)可以調(diào)優(yōu)業(yè)務(wù)代碼和基本參數(shù)；好一些的優(yōu)化架構(gòu)和第三方組件；牛逼的可以深入jvm 和內(nèi)核原理。調(diào)優(yōu)經(jīng)驗(yàn)多了，總會(huì)有種“無論怎么優(yōu)化也到不了頭”的感覺。另外，我們今年基于云服務(wù)、容器技術(shù)、調(diào)度系統(tǒng)、混合云編排系統(tǒng)、容量評(píng)估系統(tǒng)和自身的微服務(wù)架構(gòu)體系，實(shí)現(xiàn)了公司成本部門老是念叨的的“按需擴(kuò)縮容”功能，我們的直播互動(dòng)系統(tǒng)也成為了微博內(nèi)部首個(gè)按流量自動(dòng)擴(kuò)縮容的服務(wù)

7、，達(dá)到了“5分鐘完成無人值守自動(dòng)擴(kuò)縮容”的狀態(tài)。在這個(gè)系統(tǒng)的幫助下，支撐微博直播互動(dòng)服務(wù)的常備機(jī)器只有幾臺(tái)而已，參加技術(shù)大會(huì)看到有人談直播架構(gòu)時(shí)，總是莫名的有一種優(yōu)越感應(yīng)該做更多有挑戰(zhàn)的事情，而不是一直重復(fù)自己的工作今年我們承擔(dān)了更多微博的業(yè)務(wù)，我們?nèi)缃駪?yīng)該算是微博里少有的“后端服務(wù)一條龍”團(tuán)隊(duì)，一整年來我們都在整合和優(yōu)化各種服務(wù)的架構(gòu)和鏈路。從消息箱底層業(yè)務(wù)，到tcp 連接服務(wù)，到收件箱后端服務(wù)，到直播互動(dòng)服務(wù)，到微博視頻服務(wù)，到文件存儲(chǔ)服務(wù)等等，這一年做了不少對(duì)原服務(wù)進(jìn)行重寫和進(jìn)行新架構(gòu)設(shè)計(jì)的工作。技術(shù)棧的多樣化帶來的是難以管理和重復(fù)性的工作，但是只要對(duì)不同的業(yè)務(wù)稍作抽象，那么就可以復(fù)用很

8、多現(xiàn)有的基礎(chǔ)設(shè)施，抽象和復(fù)用的實(shí)踐多了，就可以稱之為體系。今年我們對(duì)不同服 務(wù)的各方面，比如架構(gòu)、開發(fā)框架、運(yùn)維、監(jiān)控、報(bào)警等等方面做了抽象，建立起了一套體系，使我們不再受技術(shù)棧過于發(fā)散的困擾。換句話說，團(tuán)隊(duì)一方面享受著大公司的技術(shù)積累，一方面又有各種新業(yè)務(wù)場(chǎng)景帶來的技術(shù)挑戰(zhàn)，這是挺難得的狀態(tài)。The Bad就跟之前說的一樣，今年本來想做一些更純粹的研究工作，比如對(duì)操作系統(tǒng)內(nèi)存模型完整的剖析，或者對(duì)性能分析能力的進(jìn)一步提高，又或者再去qcon 之類的技術(shù)大會(huì)露個(gè)臉，但是受限于身體狀態(tài)，只好作罷。前兩年工作加班的比較猛，經(jīng)常一搞就到凌晨5， 6 點(diǎn)。這一年也做了些調(diào)整，沒再整到過后半夜，下了班就

9、一溜小跑回家玩守啊不是，回家休息。對(duì)團(tuán)隊(duì)小伙伴們的要求也是盡量提升效率，少加班。合理的作息和鍛煉對(duì)于程序員很重要， ”身體是革命的本錢“這句話誠(chéng)不欺我。今年還有個(gè)遺憾就是沒能實(shí)現(xiàn) “三十歲前用自己寫的語言寫一個(gè)操作系統(tǒng)”的愿望。也忘了這是什么時(shí)候定下的“小目標(biāo)”了，在如今，寫個(gè)語言其實(shí)并不困難，編譯器已經(jīng)是很完善的技術(shù)了；寫個(gè)操作系統(tǒng)也有一大堆從入門到xx 系列。但難就難在真的去做，說到做到和覺著自己能做到還是兩件事情，希望有機(jī)會(huì)還是自己動(dòng)手做一做。另一方面，對(duì)團(tuán)隊(duì)來說，還有很多想做但因?yàn)樾聵I(yè)務(wù)太多而沒有時(shí)間做的事情。比如弱網(wǎng)環(huán)境下的文件上傳性能優(yōu)化，微博私有通訊協(xié)議的優(yōu)化，我們團(tuán)隊(duì)維護(hù)著的開

10、源motan rpc 框架對(duì)于微服務(wù)監(jiān)控和調(diào)度能力的優(yōu)化，還有最近微博越來越火的視頻服務(wù)的后端轉(zhuǎn)碼服務(wù)、存儲(chǔ)服務(wù)的性能優(yōu)化，等等等等。這些只 能期望來年搞定了。The Ugly程序員這個(gè)行業(yè)里的人大多數(shù)人不喜歡交際，我也一樣。而實(shí)際工作中總有很多需要溝通的工作，而對(duì)于這部分工作實(shí)在是我的痛點(diǎn)。而痛苦的來源主要來自于溝通時(shí)不在一個(gè)頻段上，比如我問”為什么沒搞定 “， 而對(duì)方的回答是： “我不會(huì)啊”。又或者我說“這么做的話會(huì)更合理”，而對(duì)方一直在強(qiáng)調(diào)：“我這么做能實(shí)現(xiàn)啊”。再或者我說“這里的需求明顯不合理”，而對(duì)方只有一句：“老板是這么要求的”。無論如何，跟人溝通是一件痛苦的事情，尤其是跟與自己三觀不合的人溝通更是如此。今年也沒少經(jīng)歷過拍桌子大吼的場(chǎng)面。雖然不想承認(rèn)，但是很多人并不是真的想把事情做好；有一些人的 “好” 跟你的 “好” 不是一個(gè)衡量體系；有些人雖然意愿很強(qiáng)，但他是笨蛋；當(dāng)然，還有又懶又笨三觀還跟你不一致的如何跟人打交道是我今年反思最多的問題之一，作為一個(gè)與世無爭(zhēng)的程序員，我希望盡量少跟人起沖突，默默的多寫些代碼，但又不想自己因?yàn)橐苊鉀_突，變成跟他們一樣又笨又懶