最近因?yàn)椴块T(mén)架構(gòu)調(diào)整，之前工作做了交接，新的安排又沒(méi)有確定，領(lǐng)導(dǎo)建議學(xué)習(xí)下JAVA開(kāi)發(fā)，后續(xù)直接參與到研發(fā)工作中而不再負(fù)責(zé)運(yùn)維工作。周圍同事也都在說(shuō)運(yùn)維工作比較low，轉(zhuǎn)研發(fā)會(huì)好一些。但是畢竟從畢業(yè)之后陰差陽(yáng)錯(cuò)進(jìn)入這個(gè)行當(dāng)，已經(jīng)三年時(shí)間了，多多少少還是有些感情的，內(nèi)心還是有點(diǎn)糾結(jié)。正好借著這個(gè)機(jī)會(huì)，整理下自己之前的經(jīng)歷，反思下自己的工作，看看能否理清今后的發(fā)展思路。

什么是運(yùn)維？什么是開(kāi)發(fā)？

14年畢業(yè)至今，前后換過(guò)三分工作，每一次都對(duì)運(yùn)維工程師這個(gè)職位有一些新的認(rèn)識(shí)。

第一份工作是在一家比較小的安全公司，大四實(shí)習(xí)之后直接轉(zhuǎn)正，做工作有老員工帶著，遇到問(wèn)題可以直接請(qǐng)教老員工。那時(shí)候的工作就是跟著前輩部署一些程序，排查下性能問(wèn)題，重啟下服務(wù)器，每天最大的樂(lè)趣就是寫(xiě)一點(diǎn)小shell腳本，簡(jiǎn)化下繁瑣的工作。所以，那時(shí)候的認(rèn)知就是：在服務(wù)器上執(zhí)行命令處理問(wèn)題的就是運(yùn)維，根據(jù)需求寫(xiě)代碼完成功能和修復(fù)BUG的就是開(kāi)發(fā)。

第二份工作呢，則是進(jìn)了一家小型的創(chuàng)業(yè)公司。作為公司唯一的一名運(yùn)維工程師，并沒(méi)有人能指導(dǎo)我的工作，沒(méi)人告訴我該干什么，怎么干，我只知道，如果應(yīng)用系統(tǒng)出了問(wèn)題，領(lǐng)導(dǎo)就會(huì)找我。 為了避免系統(tǒng)出現(xiàn)問(wèn)題影響業(yè)務(wù)，我需要做負(fù)載均衡，高可用，監(jiān)控，制定問(wèn)題處理的流程規(guī)范。這時(shí)候的認(rèn)知變成了：運(yùn)維工程師是保障系統(tǒng)可以穩(wěn)定的為業(yè)務(wù)提供服務(wù)，開(kāi)發(fā)工程師是讓系統(tǒng)更友好的給業(yè)務(wù)提供服務(wù)，研發(fā)創(chuàng)造價(jià)值，運(yùn)維避免風(fēng)險(xiǎn)。

第三份工作，也就是目前的工作 則是就職于某大型電商集團(tuán)中間件部門(mén)devops小組，重新做回了小小螺絲釘?shù)慕巧Ｅc之前工作不同的是，我們所有系統(tǒng)都是服務(wù)于集團(tuán)內(nèi)部的研發(fā)人員，而且很多系統(tǒng)和其它部門(mén)的系統(tǒng)之間相互依賴。為了完成工作，除了一些技術(shù)問(wèn)題處理，更有一部分精力需要花在和各種同事溝通，尋求最優(yōu)解或者雙方都可以接受的妥協(xié)方案。 這時(shí)候?qū)\(yùn)維工作的理解就是：與開(kāi)發(fā)人員一起配合，盡可能的給用戶優(yōu)質(zhì)的體驗(yàn)。

So，區(qū)分運(yùn)維和開(kāi)發(fā)的并不是工作方式，并不是說(shuō)研發(fā)就是一直在寫(xiě)代碼，運(yùn)維就是一直在插拔網(wǎng)線，部署程序，重啟服務(wù)器。 而是大家的職責(zé)不同，僅此而已。

運(yùn)維工作真的比研發(fā)low嗎

