P

右軍

讀完需要

17

分鐘

速讀僅需 6 分鐘

右軍(于君澤)，螞蟻金服 P9 技術(shù)專家，在 IT 領(lǐng)域從業(yè)超過十五年。對(duì) 高并發(fā)、分布式架構(gòu)、內(nèi)建質(zhì)量、研發(fā)管理有一些心得。維護(hù)公眾號(hào)“技術(shù)瑣話”，合著有《深入分布式緩存》、《架構(gòu)寶典》、《程序員的三門課》等書籍。本文摘取自右軍在中生代技術(shù)社區(qū)的分享。重新編排整理，以饗讀者。

張逸老師曾說，軟件系統(tǒng)的穩(wěn)定性，主要決定于整體的系統(tǒng)架構(gòu)設(shè)計(jì)，然而也不可忽略編程的細(xì)節(jié)，正所謂“千里之堤，潰于蟻穴”，一旦考慮不周，看似無關(guān)緊要的代碼片段可能會(huì)帶來整體軟件系統(tǒng)的崩潰。

本文將和大家聊一聊軟件質(zhì)量穩(wěn)定性問題與求解。

目錄

大話軟件質(zhì)量穩(wěn)定性

1. 舞動(dòng)的黑天鵝

2. 蝴蝶效應(yīng)

3. 墨菲定律

4. 業(yè)務(wù)高速發(fā)展帶來的變化

5. 技術(shù)債問題

6. 人、流程、文檔的博弈

7. 采用不能cover的工具和框架?

8. 復(fù)雜的問題域

9. 質(zhì)量意識(shí)

求解質(zhì)量熵?

1. 運(yùn)用敏捷思想

2. 運(yùn)用系統(tǒng)化的思想

3. 技術(shù)債償還計(jì)劃

4. 內(nèi)建質(zhì)量

5. 不唯新、不唯上、實(shí)踐是檢驗(yàn)真理的標(biāo)準(zhǔn)

6. 復(fù)雜的問題域：專項(xiàng)突破

7. Leader的意識(shí)?

8. 創(chuàng)新解決方案

大話軟件質(zhì)量穩(wěn)定性? ?

1

? ?

舞動(dòng)的黑天鵝

納西姆·尼古拉斯·塔勒布(Nassim Nicholas Taleb)寫了兩部超級(jí)暢銷書《隨機(jī)致富的傻瓜》和《黑天鵝》，并且被譽(yù)為[黑天鵝之父]。何為黑天鵝？

在發(fā)現(xiàn)澳大利亞之前，17 世紀(jì)之前的歐洲人認(rèn)為天鵝都是白色的。但隨著第一只黑天鵝的出現(xiàn)，這個(gè)不可動(dòng)搖的信念崩潰了。黑天鵝的存在寓意著不可預(yù)測的重大稀有事件，它在意料之外并且后果非常嚴(yán)重。

一個(gè)黑天鵝事件，具有這三個(gè)特點(diǎn)：

1. 稀缺、通常史無前例（rarity），
2. 影響很極端（extreme impact），
3. 雖然它具有意外性，但人的本性促使我們在事后為它的發(fā)生編造理由，并且或多或少認(rèn)為它是可解釋和可預(yù)測的。

在 IT 系統(tǒng)、社會(huì)事件尤其是金融市場，[黑天鵝事件]屢見不鮮。列舉著名的黑天鵝事件如下：

在 1933～1934 年，經(jīng)歷過大蕭條之后誕生的羅斯福新政，宣布私人持有黃金為非法，規(guī)定以每盎司 20.67 美元將私人黃金上收，然后由國會(huì)立法將黃金定價(jià)為每盎司 35 美元，美元很快貶值 69%。

2001 年 9 月 11 日上午，美國人剛準(zhǔn)備開始一天的工作，恐怖分子劫持了四架飛機(jī)撞向美國紐約世貿(mào)中心與華盛頓五角大樓。3000 多人在這次黑天鵝事件中喪生，美國的經(jīng)濟(jì)此后一度處于癱瘓狀態(tài)，巨大的經(jīng)濟(jì)損失無法用數(shù)字來統(tǒng)計(jì)。

2013 年 8 月 16 日 11 點(diǎn) 05 分上證指數(shù)出現(xiàn)大幅拉升大盤一分鐘內(nèi)漲超 5%。最高漲幅 5.62%，指數(shù)最高報(bào) 2198.85 點(diǎn)，盤中逼近 2200 點(diǎn)。11 點(diǎn) 44 分上交所稱系統(tǒng)運(yùn)行正常。下午 2 點(diǎn)，光大證券公告稱策略投資部門自營業(yè)務(wù)在使用其獨(dú)立的套利系統(tǒng)時(shí)出現(xiàn)問題。有媒體將此次事件稱為“光大證券烏龍指事件”。

對(duì)于烏龍指的事故復(fù)盤，觸發(fā)原因是系統(tǒng)缺陷，策略投資部使用的套利策略系統(tǒng)出現(xiàn)了問題。該策略投資部門系統(tǒng)完全獨(dú)立于公司其他系統(tǒng)，甚至未置于公司風(fēng)控系統(tǒng)監(jiān)控下，因此深層次原因是多級(jí)風(fēng)控體系都未發(fā)生作用。

