作者：鄒振文
初六的早晨，剛從老家回來，坐在出租屋的陽臺上，陽光燦爛，竟然是北京難得的好天氣。距離上次寫年終總結已經(jīng)過去好久，打開博客，發(fā)現(xiàn)上次寫年終總結已經(jīng)是四年前的事情。上次寫總結的時候還是在東直門溫暖的辦公室里，隨著年齡的增長，覺得時間過得越來越快，四年時間，發(fā)生了太多太多的事情：有小孩了，換工作了，最重要的，是三十了。三十，意味著很多事情，古人說，三十而立，對我來說，更重要的是有了更多的責任，不僅僅是家庭，工作也如是。
年初負責的第一個項目是配置管理組的運維自動化項目，簡單的說就是將之前手工管理的20多臺機器使用puppet管理起來。想一想，命運真是諷刺，就在一年前，在上一家公司，自己還對持續(xù)集成工具不太感冒，不愿去學，甚至認為有些太難：機器環(huán)境的管理、構建工具、jenkins、puppet/chef、shell，覺得這些東西太瑣碎，一心只想寫代碼。換了工作，陰差陽錯，先到配置管理組工作一段時間，必須學習這些東西，過程就不多說了，只有一個感悟：很多時候，你覺得太難，只是因為你不了解它。用了兩周時間，將整個puppet環(huán)境搭建起來，一切皆SVN，一切皆代碼。
接下來的第二個項目是負責調研搜索新架構的自動化發(fā)布方案，這是跨部門的合作項目，大大小小跨越20多個項目組，這其中還包括了運維同事、測試同事和云計算基礎服務的同事，調研一禮拜，實際上事前準備了很長時間，僅僅那一周的調研計劃就修改了四版，系統(tǒng)整理了整個新架構的架構方式，和對方領導達成一致，取得他們的支持，了解大家的期望：開發(fā)同事希望能夠更快更有效率的發(fā)布代碼，測試同事希望測試的代碼與發(fā)布的代碼同源，運維同事希望發(fā)布過程能夠遵從規(guī)范可控，當大家對共同的目標達成一致時，方案就順理成章了：持續(xù)集成服務器負責一鍵編譯測試打包上傳到包服務器，包服務器保存所有的預發(fā)布包，預發(fā)布包經(jīng)過測試后才轉為發(fā)布包，發(fā)布包透過發(fā)布系統(tǒng)一鍵推送到Torca集群調度系統(tǒng)，Torca完成最終集群的發(fā)布調度。相比老架構，感覺新架構最明顯的提升是：下載、索引和檢索三大模塊被分離成各自獨立的服務，獨立演進；統(tǒng)一的數(shù)據(jù)管理平臺，以前追蹤badcase很難判定是哪個模塊處理數(shù)據(jù)出了問題，現(xiàn)在透過數(shù)據(jù)管理平臺，數(shù)據(jù)處理過程被可視化可追蹤；統(tǒng)一的腳本執(zhí)行系統(tǒng)，所有腳本以及執(zhí)行過程透明可視化；云計算平臺，XFS文件系統(tǒng)、Xcube數(shù)據(jù)庫、Torca集群調度、mapreduce并行計算，這些服務大大簡化了上層應用的開發(fā)。越來越體會到架構的本質：隨著系統(tǒng)的演進，我們需要不斷進行系統(tǒng)的分解，做到服務的獨立演化。當然當時也有困惑：當所有的希望都被壓在新架構身上，畢其功于一役，現(xiàn)網(wǎng)老架構停止開發(fā)運營時，項目的風險可想而知。做完這個項目，感悟有兩個：一是機會只青睞有準備的人；二是跨部門溝通一定要找到共同的利益點，一定要多換位思考。
4月份，準備調回項目管理組，去云計算基礎架構部做項目經(jīng)理。在配置管理組的最后一個項目是Jenkins的報表系統(tǒng)，只有一周半時間，最開始準備使用scala，考慮到后續(xù)維護最后使用了java，好久沒有編碼了，找回久違的感覺：打印出IDE的快捷鍵，搭建開發(fā)環(huán)境、測試環(huán)境和產(chǎn)品環(huán)境，jenkins一鍵自動部署，數(shù)據(jù)庫版本管理，TDD，一周半的時間就上線第一個版本，最后還不得不贊一下jenkins的rest api。感悟是：感謝一期開發(fā)時間只有一周半，這使得我們不斷思考到底我們要做些什么，哪些是我們最緊急最需要的，哪些是錦上添花的，一期上線后，唯一也是最大的好處就是：我們再也不用手動統(tǒng)計和發(fā)送構建周報了，每個禮拜一再也不用那么忙碌了。時間盒，很重要。
終于轉回了項目經(jīng)理，去云計算，牛人聚集的地方。首先仍舊是補課：計算機原理、Linux系統(tǒng)編程、C++ primer，一個都不能少。去了沒多久，出現(xiàn)了一起事故：搜索模塊對云計算SDK的依賴是源代碼依賴，云計算有5個產(chǎn)品，但是一個產(chǎn)品單獨發(fā)布時與之前的SDK不兼容，一發(fā)布就直接導致了大量搜索模塊的無法編譯。正好由我負責來推動解決這個問題，立了一個發(fā)布流程規(guī)范化項目：通過規(guī)范化發(fā)布流程、增加自動化集成測試，減少云計算平臺的發(fā)布風險。所有SDK統(tǒng)一打基線發(fā)布，發(fā)布前必須進行自動化集成測試，server發(fā)布時也要與所有SDK版本進行兼容性測試。隨著項目的進行，逐漸融入了這個部門：這是一個工程師文化非常強烈的部門，所有人都在技術上追求卓越，加班到10點以后是非常常見的事情，單元測試覆蓋率令人驚訝的全部達到85%，但是很多同事一聽到規(guī)范和流程就頭疼，項目計劃也是比較隨意，延期比較常見，另外因為之前發(fā)布版本升級比較隨意，也會經(jīng)常受到上游兄弟部門的投訴，有很多次出現(xiàn)問題，兄弟部門抱怨云計算平臺不穩(wěn)定，而仔細檢查后發(fā)現(xiàn)很多時候是使用的方式不對，比如查找文件時使用了遍歷。逐漸意識到，部門最大的問題其實是缺少產(chǎn)品運營，大家的關注點全部集中在產(chǎn)品本身上（吞吐量、最大存放文件數(shù)、強一致性），或多或少的忽略了用戶。5月下旬，風神項目啟動，項目目標是搭建臺風統(tǒng)一的監(jiān)控平臺和自動化部署框架，打造一站式的臺風服務。開始在項目中引入項目管理的實踐，WBS是最基本的了，迭代計劃找到開發(fā)節(jié)奏、回顧、每個迭代結束后都努力向線上發(fā)布版本，實現(xiàn)持續(xù)交付，工程上則將開發(fā)環(huán)境與線上環(huán)境進行了隔離。效果都還不錯，但思考更多的還是，我們還應該做些什么。產(chǎn)品發(fā)布規(guī)范化，必須通過自動兼容性測試和周知用戶；集群環(huán)境的修改必須可被審計，暫時不能自動化，那么先必須周知部門內(nèi)同事或結對操作；監(jiān)控有風神項目，但集群運營、用戶數(shù)據(jù)、可用率日報也需要發(fā)送；開發(fā)、測試和線上環(huán)境互相隔離；定期和用戶進行主動溝通，了解他們的問題。這段經(jīng)歷的感悟很簡單：產(chǎn)品的核心在于運營，作為服務部門，我們交付的一定是用戶滿意度而不是產(chǎn)品。
緊跟著，新架構還未上線，組織結構調整來了，喜歡ls的直率：我現(xiàn)在的任務很簡單，就是看到哪里有山頭就把它給平了，所有人都必須聽我的，所有人的思路必須一致。
在敏捷中國大會發(fā)表了演講《百年歷史看管理》，這個session足足準備了2個月時間，重新思考了流程、組織結構和人之間的關系。從20世紀初到40年代，管理科學完成了從無到有的第一個階段發(fā)展，這個階段最重要的成就就是將管理作為一門科學建立起來，發(fā)現(xiàn)了管理的三要素：工作流程、組織結構和人，并振聾發(fā)聵的告訴所有人：管理是可以學習的。我們可以看到，所謂管理，都不過是在流程、組織結構和人這三者之中進行權衡調節(jié)，管理沒有固定模式，只有不同企業(yè)根據(jù)不同情況在這三者間權衡裁剪罷了。如果說管理科學的第一個階段是在探討如何正確的做事，如何提高工作的效率，那么50到60年代這二十年管理科學的第二個階段則是在探討如何做正確的事：以顧客為中心、做事之前一定要想清楚做事的目的。管理至此也終于有了一個完整的定義：做正確的事、正確的做事。從70年代開始，管理科學進入第三個發(fā)展階段，在這個階段，首先提出的思想就是沒有銀彈，管理是一門藝術需要柔性，接下來就是流程的內(nèi)涵開始延伸，不再是單純的工作流程，而是面向顧客，強調端到端滿足顧客需求的整個過程，這個過程在全球化背景下越來越強調企業(yè)之間的協(xié)調、強調整個面向交付生態(tài)系統(tǒng)的協(xié)調，業(yè)務流程的概念被提出。進入新世紀，不管是更合理組織結構的思考（扁平化），還是對人的推崇（喬布斯、創(chuàng)新）抑或是業(yè)務流程效率的競爭（供應鏈），都明白無誤的告訴我們：管理只有恒久的問題，沒有終結的答案。
9月份調整到新的部門：搜搜問問。先負責的是后臺組的項目管理。新團隊，老人只有一個，士氣低下，缺少文檔，上百個服務，光維護就非常困難，重寫計劃。從回顧會議開始，持續(xù)改進。這段時間的感悟是：提升團隊士氣的最好方式就是幫助大家成功，任何一點成績都值得鼓勵。我們引入了持續(xù)集成和自動化發(fā)布，鼓勵同事做總結和分享；引入了自動化測試，鼓勵同事做匯報，幫助review ppt；積極的讓大家做有態(tài)度的程序員，對產(chǎn)品進行思考和反饋，把團隊精神傳遞到部門經(jīng)理，讓部門經(jīng)理進行鼓勵。可以自豪的說，后臺組是現(xiàn)在問問最有戰(zhàn)斗力的團隊。還有一點最重要的感悟是：一定是團隊leader決定團隊是否給力，幸運的是，我們有一個非常優(yōu)秀的leader。
12月份開始負責部門的社區(qū)化運營項目。這和今年工作的感悟是一致的，產(chǎn)品的核心在于運營，這正是我想做的。項目立項一定要有一個NB的名字，我們就叫黑暗騎士。這個項目同樣面對很多的挑戰(zhàn)，目前最大的挑戰(zhàn)還是在于人，團隊的信心目前還沒有建立，年后可能還會有人提出離職，而招人又是如此的困難，所以，上班第二天的第一件事是回顧會議。團隊年前第一個版本發(fā)的很有挫折感，需求反復修改，開發(fā)人員都心灰意冷，所以，感悟是：一份優(yōu)秀的需求文檔是一切合理計劃的起點。
1月份組織了技術中心的部門年會節(jié)目，我們原創(chuàng)的小品《非問勿擾》獲得了二等獎。把新人都變?yōu)橹鹘牵@也算團隊建設的一部分。
依然在不停思考，對問問來說，我們還應該做些什么。傳統(tǒng)問答模式作為搜索引擎的補充是否已經(jīng)走到了盡頭？SNS的問答模式是否值得探索？與微博是否有更深的整合方式，或者，它們本身就是一種產(chǎn)品的兩種展現(xiàn)方式？新浪微什么的探索是否還不夠大膽？在移動端，獨立的app沒有前景，如何和微信更有力的結合。
終于到了可以結尾的段落，還有一件事情似乎忘了總結，那就是我們寫了長達四年的那本書《流程的永恒之道-一個工作流和BPM項目的實戰(zhàn)》，什么也不說了，一個例子來說明為什么值得期待：當我們把房管局及各委辦局的數(shù)據(jù)和流程用BPM全部打通后，客戶卻依舊堅持要手動蓋章走人工流程，BPM實施技術根本就不是瓶頸，瓶頸依舊是人啊。今年上半年一定出版。之所以寫了四年，是因為寫著寫著總覺得知道的越來越不夠，不斷讀書和補充內(nèi)容，真是，那時年少，無知者無畏，唉。
2013，黑暗騎士崛起！
本文為轉載：原創(chuàng)地址http://www.software8.co/wzjs/cxyyg/2953.html