美團外賣系統架構演進與穩定性的探索

「相信大部分人都用過美團外賣，尤爲是在天天的兩個吃飯的高峯期。美團外賣從創業到如今經歷了數次的迭代，不斷的適應需求，提供更好的體驗。本文是美團外賣架構師曹振團在ArchSummit 2016 深圳站上的分享。老司機簡介

曹振團，美團外賣技術專家/架構師，目前負責美團外賣業務系統的架構設計及優化工做。2013年加入美團，早期參與了多個創新業務的探索。經歷了美團外賣從無到有的創業過程，以及業務快速發展的高增加期，積累了豐富的從0到1業務系統的架構設計和優化經驗。加入美團以前，在網易網站部工做，負 責後臺服務的設計和開發工做，擁有豐富的高併發系統的架構設計和實戰經驗。

本視頻時長39分，建議在Wifi環境下觀看。

技術體系架構演進

簡單介紹一下外賣如今的狀況：咱們從2013年10月份作外賣的事情，是從餐飲外賣開始的。通過兩年多的發展，咱們不光能夠提供餐飲外賣，也能夠提供水果、鮮花、蛋糕、下午茶甚至是超市和便利店一些外送的服務。咱們作外賣過程當中，咱們發現用戶對外送的體驗有兩個關注點：

1. 第一個是品質，用戶對品質要求很是高，送過來的飯不能涼了，不能很差看，送餐員身上髒兮兮也不行會影響食慾的；

2. 另一個關注點要準時，必定要按時間送到，好比我要求按12點送到就必定要按12點送到，不能早也不能晚，若是早爲何很差呢？11點40送到不行，咱們正在跟老闆開會，一會一個電話太煩了；12點20送來也不行，太餓了，我都餓暈了，中午也有不少的安排，吃完飯可能要睡一會，中午不睡下午崩潰呀。

咱們發現若是要把用戶體驗作到極致的話，作得足夠好能保證用戶獲得足夠好的體驗，咱們就要作專送的服務。因此咱們正在作的是美團外賣的平臺和咱們本身的配送服務。

咱們從2013年10月份確立作這個事情，到11月份正式上線，到14年末11月份時突破日訂單一百萬單，15年的5月份大概突破了天天兩百萬單，而後大概15年12月份作到天天三百萬單，今年5月份的時候咱們作到了四百萬單天天。咱們但願在響應國家大的號召下，咱們作供給側改革。咱們但願給你們提供更多的、優質的、可選的外送服務，但願將來的某一天作到天天1000萬單。

介紹一下咱們的業務，也介紹一下在作這個業務過程當中技術架構的演進的歷程。咱們在開始作外賣的時候發現，那時候都是經過電話來點外賣的，小餐館的老闆發傳單，咱們用傳單上的電話給老闆打電話下單。咱們在思考咱們是否是能夠把電話點餐的事情變成網絡點餐，讓用戶只須要在網絡上點點點就好了，不用打電話。

因而咱們在公司周圍的商家摸索這個事情，咱們早上下了地鐵在地鐵口發傳單。咱們怎麼可以最快地去驗證這個事情是否可行？

咱們提供了一個很是簡單的Web版本和Android的App，對於商家那一邊咱們沒有提供任何軟件的服務，用戶在咱們平臺裏下單之後，咱們再打電話給商家下單，有時候咱們是發傳單的，有時候咱們是接線員，用戶在咱們平臺上下單，咱們再打電話給商家下單，而後再去寫代碼。那時候基本上沒有太多架構考慮，就是怎麼快怎麼來，以最快的速度去把咱們的功能給變上去。

這個事情咱們驗證以後發現確實可行，咱們發現「懶」是極大的需求。由於懶得去換臺，因此發明了遙控器，懶得爬樓梯就發明了電梯，人都是很懶的，由於懶得打電話訂餐，因此在網上點點點就行了。

咱們發現這是極強的需求，因而咱們就考慮規模化，由於只有規模化以後邊際的成本才能夠變低，這套軟件在一個區域能夠用，在一個城市能夠用、在全國也能夠用，咱們的開發成本就是這麼多，因此咱們在嘗試在作規模化。

這個過程爆發性產生了很是多系統，咱們在用戶這邊提供各類APP，商家這一邊咱們也開始提供服務。咱們給商家提供PC的版本、App版本，還給商家提供打印機。

