隨著運維的復雜和繁瑣化，運維工作也在進行職責的細分，比如：基礎運維、系統運維、應用運維，見名識意大概能猜出其職責，基礎運維偏重基礎資源，系統運維偏重系統也就是自動化運維，其中應用運維是近年新出來的名詞，其既要對系統負責又要對產品的用戶體驗和成本負責，這就要求運維人員在做好日常系統運維的基礎上，深入研究業務，研究產品架構和數據流。隨著微服務設計理念的普及，一個大型應用被拆分成多個微服務，雖然帶來了諸多益處，但各微服務間的調用錯綜復雜，增加了運維、排障、調優的難度，而應用運維就是為了解決這個問題而產生的，工作中要與開發、基礎運維、DBA、CDN等各部門打交道，主導問題解決。

  一個應用運維腦袋里至少要有產品業務邏輯架構圖、數據請求流程圖、服務器部署架構圖這3張圖，結合各種運維工具，當出現故障能第一時間定位是哪個微服務、哪個機房、哪個負載均衡、哪臺服務器、哪幾行代碼導致，并找到相應的負責人，第一時間進行問題解決，如果短時間解決不了進行相應的故障升級、業務降級、流量調度。而且應用運維在心中應該有一本賬，知道系統架構的短板在哪，為了提升整個系統的性能和吞吐量，如何進行優化；在有新的功能和應用場景時，跟隨開發共同研究解決方案，評估技術可行性和業務邏輯的合理性，為公司節約基礎成本，因為微服務的一個改動可能就會惡性影響到上下游資源，特別是在業務量大的場景，多調用一次每天可能就會多1000萬次請求，少調用一次可能就會優化500萬次請求，上下游依賴的微服務容量以及跨南北調用的問題等都要考慮。

  從繁瑣的工作中尋找規律，應用運維拆分收斂后基本上就是三塊：圍繞數據、圍繞運維管理、圍繞產品本身三大部分，其中圍繞數據的包含告警、監控、數據分析、異常檢測、性能分析，圍繞運維管理的包含資產管理、配置管理、代碼上線、服務調度，圍繞產品本身的包含調優、消峰、降級、容災，其余的事情基本都是基礎運維處理，下面拿我負責的內容服務平臺的前端業務做一個拋磚引玉應用運維的介紹。

內容服務平臺的總體概述：

  公司的內容服務平臺是一個微服務架構設計的大型內容管理系統，上行寫入面向公司編輯和抓站，下行是在線的頁面、接口、文件（圖片）和裁圖服務，為了靈活應對消峰和系統迭代開發等場景，系統做了徹底的服務化和組件化拆分，模塊間通過HTTP型API進行調用，一些模塊通過消息中間件進行異步解耦。內容服務平臺在公司的一個生態位置圖如下：

  從上圖看，內容服務平臺是一個核心的數據源，同時提供了4大塊在線服務，在此之上生長了各種應用。各產品可以直接在頁面服務模塊開發應用，如果是APP類也可以通過接口服務獲取平臺的內容和功能再自行處理，下面以此產品為例展開介紹運維工作圍繞數據、圍繞運維管理、圍繞產品本身的三塊內容。

一、圍繞數據

  圍繞數據都有哪些事兒呢？順著數據去考慮，比如監控告警、異常檢測、日志分析、性能分析、機器學習等等，其中圍繞數據的應用核心三點是數據采集、分析和使用。

  一個系統在運行中會產生各種數據，而產品的健康狀況就藏在這些數據里，應用運維需要通過各種手段和工具將這些數據收集起來，并對其收斂做成監控，進而對監控收斂做成告警。我們通過告警發現故障、監控定位故障點、產品運維處理分發故障，短時間解決不了的，進行故障升級、業務降級、切換流量。為了能夠將還沒有形成故障的薄弱接口提前暴露出來優化解決，預防故障，我們依托歷史數據做了異常檢測，每天將前一天的薄弱接口計算出來，發給此接口的最近修改人，推動其優化。

  隨著用戶量的增加和系統的更加復雜化，慢慢就有了監控每個環節性能的需求，如果從用戶的訪問流考慮，把每個環節都做埋點日志打出來，就可以做到產品的APM性能分析，從而掌握每個環節的健康情況，總之圍繞數據的應用有足夠多的想象空間，最終可以通過機器學習來尋找更多的數據規律，為各層面的人員提供服務。

  目前內容服務平臺每天產生的數據在2T以上，畫了一個圍繞數據的整體架構圖如下：

  我們將監控告警從整體上分為了系統層和應用層，系統層的基礎監控（cpu、內存、網絡、硬盤io）通過zabbix來實現，應用層面的監控告警走數據分析的渠道。

  我們每天的異常檢測的幾張圖表如下（在此多謝雄飛同學的一起研究貢獻）：

