老王亲述：我的运维心路历程
本文根據高效運維專家群友文章整理并發布。歡迎關注“高效運維”公眾號，以搶先賞閱誠意滿滿的各種原創文章。
嘉賓簡介
王津銀
他，曾經從業騰訊、YY、UC等知名互聯網公司
他，維護的微信訂閱號《互聯網運維雜談》每篇文章都有上萬的點擊率！
他，在2015年下半年創立優維科技，公司已成立在業界就引起強烈關注！
以下是老王在《運維前線》群分享實錄，高效運維公眾號授權聯合首發!
開場白
其實開始我是想分享名字服務，這樣才契合肖大師KVM群的氣質，特別是看肖大師的分享，永遠都是技術干貨滿滿，不能拖它后腿。
但是肖大師說，不要啦，就想聽聽運維經歷。這么一來，搞得自己跟一個運維典型似的，不過還真是個典型，后面再告訴你們答案。
再次感謝力哥的邀請，進入老王的嘮叨時刻，老王隔壁干的事情今天咱不說哈。
老王的經歷概述
我自己的幾段工作經歷如下：
經歷發生了一點變化，最近自己創業了，后面再說哈。我把以上經歷分成了幾個階段。
每段經歷有自己的工作內容和收獲。
1、起步階段（廣東普信科技）
第一份工作經歷是研究生畢業之后，加入了一家電信服務商做電信系統研發，當時剛好碰到97電信系統遷移到我們開發新一代的boss系統。在這個過程中，自己參與里面一個電信資源管理系統的研發（CMDB比它簡單多了），后來稀里糊涂就帶團隊。在此過程中，也參與過幾個地方資源新舊系統的割接實施。這段經歷給我帶來一些收獲：
規范意識。電信系統的研發非常規范，從需求到概要設計，詳細設計，數據庫設計都一套規范下來，到到現在我設計庫表結構時候還帶著tb（代表表名）,tf（代表字段名），要知道語句復雜了，這樣標準化很容易查找程序問題的。
方法論的培養。方法論很重要，當年給自己影響最大的就是eTOM模型了，還有NGOSS的系統建設方法論，領域驅動設計等等。
這段經歷，我把自己當成了一個開發者（其實是偽的），當時就興致沖沖去騰訊面試，說要做OSS開發，其實到了騰訊之后，才知道我們那個開發不是開發。不過，騰訊，我還是來了！
2、積累階段（騰訊）
騰訊是我的職業過程最美妙的旅程，從各方面塑造了我，非常感謝騰訊！開始騰訊工作的日子超級苦逼。
剛剛進入騰訊，我天天做發布／自動化構建，它們搞定以后，去做告警值班，然后去做需求。不過每個階段都是順應團隊的需要。
做發布的時候，希望把發布規范和發布平臺建立起來，所以我說我是運維發布做得最好的，手工做，平臺發，梳理流程什么的；
然后告警量太大，無法有效收斂，我和我老大兩個人輪流值班，確保解決方案集中輸出，否則每個人處理告警不能形成解決方案，很快收到成效；
這個階段邁過去之后，變更需求太多，能否再進一步優化，通過需求里面變更場景來提煉運維平臺的建設。很慶幸自己熬過來了。
媳婦熬成婆，終于自己也成了核心員工，核心員工的最大好處就是能接觸到更多的項目，可以多了解更多信息。
再后來去接手存儲運維組的leader崗位，騰訊一個很好的地方就是在你上leader崗位之前，公司會有一系列的領導力課程帶來過度過去，對比說第一家是稀里糊涂。
騰訊的經歷收獲最大，滿滿的：
建立了對運維體系的理解。從ITIL到工具化（還不叫平臺化），從基礎運維到業務運維／存儲運維，從職能運維走向應用運維再到職能運維，自己都有幸參與了全部過程。
建立了互聯網技術體系的理解。我所在的部門把運維按照架構組劃分之后，自己很有幸參與了前端和存儲小組的運維，技術棧非常全面，恰好自己也是核心成員，很多核心項目都有參與，所以便有了更多的體悟和技術的理解。
應和優秀的人一起做事。但是我們web運維小組，5個人，戰斗力超強，推標準化，做平臺，定規范，我記得我11年離開騰訊的時候，交接了服務器接近7K臺給他人?，F在優維的創始人還是來自于當時的鐵三角，信任和配合非常重要的。
苦逼是讓你成長的?？啾剖钦嬲淖屛覀儊沓砷L的，有些人把它看成了機會，有些把它看成了折磨。那真實的苦逼之痛，很多經驗才真正的進入到心里。誰苦逼，誰解決，就是大成之道！
騰訊讓自己對運維了全面的理解，從前端到存儲端，從流程到自動化，從工具到平臺，從運維到技術研發側等等。
3、釋放階段（廣州YY和UC）
離開騰訊，加入廣州YY和后來的UC，當時想把騰訊的運維經驗復制到其它公司，很有意思的經歷。經常有人說“你在大公司成功不代表是你成功，因為資源太多了”。那咱們就出去瞧瞧！
在YY和UC自己帶業務運維和運維研發，所以能夠一體化規劃設計，落地實施。效率奇高，一般所有的系統就是三個月左右上線（監控除外），比如說CMDB／持續部署／itil流程系統等等。監控涉及到老的監控策略遷移，麻煩些
這個過程也有一些總結和思考：
不要太依賴運維研發。一般公司的運維研發資源很缺乏，有些需求可以在業務運維內部消化，其實很多運維人身上的潛能很大，很容易突破屏障。在YY有個大神，用shell腳本實現了這個持續部署在agent端的邏輯；在UC，有個小伙伴，自己從前端到后段研發持續部署，后來連小組的一個妹子都可以在ELK做一些管理開發了。運維小伙伴們潛能無限！
運維能研發就是核心競爭力。老生常談了，不談了，自己去體悟。
一體化的方向思考比單純的運維建設更重要。把研發／測試和運維結合起來一起思考，然后同步建設運維體系，這個效果比單純做運維工具平臺更有效。所以很多時候運維就需要DevOps的思維，DevOps思維之一就是跨界思維。
名字服務中心。這東西我就是喜歡，在YY沒搞定，到UC來，還是把它弄到線上業務去了。
從一開始就研究zk如何做名字服務，還看zk client實現，就是為了實現一個，記得在YY的時候，還在論壇寫過一篇文章，如何把單點調度中心daemon透明化的切換到zk上，開發沒鳥我，其實我更不爽呢。
后來來UC，我還講名字服務中心（搞得跟某種情結似的），和一個架構牛人一說，一拍即可，成功了。上次在一個線下沙龍專門分享了這個主題《名字服務的設計與實現》，后來有人說我是做研發，暗喜。自己有時候有點死磕的勁，這種死磕的勁頭到創業也是如此。
因此我建議在大公司呆久了，一定要出去走走。
UC是一家很棒的公司，執行力超強，我很喜歡這樣的公司。
4、提升階段（創業階段）
我把它概括成我現在的優維創業階段。說說我的創業初衷：就想用互聯網運維這套解決方案來替換掉ITIL的IT管理體系，同時縮短傳統企業到達互聯網運維路徑。可能么？不可能么？反正我知道互聯網＋業務成功了，那么作為IT支撐的互聯網運維也應該是靠譜的。
提升來自于兩個方面，首先是行業的，運維苦逼不要的；其次是自己的，運維屌絲不要的，我們就要做一些改變自己和有趣的事情。改變行業其實是整體運維人的事情，我還不敢說哈。
那么我們現在做哪些有趣的事情呢？我們的運維產品只分成兩塊：自動化（ITOA）和數據化（ITOA），一個a是automation，另外一個a是analytics。自動化聚焦在持續交付，數據化聚焦在分析法（analytics），這塊分智能監控和數據分析，而它們的基礎就是元數據共享化，姑且稱之為CMDB（為啥叫姑且呀）。
今天不分享產品實現和形態了（年后就有SaaS版了），分享幾個有趣的事情吧。
一個是產品方面的。我們為了向客戶有力的證明，我們提供的平臺方案是靠譜的，我們把自身系統架構全部接入了名字服務＋服務染色＋自動化測試，實現了端到端的監控體系。
如果一個互聯網產品自身沒有做到這點，那么他的產品和方案是沒有說服力的。我們希望能傳遞Best Pracetice給客戶，而非僅僅是一個運維平臺本身。
一個是理念方面的。我們把運維平臺的理念做一次完整的重構，從整個體系到每個產品方向，比如說姑且的 CMDB 我們把其理念和使用場景做了一次完整的重構，把CMDB的資源管理管理分成基礎資源管理和業務資源管理，同時找個點結合。
這樣就保證了面向資源中心的CMDB和面向業務的CMDB可以獨立運行，甚至面向業務的CMDB可以不依賴底層的基礎資源CMDB管理。
業務資源管理，我們現在稱之為業務信息管理平臺（BIM），都不叫CMDB了，免得誤導。我們想重定義產品形態！
有趣的東西很多，因為很多過去腦子中的想法一步步變成產品，很多人運維人肯定都想這樣，不是么？
在此搞個小廣告。歡迎大家加入優維哈，我們在廣州和深圳有研發中心隨你挑選加入哈，可以一起做更多有趣的事情！
我的運維之路其實挺折騰的，呆過幾家公司，只因那“胸中燃燒的夢想”放棄了三次股票（騰訊／YY／UC），真的算是一個＊＊運維典型。
我真的呼吁大家一起參與到互聯網運維創業的隊伍中來，大把的機會和廣闊的天地等著你我發揮，真正樹立一個互聯網運維的新型IT服務形態－－－IT運營管理。
其實還有很多運維人為了運維都非常努力，在全力組織全球運維大會，提供一個舞臺給運維人，非常贊，再次感謝老蕭！
歡迎大家前來參加今年3月25-26的全球運維大會·深圳站
http://gops2016-shenzhen.eventdove.com/我到時候還有一個主題分享：題目為“面向IT高性能的精益運維體系”，這次我把內容重構了，更全景的去看精益運維，從理論／框架／實踐／工具／組織等多個角度解讀一下。
最后感謝肖總，感謝幾個微信群連播的同事們，大家辛苦了！
好消息！福利來了
具體的運維平臺從概念／框架／設計到實現，請見老王的PPT《運維時代，全棧DevOps運維平臺的設計與實現》
http://pan.baidu.com/s/1bouculxQ&A
Q1：王總，運維包含的技術太多，太雜，您是如何去學習的？
答：的確技術太多，上次看一個devops技術元素周期表，覺得內容太多了，看著我都有點寒。技術很多，但還是有些方法可以去學習的
第一、運維故障是最好的老師。每次故障發生了，一定不要只是浮于表面的解決，要深層次挖掘原因。
第二、要不斷的打開知識譜系。舉個例子,大家打開top命令，其實在現實cpu占用那一行有很多cpu的占用指標，系統調用，用戶調用，硬中斷／軟中斷。如果你每個知識點走進去，發現很多原理性的東西。
第三、還是要和高手多交流，身邊的很多牛人都是很好的學習資源。
第四、業務運維不建議把自己定位成技術達人。人的精力有限，很難在多個維度上達到最優，但你需要知道遠離，技術特點等等。
Q2：關于運維團隊的建設有什么好的建議么，怎么一步步提升運維的價值的體現？
答： 團隊建設方面首先還是要看你的業務規模，基礎設施情況，這些都決定了你的運維階段。然后團隊的價值觀要有，之前在騰訊提煉的質量／成本／效率／安全很實用，不過你需要在不同的階段，要對以上指標有不同的理解，什么是運維質量，什么是業務質量，什么是資源成本，什么是業務成本等等。
其實團隊建設，還設計梯隊建設，還有一個多樣化建設，需要有女性伙伴，這個是2015年高性能IT組織里面重點提出來的。
Q3：怎么著手做運維標準化和規劃化呢，比如流程規范/配置規劃/數據規范等？
答：關于規范化和標準化，他們本身就是可以標準化和規范化，關鍵是你看到你運維的IT對象層次是什么樣子的，從硬件層次／到OS／到組件／到應用部署／到業務調度（多機房部署），都可以找到具體的運維標準化和規范化的落腳點，除非你對他們運維認識還不深刻。
Q4：故障的原因挖出來的大多是痛點（或者技術債），對于這些問題怎么辦？
答：第一、絕壁把問題留給人或者流程來解決。很多故障發生了，然后“頭疼醫頭”似的找解決方案，比如說交換機故障了，就讓增加交換機的處理效率，從來沒想過核心業務和非核心業務分離，然后讓核心業務跨機柜部署什么的。
第二、把問題轉化成架構優化的絕好機會。其實問題是運維最好的老師，你如果只看到問題的淺層次問題，那看到的是技術債務，你如果看到的是深層次問題，那就是技術優化。哪個架構沒有技術債務呢。
第三，問題需要預防，很多最佳的架構實踐已經指出，我們充耳不聞，就有點不對了，大家可以看看騰訊的海量服務之道。
Q5：你在考慮運維系統架構是從自上而下還是自下而上出發的，從哪些維度評估你的決定？
答：之前我分享過一篇文章講運維自動化的，恰好昨天晚上還在回顧這篇文章。我的觀點還是明確的，系統整體架構的設計一定是自上而下的，需要頂層設計你的框架和原則，然后系統建設可以自下而上，分而治之，逐步實現。
Q6：在實施過程，當前運維體系是否要推倒重建還是優化整改？
答：其實這和技術架構的觀點一樣，是持續迭代，不可能過度設計，也無法超前設計，因此運維體系的完整性是隨著業務規模的變化而變化的，動態的去看。在騰訊，自動化調度系統織云非常重要，可是我來到UC之后，發現自動化調度系統貌似沒什么必要，業務整體擴容和調度很少。場景不同／規模不同／復雜度不同／業務不同等帶來的運維體系建設結果都不同。
Q7：怎么著手做運維標準化和規劃化呢，比如流程規范/配置規劃/數據規范等？
答：流程規范其實結合運維場景是最好的了，比如說持續部署，持續交付等場景。這個場景在運維內其實是可以根據IT維護對象和變更的場景來提煉的。IT維護對象，比如說DNS，就新增，修改，刪除等等，很簡單的系統實現就可以了。變更的場景就復雜一點，持續部署，有版本升級／發布／回滾等等，
持續交付更是從全業務變更流程來看，這個需要系統固化。
轉載于:https://blog.51cto.com/luoahong/1738681
總結
以上是生活随笔為你收集整理的老王亲述：我的运维心路历程的全部內容，希望文章能夠幫你解決所遇到的問題。
