障礙，回滾，降級是軟件開發過程中經常遇到的問題，今天我們來看看他們都涉及到開發的哪些方面，他們之間的關係是怎麼樣的？

障礙

乍一聽這個名詞感覺怪怪的，為什麼給我們的軟件開發過程設計障礙呢？這個障礙是用來對軟件開發過程中的環節和步驟進行監督和管理的。又有人說了，現在不都是敏捷開發了嗎，還需要這樣的監督和管理嗎？回答是“一定需要”。敏捷開發是讓軟件更高效的開發，並不是讓軟件開發極度的自由，不受控制，我們不能允許 cowboy coding在團隊中蔓延。實際上這個“障礙”就是為每個開發環節設置檢查管理的模式幫助每個環節做到我們預期的標準，讓整個過程能夠順利執行。我們來看看哪些方面是我們要關注的吧。

第一，架構審查委員會。大家都知道一個架構一旦被設計出來了以後，就是架構師給大家描述一下他的思路然後程序員就開始往架構裡面填寫內容了。這個場景其實在很多公司都出現過。因為公司技術最好的可能就是架構師了，老闆對技術瞭解不深，下面的程序員可能水平也一般。這就造成了架構師的技術權威性。如果沒有一個審查委員對架構進行審查，特別是大型的項目，會造成架構考慮不周全，不適用的情況。這裡就需要經驗豐富的專家（內外部）來協助驗證架構。

第二，代碼審查。這個比較常見，程序員每天開發完成以後check in代碼。試想一下如果每個人的代碼風格都不一樣，以後維護和解決問題效率就會下降。這裡我們應該制定代碼標準，並且通過程序自動審查和人工審查的方式協助程序員完成合乎標準的代碼。

第三，性能測試。如果我們不能瞭解我們系統能夠承受的業務負載是否能夠滿足我們的業務預期，那麼我們開發出來的軟件恐怕是沒有多少人會用的。所以，這塊的工作是必不可少的。

第四，單元測試。說到這裡，很多程序員都覺得這個是一場噩夢。特別是業務程序員，業務邏輯寫完以後，還有準備那麼多路徑的單元測試，估計這個測試的時間比寫代碼的時間都要多啊。不過這個是保證代碼質量，程序質量的一道屏障，也是考驗程序員功底的地方。

第五，生產監控。一旦我們的程序上到生產環境以後，需要對各個服務，特別是核心服務進行監控。這些服務的健康狀況就等於業務的健康狀況。對他們的監控是運維服務的基礎，也是提高服務質量的基礎。

回滾

這個詞大家一定不會陌生一旦程序發佈失敗，或者變更失敗我們就會提供回滾流程。如果說障礙的管理是預防風險發生的話，那麼回滾就是在風險發生以後的彌補工作。

這裡我們需要明確一個概念就是回滾窗口，他是從版本發佈到第一個服務訪問高峰之間的時間。舉個例子，我們做一次發佈，當應用發佈到服務器的時候，一直到用戶開始大規模訪問的這段時間。如果說這個時間是1小時並且在發佈之後發現應用出現問題，那麼說明回滾窗口的時間是1小時，也就是你的團隊只有1小時用來回滾應用從而恢復系統正常運行。這個時間是需要在發佈之前都預計好的。隨著發佈規模不同，發佈應用重要程度不同，這個時間是不同的。

回滾技術的考慮，詳細各位都遇到過這樣的情況，在回滾應用的時候由於回滾會造成數據庫的更改，讓回滾操作顯得捉襟見肘。新數據庫和老數據庫的差距始終讓我們犯難。有幾個建議可以給大家參考，新數據的擴展儘量放在老數據庫的結構中，例如：同一個數據列承載更多的數據含義。（在業務允許的範圍內）。或者，如果非要新增字段的情況下，讓你的應用（API）同時支持新老兩個庫的操作。讓後就是儘量不要對數據庫字段做修改和刪除的操作。

回滾成本的考慮，有些應用發佈以後發現問題，如果這個問題是馬上可以修復的，這個修復時間在回滾窗口時間內的，可以考慮快速修復並且做hotfix的發佈。在作出這個判斷之前要確定這個問題所牽連的服務，以及這個修復是否會對這些服務造成影響。在做回滾的時候，需要預估這個回滾的時間是否小於等於回滾窗口的時間。或者考慮對一部分的功能做回滾（這裡需要對模塊做嚴格的分割和降級處理做支持。）

降級服務

降級服務實際上是對回滾的一種補充，或者說回滾的一種特殊處理方式。如果我們發佈的時候發現某個服務無法使用了，這個時候回滾的時間又大於回滾窗口定義的時間。那麼我們可以採取針對某個服務降級的處理，通過暫時隔離這個服務保證整個系統的可用性。這個在架構設計上需要先考慮，特別是個別重要的服務，他們作為基礎服務會有很多其他服務分別調用他。一個這個服務不可用需要在調用方設計開關，並且測試當基礎服務/重要服務不工作的情況下。其他服務是否能夠通過兜底數據，或者服務開關保證自身的可用性。