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

什么是運維？什么是開發(fā)？

14年畢業(yè)至今，前后換過三分工作，每一次都對運維工程師這個職位有一些新的認識。

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

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

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

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

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

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

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

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

3.運維普遍要求24小時on call。 凌晨接到電話時Fuck在心口難開

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

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

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

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

自動化運維平臺空想

沒事兒的時候總喜歡瞎想，運維平臺應(yīng)該做成啥樣，趁著這個機會，也順便落到紙面上，說不定以后有機會真的付諸實踐，別到時候再忘了。

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

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

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