運維工程師不可避免得會遇到各種故障的情況，[可控]
是運維團隊追求的終極目標之一
包括故障的可控性，所以衍生出以下的子目標：
1. 降低故障概率
海恩法則：每一起嚴重事故的背後，必然有29次輕微事故和300次未遂先兆，以及1000個事故隱患。
用資料說話，統計各種異常的原因分布：
累計一段時間以來的資料，生成分布百分比圖，當某項原因突增可以及時發現
一般來說，**發布及運維變更（如機器增減、資料遷移、ip變更等）是兩大故障導火索。所以要抽象運維物件、減少人工干預、優化操作流程降低複雜度等。各個公司的團隊有自身的流程和步驟，不能一概而論，需要整個公司不僅僅運維部門的通力合作。
2. 迅速發現故障
基礎系統監控
基礎業務監控
高階業務監控
機器存活
埠可用
網路連通性
程序存活
服務超時
cpu日誌監控
資料一致性 記憶體
curl可用
關鍵元件可用 磁碟
容量監控
一般運維團隊都能做到基礎系統和基礎業務監控，但是高階業務監控才是衡量運維團隊的指標
對報警簡訊要分層、分類，再過濾掉重複冗餘資訊後，精準下發到各自應用的負責人。
3. 快速處理故障
把故障的處理分成三個子步驟：響應、定位、修復
響應的快慢取決於運維團隊的分工和職責劃分，理論上運維團隊需要做到7*24響應，到真正落實到每一位運維同事時，需要一定的激勵和懲罰措施，這個不多說。
定位故障需要運維團隊經驗的傳承和分享，需要乙份運維故障手冊，裡面記錄了各種典型的故障以及處理方法，也需要有定期故障演習和各種處理預案。
修復的速度很大程度取決於是否有足夠的自動化工具，如資料修復、回滾、流量切換、機器切換等工具
線上故障處理
於 2016 年 12 月 09 日 處理流程 故障後處理 前段時間在團隊內整理了乙份線上事故處理的流程，修改後在這裡分享。1.1 系統 業務報警 這個是獲取故障最常用的手段。一般的系統正常運營過程中都會有一定的指標監控。如 在系統層面某種報錯出現的次數，系統常規指標，如可用記憶體，jvm gc，連...
RAC 故障處理
rac的故障定位 比單節點資料庫更複雜 日誌的儲存位置更多 日誌的資訊量更大 故障更複雜 rac的核心程序，cssd,crsd 這兩個程序出現問題，那麼 rac就宕了。rac比單例項資料庫程序要複雜的多。rac日誌存放的位置也多，種類也多，相對於單例項。對於單例項資料庫，所有的關於資料庫的資訊幾乎都...
shell處理故障
以下是shell處理故障的一點積累,將來可能有用，先mark一下 1 匯出userid不為空，且下單日在2014 01 03日 含 以後的訂單 mysql u h p3307 p e use set names utf8 select distinct user id,user name from ...