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

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

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

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

下面將為大家簡(jiǎn)單介紹有贊的故障管理實(shí)踐。
 

故障處理流程介紹

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

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

當(dāng)收到客戶(hù)、內(nèi)部員工或監(jiān)控上報(bào)的潛在故障時(shí)，報(bào)告人會(huì)盡快確認(rèn)故障的有效性。
 

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

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

定位/處理故障

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

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

故障恢復(fù)

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

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

組織故障Review

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

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

同步故障報(bào)告

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

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

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

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

故障與故障Actions跟進(jìn)

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

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

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

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

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

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

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

小結(jié)

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

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

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

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

標(biāo)簽： 故障管理 運(yùn)維 

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