傳統企業的運維之痛

• 2019 年 11 月 20 日
• 筆記

首先必須要講，這個運維之痛是有前提的：

1、頻繁交付高質量的軟件是研發、測試、運維的核心職責，運維並願意承擔持續改進的職責。

2、運維在交付的「最後一公里」看到了問題，並 願意為此提出改進方案，並推動落實之。

很榮幸，自己藉助優維創業的機會，很廣泛的接觸了傳統企業，其中覆蓋了多個行業，從金融到保險和證券、從物流到電力與運營商、從政府到航空等等。越深入接觸，越能感受到一些詞語在內心的碰撞：人肉vs平台、突破vs束縛、流程vs創新、持續改進vs責任分離等等。

很有意思的現象，當我們對中國的宏觀問題不斷的深入探討的時候，最後都歸結成制度的問題，那麼運維之痛是否也有此類根源性？運維之痛到底是因為外部原因還是內部原因引起？運維真的只能安於現狀沒法突破么？

運維之痛1：人肉 vs 平台

人肉不是傳統運維的當下過失，是過去的延續。在早期，運維的很多能力建立在少量的高可用硬件對象之上，平台化的需求很弱。另外，閉源的軟件生態，給平台化的建設增加難度，而這些歷史債務，並不是一下就能丟下的。留給傳統企業的時間並不是那麼充足，開放平台和業務的互聯網化帶來的衝擊是非常大的，時間非常的短。這是一個多維衝擊能力，從思維、技術、能力等多個維度。

不過很開心的是，傳統企業運維人對運維平台擁抱非常強烈，從運維自身能力自動化到全流程的持續交付自動化。我也經過和傳統企業的IT部門深入廣泛接觸，大家對運維自動化作為突破口非常認可，更願意以此為原點，單點突破，再全面覆蓋。

運維之痛2：流程 vs 創新

很多人會告訴我，在傳統企業中沒辦法，我們必須通過流程來驅動各個組織角色，確保協同工作。真的如此么？我們在騰訊維護那麼多產品線，沒有流程怎麼做到的？然後真的會混亂不堪么？我和我之前的運維團隊來說，如果你不能保持一個對外的簡單清晰運維界面，那就是我們工作的失職。

流程是我們找不到解決方案的時候，添加的累贅！很榮幸，我了解的傳統企業中，給我上了一趟生動的流程課，此處和大家分享一下。

場景1：服務上線申請

我們都知道根據TOGAF框架，企業中分業務架構、數據架構、技術架構和基礎架構中，你仔細去看看定義，非常的完美。但我覺得這種集中式的垂直劃分，就是問題所在，誰能做到全局的架構設計，特別是面嚮應用端的系統設計。這個時候問題來了，一個研發有個業務上線，首先找到了基礎架構組要服務資源，基礎架構組和研發說，你要和業務、數據架構組先評估一下數據需要，和技術架構評估一下技術架構要求才能確定基礎的資源需求。真要如此複雜么？其實就是一個業務上線而已，我們評估了那麼多的業務容量，就那麼幾個指標而已，訪問量、讀寫、熱點集中度、數據量大小等等，基本上能評估一個業務完整資源需求。這是一個繞圈式的流程設計。

場景2：附加角色

環境搭建太痛苦了，增加一個環境管理組吧；各部門的目標不一致，KPI無法協調，成立一個目標管理組吧；流程沒法協調，成立一個流程組吧；質量不行，成立一個質量管理組吧。我覺得這些都是附加角色，所謂的附加角色，就是在沒有找到實質解決方案的情況下，不斷的添加一些check角色來改進現狀。真的改進了么？沒有，附加角色只會是增加了事務的複雜度和後續的執行難度。

那怎麼辦？這類問題要不斷的問自己，為什麼環境搭建痛苦？環境太多，太複雜了，為什麼複雜？每個業務不一樣？為什麼不一樣？是因為架構不統一，為什麼不統一？….問題的改進，其實就是工具和最佳實踐的不斷組合迭代。

運維之痛3：責任分離 vs 持續改進

