在工作過程中我們都會遇到不同的難點或者事故，那面對事故我們應該采取怎樣的應對措施呢？或者應該怎樣提前預防？一起來看看作者是如何分析的。

還記得某個請了事假的周五下午，處理完事情之后，我跟朋友北京城區內悠閑地吃個早午餐，沒想到手機中的Teams突然響起，一看竟然是來自公司作戰室的來電，心臟仿佛突然漏了一拍，只好放下手中的刀叉，接了起來……

對產品經理來說，處理事故是必修的課題，但如何「漂亮地處理事故」，則是需要不斷與團隊彼此磨合。有興趣了解的朋友就一起往下看看吧！

一、什么是事故應變措施？

前陣子我看了一部被譽為人生必看的韓劇《浪漫醫生金師傅》，劇中描寫了許多醫院急診室的故事。

其實互聯網服務的生產事故，就像在醫院急診室一樣，得由一群經驗老道，并且可以處理各式各樣的醫護人員進行第一步篩查，判斷發生原因，然后再交由各科室的同仁進行詳細處理。

因此，在產品服務面對用戶之后，有一組非常重要又辛苦的互聯網急診室的守護者，就是SRE (Site Reliability Engineering)。

他們主要負責確保服務的穩定性，監控生產環境上的各種情況，一旦發生問題時，就要立刻召集相關人員排查、解決。

服務穩定性乍聽之下可能不太起眼，但卻至關重要。作為產品經理，為了能夠提供更好的用戶體驗、保持市場競爭力，並追求更好的商業價值，我們總是不停地在「持續迭代」，而如何平穩、絲滑的調整，就依賴開發團隊及SRE團隊的合作。

互聯網服務上，系統包含的范圍非常廣，業務應用服務、網路、數據庫、云端服務或伺服器等等，每一個環節都有可能出現異常，問題真的千奇百怪。

小到用戶不理解前端提示而誤操作、網路波動影響接口調用失敗、或是大到整體機房出現異常、流量被惡意攔截需要緊急搶救的…等等。

面對不同等級的故障，團隊應該在事故的「處理時效」、「處理方式」、「通報范圍」的不同維度達成共識。

二、為什么要搭建事故應變措施？

互聯網金融服務相比于工具類的服務，服務的穩定性，在用戶心智中很大程度與資金安全有所關聯。試想看看，如果隔天就是房貸的繳款截止日了，但是金融服務突然不能用，身上也沒有現金這多令人跳腳！

當有生產事故發生時，除了影響用戶體驗、公司收入、更甚者可能引發輿論而影響公司聲譽。因此，在事故發生當下，除了排查問題、解決問題之外，與團隊內部、外部合作方、外部用戶、公關媒體的溝通，每一個環節都至關重要。

三、如何搭建事故應變措施？

1. 預想可能發生的事情

如同《浪漫醫生金師傅》劇中，我們可以看到許多奇特的意外傷害而來到醫院急診室的病患，例如：連環車禍、滑雪受傷、誤食農藥、地震等各種天災人禍皆有可能，而劇中的護理人員也會每天準備好急診室常備用品，確保當有需求時，不會因為物品匱乏而延誤搶救病患的最佳時間。

而反映在互聯網服務上，我們不難找到許多有心者惡意利用漏洞，或是意外情況而導致的生產事故，團隊可以預先想到可能發生的情況，也可以在經驗中不斷學習。

例如：系統流量超過可負荷的限額、流量被惡意攔截、依賴性系統突發異常、用戶因不理解指引的誤操作…等等。

2. 確定有哪些重要團隊成員

如上述說的，在討論生產事故處理機制時，我認為有這些角色的參與是非常重要的，每個角色可以從各自的角度提供專業建議與支持。

• 產品經理
• 架構師、開發、測試
• 客戶服務團隊
• 外部合作伙伴團隊
• 公關團隊
• 法務、合規團隊

3. 建立團隊成員對于事故等級的共識

你知道嗎？在醫院的急診室中，并非先抵達的患者能夠優先接受治療，而是需要依照傷病的緊急程度進行優先級排序。

因此，團隊成員的首要目標是擬定一套能夠幫助判斷「優先級」的指標架構，并且「達成共識」（當然內容可以依據業務發展而有所調整），畢竟當真的有P0、P1的緊急問題時，需要大家專心一致的解決。

這時候可不會希望因為彼此對標準理解不一致，降低了事故解決的效率。

（1）建立指標：可以參考以下不同維度

• 影響范圍：評估事故對用戶體驗、業務運行、系統功能、或服務可用性的影響范圍。
• 持續時間：事故持續影響時間。
• 重要性和緊急性：事故對業務運營的重要性和需要被緊急解決的程度。
• 合規性要求：思考事件對相關合規性要求的影響，如違背合規法務要求，可能會導致更嚴重的故事等級。
• 可用備份和恢復策略：考慮備份和恢復策略的可用性和有效性。

（2）為每個指標及事故等級定義數值

通常我們會與團隊成員對于不同事故等級共同討論相關指標維度，并建議「可快速量化」數值。例如：影響交易金額、事故持續時間、或受影響用戶數。

也需要針對不同等級的事故定義響應時間以及目標處理時間，例如：P0的事故需要一天內解決，P1事故可以兩天內解決，以此類推。

（3）為不同等級的事故，定義對應SOP（標準作業程序）

我們其實沒有想像中的那么冷靜。

還記得開頭我提到的周六事件吧！我印象非常深刻，那天早上雖然是電話會議，但是我感覺許多人一進到電話里頭就滿臉「我是誰？我在哪？」的感覺。

每一次有新同事加入時，就要重新解釋一遍問題、影響以及當前進度，然后想辦法厘清原因、找到對應的處理方式。

SOP（標準作業程序）是一個非常好的工具，可以幫助團隊在緊急的時候，有一個可以參考的依據。

「服務降級」也是一種常采用的方式，例如在大促活動的流量高峰時，僅維持重要的系統交互，避免過多的系統交互影響服務響應速度…等等。

4. 建立監測預警機制

監測與預警是預防、盡早掌握事故發生的重要工具。

例如：確保預先充值的云服務，會在額度快被用完之前會提供郵件或短信預警、定期監測主要核心流程是否有系統交互、流量請求（有時候沒有系統請求是因為用戶根本無法訪問該頁面），越早發現事故，也可以越快控制影響范圍。

5. 事中優先解決問題，事后詳細檢討

團隊在事故發生的當下，僅需要專注于最快的速度解決問題。而在事故解決后，也需要十分詳細地檢討原因。

每一次的生產事故對團隊成員來說，都是極其寶貴的經驗，而經驗不僅需要時間積累，更需要被紀錄與傳承，避免重蹈覆轍，保持互聯網的精神，小步快跑，在錯誤中學習。

四、結語

處理生產事故的時候，在時間與情緒的雙重壓力下，其實常常需要花費相當高的溝通成本。所以建立起團隊的合作共識，持續地磨合出一些應變機制。我也時常跟同事分享一個正念思考的心態，「有生產問題，代表真的有用戶在使用你的服務??！」