我對運維的思考

我是一名Java後端研發工程師，在個人職業生涯中，曾作過一小段時間專業的運維，然後在一段很長的時間裏兼任過運維職責，只不過職責範圍在小和大之間來回奔跑。

1、Linux命令是基礎，萬變不離其宗

我所待的幾家公司，或多或少要作運維相關的工做，其中Linux是最經常使用的，這個Linux包含Linux經常使用命令和操做系統(如Debian、紅帽、Gentoo、Ubuntu、CentOS等)。其中我接觸最多的就是CentOS和Ubuntu。

爲何說Linux命令是基礎？

• 命令行界面以Linux命令做爲基礎，若是不會敲命令，也就沒法使用(各類軟件安裝和問題排查都涉及);

• shell腳本就是由一條條Linux命令組合而來，掌握好Linux命令，你就能夠寫出各類各樣的符合實際需求的腳本(服務監控、備份、項目部署等)。

另外再從另一個角度來看，不管是專業的運維人員或開發人員都須要掌握Linux命令，只不過程度不同，對於運維人員必須掌握牢靠，畢竟是吃飯的傢伙，對於開發人員，開發寫出來的項目大可能是部署在Linux上(有一部分是Windows Server)，涉及生產環境的問題排查，必然須要熟知一些經常使用的Linux命令。

2、自動化

自動化這塊對運維很是重要，自動化涉及最多的就是寫一些shell腳本放在特定的目錄歸類好，按需執行。

如今有不少現成的軟件能夠將一些工做自動化如(jenkins持續集成(拉取項目、自動編譯、發佈等)、zabbix自動監控服務器CPU、內存、磁盤和JVM、MySQL等、Ansible輕鬆管理上百臺服務器等)。

有人幽默地說:不擅長將工做自動化的運維不是好運維。

在我作運維相關的工做的時候，發現像部署或者一些軟件的備份和安裝就那麼幾條命令，敲來敲去，敲了N多遍，雖然能夠複製粘貼，可是感受仍是太過麻煩，因而寫一個shell腳本，只需一鍵執行便可。這樣一來就能夠節省更多的時間。

更多的時間能夠用來思考更多，比方說現有的運維體系哪些不是很完善或者是以前遺留的哪些問題(不那麼緊急但比較重要)能夠如今來解決。
再或者對於一些軟件它的一些設計原理和思想是什麼，也能夠研究研究。再或者是配置文件，爲何要這麼配置，每一個配置是什麼含義。

在我作運維的時候，網上搜索安裝和配置軟件，基本上就是複製過來一步步來，但後來發現有一點很差的就是我對於爲何這樣配置不知道，不知道意味着可能存在一些風險，運維人員要想進步成長，對一些軟件不只僅作到知其然，更要知其因此然(與咱們研發人員寫代碼同樣，不只僅要懂業務邏輯和代碼執行邏輯，同時也要知道所使用的庫，底層是如何處理的)。

安裝軟件誰都會，但要說到軟件的配置，如何配更合理更符合實際場景那就是一門比較深的功夫。

那麼如何作到自動化呢？

要養成」懶」的習慣，就和研發人員寫代碼同樣，發現多段重複的代碼，因而將其抽取爲一個方法進行調用(不用在複製來複制去，影響可讀行，同時也增長代碼行，代碼行越多確實不便閱讀)。運維人員常用Linux命令，在敲的過程當中總會可以發現哪些是重複屢次的，重複屢次的就能夠寫成一個shell腳本。

自動化的好處有哪些？

最直接的好處就是:你動腦思考了，思考如何簡化工做，提升效率。這樣一來給你直接帶來的就是實力的提高。

其它的好處就像上面說的，你能夠有更多的時間來思考如何作的更好或者學習(我第一家公司的運維同事在自動化方面作的很不錯，同時他的Linux功底也很是好，基本上工做作的特別快，效率也特別高，所以他有更多的時間去思考，去學習(業務或者技術層面)等)。

還有一個最重要的緣由，若是你不擅長將工做自動化，最後可能會累的要命。累的代價就是身心疲憊和中止思考(人在很是累的時候寫代碼，很是麻木，根本不知道本身在作什麼，只是在重複動做)。

