[[149142]]

通過最近的多次運維交流，還是能看到一些對運維的錯誤認識，個人總結(jié)如下：

　　錯誤1：運維是運維人的運維

　　這個是必須首先要糾正的，因為他關系到你的定位和團隊未來的發(fā)展。當你把運維限制在運維人的職責范圍之內(nèi)的時候，必定是沒法走遠的。這也限制你能提供的價值，貌似一個價值不高的團隊，必然就沒法被認可。正確的認識，運維人需要把可運維性標準和意識不斷Push到產(chǎn)品/研發(fā)過程中，讓運維成為所有人的運維，成為產(chǎn)品功能實現(xiàn)的一部分。

　　錯誤2：運維是一個成本中心

　　這里面有兩層理解，第一層是IT服務資源的管理者，他有責任對資源的使用狀況做好控制，避免浪費；第二層，運維人好像沒法直接產(chǎn)生收益，管理意識里就是要控制運維成本的投入，特別是運維人力投入。

　　對于第一層，資源的成本控制的確是運維的職責之一，但僅僅是他一個價值維度的體現(xiàn)。一個可運維性高的系統(tǒng)，帶來的是服務質(zhì)量的提升，這個是需要運維來hold(至少國內(nèi)很多研發(fā)團隊如此)；一個好的運維團隊，能夠反向驅(qū)動組織IT性能的提升，性能的提升，就是組織利潤/市場占有率的提升(2014年DevOps Report揭示的現(xiàn)實)。

　　第二層，其實在錯誤認識1里面已經(jīng)有了答案，根源是在于大家還是把運維當成維護來看待，那時運維職能化是過去的表述，今天已經(jīng)開始提倡運維價值，走向IT運營。

　　錯誤3：運維的職責就是維穩(wěn)

　　穩(wěn)定性可以理解成可用性?？捎眯砸欢ú皇俏覀兙S護出來的，運維過程的確能增加業(yè)務的可用性，但可用性的根源不是維護出來的，可用性是產(chǎn)品線上各個職能角色的共同職責。維穩(wěn)讓人感覺就是救火隊員，故障發(fā)生時，運維沖在第一線，如果沒有運維，這個產(chǎn)品的穩(wěn)定性就沒法保證？我依然覺得這還是一種有形的運維存在，還是要依賴運維這個實體，真正的運維是沒有運維的。我習慣性把應用運維有三種階段：

　　第一階段：應用是按照業(yè)務走的，此時運維人還能看到業(yè)務，把運維過程和業(yè)務特性緊密聯(lián)系在一起了。當前階段，運維需要站在用戶的角度來審視自己維護的系統(tǒng)，看看系統(tǒng)是否達到高可用的要求。

　　第二階段：運維是看不到業(yè)務的，這個時候業(yè)務的技術架構(gòu)高度服務化，A和B業(yè)務是沒有差別的，因為技術架構(gòu)是統(tǒng)一的。此時有點IT運營的感覺了。

　　第三階段：運維實體是不存在的，特別是上層的應用運維。可運維性已經(jīng)是研發(fā)體系的一部分，已經(jīng)是約定俗成，自己開發(fā)的業(yè)務，自己上線，自己維護，自己接收告警，自己處理，自己變更。運維提供的是一套標準，一種平臺，一類機制等等。

　　維穩(wěn)，是運維人的枷鎖，非常贊同老蕭的“高效運維”實踐(IT高性能)，基于互聯(lián)網(wǎng)+的業(yè)務更應該去追求運維的極致性能。在“高效運維”的實踐過程中，此時需要運維過程的徹底可視化，可視化才能可控，可視化是更是自動化的一種高級形態(tài)。更要把可視化的過程傳導到線上業(yè)務技術架構(gòu)中，讓架構(gòu)可視化是可運維性的一個重要標準。

　　錯誤4：運維人要甘居人后

　　這個是上次高效運維中透漏出來的一個觀點，并且這種觀點普遍存在。我對此并不認同，人后是一種支持者的定位。運維要改變角色認知，需要把自己放到用戶一起，你代表著用戶來看我們的系統(tǒng)，系統(tǒng)的好與壞是需要運維建立規(guī)則來衡量，同時必須要代表用戶強加一種執(zhí)行力去驅(qū)動整個內(nèi)部研發(fā)過程改善的。這需要運維從幕后走向前臺!!!

