業務復雜，做業務的產品更復雜。越復雜的業務產品，所依賴的外圍系統可能就越多。假如突然有一天，依賴的外圍系統掛掉了，少俠你是否給業務留了后路？

可能前面的話聽上去有點暈，到底啥意思？來，舉個栗子。

假如今天饅頭去醫院體檢，需要經歷的體檢流程“1-2-3-4”如上圖所示。但這里有個變態規則就是：必須按流程順序完成1-4的所有環節，體檢才算成功。（翻譯過來就是說：每完成一步，1-4的應用系統會將數據返回給到體檢系統，并觸發體檢系統向下一應用系統請求數據。當體檢系統依次向4個應用系統分別請求數據成功后，則記為“體檢成功”。如果一旦體檢系統某次請求數據失敗，體檢系統則不會繼續向下一應用系統請求數據，處于“體檢進行中”的狀態）

假如此時，血常規檢查的儀器掛掉了，而down機時間又不確定。但因為變態的規則，導致饅頭我只得停留在第2步“血常規檢查”，體檢因此無法繼續進行下去。同時隨著down機時間的延長和醫院體檢人數的增加，停留在第2步而無法繼續進行下去的人越來越多，情緒上已處于失控狀態；但此時院方又束手無策，因為這是體檢系統寫死的規則，不可更改。所以，此時此刻只有2種解決方案：要么告訴大家耐心等待，直至血常規檢查的儀器恢復正常，要么告知大家該回家的回家，該上班的上班，改日再來醫院體檢。我相信如果少俠是體檢的同學，那此時的內心早已是崩潰的…

大家發現沒有，正是因為產品設計上沒有考慮到異常流，因此導致在異常情況發生時埋下了這個天坑。由此可見，做產品留后路非常重要！

留后路，什么意思？

還是剛才的例子，假如我在設計體檢系統的產品時，讓技術同學寫一串代碼：“if 血常規檢查系統down機所引起的數據請求失敗，則直接進行下一應用系統的數據請求?！贝蠹野l現沒有，此時體檢系統就會直接跳過血常規數據的請求，來請求心電應用系統的數據。換言之，也就是說我可以不用作血常規檢查直接進行心電圖檢查，到最后體檢依然是成功的?？赡芪ㄒ坏膯栴}就在于我拿到的體檢報告中，血常規這一項是沒有檢查結果的。不過假如體檢的同學不在乎，那這就不叫問題。

那其實剛剛所說的就叫異常降級策略。比如上述設計中，當我們的系統調用外圍系統出現超時等報錯情況下，可以讓我們的系統吃掉異常的情況繼續業務，這就是一種異常降級策略。當然了，一般來說是有3種不同程度的異常降級策略，但這些是需要視業務的重要性來決定究竟采取何種策略。

現在我們以醫院的體檢系統產品為例來解釋一下上圖的含義。在1-4的體檢流程中，第一步非常重要，原因是在信息沒有注冊的情況下，這個體檢是沒有意義的，因為到頭來不知道在為“誰”做體檢。所以，由此可見“信息注冊”的業務重要性相對其他環節要高，因此如果一旦系統請求信息注冊的數據有問題，就默認攔截不要業務下去了。那這里的高風險又是什么意思？因為一旦攔截就不能繼續業務，比如信息無法注冊導致tmd我就不能體檢了，醫院的體檢就不能搞起了（至少是在此時此刻和未來的一段時間內），所以對業務來說一定是高風險的。那像“打印體檢報告”這一環節，業務上的重要性就低很多，因為此時此刻我不能打印體檢報告，我照樣可以在手機或pc上查看到體檢報告的數據，再不濟可以改日來醫院打印體檢報告。所以，如果體檢報告的打印出現了問題，可以采取直接放行跳過的降級策略，最終是能夠保證體檢成功的，那這里所帶來的業務風險就幾乎為0了。

不過，大家有沒有注意到無論采取何種異常降級策略，我們的系統每跑一次業務都是要去請求一次外圍系統，來看看外圍系統是否down機，如果down機就采取相應的異常降級策略，其實這樣“每跑一次業務就去請求一次”的處理效率是很低的。

因此也就有了主動降級策略的概念，什么意思？就是我可以在后臺配置一個開關來主動控制系統是否直接跳過向外圍系統請求的過程。假設我已經監測到“信息注冊”的系統down掉了，那我就可以直接推開關來命令體檢系統在接下來的一段時間內不再去請求該外圍系統，這樣就大大提升了業務進行的效率，原因是我干掉了向down機系統進行不必要的請求詢問的時間。

所以回到體檢這件事，如果我是設計者，就會采取相應的異常降級策略和主動降級策略。第1步信息注冊的異常降級策略是“默認攔截”，第2步、第3步的血常規檢查和心電檢查的異常降級策略是“日常攔截，緊急放行”，而第4步體檢報告打印的異常降級策略就是“默認放行”。另外，我還會在后臺做三個開關來對第2步、第3步、第4步實施主動降級策略。

這樣的話，即便哪天業務君對饅頭哭訴機器突然掛掉的悲傷故事時，饅頭我依然可以微笑地看著業務君并溫柔地對他說：“別怕，有我！你看，我給業務留了后路…”

哦對了，

我所說的，都是錯的。

作者：饅頭（微信公眾號PRODUCTER），阿里巴巴產品經理

本文由 @饅頭 原創發布于人人都是產品經理?，未經許可，禁止轉載。