向經(jīng)驗(yàn)學(xué)習(xí)的局限性

弗朗西斯·培根就曾經(jīng)發(fā)出這樣的警告：當(dāng)心被我們自己思想的絲線絲絲束縛。無論是“光大證券烏龍指事件，還是泰坦尼克的沉沒，如果業(yè)態(tài)沒有類似的案例，其學(xué)習(xí)的參考是脆弱的，無從學(xué)起。即使有業(yè)界案例，不同組織，不同公司未必?fù)碛邢鄳?yīng)的處置經(jīng)驗(yàn)，那么其實(shí)[自己的思想]，[自己的經(jīng)驗(yàn)]也是非常有局限性的。我們把自己知道的東西太當(dāng)回事了警醒地指出：我們把自己知道的東西太當(dāng)回事了，而不知道的事比知道的事更有意義。只有反常地思考一切，才有可能發(fā)現(xiàn)更多“不知道的事”。

2

? ?

蝴蝶效應(yīng)

上個(gè)世紀(jì) 70 年代，美國一個(gè)名叫洛倫茲的氣象學(xué)家在解釋空氣系統(tǒng)理論時(shí)說，亞馬遜雨林一只蝴蝶翅膀偶爾振動(dòng)，也許兩周后就會(huì)引起美國得克薩斯州的一場龍卷風(fēng)。蝴蝶效應(yīng)的意思是初始條件十分微小的變化經(jīng)過不斷放大，對(duì)未來狀態(tài)也許會(huì)造成極其巨大的影響。

我們來讀一則呂氏春秋，大抵也有這樣的例子。[楚之邊邑曰卑梁，其處女與吳之邊邑處女桑于境上，戲而傷卑梁之處女。卑梁人操其傷子以讓吳人，吳人應(yīng)之不恭，怒，殺而去之。吳人往報(bào)之，盡屠其家。卑梁公怒，曰：“吳人焉敢攻吾邑？”舉兵反攻之，老弱盡殺之矣。吳王夷昧聞之，怒，使人舉兵侵楚之邊邑，克夷而后去之。吳、楚以此大隆。（《呂氏春秋·察微》）]

呂氏春秋里面說個(gè)姑娘因游戲起沖突而引發(fā)了 2 個(gè)國之間的持續(xù)戰(zhàn)爭，比較形象的放大這樣一個(gè)道理：如不能見微知著，則其后果無法預(yù)知。

對(duì) IT 系統(tǒng)而言，對(duì)于非預(yù)期的錯(cuò)誤比如：

1. 非預(yù)期 error
2. 非預(yù)期的調(diào)用抖動(dòng)
3. 極少數(shù)場景下的規(guī)則未被正確處理
4. 錯(cuò)誤的優(yōu)惠處理邏輯
5. 未正確設(shè)置的營銷活動(dòng)
6. ……

如果不具備快速、智能的感知能力，那么可能影響的用戶變多、影響的商戶增加、資金損失增加、業(yè)務(wù)不可用時(shí)間變長…..

3

? ?

墨菲定律

“墨菲定律”是一種心理學(xué)效應(yīng)，是由愛德華·墨菲（Edward A. Murphy）提出的。

主要觀點(diǎn)：

1. 任何事都沒有表面看起來那么簡單；
2. 所有的事都會(huì)比你預(yù)計(jì)的時(shí)間長；
3. 會(huì)出錯(cuò)的事總會(huì)出錯(cuò)；
4. 如果你擔(dān)心某種情況發(fā)生，那么它就更有可能發(fā)生。

墨菲定律在生活中屢見不鮮。比如關(guān)鍵時(shí)刻掉鏈子（那些駕考被教練最看好的精英們，往往會(huì)多補(bǔ)考 2 次！！！），你出去買爆米花的時(shí)候，銀幕上偏偏就出現(xiàn)了精彩鏡頭，所以評(píng)論一部電影如何精彩往往會(huì)用一個(gè)詞：無尿點(diǎn)！

對(duì)于 IT 系統(tǒng)而言，墨菲定律的例子太多了。

舉個(gè)例子，小明在做系統(tǒng)遷移，歷時(shí)半年。小明是一位經(jīng)驗(yàn)豐富的架構(gòu)師，他對(duì)系統(tǒng)遷移過程中的自校驗(yàn)、核對(duì)、切流策略、灰度能力、回滾機(jī)制、容錯(cuò)處理都進(jìn)行了充分的考慮。但是對(duì)于老系統(tǒng)的一種流程處理的缺陷未充分考慮備案或者處理方案。想想，半年很快就過去了，去年才發(fā)生 1 起這樣的特殊規(guī)則，我在新系統(tǒng)上完全規(guī)避了這個(gè)問題…但是不湊巧，這個(gè)特殊規(guī)則不約而至，而老系統(tǒng)還未遷移完…

