發佈變動流程管理工具:作爲系統接口與其餘角色的工做銜接。並提供審批環節控制發佈變動的風險。流程管理工具並不負責具體的業務操做的執行,只是做爲單據系統跟蹤流程和確保閉環。docker
告警和突發管理工具:體現業務受損的告警自動建單管理。人工確認以後升級爲突發單。經過建單管理告警和突發確保流程的閉環,以及每次故障都可以總結出經驗,並未度量業務的可用性提供KPI。數據庫
版本管理工具(數據庫):全部的發佈應該以版本管理爲起點。研發給的版本包先入版本管理工具,再從版本管理工具分發到現網發佈。杜絕 rsync 一臺服務器發佈另一臺的作法。服務器
配置管理工具(數據庫):版本加配置等於現網每臺機器的狀態。最粗粒度的配置管理是到 IP 級別,至關於對機器作資產管理,分組到不一樣的業務,模塊和大區等業務概念上。細粒度一點會管理到進程以及進程的相關的配置。微信
配置和版本下發工具:把指定的版本,結合配置好的配置下發到現網的機器上。不一樣的版本和配置方式須要徹底不一樣的下發方式。以 ssh/fabric 爲表明的下發方式是以腳本爲中心的。以 puppet/chef 爲表明的下發方式是以配置爲中心的。網絡
現網狀態同步工具:爲了規避現網狀態漂移,與管理工具內的記錄不一致。須要有一個工具定時上報現網的實際情況。併發
服務調度工具:發佈變動常常須要一個串行的流程,先作A模塊,再作B模塊。不少機器的時候,須要把能併發的操做併發執行,不能併發的操做確保串行執行。同時不少發佈變動流程須要操做管理範圍外的服務,好比雲端的DNS服務器記錄等。這就須要有一個服務調度工具統一調度配置和版本下發工具,流程單據工具,以及其餘系統的API接口共同組裝成一個流程。運維
資源管理和隔離工具:以xen/kvm爲表明的工具讓運維能夠更靈活的切割資源。好比虛擬機的快速起停,ip在idc內的漂移等。以 lxc/docker 爲表明的工具讓運維能夠進一步的切割資源到進程級別。資源隔離代理的細粒度的資源控制能夠得到更好的資源利用率,以及更容易進行可伸縮的資源配置。ssh
發佈變動統一界面:包裝全部的下層工具,提供簡單的界面完成標準化的發佈變動操做。工具
採集工具:通常是採集日誌文件,也能夠是定時輪詢 DB 或者其餘系統的接口。流行的開源方案是 logstash。代理
收集工具:採集工具上報給收集工具。或者由開發直接修改代碼上報指標給收集工具。流程的開源方案仍是 logstash。
統計入庫工具:上報多是每次調用就上報一次,統計工具負責統計出一分鐘內的次數。上報也多是每5秒上報一次數值,統計工具負責統計出一分鐘內的最大值。統計工具的存在是爲了上報的方便。流行的開源方案是 statsd,也有大公司基於 storm 來作二次開發的。
時間序列數據庫:全部定時指標會落地到數據庫裏。監控告警所須要的數據庫須要可以支撐很是大的數據量,可是並無很嚴格的 ACID 要求。
運維事件數據庫:記錄全部的告警。包括從其餘系統得到告警,以及對現網的全部變動操做記錄。這些數據用於支撐告警的緣由定位。
指標異常檢測工具:基於數學模型發現指標是否與過去的穩定模式背離,而推測出現網狀態的變化。
撥測工具:定時 PING 或者 HTTP GET,模擬實際用戶發現服務是否中斷,產生告警。同時也產生指標上報給收集系統。撥測又分爲本地撥測,和遠程撥測。本地撥測能夠用於發現磁盤只讀等本機告警。遠程撥測能夠模擬用戶的地理分佈,把網絡的鏈路情況也包含在撥測覆蓋的範圍內。
告警收斂工具:綜合全部來源的告警,進行頻率收斂,根源分析。統一彙總成報告催促人工修復。
告警自動修復工具:接受告警進行自動化的處理。幫運維完成固定的故障機下架退庫等操做。或者在業務自己沒有作高可用的狀況下,作故障機替換,ip漂移等現網修復操做,必定程度地提升業務可用性。
告警通知工具:重要的告警須要升級爲電話。須要有高可用的電話,短信,微信等通知接口。
監控告警統一界面:屏蔽下層各類工具,提供統一的agent安裝,指標採集設置,指標曲線展現,告警查詢的界面。一個地方知道現網的全部的問題。