從運維技術架構變化初探運維組織轉型

​​關注嘉爲科技，獲取運維新知

 

運維人員的恐慌

最近在微信常常看到「將來XX年，沒有什麼工做是穩定的」、「穩定是最大的不穩定」等等文章，聯想到本身所在的運維領域和IT行業，很有感悟。

 

運維人員面臨的恐慌，恐怕是空前的：

一、從外部來看，IT架構逐步雲化，從IAAS到PAAS；市場對運維人員的需求已經不像以前，某個縱深領域的運維專家就能夠市場通吃了；

二、從內部來看，公司新的業務形態、談數字化轉型、談運營，好像永遠離運維人員很遠，而不斷增長的技術棧、不斷增加的規模和數量，卻又是運維人員必須接受的挑戰。

 

如何從內外部環境變化中贏得運維組織轉型，和運維人員價值提高的訴求，是無可奈何又必須面臨的話題。

 

從康威定律看運維組織的變化

你們都在談轉型，問題在於：轉去哪裏？

運維組織的轉型離不開運維架構和體系的變化，康威定律某種程度上也能夠用來指導運營架構。

 

第必定律

Communication dictates design.

組織溝通方式會經過系統設計表達出來。

 

第二定律

There is never enough time to do something right, but there is always enough time to do it over.

時間再多一件事情也不可能作的完美，但總有時間作完一件事情。

 

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization.

線型系統和線型組織架構間有潛在的異質同態特性。

 

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.

大的系統組織老是比小系統更傾向於分解。

 

咱們來看看運營技術架構的變化。

 

第一種：傳統建設方法。

運維技術架構按所需的功能模塊和市面上通用的產品進行不斷累加，後期進行功能和數據打通，實現統一數據化運營的大目標。

                                             

第二種：平臺化建設方法。

把通用的運維能力存儲在平臺內部，造成各個原子能力模塊，再經過SOA的架構理念進行封裝，將運維所需的場景功能，和平臺的原子能力模塊進行隔離。這樣作的好處在於避免了煙囪式的建設方法，運維的數據和功能獲得有效的治理。

 

平臺PaaS化設計：打造承載全部運維和運營功能的統一平臺，平臺具有接入資源層、運維服務能力提供和可承載自定義開發應用的能力，平臺具有強大的延展性和服務支撐性。

 

場景工具化：將所需的運維功能進行場景化，以工具化的方式運行在統一平臺上，調用底層平臺所提供的能力服務，實現功能敏捷迭代，功能之間再也不以煙囪式方式構建。

 

這兩種運營架構或許能夠給咱們一些啓示：

一、組織溝通方式會經過系統設計表達出來。第一種的運營技術架構建設是一種離散式的運維組織溝通方式，每一個縱向領域技術組本身進行技術選型，這樣帶來的組織方式就是傳統的方式，公司有不一樣的運維組：網絡、操做系統、數據庫、辦公應用、業務應用等，可是每一個組相對獨立，這種模式在當前的內外部運維環境下就會遇到問題；

 

二、企業的運維場景每每須要跨系統跨流程跨組織，自然具有個性化、全流程化的特色，這也是當前對運維組織的要求。公司要上線一個自動化發佈系統，提高業務上線效率，這個運維場景須要跨多個運維技術領域（系統、數據庫、應用運維）、有很強的個性化（A銀行與B銀行業未必同樣）；

 

三、沒有完美，只有更好。組織的轉型沒有一次調整就能解決的，可是與運營技術架構匹配的組織將帶來更大的效能。

 

轉型藍圖

轉型的目標離不開運維的價值呈現，運維須要從運維支撐提高到增值服務，也就是除了穩定，我還要想一想我和個人組織還能多幹點啥？想這些也是須要時間的，於是考慮的重點就是可否經過自動化和標準化釋放運維人員。

 

示例

運維支撐的職責：

 

增值服務：

 

從PaaS化運營技術架構的變化趨勢來看，若是把運維組織當成技術架構來看的話，應該有一個「運維發動機式的組織」，對外輸出運維解決方案。而這個組織在PaaS化的技術運營體系下，咱們稱之爲技術運營組。

 

技術運營組的職責在於：

一、首先利用輸出解決方案和工具的方式，將現有人員平常的運維工做效率提高，例如把平常巡檢、提數、配置管理等運維操做自動化、標準化，且標準化要體如今簡便的WEB交互界面功能上；這樣子運維人員就能獲得必定程度的解放，他們就能夠做爲運維組的「甲方」，去仔細思考本身的運維如何更穩定，本身是否能考慮一些運營。

 

二、技術運營組定義好統一的工具開發或場景構建的標準，並構建起流程式的賦能機制，運維逐步轉向運維開發；運維開發定義爲：企業爲了讓IT更好的支撐業務的運行和發展，經過構建運維開發團隊保障SLA和提高效率，更大的發揮IT在業務中的價值。

 

三、技術運營組不斷提高積累公司一體化運營平臺的能力，從煙囪式系統建設，轉變爲平臺化建設，只有這樣，才能實現更爲高效的數據化運營和智能運營。

 