發(fā)現(xiàn)周圍好多同事朋友，不過(guò)運(yùn)維還是研發(fā)，包括HR，部門(mén)領(lǐng)導(dǎo)，獵頭，都感覺(jué)運(yùn)維比研發(fā)low，相應(yīng)的，同等能力下運(yùn)維工資貌似也普遍略低于研發(fā)（這里的運(yùn)維包括具有一定開(kāi)發(fā)能力的運(yùn)維開(kāi)發(fā)工程師）。認(rèn)真想了下，出現(xiàn)這種現(xiàn)象的原因，可能有以下幾個(gè)：

1.大部分運(yùn)維工程師的時(shí)間充斥著瑣碎事務(wù)，完全就是一個(gè)客服加打雜的工作

2.運(yùn)維工作并不能直接的創(chuàng)造價(jià)值

3.運(yùn)維普遍要求24小時(shí)on call。 凌晨接到電話時(shí)Fuck在心口難開(kāi)

但是這些問(wèn)題，其實(shí)并不是沒(méi)有辦法解決的。相信現(xiàn)在很少再有那種單純的系統(tǒng)運(yùn)維或者應(yīng)用運(yùn)維工程師了，大家多多少少都掌握著一兩種開(kāi)發(fā)語(yǔ)言。而大多瑣碎的事務(wù)，都可以通過(guò)自動(dòng)化來(lái)完成。再有就是現(xiàn)在大多數(shù)系統(tǒng)都是分布式的高可用架構(gòu)，只要系統(tǒng)避免到單點(diǎn)故障，真的很少有問(wèn)題需要當(dāng)晚立刻處理，完全可以等到第二天工作時(shí)間在進(jìn)行操作。當(dāng)然，具體操作起來(lái)還是有很大難度，會(huì)遇到各種各樣的問(wèn)題。比如工作被各種瑣事填滿，完全沒(méi)有時(shí)間進(jìn)行工程性的工作提高工作效率。部門(mén)間信息共享不夠，比如服務(wù)器連通性報(bào)警，對(duì)于我們來(lái)說(shuō)單臺(tái)連通性報(bào)警并不是什么大問(wèn)題，但是監(jiān)控部門(mén)的同事會(huì)認(rèn)為比較重要，不管幾點(diǎn)都會(huì)電話通知我們。后來(lái)經(jīng)過(guò)和監(jiān)控部門(mén)溝通之后，監(jiān)控部門(mén)同意類似問(wèn)題只通過(guò)短信等發(fā)送報(bào)警不打電話叫醒我們之后，又會(huì)有部分研發(fā)恰巧沒(méi)睡著看到報(bào)警信息之后打電話來(lái)咨詢（這里指大型公司）。但是辦法總比困難多，不能因?yàn)檫@些困難就放棄以更優(yōu)雅的方式處理運(yùn)維問(wèn)題，而是直接認(rèn)定 運(yùn)維工作比較low。 之前我們說(shuō)了，運(yùn)維只是要保障系統(tǒng)穩(wěn)定性和可用性，和工作方式方法無(wú)關(guān)。這樣看，Google的SRE說(shuō)白了不也是運(yùn)維工程師，雖然沒(méi)有真正接觸過(guò)，不過(guò)看《SRE Google運(yùn)維解密》中寫(xiě)的，還是很有技術(shù)含量，很高大上的。 那50%的時(shí)間分配原則，真真讓人羨慕。 如果排除上述那些因素，只看工作本身的話，其實(shí)運(yùn)維的技術(shù)含量并不比研發(fā)低。要保證系統(tǒng)的穩(wěn)定性，網(wǎng)絡(luò)協(xié)議，操作系統(tǒng)，開(kāi)發(fā)流程規(guī)范各種都需要有一定的了解，而且可以開(kāi)發(fā)自己的運(yùn)維平臺(tái)簡(jiǎn)化工作，自己本身既是開(kāi)發(fā)人員，又是最終用戶，省去了和產(chǎn)品經(jīng)理及業(yè)務(wù)方的各種扯皮，可以安安心心按著自己的心意創(chuàng)造產(chǎn)品，還是很美好的，不是嗎。

如何讓我們的工作變得高大上