二、圍繞運維管理

  運維管理是比較老生常談的東西，從運維這個工種出現開始大家就一直在做，做到現在收斂總結一下基本就是資產管理、配置管理、代碼上線、服務調度降級管理四塊，當然根據產品屬性的不同有一些個性化的管理工具，那個就另說了。

  我們現在資產管理自己開發的，配管用的puppet和salt，底層套了版本管理，用戶層加了ui界面，代碼上線和服務調度降級也是個性化開發的，作為一個有歷史的互聯網公司，其實運維對運維管理這塊更多是理解和應用而不是搭建開發的層面，因為很多這些工具都有前輩做好了，運維管理這一塊就不展開說了。

三、圍繞產品本身

  能做到每天上班喝著茶看著報紙的產品運維其實不存在，隨著業務系統的迭代和應用場景的變化等，產品和集群架構的各種工作其實沒有停歇，好在多機房多服務器部署對于容災做的很成熟，即使有單臺服務器或單個機房有問題也可以自動負載調度，繁瑣的工作中總結了這些方法論。

  拿內容服務平臺里的動態前端模塊做例子，微服務化拆分后，它作為下行用戶體驗的一個核心體現，系統是nginx+php-fpm的結構，作為接口層（HTTP API）和用戶接入層對外服務，目前服務的業務域名有200個，功能接口上萬個，日訪問量在7到10個億，平均響應時間從我接手時139ms優化到現在已經到了30ms，只有網民的讀沒有寫場景（評論調第三方接口，平臺本身不提供功能），但后端php會根據不同ua、args、reffer、cookie判斷吐不同的html頁面，會通過HTTP API調用為其他業務系統提供數據，典型的前端型業務，由于為N多個業務部門提供服務，并且開放權限申請和域名接入，其后在平臺上各自編寫代碼，所以我稱作其為平臺型前端業務。在操作上，開通域名站點和權限后，業務開發登錄后臺，按照規則在微服務主應用平臺上編寫代碼，然后審核上線到動態前端的服務器上對外服務，動態前端完成了頁面渲染、php路由、功能調用和緩存功能（使用MC和reids），同時也依賴了大量外部接口，這些接口通過curl和js（ajax）進行調用。在劃分上，接口層是作為功能應用（HTTP API）吐的是json串，無狀態的為其它業務模塊服務，用戶接入層就是直接面向網民的訪問服務。