再說一個(gè)例子，前公司有一個(gè)非常古老的系統(tǒng)，一直活得好好的。但是由于 RPC 調(diào)用中有重試機(jī)制，在網(wǎng)絡(luò)異常的情況可能下會(huì)被觸發(fā)。而該系統(tǒng)對(duì)于重復(fù)請求的機(jī)制處理不是很好，導(dǎo)致如果重復(fù)了，就需要一個(gè)處理機(jī)制。而該系統(tǒng)的處理機(jī)制在 95%的情況下是有效的，而網(wǎng)絡(luò)重發(fā)的概率經(jīng)過經(jīng)驗(yàn)測算是一億分之一。看起來論據(jù)很充分了，真心是小概率事件。但是隨著業(yè)務(wù)的發(fā)展，以及某些未預(yù)期的因素（比如某應(yīng)用超時(shí)的幾率）增大，則重發(fā)的概率也將增大，導(dǎo)致后來這樣的問題連續(xù)幾周都出現(xiàn)了，我們不得不下決心從根本上解決這個(gè)問題。

第三個(gè)例子，是我們團(tuán)隊(duì)的一個(gè)親身經(jīng)歷。某一天有客戶投訴，按理說對(duì)于該問題的處理預(yù)案是有的，并且團(tuán)隊(duì)有充分的備份機(jī)制，好幾個(gè)人都可以解決。But 我們并未按預(yù)期的速度處理好這個(gè)問題。原因是團(tuán)隊(duì)的一位同學(xué)大婚，大家都去迎親去了，TL 同學(xué)只能臨時(shí)把車停到路邊，處理問題。

由于人類認(rèn)識(shí)的局限性、驕傲心態(tài)、問題域的復(fù)雜性、不可把握性等因素，導(dǎo)致軟件從業(yè)人員在處理軟件質(zhì)量穩(wěn)定性方面如履薄冰，你今天志得意滿，明天就可能傷心欲絕。那么軟件質(zhì)量問題的棘手主要有那些因素導(dǎo)致的呢?

我們從黑天鵝事件談到了蝴蝶效應(yīng)、墨菲定律。一言以蔽之為，要把軟件研發(fā)中的質(zhì)量搞好并非易事。質(zhì)量是一個(gè)綜合的大命題，涉及到業(yè)務(wù)準(zhǔn)確性、穩(wěn)定性、可用性等方面。比如 xx 大促，某廠商幾小時(shí)無法交易；收藏夾商品丟失；用戶享受的優(yōu)惠不符合預(yù)期，營銷規(guī)則復(fù)雜難以解釋等。

黑天鵝告訴我們要走出經(jīng)驗(yàn)主義，不要把自己知道的東西太當(dāng)回事了，而不知道的事比知道的事更有意義。蝴蝶效應(yīng)告訴我們要及時(shí)感知問題，止損和熔斷，避免問題范圍擴(kuò)大包括傳染到其它相關(guān)領(lǐng)域。墨菲定律告訴我們，你知道的但是忽略的漏掉終會(huì)出問題，在黎明破曉前！

4

? ?

業(yè)務(wù)高速發(fā)展帶來的變化

那么，我們得思考一下為什么會(huì)這樣。在 N 年前，就有人想把軟件從業(yè)者變成像制造工人一樣的，不斷流水線工作。但是這幾乎沒什么可能，因?yàn)橐鉀Q的問題域太復(fù)雜。雖然業(yè)界有很多規(guī)范、標(biāo)準(zhǔn)、套裝軟件，但是仍然未解決問題之萬一。我們來看一下是如何復(fù)雜的。

以我們的一個(gè) team 為例，7 個(gè)人 1 年做了 400 多個(gè)需求。平臺(tái)能力在不斷發(fā)展，有人說高速公路換輪胎，有人說飛機(jī)飛行換引擎，這樣的事情也沒少干。大家都知道滿足需求，實(shí)現(xiàn)業(yè)務(wù)價(jià)值是軟件的天職，至于為了更好適應(yīng)未來發(fā)展的平臺(tái)化能力也好，新特性也好只能在業(yè)務(wù)發(fā)展的過程中做掉。

在這么多需求的過程中，除了技術(shù)以外，對(duì)于業(yè)務(wù)包括規(guī)則要有深度把握，包括上下游的一些問題。如有評(píng)估不到位，問題就大了。分析到設(shè)計(jì)階段的缺失，到代碼、測試、發(fā)布這些階段可能一如既往的缺失了。早些年，某些系統(tǒng)已經(jīng)復(fù)雜到只有 1-2 個(gè)人能搞懂部分了，幸好這些系統(tǒng)今天都完成了拆分和治理。

5

? ?

技術(shù)債問題

技術(shù)債務(wù)是由 Ward Cunningham 在 1992 年的報(bào)告中創(chuàng)造的一個(gè)比喻，被定義為當(dāng)我們有意或無意地做了錯(cuò)誤的或不理想的技術(shù)決策所累積的債務(wù)。它和金融債務(wù)非常相似。一個(gè)人貸款了就會(huì)產(chǎn)生債務(wù)。如果他定期還款，那么所創(chuàng)建的債務(wù)是可以接受的，不會(huì)產(chǎn)生進(jìn)一步的問題。但是，如果他不還款，就會(huì)以利息作為懲罰，并隨著不還款次數(shù)的增加而增加。如果這個(gè)人很長一段時(shí)間不能支付任何款項(xiàng)，那么應(yīng)計(jì)利息使得他更難以償還債務(wù)。在極端情況下，該人不得不宣布自己破產(chǎn)。

