精益思想指導雲原生下的運維管理變革之路

雲原生不是一個產品，而是一套技術體系和方法論

雲原生的概念在最早由 Pivotal 的 Matt Stine 於2013年首次提出，儘管他提到的不太明確，但內容含義很豐富，也全新定義了計算機技術發展至今的一種新形式。

筆者認可雲原生技術層分為：容器化，微服務，DevOps，持續交付。細分為微服務框架，API框架，Service Mesh，Serveless on Kubernetes、Kubernetes軟體包管理等。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式API。但云原生更像是一種技術體系下的方法論，它的表現形式是擯棄之前的傳統的運維開發框架，透過容器化和 DevOps，微服務架構實現應用彈性伸縮和自動化部署，充分利用雲端計算資源實現最少投入做最大的事情。

雲原生架構體系自研成本很高，因此購買成型的雲原生架構並投入使用是很多非技術型企業的首選。在成型的雲原生下，應用運維更多的應該是貼近業務，為業務系統的架構實現最佳化做出成績，更聚焦需要解決的問題是傳統單體應用如何轉成雲上的服務。

精益思想理論與雲原生的方法論關係

精益思想的關鍵出發點是價值，而價值只能由最終客戶來確定。重要的三個過程需充分思考：

① 從概念到投產的設計過程;

② 從最初提出要求到產品送貨的資訊流動的訂貨過程;

③ 從原材料到客戶手上的物質產品的整個生產過程?

每一步的參與運維都在做什麼?運維在雲原生後要做的事情是更少了還是更多了?IT服務產品-從IT需求、研發、測試、應用運維、資料庫運維、基礎運維最後到上架產品的全套服務，這整個過程中需要擯棄的環節太多了，每個環節都會存在一定形式的浪費。若加了部門牆，那更大的人力和物力浪費就是可見的，對最終的使用者來說，他們並不願意為 IT 的細化分工買單，他們要的只是產品能快速穩定的被購買到。IT部門的細化是否代表著專業度的細分，從精益思想的價值體系分析，並從實際業務的技術支援角度來看，尤其龐大的金融機構，此類的細化反而影響了效率，一定程度上阻礙了雲原生下的運維變革之路。

在外購專案逐漸增加而自制專案逐漸減少的年代裡，真正需要的是有共同利益的各方自願組成的聯合，一起檢視被割裂開來的價值流才能做好IT的全域性服務。因此一切不合理的存在諸如最大的障礙：組織架構的不合理，是首當其衝應該改革和調整去適應市場的變化，才能發揮運維的價值，“知道什麼是真正需要做的事則是必要的，否則價值的定義肯定會被曲解。”

運維管理變革開始

ITIL 運維體系仍是運維管理的經典最佳實踐。恰恰因為專業，所以必須聯合發揮作用。購買來的雲原生(已經打包了基礎設施的一切)能否順利在公司現有的平臺環境上做好業務的支撐，取決於運維的專業度，運維的專業度更多的是需要平臺化的運維支援能力，平臺化的運維能力建設需要建立運維專家團隊，必須是懂業務、熟悉中介軟體、且對資料庫精通的運維且熟悉宣告式 API 的聯合運維體才能更好的在雲平臺上發揮最大效能。

因此運維管理的原則應從幫助業務模組實現基於服務流量(而非網路流量)的策略去提供服務，而無須關注這些服務是基於何種程式語言開發的。業務上線之後，在執行期的大部分時間裡，可能還會遇到各種應用的不確定性和不穩定的情況。當這些非正常場景出現時，業務需要儘可能地保證服務質量，而運維管理為該目標所提供IT技術支援。這樣的團隊能快速全方面的診斷系統並做出判斷，為業務提供最佳解決方案。

總之，適合企業發展的技術才是最好的，標準化是必不可少，但個性化也必須強調，就像業務系統的分核心和非核心繫統一樣，服務從來都是多樣化的。所謂的標準化一定是規劃化相對容易實現的部分且能產生價值的部分，比如依賴工具形成固有的流程等，其餘個性化運維部分就是價值最大的亮點，一定是最難實現的那部分。