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

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

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

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

• 對於第一層，資源的成本控制的確是運維的職責之一，但僅僅是他一個價值維度的體現。一個可運維性高的系統，帶來的是服務質量的提升，這個是需要運維來hold（至少國內很多研發團隊如此）；一個好的運維團隊，能夠反向驅動組織IT效能的提升，效能的提升，就是組織利潤／市場佔有率的提升（2014年DevOps Report揭示的現實）。
• 對於第二層，其實在錯誤認識1裡面已經有了答案，根源是在於大家還是把運維當成維護來看待，那時運維職能化是過去的表述，今天已經開始提倡運維價值，走向IT運營。

錯誤3：運維的職責就是維穩

穩定性可以理解成可用性，可用性一定不是我們維護出來的。運維過程的確能增加業務的可用性，但可用性的根源不是維護出來的，可用性是產品線上各個職能角色的共同職責。

維穩讓人感覺就是救火隊員，故障發生時運維衝在第一線，如果沒有運維，這個產品的穩定性就沒法保證？我依然覺得這還是一種有形的運維存在，還是要依賴運維這個實體，真正的運維是沒有運維的。我習慣性把應用運維有三種階段：

• 第一階段：應用是按照業務走的，此時運維人還能看到業務，把運維過程和業務特性緊密聯絡在一起了。當前階段，運維需要站在使用者的角度來審視自己維護的系統，看看系統是否達到高可用的要求。
• 第二階段：運維是看不到業務的，這個時候業務的技術架構高度服務化，A和B業務是沒有差別的，因為技術架構是統一的。此時有點IT運營的感覺了。
• 第三階段：運維實體是不存在的，特別是上層的應用運維。可運維性已經是研發體系的一部分，已經是約定俗成，自己開發的業務，自己上線，自己維護，自己接收告警，自己處理，自己變更。運維提供的是一套標準，一種平臺，一類機制等等。

維穩，是運維人的枷鎖，非常贊同老蕭的“高效運維”實踐（IT高效能），基於網際網路＋的業務更應該去追求運維的極致效能。在“高效運維”的實踐過程中，此時需要運維過程的徹底視覺化，視覺化才能可控，視覺化是更是自動化的一種高階形態。更要把視覺化的過程傳導到線上業務技術架構中，讓架構視覺化是可運維性的一個重要標準。

錯誤4、運維人要甘居人後

這個是上次高效運維中透漏出來的一個觀點，並且這種觀點普遍存在。我對此並不認同，人後是一種支持者的定位。

運維要改變角色認知，需要把自己放到使用者一起，你代表著使用者來看我們的系統，系統的好與壞是需要運維建立規則來衡量，同時必須要代表使用者強加一種執行力去驅動整個內部研發過程改善的。這需要運維從幕後走向前臺！！！

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

DevOps不是運維人的救命稻草！我把DevOps更多理解成軟體研發模式的一種變化，從早期的傳統軟體工程模式到敏捷模式再到DevOps模式，是讓軟體研發過程越來越柔和更多的角色一次性進入。

在早期的瀑布式軟體工程模式下，研發／測試／維護（還不是運維）是獨立和隔離的，研發寫好程式碼並自測後交給測試，測試完成後，維護部署上線。再到敏捷模式下，研發和測試深度融合，測試驅動研發。

當隨著基於網際網路下的業務敏捷性要求越來越高，維護的重要性日益凸顯，單純過去的維護方法論不足以支撐，此時就需要運維的能力提前加入到軟體研發過程中，比如說軟體的高可用設計（對軟硬體的容錯性）／服務監控／自動化能力封裝等等。

錯誤6、DevOps就是自動化

自動化很重要，但不代表DevOps就等同自動化。自動化是一種技術要求，當你不是全域性自動化的時候，它帶來的驅動力更是有限的，況且DevOps從來就不是一個技術問題。

因此我建議一定大家把基於使用者價值交付流的自動化作為目標，此時能全域性思考對運維內部各團隊的自動化要求，對研發、對測試的自動化要求等等。

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

很奇怪，在不同的交流場合，大家依然在問我怎麼看APM。我的觀點很明確，APM很重要，但不能代表運維。APM解決的更多是研發的程式碼效能問題，而不是運維側的問題。如果一個運維團隊要通過APM找存在感的話，我覺得運維是黔驢技窮了。

在早期的ITIL裡面就提到過能力管理，其中一個就是服務能力管理，你可以理解成服務效能管理。達到效能管理，實現手段有很多種，APM提供了一種通用方法，從這個角度來說，意義很大。

錯誤8、網際網路運維就是最好的運維

某些方面是，某些方面不是，這個需要細看，只能說網際網路找到了該業務形態及業務體量下最合適的運維模式（組織／規範／平臺等等）。就拿BAT三家來說，他們的運維差別其實很大，特別是到應用層運維。

運維的實踐性太強，照搬不一定有用，更要看到一個運維體系的建立背後考慮和依賴的因素是哪些，特別是和業務形態有關係，這些實踐性東西對大家更有用。傳統行業更需要慎重，一定要記得網際網路運維最佳實踐先行匯入，然後產品進入。

其他

其實還有很多錯誤的觀點，如：“業務運維可以不做運維繫統研發工作”，這個說法叫愚蠢；“運維繫統研發很簡單”，可以說運維繫統研發一點都不簡單，難在對運維場景的理解上，對運維模式的理解上，對運維核心需求的識別上等等；“運維沒法參與研發架構設計”，運維更應該早期參與到研發的架構設計中，把運維的要求推進去，並要求實現；“運維對初創企業不重要”，我覺得這是因為大家還不知道運維是什麼，其實越到後面構建運維能力，成本越高。

文章轉載自公眾號：網際網路運維雜談；作者：王津銀，優維科技創始人