#
先把項目背景簡單說一下，項目A可以認為是在原有業務系統的基礎上衍生出來的新需求（派生的新業務），原有業務系統是一個比較大的系統，在公司也是一個拳頭產品，賣了幾十套，目前也有好幾個人在上面維護+二次開發+缺陷修復等（人力資源緊張）。早期公司高層只是說肯定要做這個項目，但由于人力資源的問題遲遲沒有決定要開工（還有一個重要原因是領導希望能夠簽下1-2個典型客戶再啟動項目A的開發），而僅僅是上銷售去那幾十家客戶那里兜售新業務，吹的天花亂墜的，比較市場有些競爭，需要先拉單子。這些事情是年中的事情。
等到下半年的時候，市場對這個新的業務反應比較強烈，已經有客戶說要看原型再簽合同，原因是競爭對手已經出原型了。而此刻，公司以為高層決定要即刻啟動項目開發，說先把原型做出來，限期一個月。而中層領導還是由于人手緊張，就隨便抽調了4個開發人員，一半是1年工作經驗以內的新手，就這樣匆忙上陣。由于人手有限、時間緊迫、業務需求雖然已經明確，但很多業務細節這4個開發人員都不清楚，只有一個懂業務的但也談不上精通。
項目計劃就定了一個月，基本上按天把計劃排好了，1個月后系統原型出來了。但比較粗糙，缺陷也比較多，設計基本沒有做，代碼質量也比較差。拿去客戶那里安裝后，客戶認為這個系統太粗糙了，【到客戶那里，客戶就不會認為這是個原型系統了】
至此，按常規項目管理的做法，應該重新梳理真實的客戶需求、業務流程和功能設計、架構設計、概要設計。。。。
但事情的發展卻不是這樣進行的。由于客戶迫切系統以周為單位看到項目的進展，于是領導決定就在原型系統上擴展和修改，其結果就是計劃制定后很難執行，變成了按周來排計劃，主要就是按客戶的需求來改。
好不容易在年底前把版本基本上穩定了，但只是業務流程和功能比較溫度，缺陷開始收斂了。
但元旦后到客戶現場安裝測試版本，客戶對此版本又提了很多需求變更和新模塊。此刻麻煩就比較大了，因為系統的架構靈活性比較差，改起來對原有代碼影響比較大，改動范圍大。于是又是時間緊張，又是工作量，剛把功能實現，客戶就開始催啥時候測試。缺陷一直居高不小，于是決定花2周時間專門修改缺陷。
到現在為止，開發基本完成了。但問題也比較突出：
系統的性能存在問題（有些模塊客戶的意見很大，但這個從技術上講，改動會比較大，不是1周能解決的）
系統的穩定性（與1相關）
功能的可用性（有些功能早期按照開發人員的思維來設計的，到客戶那里客戶提出新的想法，開發時把這種體驗需求壓住了，但在后續還是要改）
馬上要啟動二期的需求開發，這個更麻煩
---------------------
至此，整個項目風險還是比較大的，我總結有以下幾個原因：
1. 項目的目標、業務流程、大體需求是很明確的，但細節需求在項目中前期，整個項目組都是一知半解的，造成后續返工較大，客戶和開發人員包括公司領導對質量的意見都較大；
2. 項目從開始到現在領導和項目經理的分工不明確；由于人是湊起來的，大家之前沒有合作過不了解；
3. 原型系統出來后，項目經理大部分時間都去解決客戶的需求溝通和售前支持了，少部分時間在真正項目開發上；
4. 一直對項目的總體計劃和推進情況估計不足，造成項目計劃形同虛設，完全是開發人員做到哪算哪；
5. 中前期領導對這個項目不重視，等到元旦后發現問題比較嚴重，就臨時抽調人手進來協助，而剛進來的人一方面不是項目經理想要的人（仍然是新手），另外一方面由于系統的業務性比較強，新手加進來后1-2周內根本不起作用；
6. 測試工程師，派過來的2名測試工程師是后期加進來的，業務都不熟悉，培養的2周后才慢慢熟悉，而且在客戶現場，測試工程師根本應付不了客戶的問題，即客戶講的需求測試工程師根本不懂或不熟悉；
大致就這些吧。
第三話按照原計劃是要寫寫平常心的，因為飛躍計劃要交作業，所以就改為寫自己對項目管理的一些經驗總結，剛好前一段時間那些年我們一起追過的女孩很是流行，這一話的名字就叫做那些年我們一起做過的項目。
我的第一個項目是在2005年，那是一家市場占有率前三的本地化翻譯公司，公司的信息部門只有兩個人：老大和我，我們一起開發公司內部的協同辦公系統。要解決的問題很簡單：由于公司發展迅速，以前單純依靠紙質單據和郵件分派和追蹤任務已經越來越讓項目經理和財務不堪重負，迫切需要將這些工作給自動化。系統的技術架構也很簡單：
jsp+javabean+mysql。沒有專門的開發計劃，基本開發流程是這樣的：每周一我們訪談一個業務部門經理，了解他的需求，周中開發，開發中有任何問題都可以直接找業務經理，周五的時候系統上測試環境，再和業務經理坐到一起看一下是否滿足了他的需求。系統就一直這樣不緊不慢的開發著，老板辦公室就在我們身后，一有時間老板就會和我們一起使用該系統。整個開發過程只有一個細節讓我印象深刻，就是對任務估算工作量時，不管我估算多少，老大都會給我乘以3，一次要給業務表單增加一個字段，老大問我需要多長時間，我說不就是增加數據庫字段嗎10分鐘，結果老大給了我半天時間，老大說，增加字段確實只需要幾分鐘，但打開編輯器需要時間吧，集中注意力需要時間吧，改完了啟動系統測試需要時間吧，測試完了和業務經理確認需求需要時間吧，我們估算的是完成整個事情的時間而不僅僅是編碼的時間。
這個項目完成時獲得了公司上下的一致好評，從公司老板到業務經理，每個人都非常滿意，而讓我感到唯一遺憾的卻是身為IT人員竟然從來都沒有加過班。
回想起來，這個項目之所以成功固然是因為技術簡單和系統不復雜（我們甚至都不需要 SVN，完全依靠腳本同步代碼），但最重要的還是持續交付和持續的用戶反饋，老板和業務經理每周都能看到新功能的上線，這增強了他們的信心，同時反饋幾乎每天都在進行，并且他們很快都能看到這是否是他們想要的。
第二個項目在2006年，這一年我換工作了，因為當時我認為不加班的程序員不是好程序員。新公司在上地，是一家做協同辦公業務平臺的公司，最開始去的是項目部，一開始很為業務平臺這個概念著迷，因為當寫程序時最先不是寫代碼而是用代碼生成器生成代碼，并且生成完的代碼馬上可以運行！第一個項目是豐田公司的銷售管理系統，我們創新的使用了當時最熱的Ajax技術，我們完全是用技術熱情加上周末時間完成對原有功能的 Ajax增強，這個項目獲得了用戶極高的評價，因為當大多數web系統還在使用點擊 /刷新的方式進行交互時，我們卻可以直接拖拽完成操作了。如果在當時，我會認為是技術的創新讓項目獲得了成功，但是現在，我會用漸進式增強這個詞，即只有在完成用戶所需要的核心功能（什么叫核心功能，即缺少這個功能系統不能工作）后才開始對系統用戶體驗、性能進行漸進式優化。
第三個項目是在公司的平臺部，這里部門經理正準備對原有的業務平臺進行重寫，原先業務平臺的技術框架是：jsp+struts+ojb+sqlserver，新的技術框架定義為： ajax+freemarker+webwork+spring+hibernate。這讓我興奮，因為新的技術框架幾乎是當時最流行的技術。加部門經理共有三個開發人員（所以溝通一直不是問題），老大使用project來管理項目，每個人負責一個模塊，估算以周為單位，最初計劃是 5個月交付，功能直接就是老平臺的翻版換的只是技術實現，但是 5個月后進行測試和項目試用時卻發現了大量缺陷，最后幾乎用了半年時間才將缺陷收斂，產品發布計劃延期半年。回顧這個項目，需求沒有進行詳細的分解和評審導致實現與需求不一致 似乎是項目延期最重要的問題，然而更深的思考卻是我們需不需因為技術原因開始新產品的開發，在不影響用戶使用的情況下對原業務平臺進行漸進式增強是否更加合適。即我們在啟動項目時更多關注的應該是用戶價值（只有有用戶價值用戶才會買單公司才有收益）。
第四個項目是我負責的，這個項目幾乎是上一個項目的翻版，重寫公司的工作流產品：支持更多的工作流模式，更易集成的api和管理界面，唯一不同的是這個項目采用了很多敏捷里的實踐：持續集成、單元測試、站會、迭代，但這些實踐均不影響這個項目最終的失敗。同樣是該不該重寫這個項目的問題，在公司資金鏈緊張、時間要求緊、新產品相比競品沒有突出特性的情況下，這個項目從一開始就決定了失敗。如果沒有特別充足的理由就不要重寫產品，這幾乎成為我目前最重要的一條原則，尤其要從公司全局的角度看待產品不能局限在技術。現在，只要誰一說到要重寫產品，而給出的僅僅是技術原因，我就會兩股加緊，冷汗直流。在對項目完全負責的情況下，我另一點深刻感受就是人的重要性，對團隊中的每個人員，作為leader 你都需要知道他的需求是什么，沒有人愿意做機器人，在一次對某一技術方案簡單粗暴拍板后，一個核心技術人員流失了，這成了壓垮這個項目的最后一根稻草。
08年底去了一家新公司，新公司采用敏捷實踐。第一個項目很成功，幾乎是敏捷項目的一個成功范例，需求分析、迭代、持續集成、結對、客戶 showcase、持續交付，項目甚至提前半個月完成。唯一美中不足的是項目二期時新團隊由于一期文檔很少帶來了很多困擾。突出的感受是：團隊人員有了角色、有了分工也就有了流程。現在，到了一個新的部門或中心，第一件事情往往就是梳理項目開發流程，定義出每個人的角色，職責不清是互相埋怨之源。
第二個項目是咨詢項目，略去不表。第三個項目是分布式團隊，一部分團隊在國外，一部分團隊在國內，最開始一切順利，但在上線前一個月遇到了嚴重的性能問題，陷入了一片混亂當中，所有人都不知道我們離上線還有多遠，還有哪些工作需要完成，優先級都是什么，項目經理甚至自己都失去對整個項目的把控，她不知道項目上線究竟需要滿足什么條件，于是一次次在等待國外團隊優化后的測試結果，于是一次次的測試結果不滿意，于是項目在一次次的下周二上線的空頭承諾中成了整個公司的笑柄。這個項目回顧起來就是團隊遇到挫折時放棄了計劃，迭代沒有了，故事墻沒有了，所有人都在等待，而項目經理為了不讓開發人員被公司收回還不得不想一些優先級不高的任務給團隊完成裝著我們很忙。教訓就是，任何情況下都不能放棄計劃，計劃是項目之本。其他包括團隊能不分布式就不要分布式，如果必須分布式那么一定要從架構開發任務上進行隔離，盡量減少兩個團隊之間的交互（很多項目經理進入到部門之后推進項目制，其實也是同樣的原則，團隊大了就要拆解，產品代碼多了也要模塊化，盡量減少團隊之間、模塊之間的交互，做到能夠各自獨立演進和發布）。盡早進行實際環境的測試，越早越好。測試越早進行越好，測試環境越貼近產品環境越好，這一原則什么時候強調都不過分（我們上線前的測試才發現嚴重的性能問題）。
第三個項目是幸運的，因為他們有錢，能夠等待，在多等待了大半年后系統終于上線。而第四個項目就沒有這么走運了，這個項目是一個在線 saas CRM系統的重寫，而且有著強時間約束（如果半年不能交付，將錯過該系統客戶每年做預算的窗口期），看吧，又是重寫，又是時間約束，這幾乎總預示著它厄運難逃。表面上看項目是在一次中期的架構重寫中崩潰了，重寫耗去了團隊太多的時間，而由于對未知領域知識的不正確估算（需要學習）再次令項目雪上加霜，項目目標又不能變化，要在六個月后上線，但更深層的原因還是項目開始之前沒有決策正確，真的要重寫產品嗎？老產品確實界面很丑、一些功能沒有，但這些不能漸進式增強進行嗎，一定要重新開始嗎？重寫使用新團隊，他們對該業務領域并沒有經驗，過去系統遇到的坑他們不清楚，他們的計劃因為少考慮了一些情況是否顯得過于樂觀？這個項目的其他問題包括項目計劃一直沒有發生變化，盡管所有人都認為在規定日期到來之前不可能交付，但這個日期卻沒有發生變化。最后不得不說這是一個技術強大的團隊，一切都做到了自動化，甚至部署產品環境也是一鍵完成，但是這些在項目目標失敗的情況下顯得黯然失色。而客戶貸款做這個項目則讓很多團隊成員良心不安。
來到騰訊，來到soso，最重要的收獲是對運維有了新的認識，以前曾經認為devops就是自動化部署，全功能團隊，現在發現它關乎架構：一條搜索的badcase是否能夠很快找出錯誤的原因？是抓取失敗，是索引時丟失，還是相關性排序不好？關乎監控和報警，我們能否很快從監控中定位出原因？關乎組織結構，前臺開發，后臺架構，基礎架構，運維測試團隊都是分離的，如何協作才能使團隊合作的成本最低而整體利益最大化？
回顧往事，保爾柯察金說：如何才能不虛度光陰，只有為共產主義奮斗終身；柯景騰說：唯有沈佳宜讓我懷念；而我想說的是：
做任何項目之前一定要想清楚為什么要做這個項目，一定要想清楚這個項目的價值是對用戶和公司的（尤其需要跳出站到一個比較高的層次看項目），一定要想清楚項目的約束（時間約束、人員約束）,不僅是項目開始之前要想，過程中要不斷回顧；；
項目任何時候都必須有計劃，對所有干系人透明；
項目一定是持續交付和持續反饋的，不允許黑盒出現；
測試和運維一定要盡早介入；
從每個團隊成員的角度出發關注所有人的利益實現共贏。
年輕時，不猶豫，年長時，不后悔。年輕時要盡早的給自己定位，是鳥就飛的更高，是魚就游得更快。
發揮自己的特長，有所專一，不能什么都會。根據別人的經驗為自己找方法。
趁自己還年輕，把想干的事都干了，只要對自己能力有提升的，別猶豫。不能等到年長時后悔當年
自己沒有干什么事，不能等到年老時再聊發少年狂。
年輕時，努力的探索自己，發掘自己，積極的上進，努力的學習，積攢技能，學習人事。
要努力學習，以開放積極的心態來面對困難與挑戰。
三十歲時，讓自己能夠獨當一面，能夠為人所用。跟著一群優秀的人合作共贏，積攢人脈，讓自己
變得更優秀。
四十歲時，讓優秀的人為自己工作，五十歲時，讓優秀的人變得更加優秀。
年輕時，積累自己的耐心，價值，能力，知識，創造，付出，原則
年輕時，靠的是努力。重點是學習如何成為一員有專業素養的精兵，找到立身之本的根。
年輕時，最困難在于要在最耐不住寂寞的年紀做耐得住寂寞的事。
或許某些努力看上去是無望的，但是不要放棄，堅持不懈怠，有傻×一樣的努力才有牛叉一樣的結果。
三十歲，靠的是實力。重點是學習如何成為一名有管理能力的猛將，要能獨擋一面。
這時，要將專業的深度，人格的成熟度，人情的練達度擰成自己的綜合實力。
四十歲，靠資歷。重點是學習如何成為一位有經營水平的名帥，建設枝繁葉茂的系統。
這時，你的經驗，資格，見識，榮譽都要上得了臺面。
五十歲，靠勢力。重點是學習如何成為一位成就組織的王者，培育眾木成林的勢力生態。
桃李滿天下，知交遍天下，關系滿天下。成為培育組織，保護組織，成長組織的人。
依靠以前鋪好的軌跡走自己的路。
年輕時跟優秀的人工作，三十歲跟優秀的人合作，四十歲找優秀的人為你工作，五十歲
努力是別人成為更加優秀的人。
年輕時可教，三十歲可用，四十歲有資格可捧，五十歲可敬。
五十歲的功德是自己成就的，是自己人生經驗財富的積累。
作者：鄒振文
初六的早晨，剛從老家回來，坐在出租屋的陽臺上，陽光燦爛，竟然是北京難得的好天氣。距離上次寫年終總結已經過去好久，打開博客，發現上次寫年終總結已經是四年前的事情。上次寫總結的時候還是在東直門溫暖的辦公室里，隨著年齡的增長，覺得時間過得越來越快，四年時間，發生了太多太多的事情：有小孩了，換工作了，最重要的，是三十了。三十，意味著很多事情，古人說，三十而立，對我來說，更重要的是有了更多的責任，不僅僅是家庭，工作也如是。
年初負責的第一個項目是配置管理組的運維自動化項目，簡單的說就是將之前手工管理的20多臺機器使用puppet管理起來。想一想，命運真是諷刺，就在一年前，在上一家公司，自己還對持續集成工具不太感冒，不愿去學，甚至認為有些太難：機器環境的管理、構建工具、jenkins、puppet/chef、shell，覺得這些東西太瑣碎，一心只想寫代碼。換了工作，陰差陽錯，先到配置管理組工作一段時間，必須學習這些東西，過程就不多說了，只有一個感悟：很多時候，你覺得太難，只是因為你不了解它。用了兩周時間，將整個puppet環境搭建起來，一切皆SVN，一切皆代碼。
接下來的第二個項目是負責調研搜索新架構的自動化發布方案，這是跨部門的合作項目，大大小小跨越20多個項目組，這其中還包括了運維同事、測試同事和云計算基礎服務的同事，調研一禮拜，實際上事前準備了很長時間，僅僅那一周的調研計劃就修改了四版，系統整理了整個新架構的架構方式，和對方領導達成一致，取得他們的支持，了解大家的期望：開發同事希望能夠更快更有效率的發布代碼，測試同事希望測試的代碼與發布的代碼同源，運維同事希望發布過程能夠遵從規范可控，當大家對共同的目標達成一致時，方案就順理成章了：持續集成服務器負責一鍵編譯測試打包上傳到包服務器，包服務器保存所有的預發布包，預發布包經過測試后才轉為發布包，發布包透過發布系統一鍵推送到Torca集群調度系統，Torca完成最終集群的發布調度。相比老架構，感覺新架構最明顯的提升是：下載、索引和檢索三大模塊被分離成各自獨立的服務，獨立演進；統一的數據管理平臺，以前追蹤badcase很難判定是哪個模塊處理數據出了問題，現在透過數據管理平臺，數據處理過程被可視化可追蹤；統一的腳本執行系統，所有腳本以及執行過程透明可視化；云計算平臺，XFS文件系統、Xcube數據庫、Torca集群調度、mapreduce并行計算，這些服務大大簡化了上層應用的開發。越來越體會到架構的本質：隨著系統的演進，我們需要不斷進行系統的分解，做到服務的獨立演化。當然當時也有困惑：當所有的希望都被壓在新架構身上，畢其功于一役，現網老架構停止開發運營時，項目的風險可想而知。做完這個項目，感悟有兩個：一是機會只青睞有準備的人；二是跨部門溝通一定要找到共同的利益點，一定要多換位思考。
4月份，準備調回項目管理組，去云計算基礎架構部做項目經理。在配置管理組的最后一個項目是Jenkins的報表系統，只有一周半時間，最開始準備使用scala，考慮到后續維護最后使用了java，好久沒有編碼了，找回久違的感覺：打印出IDE的快捷鍵，搭建開發環境、測試環境和產品環境，jenkins一鍵自動部署，數據庫版本管理，TDD，一周半的時間就上線第一個版本，最后還不得不贊一下jenkins的rest api。感悟是：感謝一期開發時間只有一周半，這使得我們不斷思考到底我們要做些什么，哪些是我們最緊急最需要的，哪些是錦上添花的，一期上線后，唯一也是最大的好處就是：我們再也不用手動統計和發送構建周報了，每個禮拜一再也不用那么忙碌了。時間盒，很重要。
終于轉回了項目經理，去云計算，牛人聚集的地方。首先仍舊是補課：計算機原理、Linux系統編程、C++ primer，一個都不能少。去了沒多久，出現了一起事故：搜索模塊對云計算SDK的依賴是源代碼依賴，云計算有5個產品，但是一個產品單獨發布時與之前的SDK不兼容，一發布就直接導致了大量搜索模塊的無法編譯。正好由我負責來推動解決這個問題，立了一個發布流程規范化項目：通過規范化發布流程、增加自動化集成測試，減少云計算平臺的發布風險。所有SDK統一打基線發布，發布前必須進行自動化集成測試，server發布時也要與所有SDK版本進行兼容性測試。隨著項目的進行，逐漸融入了這個部門：這是一個工程師文化非常強烈的部門，所有人都在技術上追求卓越，加班到10點以后是非常常見的事情，單元測試覆蓋率令人驚訝的全部達到85%，但是很多同事一聽到規范和流程就頭疼，項目計劃也是比較隨意，延期比較常見，另外因為之前發布版本升級比較隨意，也會經常受到上游兄弟部門的投訴，有很多次出現問題，兄弟部門抱怨云計算平臺不穩定，而仔細檢查后發現很多時候是使用的方式不對，比如查找文件時使用了遍歷。逐漸意識到，部門最大的問題其實是缺少產品運營，大家的關注點全部集中在產品本身上（吞吐量、最大存放文件數、強一致性），或多或少的忽略了用戶。5月下旬，風神項目啟動，項目目標是搭建臺風統一的監控平臺和自動化部署框架，打造一站式的臺風服務。開始在項目中引入項目管理的實踐，WBS是最基本的了，迭代計劃找到開發節奏、回顧、每個迭代結束后都努力向線上發布版本，實現持續交付，工程上則將開發環境與線上環境進行了隔離。效果都還不錯，但思考更多的還是，我們還應該做些什么。產品發布規范化，必須通過自動兼容性測試和周知用戶；集群環境的修改必須可被審計，暫時不能自動化，那么先必須周知部門內同事或結對操作；監控有風神項目，但集群運營、用戶數據、可用率日報也需要發送；開發、測試和線上環境互相隔離；定期和用戶進行主動溝通，了解他們的問題。這段經歷的感悟很簡單：產品的核心在于運營，作為服務部門，我們交付的一定是用戶滿意度而不是產品。
緊跟著，新架構還未上線，組織結構調整來了，喜歡ls的直率：我現在的任務很簡單，就是看到哪里有山頭就把它給平了，所有人都必須聽我的，所有人的思路必須一致。
在敏捷中國大會發表了演講《百年歷史看管理》，這個session足足準備了2個月時間，重新思考了流程、組織結構和人之間的關系。從20世紀初到40年代，管理科學完成了從無到有的第一個階段發展，這個階段最重要的成就就是將管理作為一門科學建立起來，發現了管理的三要素：工作流程、組織結構和人，并振聾發聵的告訴所有人：管理是可以學習的。我們可以看到，所謂管理，都不過是在流程、組織結構和人這三者之中進行權衡調節，管理沒有固定模式，只有不同企業根據不同情況在這三者間權衡裁剪罷了。如果說管理科學的第一個階段是在探討如何正確的做事，如何提高工作的效率，那么50到60年代這二十年管理科學的第二個階段則是在探討如何做正確的事：以顧客為中心、做事之前一定要想清楚做事的目的。管理至此也終于有了一個完整的定義：做正確的事、正確的做事。從70年代開始，管理科學進入第三個發展階段，在這個階段，首先提出的思想就是沒有銀彈，管理是一門藝術需要柔性，接下來就是流程的內涵開始延伸，不再是單純的工作流程，而是面向顧客，強調端到端滿足顧客需求的整個過程，這個過程在全球化背景下越來越強調企業之間的協調、強調整個面向交付生態系統的協調，業務流程的概念被提出。進入新世紀，不管是更合理組織結構的思考（扁平化），還是對人的推崇（喬布斯、創新）抑或是業務流程效率的競爭（供應鏈），都明白無誤的告訴我們：管理只有恒久的問題，沒有終結的答案。
9月份調整到新的部門：搜搜問問。先負責的是后臺組的項目管理。新團隊，老人只有一個，士氣低下，缺少文檔，上百個服務，光維護就非常困難，重寫計劃。從回顧會議開始，持續改進。這段時間的感悟是：提升團隊士氣的最好方式就是幫助大家成功，任何一點成績都值得鼓勵。我們引入了持續集成和自動化發布，鼓勵同事做總結和分享；引入了自動化測試，鼓勵同事做匯報，幫助review ppt；積極的讓大家做有態度的程序員，對產品進行思考和反饋，把團隊精神傳遞到部門經理，讓部門經理進行鼓勵。可以自豪的說，后臺組是現在問問最有戰斗力的團隊。還有一點最重要的感悟是：一定是團隊leader決定團隊是否給力，幸運的是，我們有一個非常優秀的leader。
12月份開始負責部門的社區化運營項目。這和今年工作的感悟是一致的，產品的核心在于運營，這正是我想做的。項目立項一定要有一個NB的名字，我們就叫黑暗騎士。這個項目同樣面對很多的挑戰，目前最大的挑戰還是在于人，團隊的信心目前還沒有建立，年后可能還會有人提出離職，而招人又是如此的困難，所以，上班第二天的第一件事是回顧會議。團隊年前第一個版本發的很有挫折感，需求反復修改，開發人員都心灰意冷，所以，感悟是：一份優秀的需求文檔是一切合理計劃的起點。
1月份組織了技術中心的部門年會節目，我們原創的小品《非問勿擾》獲得了二等獎。把新人都變為主角，這也算團隊建設的一部分。
依然在不停思考，對問問來說，我們還應該做些什么。傳統問答模式作為搜索引擎的補充是否已經走到了盡頭？SNS的問答模式是否值得探索？與微博是否有更深的整合方式，或者，它們本身就是一種產品的兩種展現方式？新浪微什么的探索是否還不夠大膽？在移動端，獨立的app沒有前景，如何和微信更有力的結合。
終于到了可以結尾的段落，還有一件事情似乎忘了總結，那就是我們寫了長達四年的那本書《流程的永恒之道-一個工作流和BPM項目的實戰》，什么也不說了，一個例子來說明為什么值得期待：當我們把房管局及各委辦局的數據和流程用BPM全部打通后，客戶卻依舊堅持要手動蓋章走人工流程，BPM實施技術根本就不是瓶頸，瓶頸依舊是人啊。今年上半年一定出版。之所以寫了四年，是因為寫著寫著總覺得知道的越來越不夠，不斷讀書和補充內容，真是，那時年少，無知者無畏，唉。
2013，黑暗騎士崛起！
本文為轉載：原創地址http://www.software8.co/wzjs/cxyyg/2953.html
這項利器是由CRM領域的領導Saleforce發布的。相當于HBase的JDBC。
具體詳見：
https://github.com/forcedotcom/phoenix支持select，from，where，groupby，having，orderby和建表操作，未來將支持二級索引，join操作，動態列簇等功能。
是建立在原生HBASE API基礎上的，響應時間10M級別的數據是毫秒，100M級別是秒。
WireframeSketcher是一個Eclipse 插件，用于創建線框圖，界面模型和UI原型。
項目正式開發前創建原型可以幫助用戶和開發者理解系統，使用WireframeSketcher在Eclipse中創建能夠更好的集成進入你的項目開發流程。
WireframeSketcher 如何工作？它提供了一個pre-drawn，text-driven 預制圖，文本驅動的widgets，能夠展現通用UI界面，你可以拖拽他們進入編輯器迅速畫出你的界面。界面用XML存儲。
- HBASE的SHELL命令使用
- HBASE的JAVA CLIENT的使用
新增和修改記錄用PUT。
PUT的執行流程：
首先會在內存中增加MEMSTORE，如果這個表有N個COLOUMN FAMILY，則會產生N個MEMSTORE，記錄中的值屬于不同的COLOUMN FAMILY的，會保存到不同的MEMSTORE中。MEMSTORE中的值不會馬上FLUSH到文件中，而是到MEMSTORE滿的時候再FLUSH，且FLUSH的時候不會寫入已存在的HFILE中，而是新增一個HFILE去保存。另外會寫WRITE AHEAD LOG，這是由于新增記錄時不是馬上寫入HFILE的，如果中途出現DOWN機時，則HBASE重啟時會根據這個LOG來恢復數據。
刪除記錄用DELETE。
刪除時并不會將在HFILE中的內容刪除，而是作一標記，然后在查詢的時候可以不取這些記錄。
讀取單條記錄用GET。
讀取的時候會將記錄保存到CAHE中，同樣如果這個表有N個COLOUMN FAMILY，則會產生N個CAHE
，記錄中的值屬于不同的COLOUMN FAMILY的，會保存到不同的CAHE中。這樣下次客戶端再取記錄時會綜合CAHE和MEMSTORE來返回數據。
新增表用HADMIN。
查詢多條記錄用SCAN和FILTER。
- HBASE的分布式計算
為什么會有分布式計算
前面的API是針對ONLINE的應用，即要求低延時的，相當于OLTP。而針對大量數據時這些API就不適用了。
如要針對全表數據進行分析時用SCAN，這樣會將全表數據取回本地，如果數據量在100G時會耗幾個小時，為了節省時間，引入多線程做法，但要引入多線程時，需遵從新算法：將全表數據分成N個段，每段用一個線程處理，處理完后，交結果合成，然后進行分析。
如果數據量在200G或以上時間就加倍了，多線程的方式不能滿足了，因此引入多進程方式，即將計算放在不同的物理機上處理，這時就要考慮每個物理機DOWN機時的處理方式等情況了，HADOOP的MAPREDUCE則是這種分布式計算的框架了，對于應用者而言，只須處理分散和聚合的算法，其他的無須考慮。
HBASE的MAPREDUCE
使用TABLEMAP和TABLEREDUCE。
HBASE的部署架構和組成的組件
架構在HADOOP和ZOOPKEEPER之上。
HBASE的查詢記錄和保存記錄的流程
說見前一編博文。
HBASE作為數據來源地、保存地和共享數據源的處理方式
即相當于數據庫中JOIN的算法：REDUCE SIDE JOIN、MAP SIDE JOIN。
@import url(http://www.tkk7.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);
Hadoop/Hbase是開源版的google Bigtable, GFS, MapReduce的實現，隨著互聯網的發展，大數據的處理顯得越發重要，Hadoop/Hbase的用武之地也越發廣泛。為了更好的使用Hadoop/Hbase系統，需要有一套完善的監控系統，來了解系統運行的實時狀態，做到一切盡在掌握。Hadoop/Hbase有自己非常完善的metrics framework, 里面包種各種維度的系統指標的統計，另外，這套metrics framework設計的也非常不錯，用戶可以很方便地添加自定義的metrics。更為重要的一點是metrics的展示方式，目前它支持三種方式：一種是落地到本地文件，一種是report給Ganglia系統，另一種是通過JMX來展示。本文主要介紹怎么把Hadoop/Hbase的metrics report給Ganglia系統，通過瀏覽器來查看。
介紹后面的內容之前有必要先簡單介紹一下Ganglia系統。Ganglia是一個開源的用于系統監控的系統，它由三部分組成：gmond, gmetad, webfrontend, 三部分是這樣分工的：
gmond: 是一個守護進程，運行在每一個需要監測的節點上，收集監測統計，發送和接受在同一個組播或單播通道上的統計信息
gmetad: 是一個守護進程，定期檢查gmond，從那里拉取數據，并將他們的指標存儲在RRD存儲引擎中
webfrontend: 安裝在有gmetad運行的機器上，以便讀取RRD文件，用來做前臺展示
簡單總結它們三者的各自的功用，gmond收集數據各個node上的metrics數據，gmetad匯總gmond收集到的數據，webfrontend在前臺展示gmetad匯總的數據。Ganglia缺省是對系統的一些metric進行監控，比如cpu/memory/net等。不過Hadoop/Hbase內部做了對Ganglia的支持，只需要簡單的改配置就可以將Hadoop/Hbase的metrics也接入到ganglia系統中進行監控。
接下來介紹如何把Hadoop/Hbase接入到Ganglia系統，這里的Hadoop/Hbase的版本號是0.94.2，早期的版本可能會有一些不同，請注意區別。Hbase本來是Hadoop下面的子項目，因此所用的metrics framework原本是同一套Hadoop metrics，但后面hadoop有了改進版本的metrics framework:metrics2(metrics version 2), Hadoop下面的項目都已經開始使用metrics2, 而Hbase成了Apache的頂級子項目，和Hadoop成為平行的項目后，目前還沒跟進metrics2，它用的還是原始的metrics.因此這里需要把Hadoop和Hbase的metrics分開介紹。
Hadoop接入Ganglia:
1. Hadoop metrics2對應的配置文件為：hadoop-metrics2.properties
2. hadoop metrics2中引用了source和sink的概念，source是用來收集數據的, sink是用來把source收集的數據consume的（包括落地文件，上報ganglia，JMX等）
3. hadoop metrics2配置支持Ganglia:
#*.sink.ganglia.class=org.apache.hadoop.metrics2.sink.ganglia.GangliaSink30
*.sink.ganglia.class=org.apache.hadoop.metrics2.sink.ganglia.GangliaSink31
*.sink.ganglia.period=10
*.sink.ganglia.supportsparse=true
*.sink.ganglia.slope=jvm.metrics.gcCount=zero,jvm.metrics.memHeapUsedM=both
*.sink.ganglia.dmax=jvm.metrics.threadsBlocked=70,jvm.metrics.memHeapUsedM=40
#uncomment as your needs
namenode.sink.ganglia.servers=10.235.6.156:8649
#datanode.sink.ganglia.servers=10.235.6.156:8649
#jobtracker.sink.ganglia.servers=10.0.3.99:8649
#tasktracker.sink.ganglia.servers=10.0.3.99:8649
#maptask.sink.ganglia.servers=10.0.3.99:8649
#reducetask.sink.ganglia.servers=10.0.3.99:8649
這里需要注意的幾點：
(1) 因為Ganglia3.1與3.0不兼容，需要根據Ganglia的版本選擇使用GangliaSink30或者GangliaSink31
(2) period配置上報周期，單位是秒(s)
(3) namenode.sink.ganglia.servers指定Ganglia gmetad所在的host:port，用來向其上報數據
(4) 如果同一個物理機器上同時啟動了多個hadoop進程(namenode/datanode, etc)，根據需要把相應的進程的sink.ganglia.servers配置好即可
Hbase接入Ganglia:
1. Hbase所用的hadoop metrics對應的配置文件是: hadoop-metrics.properties
2. hadoop metrics里核心是Context，寫文件有寫文件的TimeStampingFileContext, 向Ganglia上報有GangliaContext/GangliaContext31
3. hadoop metrics配置支持Ganglia:
# Configuration of the "hbase" context for ganglia
# Pick one: Ganglia 3.0 (former) or Ganglia 3.1 (latter)
# hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=10.235.6.156:8649
這里需要注意幾點：
(1) 因為Ganglia3.1和3.0不兼容，所以如果是3.1以前的版本，需要用GangliaContext, 如果是3.1版的Ganglia，需要用GangliaContext31
(2) period的單位是秒(s)，通過period可以配置向Ganglia上報數據的周期
(3) servers指定的是Ganglia gmetad所在的host:port，把數據上報到指定的gmetad
(4) 對rpc和jvm相關的指標都可以進行類似的配置
REGIONS SERVER和TASK TRACKER SERVER不要在同一臺機器上，最好如果有MAPREDUCE JOB運行的話，應該分開兩個CLUSTER，即兩群不同的服務器上，這樣MAPREDUCE 的線下負載不會影響到SCANER這些線上負載。
如果主要是做MAPREDUCE JOB的話，將REGIONS SERVER和TASK TRACKER SERVER放在一起是可以的。
原始集群模式
10個或以下節點，無MAPREDUCE JOB，主要用于低延遲的訪問。每個節點上的配置為：CPU4-6CORE，內存24-32G，4個SATA硬盤。Hadoop NameNode, JobTracker, HBase Master, 和ZooKeeper全都在同一個NODE上。
小型集群模式（10-20臺服務器）
HBase Master放在單獨一臺機器上, 以便于使用較低配置的機器。ZooKeeper也放在單獨一臺機器上，NameNode和JobTracker放在同一臺機器上。
中型集群模式（20-50臺服務器）
由于無須再節省費用，可以將HBase Master和ZooKeeper放在同一臺機器上, ZooKeeper和HBase Master要三個實例。NameNode和JobTracker放在同一臺機器上。
大型集群模式（>50臺服務器）
和中型集群模式相似，但ZooKeeper和HBase Master要五個實例。NameNode和Second NameNode要有足夠大的內存。
HADOOP MASTER節點
NameNode和Second NameNode服務器配置要求：（小型）8CORE CPU，16G內存，1G網卡和SATA 硬盤，中弄再增加多16G內存，大型則再增加多32G內存。
HBASE MASTER節點
服務器配置要求：4CORE CPU，8-16G內存，1G網卡和2個SATA 硬盤，一個用于操作系統，另一個用于HBASE MASTER LOGS。
HADOOP DATA NODES和HBASE REGION SERVER節點
DATA NODE和REGION SERVER應在同一臺服務器上，且不應該和TASK TRACKER在一起。服務器配置要求：8-12CORE CPU，24-32G內存，1G網卡和12*1TB SATA 硬盤，一個用于操作系統，另一個用于HBASE MASTER LOGS。
ZOOPKEEPERS節點
服務器配置和HBASE MASTER相似，也可以與HBASE MASTER放在一起，但就要多增加一個硬盤單獨給ZOOPKEEPER使用。
-Xmx8g—設置HEAP的最大值到8G，不建議設到15 GB.
-Xms8g—設置HEAP的最小值到8GS.
-Xmn128m—設置新生代的值到128 MB，默認值太小。
-XX:+UseParNewGC—設置對于新生代的垃圾回收器類型，這種類型是會停止JAVA進程，然后再進行回收的，但由于新生代體積比較小，持續時間通常只有幾毫秒，因此可以接受。
-XX:+UseConcMarkSweepGC—設置老生代的垃圾回收類型，如果用新生代的那個會不合適，即會導致JAVA進程停止的時間太長，用這種不會停止JAVA進程，而是在JAVA進程運行的同時，并行的進行回收。
-XX:CMSInitiatingOccupancyFraction—設置CMS回收器運行的頻率。