線上故障是指提供給客戶使用的IT服務(wù)全部或部分不可用，包括服務(wù)性能的降低，如：服務(wù)延遲導(dǎo)致用戶體驗變差。
 

在創(chuàng)業(yè)前期，為了搶占市場先機，產(chǎn)品新功能的發(fā)布速度追求往往優(yōu)先于其質(zhì)量，埋下了很多技術(shù)債務(wù)，部分技術(shù)債務(wù)的爆發(fā)會引起線上故障，造成客戶的體驗下降或經(jīng)濟損失。
 

故障管理的目標是“盡快恢復(fù)服務(wù)到正常運行，并且最小化對業(yè)務(wù)運營的不利影響，從而盡可能地保證服務(wù)質(zhì)量和可用性的水平”。
 

在故障發(fā)生后，故障緊急處理小組會定位、分析和恢復(fù)故障，并在故障恢復(fù)后對故障進行Review和總結(jié)，制定出可執(zhí)行的Actions，以提高故障處理效率和避免類似故障再次發(fā)生。
 

下面將為大家簡單介紹有贊的故障管理實踐。
 

故障處理流程介紹

有贊使用JIRA作為跨部門協(xié)作工具，線上故障管理也借助于JIRA。我們制定了下面的故障處理流程，故障JIRA工單遵循該工作流，而故障Action(s)會被建立在對應(yīng)的故障JIRA工單子任務(wù)中，子任務(wù)的工作流為JIRA默認工作流。
 

確認故障與通知協(xié)調(diào)人

當收到客戶、內(nèi)部員工或監(jiān)控上報的潛在故障時，報告人會盡快確認故障的有效性。
 

當確定是個故障后，會提交一個故障JIRA工單，并通知故障協(xié)調(diào)人（來自研發(fā)效率團隊，主要負責業(yè)務(wù)與技術(shù)部門之間的信息同步和協(xié)調(diào)）。
 

協(xié)調(diào)人確保公司內(nèi)業(yè)務(wù)部門、技術(shù)和產(chǎn)品部門被通知到位，同時將故障上報到“可用性保障微信群”里，故障原因排查和討論會在該群里或拉單獨的故障處理群進行。
 

定位/處理故障

為避免無關(guān)消息干擾，故障處理人組建故障緊急處理小組（在微信群里或坐在一起），以提高故障處理效率。
 

故障處理人在定位到問題后需將故障原因和預(yù)計多久修復(fù)同步給協(xié)調(diào)人。對于處理時間比較長的故障，緊急處理小組會每隔半小時對相關(guān)業(yè)務(wù)部門同步一次故障處理進展。
 

故障恢復(fù)

如確定是發(fā)布引起的故障，需將代碼回滾到故障前的某個穩(wěn)定版本。
 

故障恢復(fù)后，故障處理人需跟業(yè)務(wù)影響方確認是否有數(shù)據(jù)需要修復(fù)。如有，需將影響情況反饋給協(xié)調(diào)人，并配合業(yè)務(wù)方盡快修復(fù)數(shù)據(jù)。
 

組織故障Review

故障Review一般安排在故障處理結(jié)束后24小時內(nèi)，包括故障過程回顧、故障原因分析、改進預(yù)防措施制定、故障定級等，其產(chǎn)出物為：
 

故障分析報告。故障定級分為P1、P2、P3和P4四個等級（依次降低），每個業(yè)務(wù)組都有特定的等級定義，主要從業(yè)務(wù)影響面和影響時間來確定。目前使用的故障報告模板如下：
 

同步故障報告

故障Review參與人一般是故障處理人、協(xié)調(diào)人、責任人及責任方組長，故障報告人視情況自愿參與。
 

為了讓所有技術(shù)小伙伴都能了解到故障信息，故障責任人需將最終版的故障報告同步到產(chǎn)品技術(shù)群。
 

建立每個Action JIRA子任務(wù)

故障責任人在JIRA故障單下創(chuàng)建子任務(wù)，每個子任務(wù)對應(yīng)一個故障Action，子任務(wù)的“到期日”字段需被更新成：Action的Deadline，并將其分配給Action執(zhí)行人。
 

故障與故障Actions跟進

JIRA看板是個很直觀的工具，支持在規(guī)定的工作流之間移動任務(wù)板。我們使用JIRA的kanban board來跟進故障及其Actions（如下圖），頂部快速過濾器可以快速訪問各技術(shù)業(yè)務(wù)組不同狀態(tài)下的故障或Actions信息，橫向上拆分成3個泳道：
 

故障、逾期故障Actions和待處理故障Actions。
 

如果某個Action的到期日已經(jīng)到了，該Action任務(wù)板會顯示在“逾期故障Actions”泳道中，否則會顯示在“待處理故障Actions”泳道中，故障協(xié)調(diào)人會定期跟進下逾期故障Actions的執(zhí)行，并將逾期的故障Actions同步到產(chǎn)品技術(shù)群里，以提醒Action執(zhí)行人及時處理JIRA。
 

故障數(shù)據(jù)分析
 

通過分析故障數(shù)據(jù)，我們可以發(fā)現(xiàn)問題在哪里，并進行改進。目前故障數(shù)據(jù)主要記錄在JIRA和Confluence上，我們會將其按特定格式備份到Numbers中，從不同角度分析這些故障數(shù)據(jù)，如：
 

每月故障數(shù)對比、每月故障處理時間對比、近兩月故障等級占比分布、近兩月故障類別占比分布、近兩月故障來源對比和近兩月各業(yè)務(wù)組故障數(shù)對比等。
 

結(jié)合每月發(fā)布數(shù)據(jù)和線上問題數(shù)據(jù)的綜合數(shù)據(jù)分析，我們得出了“發(fā)布次數(shù)很多的月份，其線上問題和故障數(shù)也相對較多”的結(jié)論。為了減少故障發(fā)生率，我們需要減少發(fā)布頻率和規(guī)范發(fā)布流程。
 

小結(jié)

根據(jù)當前存在的問題制定出一套流程不難，難在對流程執(zhí)行的跟蹤和監(jiān)督。有贊線上故障處理流程由研發(fā)效率團隊負責跟蹤和監(jiān)督，確保了每個故障都能經(jīng)過Review，并形成完整的故障分析報告，同步給所有技術(shù)小伙伴。同時，每個故障Action都是可執(zhí)行的，且有明確的執(zhí)行人和Deadline。
 

經(jīng)過一年多的故障管理，我們不僅沉淀了寶貴的故障數(shù)據(jù)，為改進方向提供了參考，也增強了小伙伴的故障意識，對線上環(huán)境的敬畏之心和對故障的緊急處理意識。
 

關(guān)于“故障管理”，我們只邁出了一小步，還有諸多待改進的地方。例如，我們目前主要管理了線上的故障，對公司內(nèi)部系統(tǒng)故障并沒有管理起來；目前大家了解故障信息的途徑是：
 

JIRA、Confluence和技術(shù)報表，缺乏一個公共的故障檢索和自動生成故障報表平臺；我們的事件管理（Event Management）水平還很低，很多故障是由客戶上報，而不是由監(jiān)控系統(tǒng)先發(fā)現(xiàn)。
 

標簽： 故障管理 運維 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。