畢業後，一直從事著J2EE開發，每天面對的就是程式碼、業務、測試。除了找運維上線，基本運維和我沒搭邊。當然心中有信念，如果線上出了問題就求助運維。久而久之，感覺運維有點像7*24小時的客服，因為混跡在各個公司技術群裡，所以經常聽到各種事故在聯絡運維。
比如：
XXX頁面不能正常訪問了
XXX頁面訪問的時候特別慢
XXX資料庫連線不上了
XXX頁面資料顯示錯誤
XXX表單提交不了，按鈕點選沒反應
…….

一個偶然的機會讓自己也踏上了運維的路。。。以下就大概談談運維涉及的一些方面，筆者對運維的理解不深，很多地方也只是丟擲運維面臨的問題，想到哪就寫到哪，講的內容也比較片面，希望大家不要太介意，純屬讓大家對運維有一個簡單的瞭解
下面我就來，拋磚引玉。。。
1、設施服務
首先談下機房，他有一個比較高上大的名字，網際網路資料中心(Internet Data Center)。
機房裡有機櫃、伺服器、交換機、儲存、網線、光纖\防火牆、郵件服務系統、DNS伺服器，路由，光纖配線架、資料配線架、語音配線架等等。以及一系列繁瑣的事情，機器上架、裝置調通、引數配置、故障處理等等其他各種。有一個特別有意思的東西：利用一些網絡卡都支援的功能，進行遠端開關機Wake onLAN(WOL)，俗稱遠端喚醒。
複雜的特性就不多說了，直接上圖

Ps：好的運維，可以將機房打理的整整有條。

再講講網路，中國網路的核心層由北京、上海、廣州、瀋陽、南京、武漢、成都、西安8個城市的核心節點組成。理所當然這些核心節點的網路，肯定會比較好。。。關於網路的運營商，就比較多了。我們平時所瞭解的國內六大運營商指的是中國移動，中國聯通，中國電信，中國網通，中國鐵通和中國衛通。在IDC領域，中國電信無疑是業務規模最大網路資源最多的，華東沿海、華南沿海以及西南地區都是電信的主要覆蓋範圍；中國網通名列第二，網通的機房網路與電信“隔長江而治”，主要分佈於華北以及周邊地區；中國鐵通位則列第三，主要資源集中在華北、東北；移動、聯通這些也有少部分機房資源，不過一般是合作方式，機房規模也不大，拿電信少量的頻寬。 各個運營商網路之間互通，會存在問題，可想而知多個IDC之間同樣也會存在網路問題。我也終於體驗了，你的專案被部署在不同的網路節點，帶來的 “訪問不了”“訪問慢”問題排查點就多了。
當然現在雲（如Aws、Azure、阿里雲等）的興起，遮蔽了idc很多底層的這些問題。
2、資源管理
首先伺服器（虛擬機器）管理， 關於作業系統： 系統補丁漏洞升級、核心微調、維護不同的作業系統、搭建不同的產品依賴環境等等，針對大規模的伺服器，批量操作想想是不是特別過癮？當然批量操作的工具也特別多，比如說puppet、saltstack、ansible等等，這樣方便的工具，如果執行了刪除這樣危險的操作，後果也是很難預料的。再者就是計算資源，用虛擬化的方式去管理你機器上的硬體資源。簡單點說，就是能把cpu、記憶體這些東西進行虛擬化管理。有一些商業軟體，如vmware，網際網路公司會用一些開源的軟體，如cloudstack、openstack等雲端計算平臺。這樣做有什麼好處了？當你某天找到運維說，你需要一臺X核X G記憶體Centos伺服器用來做測試，而運維利用這些工具可以很快的做出一臺這樣的虛擬機器。
再講講儲存資源，從儲存解決方案(如RAID 5 是一種儲存效能、資料安全和儲存成本兼顧的解決方案)，到一些 常用的一些分散式儲存（這種機制可以很方便的進行磁碟掛載、擴容、回收、備份等等）。也會有一些開源的軟體，如ceph、swift儲存等等。儲存的幾種型別，如物件儲存：儲存一個視訊檔案或者圖片檔案，返回給使用者的是一個訪問的連結地址。塊儲存：簡單的理解為一塊可以移動、方便擴容的磁碟。分散式檔案儲存，可理解為一個超大型的檔案系統，可以儲存任意型別的檔案，可以把一個超大的檔案，切割成多份放在不同的伺服器上，然後進行分散式計算，比如說hdfs）
最後講講業務管理，不同的業務對應到不同的伺服器，當一伺服器上部署多個業務，或者還有複雜的業務依賴關係，想想看掛掉後帶來的後果。如何去維護，並且快速恢復，這對運維人員的troubleshoot，都要求很高。儘管有時候一個很簡單的問題，解決它只需要1分鐘，但是定位它就沒那麼easy了。舉個簡單場景的例子，假設有A、B、C、D四個系統，A依賴B，B依賴C，C依賴D，如果C掛了，該怎麼辦？使用者在使用A時，發現用不了C的服務，如果這是一個秒殺活動或者是限時活動，就有可能會導致雪崩效應，因為使用者往往是發現用不了服務，就會不停的重新整理頁面，導致C的整個應用叢集掛掉。可以腦補一下那位正在排查問題的運維同學額頭上的汗珠。。。
最後借用一個別人的管理資源的圖