為了快速做業(yè)務(wù)，采取簡單粗暴的方案是大家表示支持的。[臨時(shí)方案]的毛病不在于這 2 個(gè)月臨時(shí)了，而在于這個(gè)臨時(shí)上線之后，再無人管了，俗稱[有人生、沒人養(yǎng)]。1 年如果做 5 個(gè)臨時(shí)方案，就等于欠了 5 筆債務(wù)。欠債并不可怕，怕的是沒有償還計(jì)劃，或者借口沒有時(shí)間，或者接口等業(yè)務(wù)不那么高速發(fā)展的時(shí)候。吊詭的是好的業(yè)務(wù)一定是永遠(yuǎn)都沒有時(shí)間的，而差的業(yè)務(wù)確實(shí)不用發(fā)展了，因?yàn)楸幌戮€了，或者整個(gè)公司 close 了。So，珍惜高速發(fā)展的業(yè)務(wù)，記得去更換引擎，償還債務(wù)，欠的，遲早要還的。有關(guān)技術(shù)債，推薦當(dāng)當(dāng)史大官人在周評(píng)比中名列前茅的文章：當(dāng)技術(shù)宅遇上技術(shù)債，我個(gè)人覺得是這方面有調(diào)皮調(diào)性的好文章。

6

? ?

人、流程、文檔的博弈

人、流程、制度、文化都是需要的。但面對(duì)復(fù)雜的問題域，人類有簡單化思考的傾向。比如某兄弟把手工修改的代碼通過自動(dòng)生成工具覆蓋掉了，這時(shí)我們有 2 種選擇。1 是通過 2 個(gè)目錄來區(qū)分，1 是搞一個(gè)檢查工具來做合并前的 check。這些做法都沒有問題，但是不要都靠腦子去記住。

一個(gè)存在 3 年以上的產(chǎn)品，當(dāng)新人來到的時(shí)候，在第一個(gè)月他們總會(huì)提一個(gè)問題，xx 產(chǎn)品咋采取這樣的技術(shù)啊；進(jìn)入慢、一點(diǎn)文檔都沒有；只能看代碼，代碼寫得還不咋的。當(dāng)新人成了老人，他們對(duì)更新的新人解答的時(shí)候，會(huì)說我們當(dāng)年更慘，只有看代碼是靠譜的。對(duì)了，小強(qiáng)是非常了解某一塊的，有問題找他，比看文檔有用。我們不得不承認(rèn)的事實(shí)包括：

1. 寫多少文檔，如何維護(hù)[活文檔]仍是一個(gè)大問題
2. 關(guān)鍵時(shí)刻靠人傳、幫、帶，靠傳承

7

? ?

采用不能 cover 的工具和框架

技術(shù)人員有采用新工具、新語言、新開源產(chǎn)品的追求。當(dāng)全棧、多語言風(fēng)潮席卷各社區(qū)的時(shí)候，不羅列一堆名詞真心都不好意思出來打招呼。另外還涉及到技術(shù)帶頭人的偏好問題。

某電商的朋友這樣講述了他們的故事：......可能更多時(shí)候是業(yè)務(wù)方變動(dòng)太大，因?yàn)閯?chuàng)始人不懂技術(shù)。然后這種模式?jīng)]有可借鑒的，因此在業(yè)務(wù)上一直都是在變動(dòng)，然后就形成了一種業(yè)務(wù)混亂的感覺......后來，招了 CTO，CTO 是以前做移動(dòng)語音云平臺(tái)的，他們都是用數(shù)據(jù)庫 oracle 來做業(yè)務(wù)，因此來公司后，改第二版時(shí)候把大量的業(yè)務(wù)邏輯轉(zhuǎn)移到數(shù)據(jù)庫里用存儲(chǔ)過程來解決，現(xiàn)在的系統(tǒng)就是亂七八糟了。此為 CTO 經(jīng)驗(yàn)偏好癥！

另外，組織架構(gòu)、業(yè)務(wù)架構(gòu)和技術(shù)架構(gòu)息息相關(guān)。銀行的某兄弟使用 ESB 之后，如是說，esb 核心的理念還是服務(wù)化，但是我們行里實(shí)際情況，服務(wù)的梳理一開始就沒做好，而且從目前的組織架構(gòu)來說也很難有起色（服務(wù)梳理這塊主要靠科技，業(yè)務(wù)參與程度太低），而且所有服務(wù)的發(fā)布都是通過 esb，造成 esb 這邊是個(gè)開發(fā)熱點(diǎn)。而且，服務(wù)化要業(yè)務(wù)參與進(jìn)來還需要大 boss 那邊驅(qū)動(dòng)了～銀行的業(yè)務(wù)很多時(shí)候都是打太極，只管各自的一畝三分地...