沒有比責任分離更糟糕的事情了。在一個問題產生的時候，大家首先不是想着如何尋求更好的解決方案，而是在找這個問題應該由哪個團隊的責任。責任分離可以說是過度流程化的結果，流程設計者們很多都在精心設計責任應該由誰來背。當責任被清晰的界定之後，而後的解決方案也只能落到該團隊上了，自然而然，思維就局限了。

其實應該換個視角，當業務的質量出問題了，持續交付這個鏈條上的所有人都有責任，而基於責任的分析範圍應該更廣泛一些，需要思維上的突破。我們總是怪測試不夠充分，你給到足夠的時間給測試了么？你讓測試早期參與了么？你建立了穩定的技術框架，讓自動化測試更好的覆蓋了么？怪運維的環境部署有問題，你有降低運維部署的複雜度么？怪運維定位問題慢，你有把運維定位故障的複雜度降低么，消除了菜鳥和專家的區別么？反之亦然。

更糟糕的是，當問題變得越來越嚴重的時候，還在想着流程設計得不夠完美。

運維之痛4：組織設計

"設計系統的組織，最終產生的設計等同於組織之內、之間的溝通結構。"–Conway's Law.

不得不說，傳統的職能式的IT組織架構越來越不能滿足互聯網化的業務需要了。基於持續交付打造的全鏈條整合鏈條打破的就是職能邊界，提供的就是面向產品化的服務能力。如果組織不能給新產品上線和老產品快速迭代提供足夠的能力支撐，那麼這個組織一定是冗餘設計的。架構組提供的架構能力只能是一個意向參考，沒有真正的落地實現，這個架構組就是冗餘的；流程組提供的流程能力是減慢了交付速度，這個流程組就應該去思考是否把流程讓位於更優的技術實現。

很容易觀察到的一個效果，複雜的組織設計，最終讓設計出來的軟件複雜，導致問題重重，隨後便不斷的增加附加角色，讓軟件的交付過程主次不分。其實附加角色增加的檢查點並不能起到服務改善的作用，「越早發現缺陷，越早修復成本越低」這個準則需要深刻體會，check機制都是事後的機制，是人肉機制，而自動化的機制必須早期介入。

糟糕的情況，組織設計完全面向問題，而非面向用戶。誰能代替用戶來對IT組織的考核？沒有。但我們的方式恰恰相反，認為考核組就可以，針對每個小組，設計了一些指標。說實話考核組離一線現場太遠了，數據的是非判斷準則都很難建立。

運維之痛5：架構設計

架構設計的問題是一直是核心的技術問題所在。架構設計問題體現在很多方面：

1、不能建立統一的架構標準

架構師在傳統企業中是普遍的存在，而架構規範恰恰不是普遍的存在。很多時候都讓位於業務的複雜需求，認為技術架構標準可以放低。技術架構標準絕不是架構師的呼聲，應該是產品線的統一技術要求。合理的技術架構，會大大提升後續的產品推出速度和演進速度。

2、從代碼依賴到二進制依賴到服務依賴

很多傳統企業的大型軟件之間採用的還是代碼依賴，當一個組件發生變化的時候，這個時候需要整個系統的全量更新。久而久之，更新的代碼影響哪些外部系統，都不知道。這是深度耦合，給後續的測試和運維都帶來了很大的難度。到服務依賴，才能真正的實現架構自治。

3、沒有統一的開發框架

開發框架其實是統一技術標準的最佳手段，是真正的把架構規範落到了可執行層面。傳統企業的架構組應該在這個點上多思考，統一的開發框架到底包含哪些？

4、業務需求優先，非功能性需求次之

要命的是，評估一個研發團隊的績效是從實現業務的功能需求角度去考核的。

5、軟件的服務外購性

外包服務商的能力參差不齊，很難建立統一的標準化。如果只是一些外購的項目，在選型的時候，就很難考慮測試、運維的需要了。見過太多的抱怨，對外包服務商無法強制標準。我覺得基於一個統一開發框架的PaaS化平台也許是這類困境的出路，而這點則需要從上而下建立統一認識了。這個地方做得最好的要屬國家電網了！

傳統企業的運維問題絕不是人的能力問題，是多方因素的綜合結果，因此在尋求解決方案的時候，需要立體的方案。而這一切的基礎是運維首先必須改變人肉運維的現狀，方能觸及更多，這也是當下為什麼企業在廣泛接受運維自動化的原因。