4、資料庫
維護資料庫，也並不是簡單的增刪改查。就拿oracle與mysql來說。
oracle的行級鎖，比較好，併發效能自然就要好很多，對事務支援的比較好，事務的隔離級別也支援的比較好，回滾、備份與恢復機制也做的相當不錯。並且還有比較好用的查詢優化器，主要有rbo（如hint）與cbo（如分割槽表和分割槽索引）的方式，目前比較推薦的是cbo優化器。商業化的資料庫，比較重量級，要去了解的東西也特別多，當然好用的工具也特別多
再談談mysql，首先上個主從,主庫負責寫入資料，從庫負責資料庫讀的操作。
原理圖很簡單，如下：

但是要做的事情卻不少，我們先要確保資料庫的資料同步，並定時備份，全量備份會鎖表，不能寫入資料。這個鎖的問題，也是運維經常要處理的事情。如果僅僅只是全量備份資料，那就會丟失資料，因此要思考如何熱備份，主從的架構，如果是主庫掛了又怎麼辦？面試的時候還經常被問到，如果XX多少的併發同時訪問資料庫，該怎麼優化？你能找到這個瓶頸在哪裡嗎？每秒的TPS（每秒處理的事務數）、QPS(每秒處理的查詢數)有多少？
最後談談其他型別的Nosql資料庫，它們常用來快取或處理一些大資料等，這裡面的元件也特別多，對於不同的業務場景選取的元件也不一樣，你能舉出它們各自的適用場景嗎？比如Cassandra、Mongodb、 Redis、Memcached、 Riak、Membase、Neo4j 、HBase、CouchDB…..為了系統有大幅度的響應速度提升，總得來幾個吧，這又得多大的維護成本，首先得高可用搞個分散式吧？然後熱備、災備、遷移。。。這些工作也得做全套吧！當然還時不時會有點詭異的故障要排查!!!
5、安全
這個問題在任何一家企業，想做，可以做得很大很大，當然也可簡單做，但是如果做不好，甚至會讓公司倒閉。資料的安全對一個公司來說，真的很重要。做安全不僅需要了解整個公司的大局形式，而且還得深入到程式碼實現細節漏洞。不僅要確保公司的安全，還得抵得住入侵。比如說自己弄個弱密碼庫，不停的去撞庫，確保公司內部沒有弱密碼。記得有次伺服器ssh使用了弱密碼，被人登入後弄了個病毒軟體在不停的向外發起訪問請求，流量直接達到了GB每秒。對於購買了雲主機的伺服器，這些流量的產生是會直接生成很高費用的。或者再搞個Sqlmap，弄弄有沒有什麼sql注入，這是個一直被強調，一直會發生的問題。再來個埠掃描的工具，做做滲透測試。突發性的安全問題，被人DDOS、域名劫持、xss攻擊、GetShell。偶爾還搞出個openssl心臟出血，然後再來個Struts2漏洞。網際網路的安全不容小覷，新聞中經常看到各種公司被幹（如最近京東數千萬使用者12G資料疑洩露），總感覺自己的隱私資料每一天都在裸奔當中？
以是一張OSSIM的圖（open source security information management：開源安全資訊管理系統)

6、部署
現在終於體會到了，網際網路快速迭代的開發模式，需要不停的持續交付，開發出某個新功能立馬上線能看到效果，每一次生產環境部署的都心驚膽戰。生產環境故障頻出，整個人都不好了！如果一個開放人員寫出不好的程式碼，上線之後問題頻出，需要檢視生產環境日誌。每天leader各種群裡催促緊急bug修復，研發不停催促，需要趕快上線，這壓力已經夠大。。。而且時不時各種突發狀況，被各種問題打斷後仍然冷靜的連線之前思緒troubleshoot，到底是經歷了什麼才可以練就如此好的心態。所以我們也只能躲在了夜深人靜的夜裡，一個人偷偷的上線，發現問題，立馬回滾。
7、日誌
對於各類日誌，一套完美的分散式日誌收集與檢視的解決方案，顯得尤為重要。主要包括有安全日誌的收集、訪問日誌的收集、應用程式的日誌收集等等。要把各個伺服器的上的日誌收集起來進行分析，對於問題的排查與定位速度，可以說是幾何倍的增長。就簡單談談，目前瞭解到ELK這樣一套比較好的方式，