四、自生長式的運營模式；授人以魚不如授人以漁，給運維人員作工具則能讓運維水平不斷提高，簡單工做自動化、重複工做標準化。

 

五、之前的「運維領域專家」能夠選擇作「技術運營組」的需求專家，也能夠選擇轉向或靠攏數據分析、運營輔助專家；充分考慮我的職業發展：工做項與我的發展吻合了，員工纔會盡全力，作想作的事。例如開發人員-技術專家、架構師，你讓他們去作運維操做，他們或許也能作好，但不會盡全力。

 

 傳統運維組織轉型的問題和風險

傳統運維組織通常有按技術領域（基礎架構或應用）劃分，或按職責範圍（例如執行ITIL組織體系的）劃分。

組織想要轉型，例如要作運營，首要的問題來了：之前的活誰幹？

同時還須要考慮更多的問題：

一、組織轉型與運營技術架構一定是相輔相成的。技術架構支撐組織轉型，組織轉型又能持續豐富運營技術架構。

 

二、初次投入與成本的問題。轉的過程須要之前的東西仍然穩定，同時又能啓發新的東西，於是須要領導有更爲長遠的視野和堅決的決心。

 

三、轉的過程所遇到的內外部阻力。從工具文化出發，先解決部分問題，初見成效並呈現價值後，再持續解決問題。

 

四、是否每一個人都能轉型成功？這是須要領導者更爲客觀來看待的問題，以及轉型過程的引導和安撫，讓不一樣的人員都去作對應程度的提高和轉變。

 

轉型過程的思路

運維組織轉型的三個維度：流程、我的職業規劃和工具平臺。

 

傳統組織下運維人員具有各個領域運維技能，保障技術設施運行穩定性，而面對業務更爲敏捷和靈活的要求時，須要運維組織可以快速響應運營場景的需求，而藉助於PaaS提供的運營場景開發服務，傳統運維組織可以從保障穩定性上逐步提煉出更高的價值。

 

不一樣於業務系統的開發，運營場景的開發是運維人員進行運維開發轉型後能足夠勝任的，並且更懂運維與運營的是實際擁有維護經驗的人，基於平臺化的方式，使得運營場景的構建更爲敏捷，組織能力得以總體提高。

 

藍鯨研發運營一體化平臺技術架構

藍鯨智雲，簡稱藍鯨，是騰訊IEG事業部「騰訊智營」下的一個子品牌（網址：bk.tencent.com/）。藍鯨是一套基於PaaS的技術解決方案，提供了完善的先後臺開發框架、調度引擎、公共組件等模塊，幫助業務的產品和技術人員快速構建低成本、免運維的支撐工具和運營系統；藍鯨是騰訊互娛事業部沉澱多年的技術運營支撐體系，承擔着數百款業務線上運營的使命。

 

咱們能夠從IEG事業羣的業務特色，來探索總體體系是如何誕生的：

 

一、騰訊IEG遊戲運營所遇到的業務痛點：

• 有幾乎全部的業務類型：重客戶端遊戲，網頁遊戲，各種官網，移動終端遊戲，大型遊戲平臺；

• 全部業務之間無關聯：幾百款遊戲相互之間是沒有關係的；

• 有幾乎全部的流行技術：騰訊遊戲幾百款業務中，大多數是由世界各地開發商開發出來，所使用的開發語言、開發框架、操做系統、數據庫等技術，是沒有直觀規律的；

• 業務操做單元海量：服務器數量，也就是操做單元，有十餘萬。

 

二、轉型曙光：平臺原子化，抽象再抽象；

藍鯨設計思路：儘量將單個步驟抽象爲原子，再將原子自動化，然後經過任務引擎鏈接成「串」或者「樹狀分支結構」實現全自動化。這樣作的優勢在於：不依賴業務類型，不依賴架構，不依賴場景，只要運維手工能作的，均可以作成無人值守。

 

三、不斷累積原子平臺能力；

把各個運維和運營場景進行抽象，抽象出大部分典型場景都須要獲取業務配置，和進行做業執行，這個時候，藍鯨配置平臺和做業平臺就產生了，而抽象出來的這種原子平臺就成爲了PaaS能力池的能力塊。

 

四、原子平臺集成；

原子平臺越建越多，可是原子平臺最終都是用來消費和調用的，於是接下來進行總體集成，總體架構上用了SOA架構，而服務模塊上則會靈活使用微服務架構。

 

五、平臺化開發模式讓運維應用自生長；

這個階段則是真正的釋放了運維，平臺作好了，搭建服務SaaS開發生命週期的系統組件，使得運營場景可落地爲SaaS進行自生長，最大規模時，藍鯨平臺上運行了1000多個SaaS服務於各個業務各個運維和運營場景，而這些場景都是運維人員作出來的。

 

六、自生長的運營平臺，才能「完美解決」運維和運營的複雜性和多樣性：

• 支持多語言的開發框架；

• SaaS免運維託管；

• 企業服務總線統一集成；

• SaaS運營數據可視化。

 

七、  最後造成的IEG事業羣內部運營技術架構：

 

以上爲筆者對運維組織轉型的理解和分析，歡迎探討交流，謝謝！