錯(cuò)誤1：運(yùn)維是運(yùn)維人的運(yùn)維

這個(gè)是必須首先要糾正的把鉴，因?yàn)樗P(guān)系到你的定位和團(tuán)隊(duì)未來(lái)的發(fā)展故响。當(dāng)你把運(yùn)維限制在運(yùn)維人的職責(zé)范圍之內(nèi)的時(shí)候检盼，必定是沒(méi)法走遠(yuǎn)的肯污。這也限制你能提供的價(jià)值，貌似一個(gè)價(jià)值不高的團(tuán)隊(duì)吨枉，必然就沒(méi)法認(rèn)可蹦渣。正確的認(rèn)識(shí)，運(yùn)維人需要把可運(yùn)維性標(biāo)準(zhǔn)和意識(shí)不斷Push到產(chǎn)品／研發(fā)過(guò)程中貌亭，讓運(yùn)維成為所有人的運(yùn)維柬唯，成為產(chǎn)品功能實(shí)現(xiàn)的一部分。

錯(cuò)誤2：運(yùn)維是一個(gè)成本中心

這里面有兩層理解圃庭，第一層是IT服務(wù)資源的管理者锄奢，他有責(zé)任對(duì)資源的使用狀況做好控制，避免浪費(fèi)冤议；第二層斟薇，運(yùn)維人好像沒(méi)法直接產(chǎn)生收益师坎，管理意識(shí)里就是要控制運(yùn)維成本的投入恕酸，特別是運(yùn)維人力投入。

對(duì)于第一層胯陋，資源的成本控制的確是運(yùn)維的職責(zé)之一蕊温，但僅僅是他一個(gè)價(jià)值維度的體現(xiàn)。一個(gè)可運(yùn)維性高的系統(tǒng)遏乔，帶來(lái)的是服務(wù)質(zhì)量的提升义矛，這個(gè)是需要運(yùn)維來(lái)hold（至少國(guó)內(nèi)很多研發(fā)團(tuán)隊(duì)如此）；一個(gè)好的運(yùn)維團(tuán)隊(duì)盟萨，能夠反向驅(qū)動(dòng)組織IT性能的提升凉翻，性能的提升，就是組織利潤(rùn)／市場(chǎng)占有率的提升（2014年DevOps Report揭示的現(xiàn)實(shí)）捻激。

對(duì)于第二層制轰，其實(shí)在錯(cuò)誤認(rèn)識(shí)1里面已經(jīng)有了答案，根源是在于大家還是把運(yùn)維當(dāng)成維護(hù)來(lái)看待胞谭，那時(shí)運(yùn)維職能化是過(guò)去的表述垃杖，今天已經(jīng)開始提倡運(yùn)維價(jià)值，走向IT運(yùn)營(yíng)丈屹。

錯(cuò)誤3：運(yùn)維的職責(zé)就是維穩(wěn)

穩(wěn)定性可以理解成可用性调俘，可用性一定不是我們維護(hù)出來(lái)的。運(yùn)維過(guò)程的確能增加業(yè)務(wù)的可用性，但可用性的根源不是維護(hù)出來(lái)的彩库，可用性是產(chǎn)品線上各個(gè)職能角色的共同職責(zé)肤无。

維穩(wěn)讓人感覺(jué)就是救火隊(duì)員，故障發(fā)生時(shí)運(yùn)維沖在第一線侧巨，如果沒(méi)有運(yùn)維舅锄，這個(gè)產(chǎn)品的穩(wěn)定性就沒(méi)法保證？我依然覺(jué)得這還是一種有形的運(yùn)維存在司忱，還是要依賴運(yùn)維這個(gè)實(shí)體皇忿，真正的運(yùn)維是沒(méi)有運(yùn)維的。我習(xí)慣性把應(yīng)用運(yùn)維有三種階段：

第一階段：應(yīng)用是按照業(yè)務(wù)走的坦仍，此時(shí)運(yùn)維人還能看到業(yè)務(wù)鳍烁，把運(yùn)維過(guò)程和業(yè)務(wù)特性緊密聯(lián)系在一起了。當(dāng)前階段繁扎，運(yùn)維需要站在用戶的角度來(lái)審視自己維護(hù)的系統(tǒng)幔荒，看看系統(tǒng)是否達(dá)到高可用的要求。

