相傳魏文王和名醫扁鵲之間曾經發生過這樣一段對話：
魏文王：「你們兄弟三人，誰是醫術是最好的呢? 」
扁鵲：「大哥最好，二哥差些，我是三人中最差的乙個。」
魏文王：「那為什麼你的名氣最大？」
扁鵲：「大哥治病，是治病於病情發作之前，病人尚未發病即已****，使得他的醫術沒有得到認可，沒什麼名氣；二哥治病，是治病於病情初起時，二哥藥到病除，大家認為二哥善治小病，名氣只在本鄉里；而我是治病於病情嚴重之時，大家看到我或在經脈上穿刺放血，或在患處敷以毒藥以毒攻毒，或動大手術直指病灶，使重病人病情得到緩解或**，所以以為我的醫術高明，名氣因此響遍全國。」
在上面這個小故事中，根據醫生治病發生在病情發展的不同時期可以分為三個階段：
技術人員治理系統猶如醫生治病救人，為了保證系統能夠穩定地對外提供服務，有比較高的可用性，需要關注系統發展的整個生命週期，見微知著，一方面能夠識別軟體開發中潛在的問題，盡早解決；另一方面當系統出現小問題，不要忽視，及時處理；最後當系統發生較大問題時，也能夠使用雷霆手段快速恢復，保證系統可用。
為了提高系統的可用性，這三個階段我們都需要關注，本文會通過分析影響系統可用性的因素，嘗試找出在這三個階段我們需要採取的必要措施。
首先我們來看看維基百科上對可用性的一些定義：
可用性就是乙個系統處在可工作狀態的時間的比例
系統可用性是衡量乙個系統正確地對外提供服務（可工作）的能力。我們通常採用sla（service level agreement）來衡量系統可用性，也就是我們經常聽到的的幾個9，其對應的系統不可用時間可以參照下表：
3個9（99.9%）表示乙個月最多不超過43.8分的不可用時間，對於每月例行停機維護的系統基本很難達到；5個9（99.999%）要求一年內系統不可用的時長不超過5分鐘，聽起來就覺得不可思議。
除了人為原因導致的故障，基礎設施的定期維護，硬體裝置損壞，自然災害等等都會導致系統不可用，因此100%的系統可用性是基本不可能達到的；要提高系統可用性，我們得先分析影響可用性的問題發生的原因和影響，下面根據我的經驗列舉一些會對系統可用性產生較大影響的因素：
人員誤操作
經典如rm -rf . /的操作在日常的開發過程中並不少見，比如：
資料、檔案儲存等無疑是大多數企業的核心資產，涉及到資料的故障往往都是非常大的故障，不僅影響範圍非常大，如果前期沒有足夠的災備準備，是很難在短時間內恢復的，甚至可能無法恢復，造成巨大損失。
雪崩效應
在分布式系統架構下，服務之間需要配合來完成複雜的業務流程，某個服務提供者的不穩定在請求量變大的情況下，會逐步演化成整個系統的雪崩效應。
雪崩效應通常會經歷如下過程：
服務提供者不可用（宕機或效能較差）
服務呼叫者請求量增加（業務量增加、失敗重試、快取穿透等）
服務呼叫者系統資源耗盡，服務呼叫者不可用
雪崩會造成整個系統的癱瘓，以我們的系統曾經經歷了一次雪崩為例，乙個核心服務在沒有**變化的情況下，增加了使用者量（可以理解為對使用者分批開放），在資料基數增大和請求量增大時，服務的介面效能無法滿足需求，陡增的請求量對資料庫了造成非常大的壓力（cpu佔滿），介面全部超時，導致長時間占用api gateway的連線資源，api gateway無法處理其他請求，進而導致了整個系統的癱瘓，如下圖：
本質上來講雪崩的發生是因為服務提供者無法滿足當前業務的高併發需求，同時也沒有很好的應對措施保證系統其他服務的正常運轉。
未經完整測試的版本發布
以上兩類故障的發生通常會引發非常嚴重的問題，但頻率相對較低，而定期的版本發布常常因為沒有經過完整的測試導致線上故障發生，嚴重的情況下也會對可用性產生很大的影響。
隨著系統服務年限的增長，業務的增長讓系統變的越來越複雜，依賴人工的黑盒測試基本上很難覆蓋所有業務場景（我們曾經有乙個開發了3年多的系統，在沒有自動化回歸測試的情況下，每次發布後需要4個測試同學花費2個小時進行唯讀的關鍵場景回歸測試，成本非常高昂），這導致定期的版本發布經常會帶來一些意外的故障，每次發布後都需要有人值班來解決這些故障。
系統間整合測試成本更高，一方面整合測試需要跨多部門進行溝通協調，另一方面整合的一方通常無法知道另一方的實現細節，測試用例很難保證全面。對於關鍵系統的整合，如果修改後沒有充足的回歸測試，上線後很可能導致影響主流程的故障，影響使用者的使用。
基礎設施故障及定期公升級維護
不管是自建基礎設施，還是使用第三方雲服務，基礎設施的故障和定期公升級維護是不可避免的，也是影響系統可用性的關鍵因素。
影響系統可用性的因素很多，以上列舉了一些非常典型的場景，這足以讓我們對影響可用性的因素有乙個非常直觀的理解。為了從可實施的角度討論如何提高系統可用性，這裡不考慮基礎設施硬體故障等不可控因素。
從上面的因素中我們不難發現，有些問題我們可以通過提高工程化能力和優化工作流程解決，但如何將這些工程化能力和流程落地也是乙個非常複雜的問題，因此***會通過技術和團隊兩個視角來看如何才能提高系統的可用性。
從技術視角，要不斷強化工程能力
病發初期
病情嚴重
從團隊視角，要有一支重視技術的團隊
在軟體系統的開發運維過程中，我們有很多手段可以發現問題，如線上故障、監控報警、回顧會議等等，但從根本上解決問題往往非常困難，大多數情況下是頭痛醫頭，腳痛醫腳，到最後結果就是技術債台高聳，線上故障頻發；即便找到了解決問題的辦法，在實施的過程中還會遇到很多問題。
**其原因，可能比較複雜 ，但從團隊視角來看，通常存在團隊對待技術並沒有那麼嚴謹，對待生產環境沒有那麼敬畏，對待自己的**沒有那麼嚴苛。
要提公升系統的可用性，必須要有一支重視技術的團隊，這個團隊應該具備以下特徵：
追求系統的高可用就像乙個人追求身體健康一樣，整個軟體開發團隊自始至終都要秉持愛護軟體系統的心態，在軟體開發的全流程中，時刻保持警惕，通過提高團隊在三個階段中的工程化能力來及時發現和解決系統中存在的問題。
這不單純是個技術問題，善治系統的團隊首先要在團隊內建立尊重技術、工程的文化氛圍，建立團隊行為規範，嚴明紀律，有所為有所不為；在此基礎上，不斷在團隊開發過程中針對問題尋找解決問題的最佳實踐，做且做好正確的事，相信高可用是必然的結果。
文/thoughtworks 麻廣廣
IT系統可用性
it系統可用性重新認識 今天看了一篇關於it系統可用性研究的文章，有些自己的想法，一併記載下來，若以後在此基礎上有新的發現，將及時更新。it系統可用性定義 what it系統中計算機軟硬體，網路等對使用者有效使用和令人滿意的程度。換句話說，盡量縮短因系統崩潰所導致的停機時間。包括確保機器的響應速度，...
系統可用性評估
移動網際網路時代，似乎大家都在強調架構或服務的高可用，那什麼是高可用性呢？首先，我們來了解下什麼是系統的可用性 system usability 即系統服務不中斷執行時間佔實際執行時間的比例，所以高可用性就比較好理解了 系統服務不中斷執行時間佔實際執行時間的佔比更大，換句話說符合我們的預期。其次，系...
可用性測試
工作一直緊張，但今天還是岔出了一件事情，就是對我負責的模組進行使用者可用性測試。兩個小時的測試還是有點收穫，小記之。剛剛從公司的培訓課程中學到了 usability test 沒想到這麼快就用到了實踐中，雖然這次的可用性測試不是很正式的從公司外部請使用者來做，也沒有用單面透視玻璃對使用者行為作 暗訪...