“相信大部分人都用過美團外賣，尤其是在每天的兩個吃飯的高峰期。美團外賣從創業到現在經歷了數次的迭代，不斷的適應需求，提供更好的體驗。本文是美團外賣架構師曹振團在ArchSummit 2016 深圳站上的分享。老司機簡介
曹振團，美團外賣技術專家/架構師，目前負責美團外賣業務系統的架構設計及優化工作。2013年加入美團，早期參與了多個創新業務的探索。經歷了美團外賣從無到有的創業過程，以及業務快速發展的高增長期，積累了豐富的從0到1業務系統的架構設計和優化經驗。加入美團之前，在網易網站部工作，負 責后台服務的設計和開發工作，擁有豐富的高並發系統的架構設計和實戰經驗。
本視頻時長39分，建議在Wifi環境下觀看。
技術體系架構演進
簡單介紹一下外賣現在的情況：我們從2013年10月份做外賣的事情，是從餐飲外賣開始的。經過兩年多的發展，我們不光可以提供餐飲外賣，也可以提供水果、鮮花、蛋糕、下午茶甚至是超市和便利店一些外送的服務。我們做外賣過程中，我們發現用戶對外送的體驗有兩個關注點：
-
第一個是品質，用戶對品質要求非常高，送過來的飯不能涼了，不能不好看，送餐員身上臟兮兮也不行會影響食欲的；
-
另外一個關注點要准時，一定要按時間送到，比如我要求按12點送到就一定要按12點送到，不能早也不能晚，如果早為什么不好呢？11點40送到不行，我們正在跟老板開會，一會一個電話太煩了；12點20送來也不行，太餓了，我都餓暈了，中午也有很多的安排，吃完飯可能要睡一會，中午不睡下午崩潰呀。
我們發現如果要把用戶體驗做到極致的話，做得足夠好能保證用戶得到足夠好的體驗，我們就要做專送的服務。所以我們正在做的是美團外賣的平台和我們自己的配送服務。
我們從2013年10月份確立做這個事情，到11月份正式上線，到14年底11月份時突破日訂單一百萬單，15年的5月份大概突破了每天兩百萬單，然后大概15年12月份做到每天三百萬單，今年5月份的時候我們做到了四百萬單每天。我們希望在響應國家大的號召下，我們做供給側改革。我們希望給大家提供更多的、優質的、可選的外送服務，希望未來的某一天做到每天1000萬單。
介紹一下我們的業務，也介紹一下在做這個業務過程中技術架構的演進的歷程。我們在開始做外賣的時候發現，那時候都是通過電話來點外賣的，小餐館的老板發傳單，我們用傳單上的電話給老板打電話下單。我們在思考我們是不是可以把電話點餐的事情變成網絡點餐，讓用戶只需要在網絡上點點點就行了，不用打電話。
於是我們在公司周圍的商家摸索這個事情，我們早上下了地鐵在地鐵口發傳單。我們怎么能夠最快地去驗證這個事情是否可行？
我們提供了一個非常簡單的Web版本和Android的App，對於商家那一邊我們沒有提供任何軟件的服務，用戶在我們平台里下單以后，我們再打電話給商家下單，有時候我們是發傳單的，有時候我們是接線員，用戶在我們平台上下單，我們再打電話給商家下單，然后再去寫代碼。那時候基本上沒有太多架構考慮，就是怎么快怎么來，以最快的速度去把我們的功能給變上去。
這個事情我們驗證之后發現確實可行，我們發現“懶”是極大的需求。因為懶得去換台，所以發明了遙控器，懶得爬樓梯就發明了電梯，人都是很懶的，因為懶得打電話訂餐，所以在網上點點點就好了。
我們發現這是極強的需求，於是我們就考慮規模化，因為只有規模化之后邊際的成本才可以變低，這套軟件在一個區域可以用，在一個城市可以用、在全國也可以用，我們的開發成本就是這么多，所以我們在嘗試在做規模化。
這個過程爆發性產生了非常多系統，我們在用戶這邊提供各種APP，商家這一邊我們也開始提供服務。我們給商家提供PC的版本、App版本，還給商家提供打印機。
打印機是跟我們后台是聯網的，如果用戶在我們平台上下單，我們會直接推送到這個打印機上，這個打印機可以直接打出單子，同時可以用林志玲或者郭德綱的聲音告訴你：“你有美團外賣的訂單請及時處理”，這是對商家非常好的效率提升；同時我們給自身運營的系統加了很多功能，我們有上單、審核等各種各樣的系統等爆發性地產生了。
在這個階段我們業務發展特別快導致我們堆了特別多的系統，這個時候也並沒有做非常清晰的架構，就是想把這個系統盡快地提供上線。這時候所有的表都在一個數據庫里，大家都對這件事情非常熟悉，我可以做訂單，也可以做管理系統。
但是這個事情在規模化、用戶量迅速上升之后給我們帶來非常大的困擾，因為之前我們是有很多技術欠債的，在這個階段里面我們就做了重大的架構調整，在這個調整里主要說兩點：
-
第一點就是拆
我們把很多耦合在一起的服務做服務化拆分，服務與服務之間通過接口來調用和訪問，服務自己保護自己的庫：不能訪問別人的庫，否則叫出軌；你的數據庫也不能被別人訪問，否則叫綠帽子。
-
第二點是中間件
我們在這個階段引進了很多中間件，包括了在開源基礎上自研的KV系統，我們也引用了搜索Elasticsearch，我們通過Databus抓取數據庫的變更，把數據庫的實時變更刷到緩存和索引里，讓這個中間件做到穩定可靠的服務。
總結一下的話，我們的演進大概分了這樣一個階段：整體上有一個多邏輯耦合在一起的情況按服務化拆分出來，每一個服務獨立專注地做一個事情，然后我們再做應用級的容錯，到現在我們在做多機房的容錯。
在緩存上，我們早期使用了Redis，在Redis Cluster還沒發布之前我們用了他們的Alpha版本，當然也踩了很多坑。后來我們用了自研的KV系統，最早的時候我們把所有業務的KV都是共用的，這個也有很大的問題：如果所有的業務共用的KV集群，其中某一個業務導致這個KV集群有問題的話，所有的業務都受影響。后來我們也做了每一個業務拆分自己專用的KV集群。
在數據庫這一層上，基本上是把一些大表的查詢、對數據庫有較大傷害的查詢變成了高級的搜索，在數據庫和應用層之間加了中間件。
在360開源的Atlas基礎上做了我們自己的定制，這個中間件有個好處：我們對數據庫的變更對於業務層是透明的，比如說覺得能力不夠要擴容，我們加幾台從庫，業務方是無感知的，而且我們會做SQL的分組，即數據庫的分組，哪些SQL到哪個數據庫上，到主庫還是從庫上去，我們業務是不用關心的。
遇到的挑戰
下面介紹一下做外賣這個事情上遇到的挑戰：
-
第一個挑戰，外賣這個事情具有一個典型的特點，就是聚集在中午和晚上兩個吃飯的高峰期，這天然就是非常集中的秒殺的場景，因為大家會集中在11點10分到11點半去下單。我們在高峰期的時候，有一分鍾接進2萬單的巨大流量；
-
第二個挑戰，大家理解送外賣是一個很簡單的事情，我點了餐，送過來，我愉快的把它吃掉就結束了，但是做外賣的事情上我們發現確實蠻復雜的，因為我們發現用戶要下單，要支付，我們還要調度一個配送員，我們找一個最快最合理的騎手，讓他到時間取餐送過去，同時還要給這個騎手最好的路徑規划，告訴他走這條路是最快的。所以整個是一個非常復雜的過程，有非常非常多的服務；
-
另外，外賣還是快速發展的階段，對我們的挑戰是迭代太快了，你可能要頻繁的發版，就有穩定性的風險，可能有Bug，可能有測試不全的情況。另外是項目周期短，業務發展很快有很多業務需求正在排隊，架構優化的工作可能排不上去，甚至做技術架構設計的時候可能有一些折中，這是極大的隱患，我們把它叫技術欠債。
我們有一個列表記錄下來這些技術欠債，會記清楚說這是一個什么樣的條件下做的方案，它在什么情況下可能會有哪些問題，需要在什么時候必須去做哪些事情；另外一塊在監控的壓力也很大，因為業務變化非常快，你今天是這樣設置監控規則，明天業務又變了。
如何保持穩定性
介紹一下我們對於穩定性的定義，我們也是拿四個“9”來衡量穩定性，但是我們分別用於兩個指標：系統可用性和訂單的可用性。
-
系統可用性四個"9"意味着全年的宕機時間不超過52分鍾，我們是按季度考核的，相當於一個季度系統宕機時間不超過13分鍾；
-
另外一個維度訂單可用性也是四個"9"，意味着我們一個季度是一億單的話，這個季度的訂單損失不能超過1萬單，而我們高峰期一分鍾就接近兩萬單，因此只要這個系統有問題，我們這個KPI就無法完成。
我們還是要保證四個"9"的可靠性，而我們怎么去做：我們從四個階段來扎實地做這些事情：一個是日常運行，二是事前預警，三是事故處理，四是事后總結，我會詳細地介紹這四個環節：
一、日常運行
首先在日常運行里面，我們要做好穩定性的架構設計，這里有幾個原則：
第一個是大系統小做
我們不希望做一個非常大的系統，它什么都能做，我們希望做小的系統，非常專注，功能相對獨立。我們先把功能相對獨立的系統拆開，在早期發展過程中，你們看我們有一個系統它什么都能干，它其實是一個Web項目，還提供了Web的服務，同時還提供了App的API服務，它還消費消息隊列，還是Job的執行者，這就帶來一個問題：你消費消息的邏輯發生變化了，你就要去發版，其實別的功能是沒有變化的，發版就會影響到其他的功能。當我們把幾個系統拆開，它就是四個獨立的系統；
第二個原則是依賴穩定性原則，你提供的服務一定是穩定可靠的
這里希望是將易變的和不變的地方拆開。舉個例子，對於商家的服務，對於C端的用戶和服務來說，用到最大的場景就是GetById，就是知道這個商家的信息就好了，但是我們還有很多對商家管理的服務需求，比如說商家符合什么條件才能上線，需要什么過程才能改他的菜品，這些管理的功能是經常變化的，對於讀取的信息是不變的，於是我們把這它拆開，把它變為讀的服務和管理的服務。管理的服務可以隨時發版，沒有關系，讀的服務是非常穩定的，基本不發版；
最后一個原則是設計這個穩定性的時候需要考慮用戶的體驗
需要考慮在系統出現問題的時候用戶怎么辦？相信很多同學都有這個體驗：可能APP上突然有提示失敗、服務器異常、空，不知道什么情況。我相信用戶遇到這種情況一定會不停刷新的，這時候如果后台已經有問題的話其實是糟糕的事情，所以設計的時候要考慮到在異常情況下用戶的體驗和用戶如何引導。
日常運行里面，另外一個工作是做例行的穩定性巡檢
1、比如說我們做專項的巡檢
對DB來講，我們每個月要做DB容量的Review，我們看哪些表是大表、讀寫的QPS以及它的容量，以及未來某一天它能不能支持業務的發展；
2、我們會做靜態的梳理
我們按場景梳理，例如首頁、Banner、列表頁，這些場景用到哪些服務，這些服務又用到了哪些服務，這些過程中，它們對下游的調用是否存在放大的情況。有一些情況是假的高並發。
比如說有一個服務是說告訴商家今天有幾個新訂單，這個功能很簡單，就是在前端頁面去做輪詢，這個過程其實80%-90%的查詢是無效的，因為一旦有新訂單我們就會推送到商家，商家就會及時地處理掉，查這個請求其實是無效的，這么多無效的請求去查訂單的服務，最終還要落到數據庫上，這是假的高並發，這里我們在前面加一層緩存，把到數據庫的這一層假的高並發給干掉；
3、另外一個例行的工作是對指標的巡檢
我們有許多的監控指標，尤其是關注它的尖刺，這些尖刺也不會放過。
對於平時來講，給我們增強穩定性最可靠的信心就是在線壓測，我們和其他大廠差不多，我們也在做在線壓測這個東西，我們有一個在線壓測的平台。我們希望通過壓測來發現什么呢？首先發現系統里面的性能瓶頸，到底哪個系統是里面最弱的，以及我們要知道系統服務的上限和能力。
另外更關鍵的是，我們需要通過壓測來驗證我們的監控和報警機制是否生效的，可能很多時候大家都說我們配置了非常完整的監控方案，但是它可能不生效，一旦不生效就慘了。另外，我們要通過壓測指導我們報警的警戒線是怎么設置，到底CPU是設置是30%還是70%，什么時候該報警，我們就通過壓測來確立。
這個壓測告訴我們指導意見，警戒線設置到哪個位置是給你留有充足時間的，如果你的報警發生之后馬上掛了，其實報警是沒有用的。我們可以通過壓測來要設置警戒行動線，到這個時候我們要考慮和關注這個問題，留給穩定性處理有足夠的時間。
我們怎么做呢？我們把線上的流量經過日志錄取下來，把錄取的流量放到我們的壓測平台里，這是對於讀請求的。對於寫請求的，我們做一些事務的模擬，我們有一些模擬的腳本偽造一些根據我們場景做的數據。
這些數據再經過一次染色，把真實數據和測試數據隔離開，經過我們異步階梯加壓的模塊，我們先通過異步的方式把它迅速打起來，我們可以把量打地非常高；另外我們是通過階梯性地打，我們不是一次打到2萬，我們可能先到5000，然后再到9000，然后打到15000，然后再持續10分鍾。
我們對這個監控的流量施壓過程和跟我們監控指標關聯起來，我們做壓測之前先看和哪幾個指標關聯，哪幾個指標到了什么閾值就自動中止壓測，畢竟我們是在線上做這些事情，不能對真實線上的情況產生影響。對於其他依賴的服務，比如說支付，這些真的不能壓到銀行去，外部的服務我們做了一些Mock。
二、事前預警
對於事前預警階段，如果真的有事故發生我們希望更早曝露出來，觸發報警，然后有充足的時間去應對這些事情，我們在這個地方在事前預警階段我們有一些監控心得：
首先是有分層的監控：有系統級的監控，例如性能指標的監控，還有業務監控，我們還有平時健康度的分析，我們的應用是不是健康的。
我們分享一下在業務監控的想法，業務監控其實是最讓你放心的，你有一個業務大盤，這個大盤如果有一個波動你就立馬發現了，說明現在可能會有影響，你可能會收到報警，例如什么CPU的報警，你去看大盤，大盤可能說沒有什么影響，這樣你不會那么慌。
另外，我們系統里面把訂單相關的所有信息和重要節點做了日志的輸出，日志通過flume收集到Kafka再到Storm里，我們在Storm里對這些日志進行匯聚，匯聚的結果放在HBase里，在這些結果里我們有幾個非常好的應用：
-
例如首先只要告訴我一個訂單號或者手機號，我可以查到這個訂單走到了哪個環節，到了哪個服務的哪個服務器掛掉了，解決這類問題非常的方便；
-
另外我們還可以把這些指標做成監控曲線，比如說你要下單，下單量是這么高，到了接單的環節它出現了下降，接單這個服務可能關聯的ABC三個服務：可能有商家、PC、打印機的接單，到底是哪個服務出了問題導致了大盤的下降，我們的曲線可以非常方便地看出來。
三、事故處理
還有可能有一些意想不到的事情發生，真的出現了事故怎么辦？第一原則就是及時止損。我們知道發版是導致穩定性變化的第一因素，如果立馬確定是由發版引起的這次事故，最快速最有效的方法就是回滾。另外可能還有一些流量異常，對於流量異常我們有限流的模塊，我們提供了三種限流的策略：
-
第一種是防刷的，防止用戶頻繁刷新導致后台的流量繼續放大；
-
另外一個策略是等待+限時的服務，用戶其實在用我們平台的時候，用戶確實是需要選的，可能要選來選去才能下單，對於這些服務，我們希望說你願意等一段時間我們可以提供，比如說你願意等10秒鍾，我給你提供20分鍾的服務，這段時間應該是可以下完單的；
-
還有一種策略是對單機的QPS保護：我們壓測驗證的時候這個服務單機能達到500QPS是穩定可靠的，再往高有問題的話，我可以啟動這樣一個保護，確保你能夠以最大的服務能力提供服務而不至於掛掉。另外在單機QPS保護中我們需要把關鍵的路徑去放過，你真的不希望用戶在下單、支付的這些路徑把它干掉或流空掉，這些服務我們就用白名單的方式放過。
四、事故總結
事故發生之后，我們需要對事故做一個非常深刻的總結。這里面有幾個非常強的要求，第一是必須找到根源，根源我們采用5whys的分析方法，一定要追蹤到最根本的原因，從現象開始追蹤。另外要去核算清楚這次造成多少損失，因為我們要算我們的穩定性。還有一個方面，你要對這次系統出現問題的過程、你處理的過程和中間的流程進行總結，看哪些地方可以優化。
我建議的做法是：我們需要把這次事故處理的過程詳細記錄下來，它可能是需要精確到分鍾的，比如說某一分鍾誰跟誰做了什么動作，這對我們總結很有幫助。因為有可能事故處理過程本身是有問題的，比如說你去擴容花了30分鍾時間，這是有問題的；比說你在處理過程中做了錯誤的決定也是有問題的，所以我們把過程中做了詳細的記錄。
我們對於這個事故的總結和Review，我們希望能看到什么？在這個總結里面，我們希望看到到底哪里出了問題，我們能不能更快的發現它，將來如果再發現，能不能比現在處理的更快一點。
講完這些處理原則，再介紹一下我們做這個事情的實踐。我們對穩定性的要求是極高的，每一個訂單的損失我們非常敏感，我們就有一個實踐的動作：就是力保關鍵路徑不掛，我們要保住訂單，那要保住和訂單交易相關的所有路徑不能掛。
所以平時我們就梳理出了和訂單交易的關鍵路徑，從用戶下單、從用戶開始選門店，然后開始選菜，然后下單，然后到配送完成，這個過程里邊每一個環節關聯了哪些服務，這些服務都應該具備有降級的功能。
比如說Rank服務，用戶首先打開我們App的時候，我們就會給他最附近的、可以配送到的一些商家，這些服務會給用戶之前的購買記錄來做推薦，我們會給他更好的排序。
如果我們Rank的服務出現問題了，我們可以迅速地將這個Rank的服務給降級掉，改成默認按銷量去排序，這樣用戶也是可以選餐的。所以這個環節里面的每一步我們都可以降級的，從而保證在下單這個關鍵路徑上服務都OK，其他服務可以接受它的掛掉。
另外，預案的建設，你永遠需要想一下你將來可能發生什么，如果發生這些事情的話，我們該怎么辦？所以你在做這個事情之前就要去考慮，我們認為性能是功能的一部分，穩定也是功能的一部分，而不是大家做這一次技術方案設計，做完之后再來優化性能和穩定性。
我們需要在做這個架構設計的時候考慮到性能和穩定，它們是產品功能的一部分，同時也要考慮到如果性能穩定性出現問題，用戶體驗是怎樣的，用戶不希望看到很傻的提示。
所以我們在功能設計的時候，就考慮到了出現這樣的情況我們可能要降級，這個降級的方案可能是一個開關，就會有非常多降級開關，有些情況下是更復雜的場景：如果這個情況發生了，我們可能把這個開關和那個開關給關掉，這是我們的降級管理平台，我們真的把一個降級開關給做成了一個開關，就是開啟和關閉，同時我告訴你開啟意味着什么、影響着什么。
再介紹一下這個平台里面我們有對灰度的管理，有對壓測的管理，有對健康度的分析。另外有一塊我們稱為核按鈕，即如果事情發生之后你要保住的底線，如果我們的系統出現問題，商家不能接單或者配送無法送出的話，用戶下的這些單子都會被取消掉，這個體驗是很糟的。
我下了單，然后5分鍾你告訴我商家不能接單這個訂單被取消掉了，我忍了我換了一家，結果又被取消了，這會罵人的。如果商家不能接單，就不要讓用戶下單，如果這些情況發生，我們就迅速啟動核按鈕，把我們篩選的這些不能接單的商家迅速變為休息，可以保證用戶向可以服務的商家去下單。
在整個實踐的過程中，與穩定性斗智斗勇的過程中，我們總結了非常多的流程，我們叫做標准操作流程SOP，這些流程涵蓋了從需求、開發、測試、上線、監控、故障處理的每個環節，每一個環節都是標准的、非常嚴格的、經過認真思考的流程來供大家參考的，一定要按照流程來操作。為什么這樣做？
給大家舉個例子，按照這個步驟走是值得信賴的，每一步都有非常好的預案與系統的配合。比如說出現事故，大家是很慌的，因為那么多人在投訴、那么多人在等着說不能點餐了，為什么，美團外賣怎么了？然后我們處理事故的同學說：你不要慌。怎么可能呢？那么多用戶在投訴，老板還在后面問你怎么樣了，什么時候才能處理好，怎么可能不慌呢，臣妾做不到呀。
這個時候你肯定很慌的，這個時候你還要把很多問題考慮清楚幾乎是不可能的，有些同學說我這里需要這么做、我需要寫條SQL，結果忘了Where的語句，所以你在非常緊張的情況下根本想不全這件事情的，那怎么辦？我們只能提前想好，如果會出現這種情況我們就執行這條SQL，然后放在那里經過無數人的Review和實驗，它是可靠和可以被執行的。所以，我們在整個過程里面收集了非常非常多的操作流程，每一步都有非常嚴格的要求。
我們梳理完了這些流程，希望把這些流程變成自動化的，否則人工操作的話，我們是可以要求大家嚴格執行，但是畢竟也是效率低下的，我們需要把很多的操作變成自動化。
舉個例子，下圖是我們發版的流程，看上去還蠻復雜的，一共有10步，我們有非常多的要求，你在發版之前需要驗證哪些事情，發完版之后要驗證哪些功能，最重要的是你要去評估，你要去評估有什么影響，你對下游有什么影響。
更重要的是，我們對每次發版都一定要有回滾措施，就是應急預案，你要回滾到哪個版本，如果是一個大的項目，大家一起聯合發布的，是怎樣的回滾過程，誰先操作誰后操作。對於每一次發版，沒有預案是不允許發布的。
大家可能會說，我要改庫、我要改表，我已經把表結構變了，還要寫數據，這時候無法回滾，回不去了。那不行，那是不可能的，你一定有辦法把它回退過去。另外，我們有每一次的降級方案和灰度的策略，如果是這一次發版引發的故障的，發版之后整個過程做一次非常詳細的整理，到底哪些地方出了什么問題。
在處理的過程中有幾句總結的話跟大家分享：
第一句話：你要想穩定性做的非常可靠，灰度、灰度、還是灰度，沒有別的方法 ；你不要把所有的量去驗證這個事情。我們對於灰度，可以做到按照城市、按某個功能、按URL某個參數來進行灰度，也可以按照一定流量的比例，比如說先灰度1%，然后到50%，然后到100%。
另外我們對於發版是有很強要求的，我們有一個發版的時間窗，周一到周四的下午兩點到四點，其他時間是不允許發版的，如果你要發版你要提申請和審批。
為什么這么做呢？因為我們外賣特點就是中午流量非常高，晚上流量偏低。我們之前發現其實兄弟們很辛苦，非常辛苦的寫代碼，寫到晚上八點，終於寫完了開始發版，然后測試，到十點多又有十幾台服務器要發布上去，還要回歸這些功能，到11點終於發完了，一身疲憊終於可以回家了，然后回去休息。第二天早上十點鍾一個電話打過來，出問題了，怎么辦？到底去公司還是不去呢？別去了，趕緊在家看吧。
因為第二天中午是非常高的高峰，我們不希望用中午這么大的量來驗證，我們希望晚上來驗證，晚高峰雖然比中午的高峰低很多，但是也是一個非常大的高峰，我們用這個流量來驗證，所以我們把發版的時間調到下午，不要在晚上發版，這樣很累可能想不清楚，和你關聯的其他同事都不在，很多事情也無法處理。
所以我們下午來發版，這樣會很穩妥，大家都在，通過晚上的高峰來驗證，如果沒有問題，第二天也很穩妥很安心的，如果有問題則晚上進行壓測；
第二句話：慢查詢往往闖大禍。慢查詢是非常討厭的事情，而且它的出現可能會有非常大的危害，慢查詢把一個庫打掛的話，我們負載均衡會跑到其他庫也繼續打掛，然后所有都掛了，解決數據庫掛了的問題是非常耗時的，所以對SQL有極高的要求，在我們的實踐里面我們不允許寫join，不允許寫like，每一次SQL都有Review，上線的流程里面會記錄這次上線這次SQL是誰Review的；
第三句話：防御式編程，不要相信任何人和服務。別相信你的下游說，我就調你三次，你放心吧，沒事的。別信，肯定有鬼，你要做好對自身的保護，也不要相信下游說別人的提供的服務放心地使，哥向你保證五個9的可靠性，沒有一個服務能做到100%的可靠的，這是必然的，即使是5個9，也有損失的時候，別相信他，要做好對下游的依賴和熔斷；
第四句話：SOP保平安。我們把所有的流程都變成標准化流程，這比拜大仙還管用，有時候開玩笑說發版之前沒有拜一拜所以掛了，其實不是，而是因為你沒有按照標准流程來操作所以掛了，如果每一步都嚴格按照標准流程來做，它是可信賴的，是不遺不漏的，保證做到方方面面；
最后一句話：你所擔心的事一定會發生，而且可能馬上會發生。最近上了一些功能，你說好像這個地方可能會有問題，你最好趕緊看，也許馬上就會有問題。所以我們建議做例行的巡檢，定期地對你的服務、服務的指標、依賴的情況，有一天你去看發現突然多了一個服務，可能你還不知道。另外對DB、KV這樣一些中間件做例行的巡檢，及時的發現這些里面可能存在的問題。