第二階段：運(yùn)維是看不到業(yè)務(wù)的梳玫，這個(gè)時(shí)候業(yè)務(wù)的技術(shù)架構(gòu)高度服務(wù)化爹梁，A和B業(yè)務(wù)是沒(méi)有差別的，因?yàn)榧夹g(shù)架構(gòu)是統(tǒng)一的提澎。此時(shí)有點(diǎn)IT運(yùn)營(yíng)的感覺(jué)了姚垃。

第三階段：運(yùn)維實(shí)體是不存在的，特別是上層的應(yīng)用運(yùn)維盼忌』矗可運(yùn)維性已經(jīng)是研發(fā)體系的一部分，已經(jīng)是約定俗成谦纱，自己開發(fā)的業(yè)務(wù)看成，自己上線，自己維護(hù)跨嘉，自己接收告警川慌，自己處理，自己變更祠乃。運(yùn)維提供的是一套標(biāo)準(zhǔn)梦重，一種平臺(tái)，一類機(jī)制等等跳纳。

維穩(wěn)忍饰，是運(yùn)維人的枷鎖，非常贊同老蕭的“高效運(yùn)維”實(shí)踐（IT高性能）寺庄，基于互聯(lián)網(wǎng)＋的業(yè)務(wù)更應(yīng)該去追求運(yùn)維的極致性能艾蓝。在“高效運(yùn)維”的實(shí)踐過(guò)程中力崇，此時(shí)需要運(yùn)維過(guò)程的徹底可視化，可視化才能可控赢织，可視化是更是自動(dòng)化的一種高級(jí)形態(tài)亮靴。更要把可視化的過(guò)程傳導(dǎo)到線上業(yè)務(wù)技術(shù)架構(gòu)中，讓架構(gòu)可視化是可運(yùn)維性的一個(gè)重要標(biāo)準(zhǔn)于置。

錯(cuò)誤4茧吊、運(yùn)維人要甘居人后

這個(gè)是上次高效運(yùn)維中透漏出來(lái)的一個(gè)觀點(diǎn)，并且這種觀點(diǎn)普遍存在八毯。我對(duì)此并不認(rèn)同搓侄，人后是一種支持者的定位。

運(yùn)維要改變角色認(rèn)知话速，需要把自己放到用戶一起讶踪，你代表著用戶來(lái)看我們的系統(tǒng)，系統(tǒng)的好與壞是需要運(yùn)維建立規(guī)則來(lái)衡量泊交，同時(shí)必須要代表用戶強(qiáng)加一種執(zhí)行力去驅(qū)動(dòng)整個(gè)內(nèi)部研發(fā)過(guò)程改善的乳讥。這需要運(yùn)維從幕后走向前臺(tái)！＠蟆云石！

錯(cuò)誤5、DevOps是運(yùn)維人的救命稻草

DevOps不是運(yùn)維人的救命稻草研乒！我把DevOps更多理解成軟件研發(fā)模式的一種變化汹忠，從早期的傳統(tǒng)軟件工程模式到敏捷模式再到DevOps模式，是讓軟件研發(fā)過(guò)程越來(lái)越柔和更多的角色一次性進(jìn)入告嘲。

在早期的瀑布式軟件工程模式下错维，研發(fā)／測(cè)試／維護(hù)（還不是運(yùn)維）是獨(dú)立和隔離的奖地，研發(fā)寫好代碼并自測(cè)后交給測(cè)試橄唬，測(cè)試完成后，維護(hù)部署上線参歹。再到敏捷模式下仰楚，研發(fā)和測(cè)試深度融合，測(cè)試驅(qū)動(dòng)研發(fā)犬庇。

當(dāng)隨著基于互聯(lián)網(wǎng)下的業(yè)務(wù)敏捷性要求越來(lái)越高僧界，維護(hù)的重要性日益凸顯，單純過(guò)去的維護(hù)方法論不足以支撐臭挽，此時(shí)就需要運(yùn)維的能力提前加入到軟件研發(fā)過(guò)程中捂襟，比如說(shuō)軟件的高可用設(shè)計(jì)（對(duì)軟硬件的容錯(cuò)性）／服務(wù)監(jiān)控／自動(dòng)化能力封裝等等。

錯(cuò)誤6欢峰、DevOps就是自動(dòng)化