3、要懂業務

在一些互聯網公司，開發人員不懂業務的話，工做幾乎沒辦法進行下去。對於運維人員來講，能夠不懂。這是我曾經的見解。

後來經歷多了，發現還真不是這樣。什麼樣的業務決定使用什麼樣的架構(邏輯架構(如分層:數據訪問層、業務邏輯層、表示層等)、開發架構(SDK和一些第三方庫等)、物理架構(部署和運行)、系統架構等)，其中物理架構(操做系統、網絡、服務器等)、數據架構(數據表設計、高可用、備份、複製等)。

根據合適的業務，選擇合適的架構。對架構師而言很是重要，對於運維人員也一樣如此。

同時懂業務對於運維人員排查問題也是頗有幫助的，由於懂流程，懂流程意味着能夠重現，重現問題過程當中，打開對應的日誌，這樣一來能準確的定位到問題，看是由於服務器的緣由仍是某個開發人員代碼寫的問題(服務器的緣由一般那段程序執行須要更多的內存，服務器內存可能不夠;代碼的緣由一般是一些判斷邏輯不是很完善致使程序沒有按照正常流程走)。這樣就能減小運維背鍋的機率，也能有理有據的反駁。

4、要有一套完整的運維機制

曾看過李鵬寫的《IT運維之道》這本書，大部分忘記了，但其中提到的IT運維四要事，至今印象還比較深入，作運維的朋友，能夠讀一讀，曾經在創業公司讀這本書的時候，受到一些啓發運用到實際中，提升效率很多。
這本書總結了IT運維的四件要事。我以爲講的很不錯。同時這四要素可構成一套完整的運維機制。四要素以下:

1.按運維原則作事

• 事前:講計劃、重承諾;
• 事中:講規範、重控制、有反饋;
• 過後:重效率、能應急、有保障。

2.掌握服務平衡

• 主動服務:服務者發起運維服務;
• 受理服務:用戶提出運維需求。

3.落實總體運維

• 軟件支撐系統;
• 應用系統;
• 計算機硬件設備;
• 機房和環境。

4.貫穿服務流程

• 事件流程;
• 問題流程;
• 配置管理流程;
• 變動流程;
• 發佈流程。

上述四要素每個部分要細說，均可以講不少內容。因爲我運維經歷頗有限，上述四要素並無所有接觸。但對於我感觸最深的是第一點按運維原則作事和第四點貫穿服務流程。這四要素你們可擇需而取。在個人職業生涯中，涉及到運維相關的工做，若是我有權把控的話，基本上會按照第一點來作(其實不只僅是運維，開發也同樣)。

5、適當瞭解先後端

早年軟件，以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作自動化運維是很是合適的)。固然了，基本上學計算機的，你們接觸了編程語言不可能只有一個。

6、總結

記得以前在公衆號看過一篇文章《遠見|美團王慧文清華演講:社會最稀缺的是π型人才》，這篇文章提到了社會最稀缺的是」π型人才」。

「π型人才」並不等因而全才(也不能等於什麼都瞭解、什麼都不精)，只是不給本身設限(不把本身圈在特定的地方，簡單的舉例說明，我既是一名Java程序員，又是產品的創造者之一，同時我也能夠是一名業餘做家)。

個人前三家公司經理級別的領導基本上都符合這樣的。

第一家公司的技術總監

以前公司是沒有運維的，他獨立負責整個公司的運維。不只僅這樣，若是項目急的時候，他也要上陣寫Java和一些前端代碼。平時他也是主要寫後端代碼和作數據庫設計方面的。

第二家公司的項目經理

他早年作過程序員，後來作產品經理，再後來運營總監等。

第三家公司的技術經理

他是一名後端程序員，後來不知因爲什麼緣由作起來前端。我和他在一塊兒工做的時候，發現他天天和咱們同樣，除了開產品會就是在寫代碼或者是作少部分管理工做。

結合我這些年的工做經驗來看，不管是開發、測試、運維等，它們都共同涉及一個點，那就是工做的」原則」(包含工做的方法論),每家公司的研發流程不同，但工做的原則是能夠複用的。