一般的文章也好，分享也好。多是講成功的 case，講講走過的彎路其實(shí)對(duì)于廣大人民群眾是更喜聞樂見的。[雪球服務(wù)化實(shí)踐歷程] 這篇文章談到他們采用 finagle 的情況，頗有啟發(fā)性。

唐福林演講中說到：“雪球的 scala 技術(shù)團(tuán)隊(duì)免不了有一些人員更替，有轉(zhuǎn)產(chǎn)品的，有轉(zhuǎn)管理的，有轉(zhuǎn)去做另外的業(yè)務(wù)項(xiàng)目的，導(dǎo)致后面的框架升級(jí)和二次開發(fā)力量嚴(yán)重不足。加上 finagle 自己迭代速度快，向后兼任又差，整個(gè)一個(gè) no zuo no die why you try 的感覺”。于是，唐福林個(gè)人花了差不多兩周的時(shí)間，做了一個(gè)簡單版本 rpc 框架的嘗試。得益于在微博做 motan 框架的經(jīng)驗(yàn)和教訓(xùn)，框架開發(fā)很快，開發(fā)出來后，拿給整個(gè)技術(shù)團(tuán)隊(duì)做討論的時(shí)候，才發(fā)現(xiàn)問題很多：再后來，團(tuán)隊(duì)在針對(duì) rpc 框架的接下來需求的討論過程中，越討論越覺得方向有一些偏：大家對(duì)基礎(chǔ)設(shè)施需求的重點(diǎn)并不是在 rpc 調(diào)用框架，而更多在于：大量的小服務(wù)，開發(fā)業(yè)務(wù)邏輯的便捷性，升級(jí)基礎(chǔ)包的便捷性，單節(jié)點(diǎn)的運(yùn)行狀態(tài)，數(shù)據(jù)收集，監(jiān)控報(bào)警的便捷性等等。于是，在未來，會(huì)把接下來服務(wù)化工作的重點(diǎn)定義成：微服務(wù)化，具體來說，就是開發(fā)并維護(hù)一個(gè)滿足雪球自己業(yè)務(wù)需要的微服務(wù)容器。

免責(zé)聲明：作者并未反對(duì) xxx，xxx，xx。只是舉例說明再好的技術(shù)也要和團(tuán)隊(duì)的知識(shí)體系和能力匹配，同時(shí)要考慮究竟要解決什么，需要什么。

8

? ?

復(fù)雜的問題域

隨著業(yè)務(wù)的發(fā)展，對(duì)于可用性的訴求也越來越高。比如你曾經(jīng)是單機(jī)房部署、然后演變成同城異機(jī)房、最后又發(fā)展到異地機(jī)房。因?yàn)橛挟惖貦C(jī)房，對(duì)于 RPC 的路由復(fù)雜度就增加了，我得知道是路由到那個(gè)機(jī)房的；同樣的，在開發(fā)環(huán)境、線下測試環(huán)境要模擬幾種部署的情況亦是有復(fù)雜度的。

再舉一個(gè)例子，有一個(gè)系統(tǒng)作支付鏈路的規(guī)則決策，起初可能就 4 萬行代碼；后來增加到 8 萬，現(xiàn)在又增加到 10 萬。代碼行增加了，該應(yīng)用的職責(zé)增加了，也可能調(diào)用邏輯的運(yùn)算復(fù)雜度。那么如何保持對(duì)外 API 的 TPS 不降低，RT 不降低？

每次 release 不僅要完成功能用例的構(gòu)建，亦要完成性能的測試。

9

? ?

質(zhì)量意識(shí)

意識(shí)是很重要的，比如值班 oncall，隨時(shí)待命。如果沒有被叫醒或者打不通電話就比較糟糕了。我們一般還有備份 AB 角機(jī)制。著名的朱赟博士有一篇文章就談了 oncall 的故事，叫[工程師 oncall 那點(diǎn)事]。

其實(shí)經(jīng)過分析，80%的線上問題不是那么難的。其本質(zhì)是未遵循規(guī)定動(dòng)作。比如修改了代碼未充分驗(yàn)證。就修改了幾行，咋看都不會(huì)出錯(cuò)。從內(nèi)建質(zhì)量的角度，我們一般有 N 條質(zhì)量防線，一個(gè)問題被遺留到線上，往往有 3 個(gè)以上的措施都失守了。

大家知道，航空飛行是馬虎不得的。最近看到一篇報(bào)紙談飛行作風(fēng)問題，我覺得對(duì)軟件研發(fā)質(zhì)量仍有類比作用和啟發(fā)效果。

文章提到幾點(diǎn)經(jīng)驗(yàn)，頗有借鑒意義：

1. 不忘初心：嚴(yán)格遵守 SOP（標(biāo)準(zhǔn)操作程序）
2. 減少僥幸心理、增強(qiáng)風(fēng)險(xiǎn)意識(shí)
3. 狠抓作風(fēng)養(yǎng)成
4. 嚴(yán)厲處罰無后果違章，既要結(jié)果，又要過程正確

