首先宣告，本文章只在針對故障中那些不願承擔責任，而把鍋甩給運維部門的人，如果討論故障的都是君子，那麼本文並不建議使用，切記。
1，故障，故障，還是故障
任何乙個故障發生時，沒有任何乙個人是無辜的，開發的責任在於**的bug，測試的責任在於測試用例不健全，運維的責任在於監控不到位或者故障處理不給力，一般在故障定責中，聲音越大的一方，往往責任越大，所以在故障定責時，要學會察言觀色，選擇主攻點，不要廣撒網，到處開炮。
關於故障處理和故障定責，這不是體現個人責任心和擔當的場所，一定要分清哪些是自己的主職，哪些自己在協助幫忙，把故障一股腦攬在自己身上，好一點的人會一時感激，但最後為了去掉不虧欠感以達到內心的最終平和，就會找一大堆理由證明責任真的是你的，不巧的是，這些理由，一找一大把，因為雪崩時，的確沒有一片雪花是無辜的。
所以，故障定責應該遵循以下幾個原則：
1），首先，故障並非都是壞事，偶爾它是避免大故障發生的預警。
2），其次故障責任遵循是否引起還有是否有能力去改變兩個方面制定，責權一定要統一。
3），再次大故障儘量減少責任，小故障盡量增加責任，漏漏臉也好。
4），最後，老祖宗的名言，福兮禍所伏，禍兮福所倚，吃虧是福。
2，定責時一些方法和話術技巧
再次強調一遍，下面內容只防小人，不防君子，不主動欺負人，但別人欺負我，不行
1），言多必失
定責時，一定要少說話，簡潔，說話時要去抓住對方的漏洞，尤其是邏輯漏洞，尤其是攻擊對方的前提假設。
例如：「你說的太理想化了，我們實際情況是，……」
「你這個太不專業了，怎麼可以這樣去做假設……」
同時，只闡述事實，並且和故障相關，注意，不要用過多的主觀詞語字眼
「我覺得，我認為，我想」這些都要少用甚至不用，我一般用的最多的字眼是「咱們，我們」。
比如一句話：
「我覺得，這次故障測試方出現了漏側的情況，是主因」，這樣說就很不好，好的說法是，「大家想法都是好的，咱們先擱置爭議，靜下來想一想，如果測試到位，是否這次故障就可以避免？」
2），找好自己的盟友
故障時，往往是三國混戰或者多國混戰，這時候要打一方，拉一方。
例如，拉開發，打測試，「大家有些搞混了，我們首先要找的是問題根源是什麼，是**bug啊」
再例如，拉測試，開啟發，「細想想，測試同學也是很為難的，咱們生產環境那麼複雜，開發要保證第一道關的」
或者釋放善意，等著被拉
例如，「這次監控做的很到位，大大減少了故障的定位時間」
3），情感公式，站在道德制高點
這是乙個屢試不爽的方法
例如：「你考慮問題太狹窄了，應該站在公司的層面去考慮」
「現在還沒到那個階段，不要回答how，要問一下why」
「如果我來承擔責任，沒有問題，但真的解決問題了麼，下次不會重**生了麼？」
「我當然知道公司的實際是什麼，但我們不是應該朝對的方向前進麼？」
可以主動示弱：
「有些故障，運維也背了，例如***，但現在看起來，效果並不好，團結是有了，然而沒有真正解決問題」
「為了做這個變更，我已經特意選擇凌晨去做，已經熬了好幾個通宵了」
4），不要直接回答問題，記住，不要直接回答問題
不直接回答問題的好處有二，其一，顯得高階，其二，給自己留出思考空間
方法一，反覆對不起
「對不起，你說的我不太明白，能再說一遍麼？」
「對不起，我不太清楚，了解一下再答覆你？」
「對不起，剛才走神了，能再說一遍麼？」
這種方法尤其適合乙個新員工參加故障討論會
方法二，提問
「你說的我沒法直接回答你，不過，我想問一下，你覺得你們團隊問題在**？」
「等一等，有個問題，我不理解，你剛才所說的前提是什麼？」
方法三，重複或者翻譯別人的話，注意重複語氣要慢，有明顯漏洞的地方，要更慢
「剛才說的話，我是不是可以這樣理解，……」
5），說不通，那就換一種方式
方法一，直接說結論
「ok，各位說的都有道理，結論是不是這樣？」
方法二，迂迴反覆
「這個故障的確我這裡有做的不好的地方，但是就算我改進了，大家想一下，這個故障就能避免了麼？」
方法三，拉人下水，有鍋一起背
「我再思考另外乙個問題，除了大家說的之外，還有哪些我們能做的更好的呢？」
方法四，和事佬（一般到和事佬時，基本上就贏了）
「二位說的都有道理，的確各個團隊都有做的不好的地方，大家覺得呢？」
6），千萬不要挑戰別人的專業，也不要陷進別的專業
如果我們要想打敗泰森，肯定不是和他上擂台，而是要和他比說中國話。
「我承認你的領域我不太理解，但故障處理是乙個軟體工程，從軟體工程角度來看，應該是……」
「好，其實這裡存在乙個問題，那就是，監控是萬能的麼？或者說，為什麼監控做不到萬能的？」
7），最後幾點
首先，千萬不要急，不要急，不要急，一急你就輸了
其次，角度一定要新，不要說別人都知道的事
再次，任何人說的每一句話，都要打乙個問號，不要輕易接受
最後，故障無小事，做好充足準備，甚至有誰會參加，他們什麼背景和性格都要了解清楚。
運維是乙個很難說清的事情，因為太雜，太廣，別人很可能一句，我覺得是網路的問題，就讓你忙活大半天，所以運維人員一定要學會保護自己，鍋，該背的背，不能背的一定不背。
日常運維故障記錄和解決
1 esxi 中的虛擬機器無法啟動 報錯 開啟虛擬機器 10.10.3.102 namenode2 的電源時，會收到來自 esx 主機的錯誤。無法啟動虛擬機器。模組 snapshot 開啟電源失敗。無法獲取快照資訊 msg.snapshot.error config。2 salt stack 執行j...
運維分級發布 運維必備制度 故障分級和處罰規範
作者簡介 在接下來的日子裡，將以質量 效率 成本為核心，從運營規劃 管理 流程 規範 系統 平台，監控 告警 安全 優化 考核等幾個維度結合案例來與大家分享自己的體會，內容大致如下所示。正文網際網路產品提供7 24小時服務，而因人為操作 程式bug等原因導致服務不可用是影響服務持續執行的重要原因，為...
從運維角度談談故障定位 未完
一般剛畢業不久的會回答 我們有監控 看日誌等之類的答案。工作幾年的人會回答 從網路，機器，資源等方面排查有沒有問題，如果沒有問題，再看看日誌，找開發核對。也有人回答這個是開發的問題，我們運維還沒有精確到業務層面。運維人員進行故障定位時，遇到主要問題 1 業務掌握深入程度有限。不像某個應用的開發那樣，...