最近因為部門架構調整，之前工作做了交接，新的安排又沒有確定，領導建議學習下JAVA開發，後續直接參與到研發工作中而不再負責運維工作。周圍同事也都在說運維工作比較low，轉研發會好一些。但是畢竟從畢業之後陰差陽錯進入這個行當，已經三年時間了，多多少少還是有些感情的，內心還是有點糾結。正好藉著這個機會，整理下自己之前的經歷，反思下自己的工作，看看能否理清今後的發展思路。

什麼是運維？什麼是開發？

14年畢業至今，前後換過三分工作，每一次都對運維工程師這個職位有一些新的認識。
第一份工作是在一家比較小的安全公司，大四實習之後直接轉正，做工作有老員工帶著，遇到問題可以直接請教老員工。那時候的工作就是跟著前輩部署一些程式，排查下效能問題，重啟下伺服器，每天最大的樂趣就是寫一點小shell指令碼，簡化下繁瑣的工作。所以，那時候的認知就是：在伺服器上執行命令處理問題的就是運維，根據需求寫程式碼完成功能和修復BUG的就是開發。

第二份工作呢，則是進了一家小型的創業公司。作為公司唯一的一名運維工程師，並沒有人能指導我的工作，沒人告訴我該幹什麼，怎麼幹，我只知道，如果應用系統出了問題，領導就會找我。 為了避免系統出現問題影響業務，我需要做負載均衡，高可用，監控，制定問題處理的流程規範。這時候的認知變成了：運維工程師是保障系統可以穩定的為業務提供服務，開發工程師是讓系統更友好的給業務提供服務，研發創造價值，運維避免風險。

第三份工作，也就是目前的工作 則是就職於某大型電商集團中介軟體部門devops小組，重新做回了小小螺絲釘的角色。與之前工作不同的是，我們所有系統都是服務於集團內部的研發人員，而且很多系統和其它部門的系統之間相互依賴。為了完成工作，除了一些技術問題處理，更有一部分精力需要花在和各種同事溝通，尋求最優解或者雙方都可以接受的妥協方案。 這時候對運維工作的理解就是：與開發人員一起配合，儘可能的給使用者優質的體驗。

So，區分運維和開發的並不是工作方式，並不是說研發就是一直在寫程式碼，運維就是一直在插拔網線，部署程式，重啟伺服器。 而是大家的職責不同，僅此而已。

運維工作真的比研發low嗎

發現周圍好多同事朋友，不過運維還是研發，包括HR，部門領導，獵頭，都感覺運維比研發low，相應的，同等能力下運維工資貌似也普遍略低於研發（這裡的運維包括具有一定開發能力的運維開發工程師）。認真想了下，出現這種現象的原因，可能有以下幾個：
1.大部分運維工程師的時間充斥著瑣碎事務，完全就是一個客服加打雜的工作
2.運維工作並不能直接的創造價值
3.運維普遍要求24小時on call。 凌晨接到電話時Fuck在心口難開

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

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

既然有著光明的前途，那我們需要怎樣做，才能過上美好的生活呢？
作為一個一線基層運維，我覺得，自身能做的就是學習，學習，學習。學習專業技能，學習如何溝通，學習通用技能（如英語能力，文件能力）。提高專業能力，你才能實現你想做的運維平臺，解決你遇到的那些問題。 提高溝通能力，你才能讓你的直屬領導和同事支援你做你想做的事情，自動化也好，學新知識也罷，都需要時間。 提高英語能力可以讓你更快的學習專業技能，提高文件能力可以讓你的工作成果在不同部門之間推廣，讓你得到其它同事的認可。 並且不要放棄任何學習和練手的機會，如果同一份工作，手動解決和通過編寫自動化指令碼所需時間相差並不多，那一定要選擇用指令碼來實現，多動腦子少動手。

自動化運維平臺空想

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

一體化： 既然是叫做平臺，就應該有完善的功能，從硬體資源申請，持續整合，到監控，到批量命令執行，failover都應當包括在內。後臺可以分為不同的子系統，但是使用者操作時，應該是統一的入口，各系統間資料應當共享，所有操作日誌清晰可審計。
少量並多樣的互動： 互動頻率應當越少越好，只要有人蔘與到整個流程當中，那處理週期怎麼也是分鐘級的，如果涉及到多人操作，可能需要幾個小時甚至幾天。 理想狀態下，最好是監控系統發現異常後，直接通知異常處理系統進行處理，流量遷移，故障判斷一步到位，如果可能最好能直接恢復，如果是硬體故障，可以直接報修IDC或者硬體供應商。只需要在這一切完成之後，給運維人員一份記錄即可。不用業務的異常處理流程可能有所不同，這一部分最好做成可配置的。有特殊需求的使用者可以自行定義異常處理流程。 相反的，互動方式應當越多越好，手機APP,chatbot，WEB頁面。
自主進化： 由於統一了所有操作的入口，而且有著完備的資料，所以應該能夠通過機器學習等方式，讓平臺越來越智慧。由最開始的我們指定平臺應該怎麼做，到平臺根據實際情況給出處理意見，由運維人員確認是否可以進行該項操作，到運維人員制定約束，避免一些危險操作，其餘的由系統通過自主的學習來判斷應該如何去做故障處理，效能調優等工作並具體執行。