自動(dòng)化很重要葬荷，但不代表DevOps就等同自動(dòng)化涨共。自動(dòng)化是一種技術(shù)要求，當(dāng)你不是全局自動(dòng)化的時(shí)候宠漩，它帶來(lái)的驅(qū)動(dòng)力更是有限的举反，況且DevOps從來(lái)就不是一個(gè)技術(shù)問(wèn)題。網(wǎng)賺

因此我建議一定大家把基于用戶價(jià)值交付流的自動(dòng)化作為目標(biāo)扒吁，此時(shí)能全局思考對(duì)運(yùn)維內(nèi)部各團(tuán)隊(duì)的自動(dòng)化要求火鼻，對(duì)研發(fā)、對(duì)測(cè)試的自動(dòng)化要求等等雕崩。

錯(cuò)誤7魁索、APM代表運(yùn)維的存在感

很奇怪，在不同的交流場(chǎng)合盼铁，大家依然在問(wèn)我怎么看APM蛾默。我的觀點(diǎn)很明確，APM很重要捉貌，但不能代表運(yùn)維支鸡。APM解決的更多是研發(fā)的代碼性能問(wèn)題，而不是運(yùn)維側(cè)的問(wèn)題趁窃。如果一個(gè)運(yùn)維團(tuán)隊(duì)要通過(guò)APM找存在感的話牧挣，我覺(jué)得運(yùn)維是黔驢技窮了。

在早期的ITIL里面就提到過(guò)能力管理醒陆，其中一個(gè)就是服務(wù)能力管理瀑构，你可以理解成服務(wù)性能管理。達(dá)到性能管理刨摩，實(shí)現(xiàn)手段有很多種寺晌，APM提供了一種通用方法，從這個(gè)角度來(lái)說(shuō)澡刹，意義很大呻征。

錯(cuò)誤8、互聯(lián)網(wǎng)運(yùn)維就是最好的運(yùn)維

某些方面是罢浇，某些方面不是陆赋，這個(gè)需要細(xì)看，只能說(shuō)互聯(lián)網(wǎng)找到了該業(yè)務(wù)形態(tài)及業(yè)務(wù)體量下最合適的運(yùn)維模式（組織／規(guī)范／平臺(tái)等等）嚷闭。就拿BAT三家來(lái)說(shuō)攒岛，他們的運(yùn)維差別其實(shí)很大，特別是到應(yīng)用層運(yùn)維胞锰。

運(yùn)維的實(shí)踐性太強(qiáng)灾锯，照搬不一定有用，更要看到一個(gè)運(yùn)維體系的建立背后考慮和依賴的因素是哪些嗅榕，特別是和業(yè)務(wù)形態(tài)有關(guān)系顺饮，這些實(shí)踐性東西對(duì)大家更有用色乾。傳統(tǒng)行業(yè)更需要慎重，一定要記得互聯(lián)網(wǎng)運(yùn)維最佳實(shí)踐先行導(dǎo)入领突，然后產(chǎn)品進(jìn)入暖璧。

其他

其實(shí)還有很多錯(cuò)誤的觀點(diǎn)，如：“業(yè)務(wù)運(yùn)維可以不做運(yùn)維系統(tǒng)研發(fā)工作”君旦，這個(gè)說(shuō)法叫愚蠢澎办；“運(yùn)維系統(tǒng)研發(fā)很簡(jiǎn)單”，可以說(shuō)運(yùn)維系統(tǒng)研發(fā)一點(diǎn)都不簡(jiǎn)單金砍，難在對(duì)運(yùn)維場(chǎng)景的理解上局蚀，對(duì)運(yùn)維模式的理解上，對(duì)運(yùn)維核心需求的識(shí)別上等等恕稠；“運(yùn)維沒(méi)法參與研發(fā)架構(gòu)設(shè)計(jì)”琅绅，運(yùn)維更應(yīng)該早期參與到研發(fā)的架構(gòu)設(shè)計(jì)中，把運(yùn)維的要求推進(jìn)去鹅巍，并要求實(shí)現(xiàn)千扶；“運(yùn)維對(duì)初創(chuàng)企業(yè)不重要”，我覺(jué)得這是因?yàn)榇蠹疫€不知道運(yùn)維是什么骆捧，其實(shí)越到后面構(gòu)建運(yùn)維能力澎羞，成本越高。不過(guò)要提高運(yùn)維工作效率敛苇，運(yùn)維管理工具最好還是要用一個(gè)的妆绞。