打印機是跟咱們後臺是聯網的，若是用戶在咱們平臺上下單，咱們會直接推送到這個打印機上，這個打印機能夠直接打出單子，同時能夠用林志玲或者郭德綱的聲音告訴你：「你有美團外賣的訂單請及時處理」，這是對商家很是好的效率提高；同時咱們給自身運營的系統加了不少功能，咱們有上單、審覈等各類各樣的系統等爆發性地產生了。

在這個階段咱們業務發展特別快致使咱們堆了特別多的系統，這個時候也並無作很是清晰的架構，就是想把這個系統儘快地提供上線。這時候全部的表都在一個數據庫裏，你們都對這件事情很是熟悉，我能夠作訂單，也能夠作管理系統。

可是這個事情在規模化、用戶量迅速上升以後給咱們帶來很是大的困擾，由於以前咱們是有不少技術欠債的，在這個階段裏面咱們就作了重大的架構調整，在這個調整裏主要說兩點：

1. 第一點就是拆

   咱們把不少耦合在一塊兒的服務作服務化拆分，服務與服務之間經過接口來調用和訪問，服務本身保護本身的庫：不能訪問別人的庫，不然叫出軌；你的數據庫也不能被別人訪問，不然叫綠帽子。

2. 第二點是中間件

   咱們在這個階段引進了不少中間件，包括了在開源基礎上自研的KV系統，咱們也引用了搜索Elasticsearch，咱們經過Databus抓取數據庫的變動，把數據庫的實時變動刷到緩存和索引裏，讓這個中間件作到穩定可靠的服務。

總結一下的話，咱們的演進大概分了這樣一個階段：總體上有一個多邏輯耦合在一塊兒的狀況按服務化拆分出來，每個服務獨立專一地作一個事情，而後咱們再作應用級的容錯，到如今咱們在作多機房的容錯。

在緩存上，咱們早期使用了Redis，在Redis Cluster還沒發佈以前咱們用了他們的Alpha版本，固然也踩了不少坑。後來咱們用了自研的KV系統，最先的時候咱們把全部業務的KV都是共用的，這個也有很大的問題：若是全部的業務共用的KV集羣，其中某一個業務致使這個KV集羣有問題的話，全部的業務都受影響。後來咱們也作了每個業務拆分本身專用的KV集羣。

在數據庫這一層上，基本上是把一些大表的查詢、對數據庫有較大傷害的查詢變成了高級的搜索，在數據庫和應用層之間加了中間件。

在360開源的Atlas基礎上作了咱們本身的定製，這個中間件有個好處：咱們對數據庫的變動對於業務層是透明的，好比說以爲能力不夠要擴容，咱們加幾臺從庫，業務方是無感知的，並且咱們會作SQL的分組，即數據庫的分組，哪些SQL到哪一個數據庫上，到主庫仍是從庫上去，咱們業務是不用關心的。

遇到的挑戰

下面介紹一下作外賣這個事情上遇到的挑戰：

1. 第一個挑戰，外賣這個事情具備一個典型的特色，就是彙集在中午和晚上兩個吃飯的高峯期，這自然就是很是集中的秒殺的場景，由於你們會集中在11點10分到11點半去下單。咱們在高峯期的時候，有一分鐘接進2萬單的巨大流量；

2. 第二個挑戰，你們理解送外賣是一個很簡單的事情，我點了餐，送過來，我愉快的把它吃掉就結束了，可是作外賣的事情上咱們發現確實蠻複雜的，由於咱們發現用戶要下單，要支付，咱們還要調度一個配送員，咱們找一個最快最合理的騎手，讓他到時間取餐送過去，同時還要給這個騎手最好的路徑規劃，告訴他走這條路是最快的。因此整個是一個很是複雜的過程，有很是很是多的服務；

3. 另外，外賣仍是快速發展的階段，對咱們的挑戰是迭代太快了，你可能要頻繁的發版，就有穩定性的風險，可能有Bug，可能有測試不全的狀況。另外是項目週期短，業務發展很快有不少業務需求正在排隊，架構優化的工做可能排不上去，甚至作技術架構設計的時候可能有一些折中，這是極大的隱患，咱們把它叫技術欠債。

   咱們有一個列表記錄下來這些技術欠債，會記清楚說這是一個什麼樣的條件下作的方案，它在什麼狀況下可能會有哪些問題，須要在何時必須去作哪些事情；另一塊在監控的壓力也很大，由於業務變化很是快，你今天是這樣設置監控規則，明天業務又變了。

如何保持穩定性

介紹一下咱們對於穩定性的定義，咱們也是拿四個「9」來衡量穩定性，可是咱們分別用於兩個指標：系統可用性和訂單的可用性。

