每個軟件開發(fā)人員可能對什么是健康的軟件項目都有自己的想法?？赡苁钱a(chǎn)生了巨大的商業(yè)價值，也可能是解決了某個領(lǐng)域的難題，就我個人而言，如果這個項目可維護(hù)、可運營，就可以稱之為健康的項目。那么關(guān)于可維護(hù)、可運營的項目有什么特點呢？下面我列舉一些更具體的方面。

可估量

估量主要指兩個方面，一是開發(fā)工作量，二是容量明確。

(1) 開發(fā)工作量

軟件項目不同于硬件，唯一不變的就是變化。只要持續(xù)運行就會持續(xù)變化。變化需要對功能進(jìn)行擴(kuò)展，擴(kuò)展就要開發(fā)，開發(fā)就有工作量。有工作量就需要預(yù)估工作量，軟件開發(fā)中的工作量很難估算準(zhǔn)確(棋牌法、多人估算)。如果實際工作量與估計工作量相比的差異小于 15%，則您的估計值非常好。然而，一些軟件項目允許令人驚訝的準(zhǔn)確估計，而其他軟件項目往往會產(chǎn)生令人難以置信的異常值。我不止一次遇到過這樣的異常值，偏差高達(dá) 700%，就好比一個功能看似一天完成，結(jié)果做了七天。

出現(xiàn)預(yù)估不準(zhǔn)確基本都是架構(gòu)設(shè)計存在擴(kuò)展性問題，當(dāng)然也不排除不了解項目內(nèi)部運行機(jī)制而導(dǎo)致的盲目評估。

(2) 容量明確

日常生活中的各種工業(yè)化產(chǎn)品都會有一個說明書或者儀表盤，明確告訴你該產(chǎn)品的能力。比如汽車，承載量2t，時速 140km/h。軟件項目也一樣，應(yīng)該明確說明該項目 core 數(shù) 對應(yīng)的 qps，當(dāng)出現(xiàn)性能問題可以進(jìn)行準(zhǔn)確的容量和資源評估。

可觀測

監(jiān)控其本質(zhì)就是軟件系統(tǒng)運行情況的可視化，具體參考：Prometheus+Grafana的思考和實踐，打個形象的比方，你在開車的時候，你不知道你的時速是多少?那么如何決定什么時候加速?什么時候剎車?什么時候加油?即便如此重要，很多公司，特別是中小企業(yè)基本不會重視監(jiān)控指標(biāo)的建設(shè)，究其原因成本高，短期收益相對較低，所以只能頭疼醫(yī)頭腳痛醫(yī)腳。

在缺少告警機(jī)制的情況下，無法第一時間洞悉到系統(tǒng)發(fā)生故障，只能通過用戶的反饋來獲取，系統(tǒng)運維人員往往也只是充當(dāng)了一個“救火” 隊員，大面積的系統(tǒng)癱瘓往往也會給企業(yè)和用戶帶來極大的損失。通過監(jiān)控，服務(wù)可以在系統(tǒng)受損的第一時間得到反饋，并通過電話/短信進(jìn)行告警，oncall 人員及時處理問題，大大減小了系統(tǒng)故障對企業(yè)和用戶造成的影響，更有可以做到無感知的修復(fù)。

可部署

軟件部署及其自動化程度是另一個關(guān)鍵方面。這與可重復(fù)性密切相關(guān)，但自信的布署也是一個文化問題。如果部署仍然是一件特殊且危險的事情，沒有人愿意負(fù)責(zé)，那么部署問題會成為一個復(fù)雜問題。我了解到很多公司和團(tuán)隊也很重視 CI/CD、DevOps 等文化，但是多數(shù)停留于概念表面，比如通過文檔驅(qū)動部署、千遍一律的人工配置發(fā)布，這種方式看似穩(wěn)妥，其實一種偷懶的表現(xiàn)。因為文檔和人都會犯錯，它不能幫助我們解決軟件部署的根本問題。當(dāng)然持續(xù)部署模型并不適合每個團(tuán)隊或產(chǎn)品，但部署至少必須盡可能自動化、盡可能可重復(fù)且盡可能簡化。

總結(jié)

業(yè)界的發(fā)展歷程來看，技術(shù)的代碼化、標(biāo)準(zhǔn)化、自動化是一個必然的演進(jìn)過程。對于有能力和前景的企業(yè)，在發(fā)展過程中會把技術(shù)棧統(tǒng)一、資源接口統(tǒng)一、底層基礎(chǔ)設(shè)施統(tǒng)一，這個歷程會非常長，從筆者的經(jīng)驗來看，應(yīng)該小步迭代，按照實際效果謹(jǐn)慎執(zhí)行。軟件項目雖然說技術(shù)很重要，但是人、成本、落地場景同樣重要。

所以不能只是考慮光鮮的政績，并沒有有效地解決實際問題。就像最近一段時間提出的 AIOps，這種高度自愈的系統(tǒng)一定是軟件運行的終極目標(biāo)。但這跟軟件工程并不沖突，學(xué)會用科學(xué)的方法實現(xiàn)最大化軟件收益仍然是最重要的。