Logstash負責收集日誌，然後寫入到ElasticSearch，最後通過Kibana展示出來。雖然運用開源軟體的特性，配合上文件可以很快搭建一套環境，但是其中要了解的細節確實太多太多。
比如Logstash日誌切割問題？資料量比較大時，有效能問題，怎麼辦？怎麼樣配合其他的日誌收集方式（如syslog、flume等等）？怎麼結合其他的訊息中介軟體（如kafka）？後面如何接入Storm這種流式計算框架？又如何配合hadoop做離線的計算？是否有網路問題？
再談談Elasticsearch，一個基於Lucene（lucene原理與程式碼分析）全文檢索的分散式框架。全文檢索主要是針對非結構化的資料，那非結構化的資料又是如何儲存，並被快速檢索的？倒排索引又是什麼？首先得去了解一些底層的實現細節，因為當你使用Elasticsearch時，要維護叢集的穩定性，你就會發現資料量變的大時，需要不停的去調優，同時增加了運維的難度。。。
Kibana負責展示，自已可以定製很多個性化的dashboard面板。如下圖

8、報警
這個也挺有意思的，對於開發或者是運維來說，如果線上發現問題，能第一時間通過簡訊或者郵件、語音的方式告訴大家，是不是一件很爽的事情？當然這裡也有很多開源的解決方案，如zabbix、nagios等。報警的延遲性、精準性、穩定性也給運維人員帶來了很大的挑戰。監控的範圍很廣，當然基礎的運維監控也必不可少，比如機器Down了、網路不通、訪問延遲高、磁碟滿了、伺服器負載過高、tomat掛了、頁面5XX過多等等，每一個警告都需要運維去處理好。目前，應用效能檢測（Application Performance Monitor (APM)）也在逐步的興起，監控的粒度也特別細，就拿一點簡單的來說，可以檢測到某個專案中某一行程式碼的響應時間。有一些工具，比如說大眾點評開源的Java實時應用監控平臺:CAT。有興趣的同學，也可去試試聽雲或者是OneAPM的產品。
附上一張zabbix監控圖表截圖

9、自動化
最近這些年，比較提倡運維自動化。有一個稱呼叫DevOps（英文Development和Operations的組合），當然跟Google的SRESite Reliability Engineer (網站可靠性工程師)相比，相差還甚遠。說的通俗點，就是開發一些方便的工具，提供給運維使用。那怎麼樣才算做到自動化了？首先得解放運維人員，其次就是方便開發人員。自動化運維體系比較大，比方說流程規範、部署規範、配置規範等等。
這邊就簡單的講一講，比如說
資產管理系統：用系統把物理資源與邏輯資源進行統一管理
自動化部署：可以很方便的一鍵部署你的應用到伺服器上
故障自動恢復：檢測報警，自動恢復故障
資料庫與快取管理：支援快速申請資料庫資源、恢復、回滾等操作
配置管理平臺：通過介面推送全網配置或者安裝環境
等等其他。當然你也可以鑑於自己對於運維的理解，快速開發出一些方便實用的工具。
運維問題特別多，經常需要去利用搜索引擎。附上一些查詢的簡單語法
 精確查詢—— 使用雙引號。表示查詢詞不能被拆分
如“點融科技”
 不包括某個詞——使用減號。使用+ 進行限制性檢索，相當於And
如搜尋包含“點融科技”，不包含“風險”的內容 eg：點融科技 -風險
如 查詢同事包含“水果”與“蘋果”的內容 eg：水果+蘋果
 並行搜尋——兩個詞用“|”隔開。同時搜尋多個關鍵字
如 網易新聞 | 點融網
 “site:”+“網站名”。
如在點融網的網站下搜尋如何理財。
eg：site:dianrong.com 如何理財
eg：site:http://pan.baidu.com/ java視訊
 指定格式搜——在關鍵詞前面加“Filetype:+格式”
如搜尋包含點融的pdf文件eg：Filetype:pdf 點融
 只在標題中出現關鍵詞——前面加intitle:
如在網站標題中出現“知乎”與 “點融網”的title eg：intitle:知乎 點融網
 Intext–正文檢索.和標題搜尋相比，正文檢索的搜尋目標更明確，而且適合於一次性搜尋同一主題的不同分支內容
eg：intext:點融網招聘
 Inurl–直攻URL連結
如 搜尋包含” 點融科技” 且url中包含photo的內容eg：點融 inurl:photo