手機(jī)天貓全局體驗(yàn)組負(fù)責(zé)人吳發(fā)偉于APMCon 2016移動(dòng)性能優(yōu)化專場發(fā)表了題為《天貓客戶端穩(wěn)定性保障以及性能優(yōu)化實(shí)踐》的演講，現(xiàn)場解讀了天貓客戶端在穩(wěn)定性保障方面的舉措，介紹如何從救火式的"消防隊(duì)"轉(zhuǎn)型到能夠及時(shí)的發(fā)現(xiàn)問題、預(yù)防問題的產(chǎn)生，以及解決客戶端啟動(dòng)Crash的利器““安全模式是如何打造的。 我是來自天貓的吳發(fā)偉，今天來介紹一下客戶端架構(gòu)的演進(jìn)、穩(wěn)定性保障這一塊做的事情，最后再簡單介紹一下在性能優(yōu)化實(shí)施的一些舉措。 架構(gòu)演進(jìn) 一開始天貓客戶端每一個(gè)端是一個(gè)同學(xué)在做開發(fā)，這個(gè)時(shí)候大家都很高興，所有人都愉快地進(jìn)行開發(fā)。但是隨著無線占領(lǐng)市場，流量以無線為主，整個(gè)行業(yè)包括阿里也不例外，天貓無線會面臨各種挑戰(zhàn)，我們從一個(gè)團(tuán)隊(duì)負(fù)責(zé)無線，變成多個(gè)團(tuán)隊(duì)負(fù)責(zé)。其次，所有需求必須先在移動(dòng)端上線，以前PC端長線需求必須轉(zhuǎn)到無線上面去做，并且需求也是成倍增加的。所以這個(gè)時(shí)候很多同學(xué)其實(shí)是從后臺或者其他的角色轉(zhuǎn)過來做客戶端的。相對來說他們就算客戶端研發(fā)新同學(xué)，在這種情況下我們?nèi)绾伪Ｕ袭a(chǎn)品的穩(wěn)定性呢，這個(gè)是我們面臨的一個(gè)很大的挑戰(zhàn)。 為什么說架構(gòu)上要做改造?第一，支持多團(tuán)隊(duì)的研發(fā)節(jié)奏。第二，負(fù)責(zé)穩(wěn)定性同學(xué)發(fā)現(xiàn)一個(gè)問題，如果版本發(fā)布要很久，這時(shí)遠(yuǎn)水解不了近火，提升版本的研發(fā)迭代速度非常重要。我總結(jié)兩個(gè)詞語，第一個(gè)對于我們來說研發(fā)效率，第二是用戶體驗(yàn) 。 所以，我們做架構(gòu)改造之前有這些問題，第一個(gè)開發(fā)階段沖突非常多 。因?yàn)榇蠹叶紩瑫r(shí)改一個(gè)地方和模塊，開發(fā)階段 編譯時(shí)間也是耗時(shí)比較久。第二， 發(fā)布周期特別長，這個(gè)時(shí)候是捆綁式研發(fā)模式，只要有任何模塊的業(yè)務(wù)方出現(xiàn)問題，我們整個(gè)版本就發(fā)布不了了。第三，線上質(zhì)量怎么樣去保證?所以，架構(gòu)改造勢在必行。 做架構(gòu)改造有一些原則，這里簡單介紹一下。 第一，算法導(dǎo)入里面提的分而治之，一個(gè)工程說是所有人負(fù)責(zé)事實(shí)上是沒有人去具體負(fù)責(zé)。所以，很重要一個(gè)點(diǎn)就是一定要?jiǎng)澐帜K，SRP就是The Single Responsibility Principle ，單一功能職責(zé)。 第二，就是業(yè)務(wù)模塊的Bundle化 。天貓業(yè)務(wù)模型跟大家說一下，這個(gè)里面有首頁，搜索，店鋪，還有購物車，下單，物流等等這么多業(yè)務(wù)模塊。我們架構(gòu)怎么樣去拆分?橫向是按照功能拆分，第二，就是按業(yè)務(wù)劃分，把首頁的相關(guān)電路模塊劃分到首頁團(tuán)隊(duì)去，這就是康威定律。 接下來提一下架構(gòu)改造用到的一些工具，模塊解耦中有跳轉(zhuǎn)協(xié)議、Rewrite、Beehive。從首頁到商品詳情最下面就是更多的驚喜，直接點(diǎn)一下就可以了。我們要保證研發(fā)速度快，怎樣解除依賴?我們會通過一串URL跳到對應(yīng)的時(shí)候，需要根據(jù)報(bào)的結(jié)構(gòu)跳轉(zhuǎn)過去。第二點(diǎn)是 Rewrite，我們有多個(gè)跳轉(zhuǎn)目的地時(shí)，當(dāng)線上一個(gè)地方出現(xiàn)問題，可以通過它來指到另一個(gè)目的地。第三，Beehive做模塊解耦。 關(guān)于依賴管理工具，這里大概畫了一個(gè)示意圖。 在改造之前就是這樣一個(gè)單工程架構(gòu)，當(dāng)然架構(gòu)有一些分層。我們所有的業(yè)務(wù)都是在上層，UI都是在一個(gè)工程里面開發(fā)，右邊是容器化的架構(gòu)，各個(gè)業(yè)務(wù)團(tuán)隊(duì)可以依賴于這個(gè)業(yè)務(wù)容器進(jìn)行獨(dú)立的開發(fā)，研發(fā)好測試通過就可以及時(shí)地進(jìn)行發(fā)布。通過這樣的改造，可以做到按業(yè)務(wù)進(jìn)行快速迭代的能力。改造之前，大家都是捆綁式的，但是，做了這個(gè)架構(gòu)改造以后，我們就支持多團(tuán)隊(duì)開發(fā)并且能夠做到想發(fā)布隨時(shí)發(fā)布，隨時(shí)進(jìn)行拉分支，把要改動(dòng)的業(yè)務(wù)模塊做一個(gè)集成。因?yàn)槲覀兏鱾€(gè)SDK都是有版本的管理，如果說有問題，我們把它弄掉就可以了。 中間的BUS層就是跳轉(zhuǎn)協(xié)議，還有Rewrite，Beehive。同時(shí)，我們也對之前的一些邏輯，包括一些輔助功能，把它抽離中間鍵，將一部分功能做了合并，這樣有利于安裝包縮小。 穩(wěn)定性保障 穩(wěn)定性保障，上一個(gè)架構(gòu)改造舉措目的就是提升迭代速度，一開始負(fù)責(zé)穩(wěn)定性的時(shí)候就會比較痛苦。舉一個(gè)例子，當(dāng)線上出問題的時(shí)候，你現(xiàn)在修改了，發(fā)布版本需要至少幾天甚至兩周的時(shí)間。如果真的是很重大的問題，像你負(fù)責(zé)的APP到消費(fèi)者手中因?yàn)榫彺鏇]有辦法啟動(dòng)了?怎么辦?有沒有同學(xué)碰到這樣的問題?所以說負(fù)責(zé)穩(wěn)定性同學(xué)很辛苦，他們默默做很多的工作，應(yīng)該多鼓勵(lì)一下。 我們一開始也是碰到這個(gè)情況，面對這種方式最開始我們覺得就是采取救火式，著火了我們就去解決，其實(shí)應(yīng)該建立比較好的機(jī)制去杜絕，甚至各個(gè)環(huán)節(jié)去解決這個(gè)問題。我這里介紹一些相關(guān)經(jīng)驗(yàn)。 按照我們的一個(gè)研發(fā)周期，去把它拆成幾個(gè)環(huán)節(jié)，比如說開發(fā)，測試，灰度，線上，還有線上的監(jiān)控 。 我們把以前線上Crash上報(bào)，再去分析下一個(gè)版本解決的方式。用形成閉環(huán)的方式去解決一些問題，比如說，在開發(fā)階段有這些舉措。 第一，Code Review。第二，預(yù)置開關(guān) ，很多新功能上線的時(shí)候，你做一些hook，做一些前瞻性改動(dòng)，可能不是特別的確定，這個(gè)時(shí)候需要開關(guān)，如果沒有開關(guān)碰到一些狀況，一定會出問題。第三，靜態(tài)掃描 。出現(xiàn)問題，我們不光靠人，是通過機(jī)器、工具，總結(jié)出來一些規(guī)則沉淀成代碼，把風(fēng)險(xiǎn)點(diǎn)掃描出來，并且要及時(shí)通過郵件短信的方式進(jìn)行報(bào)警，防止破窗效應(yīng)。第四個(gè)就是動(dòng)態(tài)檢測 。 第二個(gè)環(huán)節(jié)：測試 。一般出問題都是來自于變動(dòng)，變動(dòng)對于客戶端來說很多時(shí)候就是服務(wù)端response，比如說接口定好了，反饋的字段都是協(xié)商好的，大家都拍著胸脯說不會再有變化了。但是，出現(xiàn)變化的時(shí)候，可能服務(wù)端接口變了，字段缺失，類型也變化了。這種問題怎么去避免呢?在測試階段我們也研發(fā)了相應(yīng)的工具，我們會模擬服務(wù)端各種接口，數(shù)據(jù)，測試客戶端，讓它在各種異常情況下也不會發(fā)生問題。 第三個(gè)環(huán)節(jié)：灰度 ，這個(gè)非常重要。就算開發(fā)測試階段再怎么測試，團(tuán)隊(duì)人手都是有限的，怎么樣去把這些問題更多地暴露出來?我們有渠道包，有內(nèi)部一個(gè)企業(yè)包去測試，去發(fā)現(xiàn)這些問題。 這個(gè)階段發(fā)現(xiàn)問題以后，去做好修復(fù)以后再發(fā)布到線上 ，這樣的話質(zhì)量可以得到比較好的保證。在線上，我們也是比較早開始就有這個(gè)技術(shù)了。然后我們還研發(fā)專門解決啟動(dòng)問題的安全模式，在去年雙11之前就已經(jīng)開始做了。還有客服端一些調(diào)試工具，便于發(fā)現(xiàn)問題。另外就是問題反饋，線上用戶及時(shí)反饋對于我們來說也是非常重要的環(huán)節(jié)，人多力量大，移動(dòng)互聯(lián)網(wǎng)每個(gè)環(huán)境都是不一樣，用戶的及時(shí)問題反饋也是非常重要的。 監(jiān)控 這個(gè)環(huán)節(jié)非常重要，我們負(fù)責(zé)穩(wěn)定性的同學(xué)會對數(shù)據(jù)進(jìn)行監(jiān)控，配置實(shí)時(shí)報(bào)警。比如說看實(shí)時(shí)Crash，原來基準(zhǔn)線可能是5次，當(dāng)它發(fā)生到10次的時(shí)候，我們就會收到短信，甚至是其他方式的及時(shí)報(bào)警，如果是Crash次數(shù)上升，范圍會擴(kuò)大，更多同學(xué)會收到報(bào)警，我們通過這種監(jiān)控方式去及時(shí)發(fā)現(xiàn)問題。發(fā)現(xiàn)問題以后通過一些開關(guān)，包括修復(fù)手段把問題解決掉。但是，就算你考慮的再多方面，難免會出現(xiàn)一些故障。碰到故障以后，我們會進(jìn)行故障的Review，把這一類問題甚至把這個(gè)故障為什么發(fā)生所暴露出來的各個(gè)環(huán)節(jié)去認(rèn)真地討論清楚。討論了以后，不是為了定誰的責(zé)任，而是讓大家明白問題在哪里，下一次如何去避免?我們是通過這些故障的Review，把這整個(gè)環(huán)節(jié)里面的措施一點(diǎn)一點(diǎn)補(bǔ)齊的。還有一部分就是Crash的定位，經(jīng)驗(yàn)沉淀。定位Crash工具有很多，包括上報(bào)，分析等。負(fù)責(zé)穩(wěn)定性的同學(xué)會把潛在一些風(fēng)險(xiǎn)點(diǎn)注意到，保證下一次不發(fā)生。通過這種方式，我們對于穩(wěn)定性形成了一個(gè)閉環(huán)，下面對于其中一些環(huán)節(jié)重點(diǎn)做介紹。 開發(fā)階段，需要重點(diǎn)介紹一下。動(dòng)態(tài)檢測，非主線程UI代碼可以及時(shí)在開發(fā)階段發(fā)現(xiàn)問題。靜態(tài)掃描,凡是編譯器報(bào)出來的OOM，我們一定必須去解決的。報(bào)警比較多，我們花時(shí)間把它梳理一下非常重要。防微杜漸，有一個(gè)效應(yīng)叫做破窗效應(yīng)，一個(gè)窗戶破了，過一周看一下，其他更多地方都破了。所以，一定把任何的細(xì)節(jié)問題在開發(fā)階段都杜絕掉，不要留隱患。 接下來就是配置中心。天貓客戶端有非常重要的基礎(chǔ)設(shè)施，我們會按照客戶端類型，每一個(gè)版本都有配置。開發(fā)的時(shí)候，潛在有一些風(fēng)險(xiǎn)要上線了，我們都給它加上一個(gè)配置，開發(fā)人員自己形成一個(gè)習(xí)慣了。因?yàn)槲覀兘?jīng)常做這樣的技術(shù)分享，加一個(gè)配置非常簡單，首先寫一個(gè)判斷就可以了。最后在服務(wù)端，在后臺我們把相應(yīng)的配置加上去。 第一個(gè)就是Code Review。為什么要做Code Review?首先第一個(gè)問題在開發(fā)階段解決是成本的，而且效率的。用Code Review不只是為了穩(wěn)定性，還可以保障我們的代碼可維持，架構(gòu)也會得到不斷的梳理和完善，第三個(gè)是我們能夠?qū)φw一個(gè)概況產(chǎn)生更直接的了解，還有可能我們有時(shí)候?qū)懘a會覺得，有別人看就可能寫的優(yōu)雅一點(diǎn)，讓別人欣賞我們的代碼。第五點(diǎn)，保證團(tuán)隊(duì)當(dāng)中至少兩個(gè)同學(xué)懂這一塊代碼，這一點(diǎn)非常重要。我分享一個(gè)案例，一個(gè)國外做游戲視頻直播的公司，他們團(tuán)隊(duì)3個(gè)技術(shù)同學(xué)，每一個(gè)同學(xué)負(fù)責(zé)非常大一塊功能開發(fā)。恰好團(tuán)隊(duì)當(dāng)中有一個(gè)同學(xué)要出去旅游，美國人都比較瀟灑，報(bào)一下老板也會批，休假了之后這個(gè)時(shí)候恰好碰上一個(gè)網(wǎng)紅，在網(wǎng)站上直播，服務(wù)器掛了。只有那個(gè)同學(xué)懂，這個(gè)時(shí)候怎么辦?最后問題很簡單，那個(gè)同學(xué)重啟機(jī)器就解決了。 所以，我想舉的例子就是這樣。尤其是團(tuán)隊(duì)和產(chǎn)品經(jīng)理，這一點(diǎn)非常重要，團(tuán)隊(duì)同事很重要。團(tuán)隊(duì)不要出現(xiàn)單點(diǎn)，一定要有備份。這樣的話，團(tuán)隊(duì)同學(xué)包括TEL，大家都是可以為整個(gè)的客戶端的穩(wěn)定性做出很好的保障。 最后一點(diǎn)，Phabricator。就是團(tuán)隊(duì)肯定有很多的安卓工程師，有很多的專家，所謂專家就是把所有錯(cuò)誤都是犯過一次，或者看別人犯過一次的人。怎么樣把這種經(jīng)驗(yàn)傳遞下去?分享肯定就是要做的，但是那個(gè)頻率不會特別高。如果讓新同學(xué)把之前犯過的錯(cuò)誤，把一些功能問題上去了再改這個(gè)成本非常高。通過Code Review就可以使得新的工程師經(jīng)驗(yàn)得到快速成長。有的時(shí)候，相互做Review的時(shí)候，被Review的同學(xué)也是可以提一些很有趣的觀點(diǎn)給一些的同學(xué)。所以，這個(gè)東西是使得團(tuán)隊(duì)的成員每一個(gè)人的經(jīng)驗(yàn)，能力都可以得到提升。 這里有一個(gè)數(shù)據(jù)，大家可以看一下。 Code Review不是說寫了代碼我們?nèi)彶?，而是在設(shè)計(jì)方案的時(shí)候同時(shí)在審查方案可不可行。大家可以看一下。通過Design and code inspections可以提前發(fā)現(xiàn)60%的問題。我們花很大力量去做單測只能解決20%，但是在前面做這些事情，成本更低，效果更好。Code Review在工業(yè)界的做法，硅谷，facebook，還有谷歌都是非常嚴(yán)格的去執(zhí)行的。 現(xiàn)在我們團(tuán)隊(duì)已經(jīng)有一半同學(xué)會去做提交前的Review，還有一些同學(xué)就是做提交后的Review，接下來就是推動(dòng)讓所有同學(xué)都做到提交前的一個(gè)Review。 說下我們的線上運(yùn)維。我們把一個(gè)事件處理定義成這樣幾個(gè)階段。 第一監(jiān)控，第二報(bào)警，第三解決，第四預(yù)防。第一，我們會有一個(gè)專門的平臺，整個(gè)平臺共用一套基礎(chǔ)設(shè)施，可以把用戶的Crash日志，包括Crash的數(shù)量、用戶數(shù)，Crash率都在這個(gè)平臺上面做處理。有問題的時(shí)候超過一定閾值，通過集團(tuán)內(nèi)部一個(gè)工具，叫做Xflush，它的目的就是為了監(jiān)控報(bào)警。第三個(gè)階段，就是修復(fù)它了，修復(fù)的手段就是剛剛講的，第一就是修復(fù)工具，比如說iOS、安卓的一些修復(fù)手段。第二就是安全模式，一會兒介紹一下啟動(dòng)階段的安全模式設(shè)計(jì)。第三個(gè)就是配置中心。第四個(gè)預(yù)防，通過這樣一套體系來做線上的運(yùn)維。 下面介紹一下天貓客戶端安全模式，我們的1.0就是去年10月份做的，當(dāng)時(shí)是重大活動(dòng)一個(gè)前夕，壓力很大。但我們還是在比較短的時(shí)間做出了1.0版本，就是用來解決啟動(dòng)的問題，當(dāng)時(shí)設(shè)計(jì)兩級安全模式，第一級安全模式的原理，我這邊介紹一下。 這個(gè)思路還是比較的簡單，短時(shí)間連續(xù)Crash的時(shí)候，第一個(gè)動(dòng)作是進(jìn)入第一級安全模式，就是把關(guān)鍵點(diǎn)清空。從安卓市場下載APP第一次啟動(dòng)沒有問題，有問題肯定也不會發(fā)出去。導(dǎo)致問題的一般來說都是服務(wù)端下發(fā)數(shù)據(jù)，第一步清除關(guān)鍵目錄緩存，我們會讓它正常啟動(dòng)。這個(gè)時(shí)候如果還是發(fā)生Crash，我們就讓它進(jìn)入到二級安全模式。讓整個(gè)APP恢復(fù)到初始安裝狀態(tài)，把所有的包括非關(guān)鍵目錄的其他地方的文件都清空掉。同時(shí)支持啟動(dòng)過程當(dāng)中做熱修復(fù)，這一點(diǎn)很重要。就是緩存搞不定的時(shí)候，我們可以通過Crash、熱修復(fù)解決這個(gè)問題。 V2.0時(shí)做了更多的工作，比如說，安全模式在比較極端情況下，如果說你依賴很多SDK，我們做了一個(gè)解耦，把對于其他的SDK依賴全部解耦掉了。并且1.0的時(shí)候還有一個(gè)界面就是提示用戶點(diǎn)此修復(fù)，我們再去修復(fù)這個(gè)問題。但是在2.0時(shí)開始做了一個(gè)無感修復(fù)。用戶看不到這個(gè)頁面，我們在后臺默默把這些問題解決掉。因?yàn)樵谶@種情況下快速解決問題才是最重要的。 然后，3.0版本我們做了SDK化。之后的4.0我們支持了灰度，并且支持測試。還有一個(gè)支持業(yè)務(wù)定制。舉個(gè)場景講一講支持業(yè)務(wù)定制什么意思?假設(shè)APP不是啟動(dòng)的Crash，啟動(dòng)之后，點(diǎn)了首頁一個(gè)按鈕或者一個(gè)頻道，再到頻道里面才會加載一個(gè)緩存，但是，這可能就不算啟動(dòng)Crash，因?yàn)樗瞧毡檫^一段時(shí)間，這種問題怎么處理呢?我們的一個(gè)設(shè)計(jì)方案支持在啟動(dòng)階段對于特定業(yè)務(wù)一個(gè)緩存做清除操作，在服務(wù)端增加目錄地址，這個(gè)下一次啟動(dòng)的時(shí)候，不點(diǎn)有問題的地方，就是在啟動(dòng)階段把有問題的干掉了。 下面這個(gè)圖畫的比較抽象一點(diǎn)。 配置中心剛剛提到了，數(shù)據(jù)中心就是一些補(bǔ)丁之類的。測試，我們之前說安全模式很重要，所以做了以后就是會想，如果承諾做了安全模式，但是過了半年，安全模式不生效，我覺得這個(gè)是有問題的。一開始測試時(shí)間比較久，就是制造各種各樣的邊界條件，開始測斷斷續(xù)續(xù)需要4個(gè)小時(shí)。我們根據(jù)很多的場景做很多內(nèi)部小工具，把這一塊工作簡化掉，現(xiàn)在這一塊的測試完成只需要10分鐘就可以搞定了，大幅度的提升測試效率。 大家覺得一周之中線上故障周一到周日哪故障問題數(shù)最少?我講一下答案。可以看一下這個(gè)圖。 經(jīng)統(tǒng)計(jì)發(fā)現(xiàn)，周六線上故障出問題的次數(shù)最少。為什么?因?yàn)橹芰膭?dòng)最少。所以，用一個(gè)詞，叫做no zuo no die，去改動(dòng)很容易帶來一些問題。一個(gè)改動(dòng)會帶來問題，下面的圖是按照周維度講的。為什么有兩周完全沒有故障;第一周就是12月最后一周，還有就是第二月第三周，這里直接講答案了。第一個(gè)是圣誕節(jié)的時(shí)候沒有問題，第二，是在幫同事做360度的績效評估，這個(gè)就沒有什么問題。所以，有一本書講的好，可以給大家推薦一下：《你的燈亮著嗎?》想改動(dòng)的話，如果沒有想出三個(gè)點(diǎn)，說明對這個(gè)問題思考還不是很深刻。不可以說我這個(gè)完全沒有問題，但是可能還是不錯(cuò)的。所以，我們制訂一個(gè)規(guī)則，就是在工作日期發(fā)布。這一點(diǎn)很重要。這個(gè)跟之前一些認(rèn)知有一些變化?？蛻舳说脑?，我們要在工作日期發(fā)布，這樣就可以及時(shí)做回穩(wěn)和處理，及時(shí)發(fā)現(xiàn)和解決問題。如果是周末可能找不到人。 灰度發(fā)布，這里是講配置的灰度發(fā)布。經(jīng)過分析發(fā)現(xiàn)改線上配置，是導(dǎo)致出現(xiàn)Crash問題一個(gè)非常重大的人為原因之一，如果有配置中心，改一個(gè)配置全量生效的話，非常容易導(dǎo)致Crash。所以從經(jīng)驗(yàn)上來講，我們配置一定是灰度發(fā)布的。我們在業(yè)務(wù)快速上線，快速迭代的同時(shí)，iOS、安卓的Crash率做到0.03%左右。這就是一個(gè)穩(wěn)定性優(yōu)化的結(jié)果。下一個(gè)階段的重點(diǎn)，就是要解決Native Crash，包括iOS和安卓，還有OOM。 性能優(yōu)化 簡單介紹一下新的優(yōu)化舉措 Webview大家可以看一下，剛剛講過了，第一個(gè)就是WKWebview，第二個(gè)跟UC合作，安卓端用UC內(nèi)核來做一個(gè)提升，用了UCWebview之后，速度提升了百分之十幾。還有就是圖片庫做了很多優(yōu)化措施，尤其是移動(dòng)端，在4G、無線網(wǎng)情況下，對于圖片的尺寸，屏幕大小，要根據(jù)屏幕大小做很多的裁剪、優(yōu)化。網(wǎng)絡(luò)這一部分做很多的比如說請求合并，包括使用緩存，還有SPDY，我們現(xiàn)在是支持SPDY的。關(guān)于流暢度，我們根據(jù)不同頁面的情況對卡頓的地方做優(yōu)化，把BS這一塊提升上去。啟動(dòng)優(yōu)化我們做了很多，比如任務(wù)分級，加載等等。最后一個(gè)是安裝包瘦身，瘦身了之后，有一個(gè)業(yè)務(wù)會上去，這個(gè)是循環(huán)變化的過程。降下去了以后，過一段時(shí)間又上去了，這個(gè)是持續(xù)做的。 這里對穩(wěn)定性和性能優(yōu)化措施做一個(gè)總結(jié)。 我們從救火式方式到形成閉環(huán)體系化方式去解決問題。就是用這樣幾個(gè)詞語，預(yù)防，監(jiān)控，解決，報(bào)警。每一個(gè)環(huán)節(jié)都是可以梳理做很多的自動(dòng)化測試工具和經(jīng)驗(yàn)沉淀。中間有一句話：Move fast with stable infrastructure 。我們要在快速迭代的同時(shí)保證基礎(chǔ)架構(gòu)的穩(wěn)定。

« 數(shù)果智能：智能時(shí)代大數(shù)據(jù)實(shí)時(shí)分析技術(shù)DaTalk專業(yè)觀眾火熱招募 | 這家零售店 如何做到單店年平均銷售是星巴克的3倍？ »