[i]偶然翻到電腦裡早前寫的一篇帖子，轉過來[/i]
[b]引子[/b]
本周二，***系統一天內三次故障，報警簡訊頻傳。星期三一早，下去協助abc一起分析zzz系統的事故，此時的pmd老大已經連續在公司待了24個小時，接著又跟我們一起做了一天的事故分析工作，然後他還要去向領導層匯報事故處理進展。
這讓我想起了***系統剛剛上線後的情景，系統不斷地冒煙，按下一處起來一處，商戶的**不斷地打到業務人員的手機，快抓狂的業務人員不斷地詢問系統何時可以正常工作，ceo自己也坐到開發人員背後焦急地等待，被巨大的壓力壓到同樣快抓狂的開發人員，一邊擦汗，一邊詛咒這見鬼的程式為什麼一上生產就垮了。
商戶有壓力，因為他們接了快錢，但是收不到款了，買東西的使用者買不了東西，住店的客戶住不了店；公司業務人員有壓力，因為商戶在罵人，因為這個月的指標完不成，提成拿不到；公司高層有壓力，因為商戶可能流失，戰略目標的實現受到威脅，投資人的利益無法得到保證；開發人員有壓力，因為業務人員和高層很生氣，後果很嚴重，因為自己覺得能力不差，怎麼開發出來的系統這麼不爭氣……所有的焦點都指向乙個地方----怎麼才能做好一套軟體系統，它不需要多麼出類拔萃，只要能好好幹活別老添亂就行。
[b]一套亂糟糟的系統[/b]
讓我們來看一眼這套亂糟糟的系統吧----
雖然grasp，solid，kiss，乃至soa之類的設計原則和架構風格已經提出多年，這套系統還是像個大泥團，子系統跟子系統耦合，模組跟模組耦合，資料庫表雜糅在一起；
幾年的時間裡，堆砌到系統中的特性**交叉纏繞，新的修改需要很高的技巧才能進行，系統出點故障，也需要抽絲剝繭地去找原因；
質量堪憂的**，效能極差的sql，應用伺服器和資料庫伺服器廠商或許從來沒想到他們的產品需要面臨這樣系統的考驗；
可以羅列的還有很多……
[b]怎麼會這樣呢[/b]
要說當年開發這套系統的團隊，以及幾年裡維護這套系統的團隊，單從能力上講，我覺得不算太差，有知名的架構師，有強力的管理者，有一群技術能力不錯的開發人員，他們聚在一起，他們的每個人，最初的意願，我以上帝的人格保證，絕對不是想做一套亂糟糟的系統逗大家玩兒的，因為我就是那個團隊中的一員。
但是怎麼會這樣？事情是怎麼被搞砸的呢？
[b]成功需要千萬行**，失敗只需要乙個位元組[/b]
因為少判斷了銀行返回結果的狀態，當年的補單程式導致損失幾百萬，相關干係人降級處理；因為沒有考慮多個節點上quartz的同步，當年的兌換程式一下子多給商戶兌換了幾百萬，幸好及時發現才得以追回（這個bug出在我當時負責的產品中，如果沒有追回，我的生活就會跟現在不同）。
乙個軟體專案從需求階段就會有bug注入進來，到分析（做分析的是個新人）、設計（那個設計人員能力欠點兒）、開發（這個專案的程式設計師正集體跟女朋友鬧彆扭）、發布（發布人員資源太少，手腳並用地做著打包工作）、上線（凌晨一點，上線人員打著哈欠部署），各個環節那些讓人痛恨的bug都有機會悄悄地爬進系統中，在**中作怪；
乃至上了生產以後，應用伺服器，作業系統，資料庫，訊息中介軟體，網路，路由器，機房電力，老化的硬體，這麼多的因素都會導致我們的軟體系統故障乃至癱瘓。
絕對地避免事故很難，事故出現之前怎麼進行預判，事故出現之後又如何把影響降到盡量低。
這樣掰著手指頭一數，做一套並且運營一套能正常工作的軟體系統，要求還真不是乍看起來那麼低。
[b]軟體熵[/b]
熵定律告訴我們，乙個封閉系統內的有性能力總是趨於變成無性能量，一切事物總是從有序趨於無序。軟體系統是這樣，軟體團隊也是這樣。
當年那個***專案團隊在專案之初，跟我們現在的任何專案啟動之初一樣，大家有對專案的責任心，有一套如何做好專案的想法----系統內有設計原則和思路，系統外有軟體過程來護航。但是很可惜，軟體系統的腐壞程度比想象中要快，一年的開發時間，系統還未上線，已經有臭味冒出來了。而經過幾年高變化弱治理的維護，系統越來越顯得亂糟糟；最初的雄心和好意與最終亂糟糟的系統之間的反差顯得那麼不協調，但這確實發生了，就在我們眼前。
歷史總是在重複自己的，我們看到的***系統的故事，就在我們現在的系統/團隊中悄然發生，只是它是那麼地隱蔽，每天繁忙的工作中沒人去關注它，讓它得以不斷積累，擴散，直到不可收拾。我甚至可以想象，如果沒有有效的控制，一年後的我們，會像現在pmd的一些同事一樣，被頻繁的事故弄得壓力重重，黑白顛倒。
據說把乙隻青蛙扔到熱水中，它有機會一下子跳開，但是如果把它放在冷水中然後慢慢加熱，它就沒有逃開的可能了。
[b]教訓是什麼[/b]
說到這裡，還有個問題呢。上面這些所謂的道理，其實是如此地淺顯，當年團隊中的人，怎麼會沒有對策？對此，我看到的實際情況上，軟體腐壞的問題，在很長的時間裡，還真是沒有被足夠重視過，更別提採取嚴格的措施來阻止。
當然，不止是軟體系統腐壞，團隊也會。
要阻止有性能量變成無性能量，必須要有新的能量注入進來，比如，要組織軟體系統的腐壞，需要有架構的治理工作，需要設計評審、**評審；要阻止團隊趨於無序的趨勢，需要有合適的過程方法，氛圍調和和激勵工作，還有更多。
這些實踐在日常的工作中顯得無關痛癢，總會有更緊急的事情比這些更值得做，所以乙個個團隊乙個個產品才會前赴後繼地走著差不多的路。
我們要成為其中的一員，再走一遍麼？
[b]一輛車的感悟[/b]
一輛車，從設計到生產，從生產線到使用者手上，一直到最後報廢，粗略分為兩個階段。在生產線上的時候，生產線的質量決定著最終車子的質量；待到交付到使用者的手上以後，車子自身內建的監控系統需要在汽油不足的時候提示使用者，需要在水溫過高的時候報警，即使安全使用的過程中，也需要定期地進行保養。
一套軟體系統的一生，差不多也是這樣吧。但等一下，軟體系統好像少了點什麼？
[b]軟體生命週期的延續[/b]
在剛入行的時候，許多的資料文件都是這樣定義軟體生命週期：需求-設計-開發-測試-上線，上線（或者發布）似乎是軟體生命週期的終點，至少對很多軟體團隊來說都是這樣，好多人也都是這麼理解的。對照一輛車的一生，可以看到少了什麼。
從需求到交付，軟體系統只是度過了生產線的一段，在接下來的更長的時間裡面，它要對外服務，要演進和變化。我們在軟體的生產過程中，為軟體系統執行期可能面臨的問題做過什麼嗎？為軟體的演進做過什麼嗎？比如，我們是否可以考慮為軟體系統嵌入乙個監控模組來檢測系統的運**況，是否可以考慮在軟體出現故障的時候進行某種程度的故障隔離以實現優雅降級（graceful degradation），是否可以在新的特性**上線時只對部分指定使用者開放……
如果把軟體的生命週期看的長一點，延續到軟體系統的運營，那麼在分析設計和其他好多環節，有更多的事情需要做，這些和後來的運營工作一起，才能真正保證軟體系統的良好運作。
[b]架構藏在**[/b]
軟體架構是乙個出鏡率很高的詞彙，我有時候就會覺察到自己都有點「言必稱架構」。但是架構這東西摸不著看不見，它在**，它真的在發揮作用嗎？
如果單看乙個軟體專案的功能需求，還真是找不到架構的容身之處，需求讓做把椅子，就做把椅子嘛，簡單的很。直到把軟體生命週期延續到運營之後，就會發現好多事情需要考慮，領導層關心系統可用性，業務人員關心系統伸縮性，運營人員關心系統的可操作性，qa關心可測試性，諸多的要求，彙總到乙個專案中，分析設計的難度大大增加，突然發現生活不是電視劇集中描述的那麼簡單純粹，有太多的細枝末節柴公尺油鹽的事情需要關注。
幸好，這裡面好些工作不是需要在每個專案中都做一遍的，把其中可復用的東西彙總起來，就找到了架構；或者說，架構藏在對這一些「額外」需求的處理部分。比如上面提到的優雅降級，如果為特性模組加入超型別，使之可以監聽特定的故障事件從而可以關閉部分特性，比如檢測到資源緊張從而自動關閉部分非核心特性。這是架構應該考慮的東西。
軟體產品從軟體過程這個容器中被孵化出來以後，還應該有另外一套容器來照顧它在執行期的衣食住行吃喝拉撒，前面的容器是軟體過程，後面的容器，我覺得除了更加外圍的軟硬體系統外，就是架構（更多的時候體現到框架中）。
也是基於這個認識，我覺得，我們日常工作中的設計少了點東西，當乙個個本身並不存在設計問題的專案被加到乙個產品中時，最終還是會導致作為整體的系統不可控，不滿足需求。
[b]我們的路，該怎麼走[/b]
這一節，我想應該所有關心怎麼做好我們現在的軟體系統的大家一起來想。為了對抗軟體熵，我們已經在漸漸引入敏捷方法，做設計/**評審，做團隊技術交流，但是在架構方面，我覺得我們還有好多事情可以做。
軟體開發，怎麼才能做好呢？（一）
軟體開發，怎麼才能做好呢？這個題目太大了，好像應該是乙個軟體大師，至少也應該是乙個資深程式設計師應該討論的話題，應該採用的文章題目。而絕不應該是我這個僅僅工作兩年，僅僅做了兩年c開發的小菜鳥應該討論的問題。但是，在這兩年了，我還是有些自己的一點兒體會的，願意分享給大家，也作為我的第一篇csdn部落格...
企業使用的雲計算技術，怎麼才能做好優化？
近年來，隨著雲計算技術的快速發展，雲 已經不是單純的字面意思，而是被賦予了全新的含義。雲計算技術已經成為社會企業必不可少的業務技術，它已經改變了企業儲存和管理資料的方式，同時也改變了企業的業務模式。雲服務由於其出色的便捷性和可靠性而成為增長最快的服務之一。據 富比士 雜誌預計，到2020年，全球雲服...
怎麼才能更專業的做好共享軟體
怎麼才能更專業的做好共享軟體 怎麼才能更專業的做好共享軟體 一 part i 共享軟體業餘者對共享軟體專業者 by 史蒂夫?包林納 手巧軟體總裁 為什麼當大多數共享軟體開發者仍僅有聊聊可數的交易時，某些卻是在財務上異常地成功,他們的銷售收入從微乎其微成長至千百萬美元,我們可以從探索這兩個小組的不同心...