1. 系統可用性四個"9"意味着整年的宕機時間不超過52分鐘，咱們是按季度考覈的，至關於一個季度系統宕機時間不超過13分鐘；

2. 另一個維度訂單可用性也是四個"9"，意味着咱們一個季度是一億單的話，這個季度的訂單損失不能超過1萬單，而咱們高峯期一分鐘就接近兩萬單，所以只要這個系統有問題，咱們這個KPI就沒法完成。

咱們仍是要保證四個"9"的可靠性，而咱們怎麼去作：咱們從四個階段來紮實地作這些事情：一個是平常運行，二是事前預警，三是事故處理，四是過後總結，我會詳細地介紹這四個環節：

1、平常運行

首先在平常運行裏面，咱們要作好穩定性的架構設計，這裏有幾個原則：

第一個是大系統小作

咱們不但願作一個很是大的系統，它什麼都能作，咱們但願作小的系統，很是專一，功能相對獨立。咱們先把功能相對獨立的系統拆開，在早期發展過程當中，大家看咱們有一個系統它什麼都能幹，它實際上是一個Web項目，還提供了Web的服務，同時還提供了App的API服務，它還消費消息隊列，仍是Job的執行者，這就帶來一個問題：你消費消息的邏輯發生變化了，你就要去發版，其實別的功能是沒有變化的，發版就會影響到其餘的功能。當咱們把幾個系統拆開，它就是四個獨立的系統；

第二個原則是依賴穩定性原則，你提供的服務必定是穩定可靠的

這裏但願是將易變的和不變的地方拆開。舉個例子，對於商家的服務，對於C端的用戶和服務來講，用到最大的場景就是GetById，就是知道這個商家的信息就行了，可是咱們還有不少對商家管理的服務需求，好比說商家符合什麼條件才能上線，須要什麼過程才能改他的菜品，這些管理的功能是常常變化的，對於讀取的信息是不變的，因而咱們把這它拆開，把它變爲讀的服務和管理的服務。管理的服務能夠隨時發版，沒有關係，讀的服務是很是穩定的，基本不發版；

最後一個原則是設計這個穩定性的時候須要考慮用戶的體驗

須要考慮在系統出現問題的時候用戶怎麼辦？相信不少同窗都有這個體驗：可能APP上忽然有提示失敗、服務器異常、空，不知道什麼狀況。我相信用戶遇到這種狀況必定會不停刷新的，這時候若是後臺已經有問題的話實際上是糟糕的事情，因此設計的時候要考慮到在異常狀況下用戶的體驗和用戶如何引導。

平常運行裏面，另一個工做是作例行的穩定性巡檢

一、好比說咱們作專項的巡檢

對DB來說，咱們每月要作DB容量的Review，咱們看哪些表是大表、讀寫的QPS以及它的容量，以及將來某一天它能不能支持業務的發展；

二、咱們會作靜態的梳理

咱們按場景梳理，例如首頁、Banner、列表頁，這些場景用到哪些服務，這些服務又用到了哪些服務，這些過程當中，它們對下游的調用是否存在放大的狀況。有一些狀況是假的高併發。

好比說有一個服務是說告訴商家今天有幾個新訂單，這個功能很簡單，就是在前端頁面去作輪詢，這個過程其實80%-90%的查詢是無效的，由於一旦有新訂單咱們就會推送到商家，商家就會及時地處理掉，查這個請求實際上是無效的，這麼多無效的請求去查訂單的服務，最終還要落到數據庫上，這是假的高併發，這裏咱們在前面加一層緩存，把到數據庫的這一層假的高併發給幹掉；

三、另一個例行的工做是對指標的巡檢

咱們有許多的監控指標，尤爲是關注它的尖刺，這些尖刺也不會放過。

對於平時來說，給咱們加強穩定性最可靠的信心就是在線壓測，咱們和其餘大廠差很少，咱們也在作在線壓測這個東西，咱們有一個在線壓測的平臺。咱們但願經過壓測來發現什麼呢？首先發現系統裏面的性能瓶頸，到底哪一個系統是裏面最弱的，以及咱們要知道系統服務的上限和能力。

另外更關鍵的是，咱們須要經過壓測來驗證咱們的監控和報警機制是否生效的，可能不少時候你們都說咱們配置了很是完整的監控方案，可是它可能不生效，一旦不生效就慘了。另外，咱們要經過壓測指導咱們報警的警惕線是怎麼設置，到底CPU是設置是30%仍是70%，何時該報警，咱們就經過壓測來確立。