文章深刻的提到，隨著飛行經(jīng)歷的增加，許多程序顯得啰嗦、許多檢查顯得多余、以至于越飛程序越少、多做越簡化且不把規(guī)章當(dāng)回事...

總之，質(zhì)量問題就是達(dá)摩克利斯之劍高懸于空中。你不注意它，它就會(huì)在某一天降落。上述提到的復(fù)雜度問題、業(yè)務(wù)高速發(fā)展、技術(shù)債、對(duì)于工具的掌握能力等都可能為品質(zhì)埋下了隱患。能不能破，如何破？

求解質(zhì)量熵

? ?

在前文中，我們從黑天鵝事件談到了蝴蝶效應(yīng)、墨菲定律。一言以蔽之為，要把軟件研發(fā)中的質(zhì)量搞好并非易事。質(zhì)量是一個(gè)綜合的大命題，涉及到業(yè)務(wù)準(zhǔn)確性、穩(wěn)定性、可用性等方面。比如 xx 大促，某廠商幾小時(shí)無法交易；收藏夾商品丟失；用戶享受的優(yōu)惠不符合預(yù)期，營銷規(guī)則復(fù)雜難以解釋等。

黑天鵝告訴我們要走出經(jīng)驗(yàn)主義，不要把自己知道的東西太當(dāng)回事了，而不知道的事比知道的事更有意義。

蝴蝶效應(yīng)告訴我們要及時(shí)感知問題，止損和熔斷，避免問題范圍擴(kuò)大包括傳染到其它相關(guān)領(lǐng)域。

墨菲定律告訴我們，你知道的但是忽略的漏掉終會(huì)出問題，在黎明破曉前！

我們討論了導(dǎo)致質(zhì)量問題難以掌握把控的原因：

1. 業(yè)務(wù)高速發(fā)展帶來的變化
2. 技術(shù)債問題
3. 人、流程、文檔的博弈
4. 采用不能 cover 的工具和框架
5. 復(fù)雜的問題域
6. 質(zhì)量意識(shí)

為了破解這個(gè)復(fù)雜的問題，我們打算從以下幾個(gè)方面來思考這個(gè)問題。如同沒有銀彈一樣，也沒有萬能解藥。

1

? ?

運(yùn)用敏捷思想

什么是敏捷思想，徐毅大大等知名教練、咨詢師們必然懂得比我得多，有開山立派的，有翻譯多本書籍的，有已服務(wù)萬千客戶的。他們同時(shí)還在理論界辛勤耕耘。接地氣的申導(dǎo)《技術(shù)團(tuán)隊(duì)領(lǐng)導(dǎo)者的軟技能》布道說，敏捷的三個(gè)層次。一是思想，二是組織，三是操作方法。

敏捷宣言如是說：

我們一直在實(shí)踐中探尋更好的軟件開發(fā)方法，身體力行的同時(shí)也幫助他人。由此我們建立了如下價(jià)值觀：
? ? 個(gè)體和互動(dòng) 高于 流程和工具
? ? 工作的軟件 高于 詳盡的文檔
? ? 客戶合作 高于 合同談判
? ? 響應(yīng)變化 高于 遵循計(jì)劃
? ? 也就是說，盡管右項(xiàng)有其價(jià)值，我們更重視左項(xiàng)的價(jià)值。

敏捷建模（Agile Modeling，AM）的價(jià)值觀包括了 XP（Extreme Programming：極限編程）的四個(gè)價(jià)值觀：溝通、簡單、反饋、勇氣，此外，還擴(kuò)展了第五個(gè)價(jià)值觀：謙遜。至少我們明白了快速反饋有什么好處，做錯(cuò)了做偏了，可以馬上校正。如果瀑布模型式的開發(fā)反饋必然是慢的。此前有一位做醫(yī)療單機(jī)軟件的朋友說，他們半年才發(fā)布一次，可見這里面提升的空間有多大。

申導(dǎo)提及的第二層組織，我理解有組織層的支持，比如 PMO，項(xiàng)目團(tuán)隊(duì)是否按 Scrum 等；

第三層操作方法則是持續(xù)集成、單元測試、TDD 這些具體的實(shí)踐。

2

? ?

運(yùn)用系統(tǒng)化的思想

我理解系統(tǒng)化的思想就是體系、舉一反三、通過類比、抽象、層次化等手段挖掘本質(zhì)。往往出了一個(gè) bug，故障復(fù)盤會(huì)開了，action 有了，但下次又出錯(cuò)了。究其本質(zhì)，我覺得兩點(diǎn)。一是復(fù)盤的內(nèi)容 focus 在單個(gè)事件，對(duì)于更體系的影響洞察不夠。二是未持續(xù)學(xué)習(xí)，對(duì)于問題是不情愿的承擔(dān)。