既然有著光明的前途，那我們需要怎樣做，才能過(guò)上美好的生活呢？

作為一個(gè)一線基層運(yùn)維，我覺(jué)得，自身能做的就是學(xué)習(xí)，學(xué)習(xí)，學(xué)習(xí)。學(xué)習(xí)專業(yè)技能，學(xué)習(xí)如何溝通，學(xué)習(xí)通用技能（如英語(yǔ)能力，文檔能力）。提高專業(yè)能力，你才能實(shí)現(xiàn)你想做的運(yùn)維平臺(tái)，解決你遇到的那些問(wèn)題。 提高溝通能力，你才能讓你的直屬領(lǐng)導(dǎo)和同事支持你做你想做的事情，自動(dòng)化也好，學(xué)新知識(shí)也罷，都需要時(shí)間。 提高英語(yǔ)能力可以讓你更快的學(xué)習(xí)專業(yè)技能，提高文檔能力可以讓你的工作成果在不同部門(mén)之間推廣，讓你得到其它同事的認(rèn)可。 并且不要放棄任何學(xué)習(xí)和練手的機(jī)會(huì)，如果同一份工作，手動(dòng)解決和通過(guò)編寫(xiě)自動(dòng)化腳本所需時(shí)間相差并不多，那一定要選擇用腳本來(lái)實(shí)現(xiàn)，多動(dòng)腦子少動(dòng)手。

自動(dòng)化運(yùn)維平臺(tái)空想

沒(méi)事兒的時(shí)候總喜歡瞎想，運(yùn)維平臺(tái)應(yīng)該做成啥樣，趁著這個(gè)機(jī)會(huì)，也順便落到紙面上，說(shuō)不定以后有機(jī)會(huì)真的付諸實(shí)踐，別到時(shí)候再忘了。

一體化： 既然是叫做平臺(tái)，就應(yīng)該有完善的功能，從硬件資源申請(qǐng)，持續(xù)集成，到監(jiān)控，到批量命令執(zhí)行，failover都應(yīng)當(dāng)包括在內(nèi)。后臺(tái)可以分為不同的子系統(tǒng)，但是用戶操作時(shí)，應(yīng)該是統(tǒng)一的入口，各系統(tǒng)間數(shù)據(jù)應(yīng)當(dāng)共享，所有操作日志清晰可審計(jì)。

少量并多樣的交互： 交互頻率應(yīng)當(dāng)越少越好，只要有人參與到整個(gè)流程當(dāng)中，那處理周期怎么也是分鐘級(jí)的，如果涉及到多人操作，可能需要幾個(gè)小時(shí)甚至幾天。 理想狀態(tài)下，最好是監(jiān)控系統(tǒng)發(fā)現(xiàn)異常后，直接通知異常處理系統(tǒng)進(jìn)行處理，流量遷移，故障判斷一步到位，如果可能最好能直接恢復(fù)，如果是硬件故障，可以直接報(bào)修IDC或者硬件供應(yīng)商。只需要在這一切完成之后，給運(yùn)維人員一份記錄即可。不用業(yè)務(wù)的異常處理流程可能有所不同，這一部分最好做成可配置的。有特殊需求的用戶可以自行定義異常處理流程。 相反的，交互方式應(yīng)當(dāng)越多越好，手機(jī)APP，chatbot，WEB頁(yè)面。

自主進(jìn)化： 由于統(tǒng)一了所有操作的入口，而且有著完備的數(shù)據(jù)，所以應(yīng)該能夠通過(guò)機(jī)器學(xué)習(xí)等方式，讓平臺(tái)越來(lái)越智能。由最開(kāi)始的我們指定平臺(tái)應(yīng)該怎么做，到平臺(tái)根據(jù)實(shí)際情況給出處理意見(jiàn)，由運(yùn)維人員確認(rèn)是否可以進(jìn)行該項(xiàng)操作，到運(yùn)維人員制定約束，避免一些危險(xiǎn)操作，其余的由系統(tǒng)通過(guò)自主的學(xué)習(xí)來(lái)判斷應(yīng)該如何去做故障處理，性能調(diào)優(yōu)等工作并具體執(zhí)行。