這個壓測告訴咱們指導意見，警惕線設置到哪一個位置是給你留有充足時間的，若是你的報警發生以後立刻掛了，其實報警是沒有用的。咱們能夠經過壓測來要設置警惕行動線，到這個時候咱們要考慮和關注這個問題，留給穩定性處理有足夠的時間。

咱們怎麼作呢？咱們把線上的流量通過日誌錄取下來，把錄取的流量放到咱們的壓測平臺裏，這是對於讀請求的。對於寫請求的，咱們作一些事務的模擬，咱們有一些模擬的腳本僞造一些根據咱們場景作的數據。

這些數據再通過一次染色，把真實數據和測試數據隔離開，通過咱們異步階梯加壓的模塊，咱們先經過異步的方式把它迅速打起來，咱們能夠把量打地很是高；另外咱們是經過階梯性地打，咱們不是一次打到2萬，咱們可能先到5000，而後再到9000，而後打到15000，而後再持續10分鐘。

咱們對這個監控的流量施壓過程和跟咱們監控指標關聯起來，咱們作壓測以前先看和哪幾個指標關聯，哪幾個指標到了什麼閾值就自動停止壓測，畢竟咱們是在線上作這些事情，不能對真實線上的狀況產生影響。對於其餘依賴的服務，好比說支付，這些真的不能壓到銀行去，外部的服務咱們作了一些Mock。

2、事前預警

對於事前預警階段，若是真的有事故發生咱們但願更早曝露出來，觸發報警，而後有充足的時間去應對這些事情，咱們在這個地方在事前預警階段咱們有一些監控心得：

首先是有分層的監控：有系統級的監控，例如性能指標的監控，還有業務監控，咱們還有平時健康度的分析，咱們的應用是否是健康的。

咱們分享一下在業務監控的想法，業務監控實際上是最讓你放心的，你有一個業務大盤，這個大盤若是有一個波動你就立馬發現了，說明如今可能會有影響，你可能會收到報警，例如什麼CPU的報警，你去看大盤，大盤可能說沒有什麼影響，這樣你不會那麼慌。

另外，咱們系統裏面把訂單相關的全部信息和重要節點作了日誌的輸出，日誌經過flume收集到Kafka再到Storm裏，咱們在Storm裏對這些日誌進行匯聚，匯聚的結果放在HBase裏，在這些結果裏咱們有幾個很是好的應用：

1. 例如首先只要告訴我一個訂單號或者手機號，我能夠查到這個訂單走到了哪一個環節，到了哪一個服務的哪一個服務器掛掉了，解決這類問題很是的方便；

2. 另外咱們還能夠把這些指標作成監控曲線，好比說你要下單，下單量是這麼高，到了接單的環節它出現了降低，接單這個服務可能關聯的ABC三個服務：可能有商家、PC、打印機的接單，究竟是哪一個服務出了問題致使了大盤的降低，咱們的曲線能夠很是方便地看出來。

3、事故處理

還有可能有一些意想不到的事情發生，真的出現了事故怎麼辦？第一原則就是及時止損。咱們知道發版是致使穩定性變化的第一因素，若是立馬肯定是由發版引發的此次事故，最快速最有效的方法就是回滾。另外可能還有一些流量異常，對於流量異常咱們有限流的模塊，咱們提供了三種限流的策略：

1. 第一種是防刷的，防止用戶頻繁刷新致使後臺的流量繼續放大；

2. 另一個策略是等待+限時的服務，用戶其實在用咱們平臺的時候，用戶確實是須要選的，可能要選來選去才能下單，對於這些服務，咱們但願說你願意等一段時間咱們能夠提供，好比說你願意等10秒鐘，我給你提供20分鐘的服務，這段時間應該是能夠下完單的；

3. 還有一種策略是對單機的QPS保護：咱們壓測驗證的時候這個服務單機能達到500QPS是穩定可靠的，再往高有問題的話，我能夠啓動這樣一個保護，確保你可以以最大的服務能力提供服務而不至於掛掉。另外在單機QPS保護中咱們須要把關鍵的路徑去放過，你真的不但願用戶在下單、支付的這些路徑把它幹掉或流空掉，這些服務咱們就用白名單的方式放過。

4、事故總結

事故發生以後，咱們須要對事故作一個很是深入的總結。這裏面有幾個很是強的要求，第一是必須找到根源，根源咱們採用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這樣一些中間件作例行的巡檢，及時的發現這些裏面可能存在的問題。