談到學(xué)習(xí)，想起大衛(wèi)張《瑯琊訪談錄》引用的一張圖。太多人對(duì)這種發(fā)生的改變持抵抗態(tài)度。如同薩提亞改變模型所示，當(dāng)我們適應(yīng)了老的狀態(tài)，遭遇到改變時(shí)，我們會(huì)經(jīng)歷抵抗、混亂、改變主意、重新上路等過程，最后到達(dá)新的狀態(tài)。此前我們團(tuán)隊(duì)通過深度復(fù)盤這一實(shí)踐讓鮮血直接噴灑出來，通過大約 1 年的持續(xù)聯(lián)系終使我們對(duì)于問題的認(rèn)知【包括對(duì)于故障】，以及擔(dān)當(dāng)力都上了一個(gè)臺(tái)階。

引用地址：http://davidzhang33.blog.51cto.com/3095817/1129749/

3

? ?

技術(shù)債償還計(jì)劃

技術(shù)債務(wù)是由 Ward Cunningham 在 1992 年的報(bào)告中創(chuàng)造的一個(gè)比喻，被定義為當(dāng)我們有意或無意地做了錯(cuò)誤的或不理想的技術(shù)決策所累積的債務(wù)。它和金融債務(wù)非常相似。一個(gè)人貸款了就會(huì)產(chǎn)生債務(wù)。如果他定期還款，那么所創(chuàng)建的債務(wù)是可以接受的，不會(huì)產(chǎn)生進(jìn)一步的問題。但是，如果他不還款，就會(huì)以利息作為懲罰，并隨著不還款次數(shù)的增加而增加。如果這個(gè)人很長一段時(shí)間不能支付任何款項(xiàng)，那么應(yīng)計(jì)利息使得他更難以償還債務(wù)。在極端情況下，該人不得不宣布自己破產(chǎn)。

前一段在一個(gè)討論中，關(guān)于技術(shù)債務(wù)有 4 個(gè)有趣的觀點(diǎn)。

1. 由于技術(shù)人員水平不行，意識(shí)不夠，所以越寫越爛。
2. Developer 都有一顆積極向上的紅心，但是他們不知道如何做才是好的。
3. 上行下效，沒有靠譜的 Leader，架構(gòu)師，大家都是懶惰的，不想去還債。
3. 華為的同學(xué)表示，永遠(yuǎn)的業(yè)務(wù)壓力；其實(shí)所有公司都一樣滴，趕著交付，那有時(shí)間去清償。

關(guān)于債務(wù)清償，總結(jié)了務(wù)實(shí)接地氣的幾個(gè)思路。

1. 構(gòu)建質(zhì)量保障體系，讓我有勇氣動(dòng)手動(dòng)刀。比如接口測試、單元測試，通過 CI 持續(xù)反饋，這樣我有 50%的勇氣來做重構(gòu)。
2. 對(duì)于遺留系統(tǒng)，沒出問題的地方，你不要?jiǎng)铀３鰡栴}的，修復(fù)并補(bǔ)充測試代碼。如果更進(jìn)一步，對(duì)于高危的功能和模塊可以做定向增強(qiáng)。
3. 招募優(yōu)秀的工程師，好的作風(fēng)和習(xí)慣可以影響整個(gè)團(tuán)隊(duì)。
4. 抓住痛得不行的時(shí)候大作文章。平常說持續(xù)集成，可能團(tuán)隊(duì)成員沒有感受到好處，出 bug 了，再回顧看看；copy-paste 代碼總有一天不能滿足更復(fù)雜的需求，這樣從心理認(rèn)同上，大家覺得必須重寫了。抓住這樣的機(jī)會(huì)，構(gòu)建品質(zhì)高一些的代碼和質(zhì)量防線。改變一個(gè)人是非常難的，抓住這樣的機(jī)會(huì)很重要！

4

? ?

內(nèi)建質(zhì)量

前文談技術(shù)債務(wù)，談反饋都提及到了持續(xù)集成。那么整體來講，內(nèi)建質(zhì)量就是更短構(gòu)建，更快反饋。

同時(shí)，除了正確的做事，還要思辨【做正確的事】。通過 ATDD/引流對(duì)比/串講反串講/評(píng)審/錄制回放驗(yàn)證/接口回歸測試 等手段可以保證需求到設(shè)計(jì)、實(shí)現(xiàn)是否發(fā)生了變形。

內(nèi)建質(zhì)量=正確的做事*做正確的事

5

? ?

不唯新、不唯上、實(shí)踐是檢驗(yàn)真理的標(biāo)準(zhǔn)

就技術(shù)選型而言，不迷信、不唯新、不唯上，建議盡早做小范圍的可行性論證。比如好久前流行的 OSGI，上這個(gè)東西，獲得了什么，風(fēng)險(xiǎn)是什么。引入一個(gè)新的技術(shù)棧就帶來一層復(fù)雜度，而復(fù)雜度有一條天性。復(fù)雜度只能增加，不能減少，就像宇宙中的熵一樣。就如同一個(gè)接口一旦開放使用，就很難把這個(gè)接口停用。一旦以一個(gè)高耦合的方式引入到一種技術(shù)，要調(diào)整或者去除，帶來的成本是幾何級(jí)數(shù)一樣的。

總結(jié)，對(duì)于技術(shù)選型請看看成熟度、團(tuán)隊(duì)人員的掌握程度、收益和風(fēng)險(xiǎn)評(píng)估，一旦陷入泥潭則無異于夢魘之旅。要活得好好的，可以采取可行性論證，基于風(fēng)險(xiǎn)的架構(gòu)設(shè)計(jì)。

