??關注嘉微科技，獲取運維新知識

運維人員的恐慌

最近在微信上經常看到諸如“未來XX年沒有工作是穩定的”、“穩定是最大的不穩定”之類的文章。想想運維領域和IT行業，我還是挺開明的。

運維人員面臨的恐慌恐怕是前所未有的：

1、從外部來看，IT架構正在逐漸云化，從IAAS到PAAS；運維人員的市場需求不再像以前那樣，一定深度領域的運維專家可以占領所有市場；

2、從內部來看，公司的新業態、數字化轉型、運營似乎永遠離運維人員很遠，而技術棧不斷增加、規模不斷擴大、數量有多少是運營商必須接受的另一個挑戰。

如何從內外部環境的變化中贏得運維組織的轉型和運維人員價值提升的需求是必須面對的課題。

康威定律視角下的運維組織變遷

每個人都在談論轉型，但問題是：在哪里？

運維組織的變革，離不開運維架構和制度的變革。在某種程度上，康威定律也可以用來指導操作結構。

第一定律

.

一個組織的溝通方式是通過系統設計來表達的。

第二定律

沒有時間做正確的事，但有時間重新做。

沒有多少時間可以完美地完成一件事，但總有時間完成一件事。

第三定律

從a的圖到它的圖有一個。

線性系統和線性組織結構之間存在異態的可能性。

第四定律

大的比小的更傾向于 。

大系統組織總是比小系統更容易分解。

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

第一：傳統的施工方法。

根據市場上所需的功能模塊和常用產品不斷積累運維技術架構，后期對接功能和數據，實現數據統一運營的大目標。

第二種：平臺搭建方法。

將通用運維能力存儲在平臺中，形成各種原子能力模塊，然后通過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事業部“騰訊智慧陣營”的子品牌（網址：/）。藍鯨是一套基于PaaS的技術解決方案，提供完整的前后端開發框架、調度引擎、公共組件等模塊，幫助業務產品和技術人員快速構建低成本、免運維的支持工具和操作系統；藍鯨是騰訊互娛事業部多年積累的技術運營支撐體系，承擔著百家商家在線運營的使命。

我們可以從IEG事業群的業務特點來探索整個系統是如何誕生的：

1、騰訊IEG游戲運營遇到的業務痛點：

2、轉型的曙光：平臺原子化、抽象與抽象；

藍鯨設計思路：盡可能將單個步驟抽象成一個原子，然后將原子自動化，再通過任務引擎將其連接成“字符串”或“樹狀分支結構”，實現全自動化這樣做的好處是它不依賴于業務類型、架構或場景。只要可以手動操作維護，就可以做到無人值守。

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

抽象各種運維和操作場景，抽象出最典型的需要業務配置和作業執行的場景。此時藍鯨配置平臺和作業平臺創建完成，抽象的原子平臺成為PaaS能力池的能力塊。

4、原子平臺集成；

原子平臺越來越多，但原子平臺最終是用于消費和調用的。因此，進行了整體整合。整體架構采用SOA架構，服務模塊靈活采用微服務架構。

5、平臺開發模式，讓運維應用自動增長；

這個階段是真正的運維發布，平臺準備好，搭建服務SaaS開發生命周期的系統組件，讓運營場景實現SaaS自我成長。藍鯨平臺最大規模運行在1000多個SaaS服務上，服務于各種業務的各種運維和運營場景，這些場景都是運維人員做的。

6、一個自我成長的運營平臺，可以“完美解決”運維的復雜性和多樣性：

7、IEG事業群最終內部運營技術架構：

以上是作者對運維組織轉型的理解和分析。歡迎討論交流服務器運維技術，謝謝！