1、調優 

  1）系統軟件的調優

  系統軟件的調優指的是centos、nginx、php-fpm、ats等這種軟件的軟調優，這種調優雖然比不上加機器，但是也是非常非常重要的。比如在我接手這個業務時，動態前端使用的是nginx1.4.7版本，由于也沒出什么問題就一直沒動，后來在升級了tengine2.1.2之后，調整了一些參數，平均響應時間提升了將近一半，所以系統軟件的調優也是不容小看的。系統軟件的調優包含系統軟件的版本升級和系統軟件的參數的調整優化。

  2）業務分池故障隔離調優

  任何做法都有其原因，比如說N多業務使用一套CMS，前端訪問使用一個大池子，而不是每個業務單獨來一套，其實是共享的概念，這種共享做法的好處自不必多說，大大減少了資源浪費和節約了人力成本。但隨著加入業務的越來越多，關聯調用越來越復雜，訪問量越來越大，系統的高可用性越來越重要，因為出故障的影響越來越嚴重，隨之帶來了各種大系統病。

  比如說動態前端，用戶訪問雖然會通過dns智能解析把不同請求分發到不同機房，但從業務邏輯看終究是一個大池子，如果某個業務接口或頁面模板有問題，會瞬間把php進程池堵死，到時不分誰的業務，全部報錯，結果就是個別業務代碼影響到了全部業務。分析后，分池隔離是勢在必行的一個事兒，一來減少業務間的相互影響，二來讓優質的業務跑的更健壯。然后分析服務屬性，發現有兩類業務，一類是直接面向網民的用戶接入層，這類訪問受最后一公里上網環境的影響，更容易出各種問題，另一個是作為微服務提供HTTP API功能調用吐的是json串，這個一般是外部系統過來的功能調用，環境相對簡單。將這兩個業務拆開成頁面池和接口池后，理論上故障減少一半，整個業務更加健壯。

  分池是一種隔離方法，可以完全通過調度分發實現，不需要開發重構代碼，隨著業務的變化，可靈活實施拆分，比如結合業務方需求，將需要重保的業務分出來、將訪問量大的業務分出來、將危險的接口分出來。。。。所謂道法自然，術變萬千。

  3）程序執行時間限制調優

  作為一個平臺，為了保障整體業務的健壯，必須通過時間限制割肉放棄慢或錯誤的請求，俗話說不能因為“幾顆老鼠屎壞了一鍋湯”，程序執行時間限制分為兩個層次，一個是外部php woker進程允許的php腳本的最大執行時間，另一個是腳本代碼里通過curl依賴的外部接口的時間限制。

  對于php worker進程的時間限制，分池后，同一個池子還是混跑著各種接口，如果某個業務的代碼有問題，將php資源池堵死，同池內的其它業務同樣會受到牽連，為防止這個問題，必須要做php的執行時間限制，將執行慢的業務割肉拋棄，不至于影響總體業務，慢請求達到指定時間后馬上殺掉，返回502代碼。配置后，反向倒逼業務方對自個兒的代碼和邏輯進行調優，定期將502/504的top排名發給業務方，給他們以壓力，對應的配置如下：

  對于程序中curl的時間限制，升級lib庫后已支持到ms級控制，可以根據接口的情況進行限制，系統有一個整體閥值。比如說我們當前的限制，所有接口默認超時時間是1s，最長容忍設置為2秒，ms級的控制業務方可以自行配置，因為當訪問量上來后，各業務方必須對自個兒的用戶體驗負責。最長容忍設置為2s，同時也倒逼業務方對其使用的接口進行不斷調優。

  4）依賴資源local化調優

  這個是最常識，但是又最容易被忽略的地方，比如說動態前端依賴了mc、redis這些緩存資源，能做到本機房、同網段、同交換機效率是最高的，最次也是同內網跨機房，少一個節點，就少一個故障點，少一個資源消耗。對于通過curl或者js依賴的接口，要做到不跨南北、不跨運營商調用，否則單看網絡時延就夠大的，而且可能丟包，實際操作中其實很難做到，所以對于實時性不是非常強的接口，要對接口的緩存結果做下curl的cache。

  5）HTTP API提供內網接口調優

  一個HTTP API功能接口，通過域名解析到公網IP進行調用，如果大部分調用是由公司內部系統發起的，那么就沒必要走公網透傳一遍，這個時候就需要做一個解析到內網IP供內網調用的域名，也就是做一個內網接口，減少網絡時延消耗和故障率。

  動態前端有一塊功能是為其他業務系統提供HTTP API的接口調用，吐的是json串，有很大一部分請求是公司內部系統發起，在結構上，我們接口域名解析到公司的外網vip（lvs），vip下屬掛著7層的Ha，下面才是我們的服務器，走外網調用相當于這些全部環節透傳一遍，還要走外網網關、外網鏈路、外網帶寬，而做好內網接口后，故障少了的同時也提高了系統性能。

  6）本地內存和網絡緩存的二級緩存模式

  這個很重要，像cms當前的業務，我們為開發在本地服務器上安裝了php的yac擴展，配置了key64M和value1024M的緩存供其使用。開發在使用一些熱資源時，進行本地和遠程mc或redis的雙寫，讀取時先在本地內存找，本地找不到再到mc或redis上回源，遠程也沒有再進行穿透，這大大提高了系統的吞吐量和性能，同時呢也起到了一定的削峰作用，相當于每臺服務器都有一個高速緩存，mc或者redis成為了他們的回源緩存，速度可想而知。