6

? ?

復(fù)雜的問題域：專項(xiàng)突破

在文章中提到過，問題域的復(fù)雜度會(huì)導(dǎo)致出 bug 的風(fēng)險(xiǎn)增加。

隨著業(yè)務(wù)的發(fā)展，對(duì)于可用性的訴求也越來越高。比如你曾經(jīng)是單機(jī)房部署、然后演變成同城異機(jī)房、最后又發(fā)展到異地機(jī)房。因?yàn)橛挟惖貦C(jī)房，對(duì)于 RPC 的路由復(fù)雜度就增加了，我得知道是路由到那個(gè)機(jī)房的；同樣的，在開發(fā)環(huán)境、線下測試環(huán)境要模擬幾種部署的情況亦是有復(fù)雜度的。

再舉一個(gè)例子，有一個(gè)系統(tǒng)作支付鏈路的規(guī)則決策，起初可能就 4 萬行代碼；后來增加到 8 萬，現(xiàn)在又增加到 10 萬。代碼行增加了，該應(yīng)用的職責(zé)增加了，也可能調(diào)用邏輯的運(yùn)算復(fù)雜度。那么如何保持對(duì)外 API 的 TPS 不降低，RT 不降低？

每次 release 不僅要完成功能用例的構(gòu)建，亦要完成性能的測試。

那么要如何破呢？對(duì)于第二個(gè)例子而言，除了構(gòu)建功能回歸測試環(huán)境，還需要有性能回歸測試環(huán)境，以保障每次 release 的產(chǎn)品性能是沒有降低的。對(duì)于多機(jī)房這個(gè) case 而言，技術(shù)架構(gòu)要關(guān)注可測試性、易用性。不僅僅考慮復(fù)雜度帶來諸多依賴產(chǎn)品的修改成本，還要考慮易用性，如何測試，甚至是如何方便的，低侵入的測試。因?yàn)橐坏膯螜C(jī)房到多機(jī)房了，問題的外延就翻倍了。

比如一個(gè)定時(shí)任務(wù)會(huì)不會(huì)同時(shí)在 2 個(gè)機(jī)房運(yùn)行導(dǎo)致數(shù)據(jù)重復(fù)；機(jī)房切換時(shí)是否有緩存切換的問題導(dǎo)致業(yè)務(wù)不可用；數(shù)據(jù)復(fù)制延遲帶來的不一致性對(duì)業(yè)務(wù)的影響；對(duì)于就得有數(shù)據(jù)復(fù)制的監(jiān)控、緩存的監(jiān)控、數(shù)據(jù)在全局的唯一性管理策略，業(yè)務(wù)兼容性方案等等。

7

? ?

Leader 的意識(shí)

一個(gè)公司的文化由創(chuàng)始人決定，而一個(gè)團(tuán)隊(duì)的品質(zhì)追求往往由其 Leader 決定。Leader 不自覺的保護(hù)主義，報(bào)喜不報(bào)憂等做法會(huì)讓這個(gè)問題變得嚴(yán)重。見微知著，一葉而知秋。

如果有足夠的意識(shí)，依靠體力至少也能拿過 80 分。團(tuán)隊(duì)成員都是看 Leader。Leader 是看重質(zhì)量，大家就看重；Leader 是欺瞞，他們就欺瞞，Leader 熟視無睹，這個(gè)團(tuán)隊(duì)就壞透了。：）

8

? ?

創(chuàng)新解決方案

Perl 設(shè)計(jì)者在著作 programming perl 中提到:優(yōu)秀的程序員具有三大美德:
懶惰、急躁和傲慢 ( laziness, Impatience and Hubris)
為了減少總能量支出而不遺余力地努力的素質(zhì),就是懶惰;
忍受不了程序執(zhí)行的低效就是急躁;
容不得對(duì)錯(cuò)誤不管不顧就是傲慢。

要發(fā)揚(yáng)程序員的美德，比如對(duì)于規(guī)則系統(tǒng)如果不能構(gòu)建上游上千種場景，就可能思考新的解法；有人說做業(yè)務(wù)系統(tǒng)沒啥追求和挑戰(zhàn)，但是又有滿目蒼夷的 bug，小事不想做，大事做不來。其實(shí)【小事不小】!

最后，推薦一下作者右軍公眾號(hào)技術(shù)瑣話

---

推薦閱讀

?

史海峰：構(gòu)建產(chǎn)業(yè)互聯(lián)網(wǎng)金融系統(tǒng)的正確姿勢

?

阿里合伙人程立：阿里15年，我撕掉了身上兩個(gè)標(biāo)簽

?

揭秘阿里中臺(tái)！一文看懂阿里推薦業(yè)務(wù)的兩大利器 | 贈(zèng)書

?

阿里P9專家右軍：以終為始的架構(gòu)設(shè)計(jì)

??

? ?END ? ?? #接力技術(shù)，鏈接價(jià)值#

點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的阿里P9专家右军：大话软件质量稳定性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。