　　錯誤5：DevOps是運維人的救命稻草

　　DevOps不是運維人的救命稻草！我把DevOps更多理解成軟件研發(fā)模式的一種變化，從早期的傳統(tǒng)軟件工程模式到敏捷模式再到DevOps模式，是讓軟件研發(fā)過程越來越糅合更多的角色一次性進入。

　　在早期的瀑布式軟件工程模式下，研發(fā)/測試/維護(還不是運維)是獨立和隔離的，研發(fā)寫好代碼并自測后交給測試，測試完成后，維護部署上線。再到敏捷模式下，研發(fā)和測試深度融合，測試驅(qū)動研發(fā)。當隨著基于互聯(lián)網(wǎng)下的業(yè)務敏捷性要求越來越高，維護的重要性日益凸顯，單純過去的維護方法論不足以支撐，此時就需要運維的能力提前加入到軟件研發(fā)過程中，比如說軟件的高可用設計(對軟硬件的容錯性)/服務監(jiān)控/自動化能力封裝等等。

　　錯誤6：DevOps就是自動化

　　自動化很重要，但不代表DevOps就等同自動化。自動化是一種技術要求，當你不是全局自動化的時候，它帶來的驅(qū)動力更是有限的，況且DevOps從來就不是一個技術問題。因此，我建議大家一定把基于用戶價值交付流的自動化作為目標，此時能全局思考對運維內(nèi)部各團隊的自動化要求，對研發(fā)、對測試的自動化要求等等。

　　錯誤7：APM代表運維的存在感

　　很奇怪，在不同的交流場合，大家依然在問我怎么看APM。我的觀點很明確，APM很重要，但不能代表運維。APM解決的更多是研發(fā)的代碼性能問題，而不是運維側(cè)的問題。如果一個運維團隊要通過APM找存在感的話，我覺得運維是黔驢技窮了。在早期的ITIL里面就提到過能力管理，其中一個就是服務能力管理，你可以理解成服務性能管理。達到性能管理，實現(xiàn)手段有很多種，APM提供了一種通用方法，從這個角度來說，意義很大。

　　錯誤8：互聯(lián)網(wǎng)運維就是最好的運維

　　某些方面是，某些方面不是，這個需要細看，只能說互聯(lián)網(wǎng)找到了該業(yè)務形態(tài)及業(yè)務體量下最合適的運維模式(組織/規(guī)范/平臺等等)。就拿BAT三家來說，他們的運維差別其實很大，特別是到應用層運維。

　　運維的實踐性太強，照搬不一定有用，更要看到一個運維體系的建立背后考慮和依賴的因素是哪些，特別是和業(yè)務形態(tài)有關系，這些實踐性東西對大家更有用。傳統(tǒng)行業(yè)更需要慎重，一定要記得互聯(lián)網(wǎng)運維最佳實踐先行導入，然后產(chǎn)品進入。

　　其實還有很多錯誤的觀點，如：“業(yè)務運維可以不做運維系統(tǒng)研發(fā)工作”，這個說法叫愚蠢；“運維系統(tǒng)研發(fā)很簡單”，可以說運維系統(tǒng)研發(fā)一點都不簡單，難在對運維場景的理解上，對運維模式的理解上，對運維核心需求的識別上等等；“運維沒法參與研發(fā)架構(gòu)設計”，運維更應該早期參與到研發(fā)的架構(gòu)設計中，把運維的要求推進去，并要求實現(xiàn)；“運維對初創(chuàng)企業(yè)不重要”，我覺得這是因為大家還不知道運維是什么，其實越到后面構(gòu)建運維能力，成本越高。其他觀點不一一列舉了～

　　關于老王(原名王津銀)

　　07年進入騰訊公司接觸運維，經(jīng)歷服務器從百到萬的運維歷程，先后在YY和UC參與不同業(yè)務形態(tài)的運維，期間帶過前端運維、數(shù)據(jù)存儲運維、YY語音、游戲運維、運維研發(fā)等多種運維團隊，對運維有著全面的理解。極力倡導互聯(lián)網(wǎng)價值運維理念，即面向用戶的價值是由自動化平臺交付傳遞，同時由數(shù)據(jù)化來提煉和衡量。