2、削峰

  隨著業務和技術發展，push類的業務成為一種需要常態應對的場景，熱點事件、熱點活動。。。。可以看下我們的QPS圖，這種場景的處理已經很迫切，需要找出峰值的瓶頸點，找出解決方案，不影響服務，除了模塊提前擴容，簡單總結一下幾個做法。
                                                                  
       

  1）動靜分離后的cdn方案（訪問削峰）；

  對于下行訪問，分析出有峰值的域名業務，針對性處理，cdn結合輕量級緩存nginx cache是一個非常強悍的削峰方案（cdn本質其實就是類nginx cache加上調度）。適合的場景是靜態業務，要對一個域名做cdn得盡量動靜分離的徹底，而且域名下屬服務業務邏輯簡單。

  2）服務器輕量級nginx cache方案（訪問削峰）

  并不是所有的業務都適合cdn或做nginx cache。比如說目前的動態前端，很多服務會根據ua、args、reffer、cookie綜合判斷后吐一個內容，如果按照這四個合集再加上url做一個key，基本上沒有命中率的，反而是增加了業務復雜性。這就需要改造，在業務和cdn間取一個都能接受的方案，太復雜的判斷在cdn上是不好做的，cdn本身也是一個無狀態的服務。比如動態前端有個push屬性的域名業務，必須做削峰處理，分析后會根據ua、參數判斷吐兩份不同html，在業務方做了js的ua判斷改造，cdn做了個性化參數判斷后才上了cdn，削峰問題能夠解決，對各方來說都能松一口氣。

  3）消息隊列消費削峰（寫削峰、數據庫相關重邏輯削峰）；

  采用消息隊列是上行寫入、數據庫相關重邏輯、質量重點保障業務的削峰利器，以時間成本換取業務的正常服務，因為總有一些邏輯比較重的業務又是絕對性不能出錯的服務，像cms里寫入、發布環節的一些模塊，都是通過消息中間件進行解耦削峰的。

3、降級

  先說下什么是降級，所謂降級就是業務出問題時，還能夠降低要求為網民服務，不致于直接服務掛掉，最常用的做法有靜態化、返回默認值和摘掉接口。舉個簡單例子，動態前端的評論是依賴其他部門的系統，通過curl去獲取的評論、評論數等，一旦評論系統掛掉，假設我們緩存了最近一次拿的評論數據，就可以通過歷史緩存為網民展示出問題前的最近一次評論，雖然做不到實時展示，但至少系統沒有報錯，網民還是可以看到內容。或者使用將評論系統摘掉的策略，雖然用戶無法看到和使用評論，但至少能看到其它信息，不至于評論影響到全部業務，當然這個方式就比較重了，影響用戶體驗。

  與程序執行時間限制調優類似，降級也分兩個層次，一個是程序直接對外結果的降級，比如說html文件或者json串，另一個是程序內部寫的curl依賴接口的降級。第一個可以結合類nginx cahce來做，使用stale文件進行服務降級，也可通過程序靜態化實現，第二個就要程序層面實現了，下面會說一下我們實現的方式。

  1）php內curl獲取外部接口緩存降級，配合懲罰機制（程序自動）

  簡單說下實現，每次curl獲取數據后，同時將內容存入MC，形成一個最近1小時的歷史數據，當檢測到連續幾次curl超時或數據錯誤就默認接口出了問題，自動啟用降級，取MC最近一次可用的歷史數據為用戶服務，設置懲罰策略，比如說降級5分鐘后自動恢復業務，如果繼續出問題，就會循環往復這種操作。   

  2）html文件在判斷請求隊列達到閥值后自動降級（程序自動）

  類nginx cache方式不多說，簡單講講程序的做法。tcp連接數側面反應了任務隊列的處理情況，我們恰是通過判斷tcp連接隊列（80、9000端口的連接數）來控制降級的，程序會隔一段時間存一次正確的靜態化結果至服務器硬盤，當tcp連接隊列一旦超過閥值，表示業務可能有問題，立馬不再穿透到后端取數據，轉而取本機靜態化數據，當連接隊列恢復正常后，自動取消靜態化。

  3）手動降級（按外部接口、按服務url）

  這是作為產品運維要求開發部門做的一個功能，程序畢竟是死的，人是活的，有自動降級必定要有手動降級作為補充操作，一旦遇到必須手動降級的操作，如果有操作頁面，就不需要每次都去找開發改代碼。例如我想降級平臺某個url或一個curl依賴的接口，只需要按照要求輸入相關配置——url、降級時間、回源周期等，就可以立即降級了。

4、容災

  對于容災，也是一定要考慮的，包含機房間容災和機器間容災。我們現在的思路，絕大部分業務通過熱備加健康心跳來實現，在評估過的服務器基礎上，多加兩臺服務器，如果有服務器死掉，流量會自動調度到其余服務器上。

  比如說當前的cms，lvs下掛了ha集群，ha集群下面掛了我們的webserver，每一層都有健康心跳，當某臺服務器死掉后，流量會自動負載到其余活著的服務器上，當服務器起來后，流量再自動調度回來，為了提高用戶服務質量，同時做好容災，我們會把服務器分到不同的機房中去。