我對運維的思考
我是一名Java後端研發工程師，在我的職業生涯中，曾做過一小段時間專業的運維，而後在一段很長的時間裏兼任過運維職責，只不過職責範圍在小和大之間來回奔跑。
一、Linux命令是基礎，萬變不離其宗
我所待的幾家公司，或多或少要做運維相關的工作，其中Linux是最常用的，這個Linux包含Linux常用命令和操作系統(如Debian、紅帽、Gentoo、Ubuntu、CentOS等)。其中我接觸最多的就是CentOS和Ubuntu。
為什麼說Linux命令是基礎？
-
命令行界面以Linux命令作為基礎，如果不會敲命令，也就無法使用(各種軟件安裝和問題排查都涉及);
-
shell腳本就是由一條條Linux命令組合而來，掌握好Linux命令，你就可以寫出各種各樣的符合實際需求的腳本(服務監控、備份、項目部署等)。
另外再從另外一個角度來看，不論是專業的運維人員或開發人員都需要掌握Linux命令，只不過程度不一樣，對於運維人員必須掌握牢靠，畢竟是吃飯的傢伙，對於開發人員，開發寫出來的項目大多是部署在Linux上(有一部分是Windows Server)，涉及生產環境的問題排查，必然需要熟知一些常用的Linux命令。
二、自動化
自動化這塊對運維非常重要，自動化涉及最多的就是寫一些shell腳本放在特定的目錄歸類好，按需執行。
現在有很多現成的軟件可以將一些工作自動化如(jenkins持續集成(拉取項目、自動編譯、發佈等)、zabbix自動監控服務器CPU、內存、磁盤和JVM、MySQL等、Ansible輕鬆管理上百台服務器等)。
有人幽默地說:不擅長將工作自動化的運維不是好運維。
在我做運維相關的工作的時候，發現像部署或者一些軟件的備份和安裝就那麼幾條命令，敲來敲去，敲了N多遍，雖然可以複製粘貼，但是感覺還是太過麻煩，於是寫一個shell腳本，只需一鍵執行即可。這樣一來就可以節省更多的時間。
更多的時間可以用來思考更多，比方說現有的運維體系哪些不是很完善或者是之前遺留的哪些問題(不那麼緊急但比較重要)可以現在來解決。
再或者對於一些軟件它的一些設計原理和思想是什麼，也可以研究研究。再或者是配置文件，為什麼要這麼配置，每個配置是什麼含義。
在我做運維的時候，網上搜索安裝和配置軟件，基本上就是複製過來一步步來，但後來發現有一點不好的就是我對於為什麼這樣配置不知道，不知道意味着可能存在一些風險，運維人員要想進步成長，對一些軟件不僅僅做到知其然，更要知其所以然(與我們研發人員寫代碼一樣，不僅僅要懂業務邏輯和代碼執行邏輯，同時也要知道所使用的庫，底層是如何處理的)。
安裝軟件誰都會，但要說到軟件的配置，如何配更合理更符合實際場景那就是一門比較深的功夫。
那麼如何做到自動化呢？
要養成」懶」的習慣，就和研發人員寫代碼一樣，發現多段重複的代碼，於是將其抽取為一個方法進行調用(不用在複製來複制去，影響可讀行，同時也增加代碼行，代碼行越多確實不便閱讀)。運維人員經常使用Linux命令，在敲的過程中總會能夠發現哪些是重複多次的，重複多次的就可以寫成一個shell腳本。
自動化的好處有哪些？
最直接的好處就是:你動腦思考了，思考如何簡化工作，提高效率。這樣一來給你直接帶來的就是實力的提升。
其它的好處就像上面說的，你可以有更多的時間來思考如何做的更好或者學習(我第一家公司的運維同事在自動化方面做的很不錯，同時他的Linux功底也非常好，基本上工作做的特別快，效率也特別高，因此他有更多的時間去思考，去學習(業務或者技術層面)等)。
還有一個最重要的原因，如果你不擅長將工作自動化，最後可能會累的要命。累的代價就是身心疲憊和停止思考(人在非常累的時候寫代碼，非常麻木，根本不知道自己在做什麼，只是在重複動作)。
三、要懂業務
在一些互聯網公司，開發人員不懂業務的話，工作幾乎沒辦法進行下去。對於運維人員來說，可以不懂。這是我曾經的看法。
後來經歷多了，發現還真不是這樣。什麼樣的業務決定使用什麼樣的架構(邏輯架構(如分層:數據訪問層、業務邏輯層、表示層等)、開發架構(SDK和一些第三方庫等)、物理架構(部署和運行)、系統架構等)，其中物理架構(操作系統、網絡、服務器等)、數據架構(數據表設計、高可用、備份、複製等)。
根據合適的業務，選擇合適的架構。對架構師而言非常重要，對於運維人員也同樣如此。
同時懂業務對於運維人員排查問題也是很有幫助的，因為懂流程，懂流程意味着可以重現，重現問題過程中，打開對應的日誌，這樣一來能準確的定位到問題，看是因為服務器的原因還是某個開發人員代碼寫的問題(服務器的原因通常那段程序執行需要更多的內存，服務器內存可能不夠;代碼的原因通常是一些判斷邏輯不是很完善導致程序沒有按照正常流程走)。這樣就能減少運維背鍋的概率，也能有理有據的反駁。
四、要有一套完整的運維機制
曾看過李鵬寫的《IT運維之道》這本書，大部分忘記了，但其中提到的IT運維四要事，至今印象還比較深刻，做運維的朋友，可以讀一讀，曾經在創業公司讀這本書的時候，受到一些啟發運用到實際中，提高效率不少。
這本書總結了IT運維的四件要事。我覺得講的很不錯。同時這四要素可構成一套完整的運維機制。四要素如下:
1.按運維原則做事
- 事前:講計劃、重承諾;
- 事中:講規範、重控制、有反饋;
- 事後:重效率、能應急、有保障。
2.掌握服務平衡
- 主動服務:服務者發起運維服務;
- 受理服務:用戶提出運維需求。
3.落實整體運維
- 軟件支撐系統;
- 應用系統;
- 計算機硬件設備;
- 機房和環境。
4.貫穿服務流程
- 事件流程;
- 問題流程;
- 配置管理流程;
- 變更流程;
- 發佈流程。
上述四要素每一個部分要細說，都可以講很多內容。由於我運維經歷很有限，上述四要素並沒有全部接觸。但對於我感觸最深的是第一點按運維原則做事和第四點貫穿服務流程。這四要素大家可擇需而取。在我的職業生涯中，涉及到運維相關的工作，如果我有權把控的話，基本上會按照第一點來做(其實不僅僅是運維，開發也一樣)。
五、適當了解前後端
早年軟件，以Java開發為例，基本上JSP+SSH之類的或者JSP+SSM等之類的框架。基本上Java代碼+前端HTML+CSS+JS混合一體。如果代碼寫的不是那麼優美，看起來很難受。
如今，基本上都是前後端分離。
前端三大主流框架Vue.js、React.js、Angular.js等。
這三大框架基本上都體現了前端模塊化的思想。作為運維人員部署方面也很簡單，要麼服務器有node.js環境，要麼讓前端人員本地編譯好，將生成的dist目錄里的文件打成zip包直接上傳到nginx對應的目錄解壓即可。總而言之，運維人員得了解。
為什麼要適當了解前後端？
最基礎的就是針對請求的響應碼，要識別一些常用的響應碼，利於排錯，同時作為運維人員也要擅長瀏覽器調試。因為像有的公司做的項目是需要現場實施的，實施人員通常是運維，去客戶公司部署項目，確定項目是否部署成功，通常要結合一些前後端相關的知識。記憶比較深刻的是在第一家公司的時候，有一次運維同事和技術總監跟着去客戶公司調設備，技術總監之所以帶他去也是讓其熟悉這個環境，同時也讓他熟悉一些Java代碼(Client-Server通信)，因為回頭就得他一個人來客戶公司調，要求他能看懂這部分Java代碼。不能排除有的時候運維不僅僅是搗鼓一些服務器上的東西，可能還要求熟悉一些前後端代碼之類的。大家可以去Boss直聘上瞄一眼，中高級運維，基本上都要求至少熟悉一門編程語言，可以是Java，也可以是Go和Python。不過近年來Go和Python是比較多(Python做自動化運維是非常合適的)。當然了，基本上學計算機的，大家接觸了編程語言不可能只有一個。
六、總結
記得之前在公眾號看過一篇文章《遠見|美團王慧文清華演講:社會最稀缺的是π型人才》，這篇文章提到了社會最稀缺的是」π型人才」。
「π型人才」並不等於是全才(也不能等於什麼都了解、什麼都不精)，只是不給自己設限(不把自己圈在特定的地方，簡單的舉例說明，我既是一名Java程序員，又是產品的創造者之一，同時我也可以是一名業餘作家)。
我的前三家公司經理級別的領導基本上都符合這樣的。
第一家公司的技術總監
之前公司是沒有運維的，他獨立負責整個公司的運維。不僅僅這樣，如果項目急的時候，他也要上陣寫Java和一些前端代碼。平時他也是主要寫後端代碼和做數據庫設計方面的。
第二家公司的項目經理
他早年做過程序員，後來做產品經理，再後來運營總監等。
第三家公司的技術經理
他是一名後端程序員，後來不知由於什麼原因做起來前端。我和他在一起工作的時候，發現他每天和我們一樣，除了開產品會就是在寫代碼或者是做少部分管理工作。
結合我這些年的工作經驗來看，無論是開發、測試、運維等，它們都共同涉及一個點，那就是工作的」原則」(包含工作的方法論),每家公司的研發流程不一樣，但工作的原則是可以復用的。
