關注嘉爲科技，獲取運維新知
運維人員的恐慌
最近在微信經常看到“未來XX年，沒有什麼工作是穩定的”、“穩定是最大的不穩定”等等文章，聯想到自己所在的運維領域和IT行業，頗有感悟。
運維人員面臨的恐慌，恐怕是空前的：
1、從外部來看，IT架構逐步雲化，從IAAS到PAAS；市場對運維人員的需求已經不像之前，某個縱深領域的運維專家就可以市場通吃了；
2、從內部來看，公司新的業務形態、談數字化轉型、談運營，好像永遠離運維人員很遠，而不斷增加的技術棧、不斷增長的規模和數量，卻又是運維人員必須接受的挑戰。
如何從內外部環境變化中贏得運維組織轉型，和運維人員價值提升的訴求，是迫不得已又必須面臨的話題。
從康威定律看運維組織的變化
大家都在談轉型，問題在於：轉去哪裏？
運維組織的轉型離不開運維架構和體系的變化，康威定律某種程度上也可以用來指導運營架構。
第一定律
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化設計：打造承載所有運維和運營功能的統一平臺，平臺具備接入資源層、運維服務能力提供和可承載自定義開發應用的能力，平臺具備強大的延展性和服務支撐性。
場景工具化：將所需的運維功能進行場景化，以工具化的方式運行在統一平臺上，調用底層平臺所提供的能力服務，實現功能敏捷迭代，功能之間不再以煙囪式方式構建。
這兩種運營架構或許可以給我們一些啓示：
1、組織溝通方式會通過系統設計表達出來。第一種的運營技術架構建設是一種離散式的運維組織溝通方式，每個縱向領域技術組自己進行技術選型，這樣帶來的組織方式就是傳統的方式，公司有不同的運維組：網絡、操作系統、數據庫、辦公應用、業務應用等，但是每個組相對獨立，這種模式在當前的內外部運維環境下就會遇到問題；
2、企業的運維場景往往需要跨系統跨流程跨組織，天然具備個性化、全流程化的特點，這也是當前對運維組織的要求。公司要上線一個自動化發佈系統，提升業務上線效率，這個運維場景需要跨多個運維技術領域（系統、數據庫、應用運維）、有很強的個性化（A銀行與B銀行業未必一樣）；
3、沒有完美，只有更好。組織的轉型沒有一次調整就能解決的，但是與運營技術架構匹配的組織將帶來更大的效能。
轉型藍圖
轉型的目標離不開運維的價值呈現，運維需要從運維支撐提升到增值服務，也就是除了穩定，我還要想想我和我的組織還能多幹點啥？想這些也是需要時間的，因而考慮的重點就是能否通過自動化和標準化釋放運維人員。
示例
運維支撐的職責：
增值服務：
從PaaS化運營技術架構的變化趨勢來看，如果把運維組織當成技術架構來看的話，應該有一個“運維發動機式的組織”，對外輸出運維解決方案。而這個組織在PaaS化的技術運營體系下，我們稱之爲技術運營組。
技術運營組的職責在於：
1、首先利用輸出解決方案和工具的方式，將現有人員日常的運維工作效率提升，例如把日常巡檢、提數、配置管理等運維操作自動化、標準化，且標準化要體現在簡便的WEB交互界面功能上；這樣子運維人員就能得到一定程度的解放，他們就可以作爲運維組的“甲方”，去仔細思考自己的運維如何更穩定，自己是否能考慮一些運營。
2、技術運營組定義好統一的工具開發或場景構建的標準，並構建起流程式的賦能機制，運維逐步轉向運維開發；運維開發定義爲：企業爲了讓IT更好的支撐業務的運行和發展，通過構建運維開發團隊保障SLA和提升效率，更大的發揮IT在業務中的價值。
3、技術運營組不斷提升積累公司一體化運營平臺的能力，從煙囪式系統建設，轉變爲平臺化建設，只有這樣，才能實現更爲高效的數據化運營和智能運營。
4、自生長式的運營模式；授人以魚不如授人以漁，給運維人員做工具則能讓運維水平不斷提升，簡單工作自動化、重複工作標準化。
5、以前的“運維領域專家”可以選擇做“技術運營組”的需求專家，也可以選擇轉向或靠攏數據分析、運營輔助專家；充分考慮個人職業發展：工作項與個人發展吻合了，員工纔會盡全力，做想做的事。例如開發人員-技術專家、架構師，你讓他們去做運維操作，他們或許也能做好，但不會盡全力。
傳統運維組織轉型的問題和風險
傳統運維組織一般有按技術領域（基礎架構或應用）劃分，或按職責範圍（例如執行ITIL組織體系的）劃分。
組織想要轉型，例如要做運營，首要的問題來了：以前的活誰幹？
同時還需要考慮更多的問題：
1、組織轉型與運營技術架構必定是相輔相成的。技術架構支撐組織轉型，組織轉型又能持續豐富運營技術架構。
2、初次投入與成本的問題。轉的過程需要以前的東西仍然穩定，同時又能啓發新的東西，因而需要領導有更爲長遠的視野和堅定的決心。
3、轉的過程所遇到的內外部阻力。從工具文化出發，先解決部分問題，初見成效並呈現價值後，再持續解決問題。
4、是否每個人都能轉型成功？這是需要領導者更爲客觀來看待的問題，以及轉型過程的引導和安撫，讓不同的人員都去做對應程度的提升和轉變。
轉型過程的思路
運維組織轉型的三個維度：流程、個人職業規劃和工具平臺。
傳統組織下運維人員具備各個領域運維技能，保障技術設施運行穩定性，而面對業務更爲敏捷和靈活的要求時，需要運維組織能夠快速響應運營場景的需求，而藉助於PaaS提供的運營場景開發服務，傳統運維組織能夠從保障穩定性上逐步提煉出更高的價值。
不同於業務系統的開發，運營場景的開發是運維人員進行運維開發轉型後能足夠勝任的，而且更懂運維與運營的是實際擁有維護經驗的人，基於平臺化的方式，使得運營場景的構建更爲敏捷，組織能力得以整體提升。
藍鯨研發運營一體化平臺技術架構
藍鯨智雲，簡稱藍鯨，是騰訊IEG事業部“騰訊智營”下的一個子品牌（網址：bk.tencent.com/）。藍鯨是一套基於PaaS的技術解決方案，提供了完善的前後臺開發框架、調度引擎、公共組件等模塊，幫助業務的產品和技術人員快速構建低成本、免運維的支撐工具和運營系統；藍鯨是騰訊互娛事業部沉澱多年的技術運營支撐體系，承擔着數百款業務線上運營的使命。
我們可以從IEG事業羣的業務特點，來探索整體體系是如何誕生的：
1、騰訊IEG遊戲運營所遇到的業務痛點：
有幾乎所有的業務類型：重客戶端遊戲，網頁遊戲，各類官網，移動終端遊戲，大型遊戲平臺；
所有業務之間無關聯：幾百款遊戲相互之間是沒有關係的；
有幾乎所有的流行技術：騰訊遊戲幾百款業務中，大多數是由世界各地開發商開發出來，所使用的開發語言、開發框架、操作系統、數據庫等技術，是沒有直觀規律的；
業務操作單元海量：服務器數量，也就是操作單元，有十餘萬。
2、轉型曙光：平臺原子化，抽象再抽象；
藍鯨設計思路：儘可能將單個步驟抽象爲原子，再將原子自動化，而後通過任務引擎連接成“串”或者“樹狀分支結構”實現全自動化。這樣做的優點在於：不依賴業務類型，不依賴架構，不依賴場景，只要運維手工能做的，都可以做成無人值守。
3、不斷累積原子平臺能力；
把各個運維和運營場景進行抽象，抽象出大部分典型場景都需要獲取業務配置，和進行作業執行，這個時候，藍鯨配置平臺和作業平臺就產生了，而抽象出來的這種原子平臺就成爲了PaaS能力池的能力塊。
4、原子平臺集成；
原子平臺越建越多，但是原子平臺最終都是用來消費和調用的，因而接下來進行整體集成，整體架構上用了SOA架構，而服務模塊上則會靈活使用微服務架構。
5、平臺化開發模式讓運維應用自生長；
這個階段則是真正的釋放了運維，平臺做好了，搭建服務SaaS開發生命週期的系統組件，使得運營場景可落地爲SaaS進行自生長，最大規模時，藍鯨平臺上運行了1000多個SaaS服務於各個業務各個運維和運營場景，而這些場景都是運維人員做出來的。
6、自生長的運營平臺，才能“完美解決”運維和運營的複雜性和多樣性：
支持多語言的開發框架；
SaaS免運維託管；
企業服務總線統一集成；
SaaS運營數據可視化。
7、 最後形成的IEG事業羣內部運營技術架構：
以上爲筆者對運維組織轉型的理解和分析，歡迎探討交流，謝謝！