概述
應用上線後，運維工作才剛開始，具體工作可能包括：升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、集群管理、服務性能評估優化、數據庫管理優化、隨著應用PV增減進行應用架構的伸縮、安全、運維開發工作。
今天重點介紹運維流程管理、運維發佈變更、運維監控告警三個方面所需要的工具。
1、運維流程管理工具
1.發佈變更流程管理工具
做為系統接口與其他角色的工作銜接。並提供審批環節控制發佈變更的風險。流程管理工具並不負責具體的業務操作的執行，只是作為單據系統跟蹤流程和確保閉環。
2.告警和突發管理工具
體現業務受損的告警自動建單管理。人工確認之後升級為突發單。通過建單來管理告警和突發確保流程的閉環，以及每次故障都能夠總結出經驗，併為度量業務的可用性提供KPI。
2、運維發佈變更工具
1.版本管理工具（數據庫）
所有的發佈應該以版本管理為起點。研發給的版本包先入版本管理工具，再從版本管理工具分發到現網發佈。杜絕 rsync 一臺服務器發佈另外一臺的做法。
2.配置管理工具（數據庫）
版本加配置等於現網每臺機器的狀態。最粗粒度的配置管理是到 IP 級別，相當於對機器做資產管理，分組到不同的業務，模塊和大區等業務概念上。細粒度一點會管理到進程以及進程的相關配置。
3.配置和版本下發工具
把指定的版本，結合配置好的配置下發到現網的機器上。不同的版本和配置方式需要完全不同的下發方式。以 ssh/fabric 為代表的下發方式是以腳本為中心的。以 puppet/chef 為代表的下發方式是以配置為中心的。
4.現網狀態同步工具
為了規避現網狀態漂移，與管理工具內的記錄不一致。需要有一個工具定時上報現網的實際狀況。
5.服務調度工具
發佈變更經常需要一個串行的流程，先做A模塊，再做B模塊。很多機器的時候，需要把能併發的操作併發執行，不能併發的操作確保串行執行。同時很多發佈變更流程需要操作管理範圍外的服務，比如雲端的DNS服務器記錄等。這就需要有一個服務調度工具統一調度配置和版本下發工具，流程單據工具，以及其他系統的API接口共同組裝成一個流程。
6.資源管理和隔離工具
以xen/kvm為代表的工具讓運維可以更靈活的切割資源。比如虛擬機的快速起停，ip在idc內的漂移等。以 lxc/docker 為代表的工具讓運維可以進一步的切割資源到進程級別。資源隔離代理的細粒度的資源控制可以獲得更好的資源利用率，以及更容易進行可伸縮的資源配置。
7.發佈變更統一界面
包裝所有的下層工具，提供簡單的界面完成標準化的發佈變更操作。
3、運維監控告警工具
1.採集工具
一般是採集日誌文件，也可以是定時輪詢 DB 或者其他系統的接口。流行的開源方案是 logstash。
2.收集工具
採集工具上報給收集工具。或者由開發直接修改代碼上報指標給收集工具。流程的開源方案還是 logstash。
3.統計入庫工具
上報可能是每次調用就上報一次，統計工具負責統計出一分鐘內的次數。上報也可能是每5秒上報一次數值，統計工具負責統計出一分鐘內的最大值。統計工具的存在是為了上報的方便。流行的開源方案是 statsd，也有大公司基於 storm 來做二次開發的。
4.時間序列數據庫
所有定時指標會落地到數據庫裡。監控告警所需要的數據庫需要能夠支撐非常大的數據量，但是並沒有很嚴格的 ACID 要求。
5.運維事件數據庫
記錄所有的告警。包括從其他系統獲得告警，以及對現網的所有變更操作記錄。這些數據用於支撐告警的原因定位。
6.指標異常檢測工具
基於數學模型發現指標是否與過去的穩定模式背離，而推測出現網狀態的變化。
7.撥測工具
定時 PING 或者 HTTP GET，模擬實際用戶發現服務是否中斷，產生告警。同時也產生指標上報給收集系統。撥測又分為本地撥測，和遠程撥測。本地撥測可以用於發現磁盤只讀等本機告警。遠程撥測可以模擬用戶的地理分佈，把網絡的鏈路狀況也包含在撥測覆蓋的範圍內。
8.告警收斂工具
綜合所有來源的告警，進行頻率收斂，根源分析。統一彙總成報告催促人工修復。
9.告警自動修復工具
接受告警進行自動化的處理。幫運維完成固定的故障機下架退庫等操作。或者在業務本身沒有做高可用的情況下，做故障機替換，ip漂移等現網修復操作，一定程度地提高業務可用性。
10.告警通知工具
重要的告警需要升級為電話。需要有高可用的電話，短信，微信等通知接口。
11.監控告警統一界面
屏蔽下層各種工具，提供統一的agent安裝，指標採集設置，指標曲線展示，告警查詢的界面。從一個地方就可以知道現網的所有問題。
篇幅有限，關於linux運維管理工具方面的內容就介紹到這，實際上基本是隻有在甲方才有可能實現的比較完整，大家也可以針對性去做一個瞭解。
後面會分享更多關於devops和DBA方面內容，感興趣的朋友可以關注下！
閱讀更多 波波說運維 的文章
