今天是會(huì)議的最后一天，日程的安排要更加簡單些，徹底放棄了Facebook的session，搞不好這個(gè)MyRocks的數(shù)據(jù)庫引擎還不如高斯DB……。所以第一個(gè)話題選擇了阿里的《Capacity Planning and Full-Link Pressure Test》，內(nèi)容主要是它們的壓測策略以及流量控制的策略，非常豐富，我只能勉強(qiáng)總結(jié)下，畢竟這些場景不是在一般公司能遇到的。
話題總共包含了四個(gè)部分:
1. 業(yè)務(wù)模型估計(jì)。這里介紹流量模型、利用歷史數(shù)據(jù)以及預(yù)測算法進(jìn)行估計(jì)。
2. 容量估計(jì)。這里先介紹了四種對于單機(jī)壓測的方法。
a. 模擬。利用ab，jmeter，gatlling去模擬場景，對服務(wù)器進(jìn)行壓力測試。其優(yōu)點(diǎn)在于實(shí)現(xiàn)簡單，缺點(diǎn)在于并非真實(shí)的生產(chǎn)流量，并且可能帶來額外的臟數(shù)據(jù)。
b. 復(fù)制。利用工具復(fù)制生產(chǎn)環(huán)境的流量，比如tcpcopy等。缺點(diǎn)在于需要額外的機(jī)器以及仍然無法避免臟數(shù)據(jù)。
c. 重定向。將流量重定向到單臺(tái)服務(wù)器上。剛開始聽還是覺得有點(diǎn)奇怪，但是想想也是個(gè)不錯(cuò)的方式。
d. 負(fù)載均衡。利用負(fù)載均衡工具將大部分流量指向一臺(tái)服務(wù)器進(jìn)行壓測，這里不會(huì)有臟數(shù)據(jù)，只是對于新的應(yīng)用或者說流量不大的應(yīng)用不太適應(yīng)。
3. 全鏈路壓測。通過全鏈路壓測來模擬超高流量(千萬/秒請求)，這里的全鏈路應(yīng)該指的是在不同的網(wǎng)絡(luò)環(huán)境下，如電信、聯(lián)通有線網(wǎng)絡(luò)，以及移動(dòng)網(wǎng)絡(luò)下運(yùn)行壓力測試引擎，測試數(shù)據(jù)和真實(shí)的用戶數(shù)據(jù)分離，中間件可以調(diào)整流量的比例，如果監(jiān)控到流量過高會(huì)通知中間件修改負(fù)載均衡比例，據(jù)稱這里的切換的時(shí)間可以到1s。
4. 流量控制?？赡苁且?yàn)橛⑽牡年P(guān)系，這里的公式?jīng)]聽明白，后來也沒什么機(jī)會(huì)找到阿里的講師，只能等下載到PPT后再研究或者請教下講師。
這個(gè)話題質(zhì)量很高，只是很多老外對于雙11沒有概念，后來還有人在問每秒一千萬請求是純交易流量還是算是圖片下載之類。個(gè)人覺得如果可以先羅列下雙11的相關(guān)數(shù)字，那個(gè)三哥可能要跪著提問了。
容量計(jì)劃專場的下一個(gè)session是來自Linkedin的《Managing Capacity in a Highly Dynamic Data Ingestion Pipeline》，幾位工程師介紹了linkedin的數(shù)據(jù)流水線以及相關(guān)組件的容量規(guī)劃。Linkedin目前全球的數(shù)據(jù)中心大約有95k服務(wù)器，各種不同的數(shù)據(jù)庫存儲(chǔ)也都是在PB級(jí)別。Linkedin的數(shù)據(jù)流水線和Netflix的數(shù)據(jù)流水線稍有不同，Netflix數(shù)據(jù)流水線是典型的Lambda架構(gòu)，將所有數(shù)據(jù)經(jīng)由kafka，然后路由到不同的地方，其中原始數(shù)據(jù)全部sink到s3，然后通過EMR的batch job去處理數(shù)據(jù)生成報(bào)告，有一部分日志數(shù)據(jù)會(huì)塞到elasticsearch 集群中，還有一部分實(shí)時(shí)數(shù)據(jù)通過spark steaming去處理。Linkedin用到工具不太相同，而且數(shù)據(jù)從一開始就分別寫到了不同的地方，Oracle DB，Espresso（NoSQL）以及Kafka。后面的數(shù)據(jù)存儲(chǔ)的容量規(guī)劃中提到了Kafka容量規(guī)劃時(shí)他們把這個(gè)比例控制在了60%，以防止其他節(jié)點(diǎn)出錯(cuò)，突然有大量數(shù)據(jù)寫入。Session結(jié)束后找講師問了幾個(gè)問題，我覺得三哥的工程師看上去還挺認(rèn)真的，對于具體的問題，不熟悉的就找旁邊的同事回答，態(tài)度很好。
上午的最后一個(gè)session是Digital Ocean的工程師Matthew Campbell，我說為什么看著這么熟悉，原來是prometheusConf上面介紹DigitalOcean的prometheus實(shí)踐的講師。Matthew講的話題是《Distributed Scheduler Hell》，內(nèi)容是關(guān)于DigitalOcean使用的分布式調(diào)度工具演進(jìn)過程。他們最終的選擇是k8s，但是提到Mesos的使用體驗(yàn)時(shí)，他們遭遇過一次網(wǎng)絡(luò)事故，結(jié)果mesos master把網(wǎng)絡(luò)出問題的數(shù)據(jù)中心的服務(wù)全部干掉了，這導(dǎo)致他們放棄了Mesos。It's ok, Mesos, I still love you。
下午的session幾乎都變成了雙簧，先是一對狗（Google）男女上演了一出《SRE your gRPC》，介紹了grpc設(shè)計(jì)的一些理念和特性，比如負(fù)載均衡，提早失敗，優(yōu)雅降級(jí)。兩年前我參與翻譯grpc的文檔時(shí)怎能想到這貨現(xiàn)在會(huì)這么火……。Google SRE 那本書中提到的Google內(nèi)部大量的服務(wù)都是使用gRPC，gRPC基于http2設(shè)計(jì)，所以占盡了http2便宜，看來今年值得花一些時(shí)間去學(xué)習(xí)下gRPC。
接下來的session來自REA的JC和Matt，以前的客戶，話題是《Operationalizing DevOps Teaching》，介紹REA如何引導(dǎo) 和培訓(xùn)畢業(yè)生，讓他們在進(jìn)入公司后快速成長，甚至于能在工作一年左右，就能勝任對能力要求很高的DevOps或者Ops這樣的角色。作為REA的乙方，同時(shí)也是畢業(yè)生的身份進(jìn)入項(xiàng)目，我為REA工作了將近6年的時(shí)間，也是REA這種培訓(xùn)、分享和幫助文化的受益者。我可以大概介紹下他們?yōu)榱水厴I(yè)生的成長所作的一些事情。
早先REA是完全不招畢業(yè)生的，和我一起工作的REA的客戶，大部分都是10年以上的工作經(jīng)驗(yàn)。后來可能是因?yàn)楹芏嗳苏业搅诵碌臋C(jī)會(huì)，不斷離職，而澳洲的IT市場相對比較小，招聘成本高，也很難找到合適的人，這才開始校招。校招的學(xué)生入職后，大概會(huì)經(jīng)歷下面的過程:
1. 為期幾天的全脫產(chǎn)的培訓(xùn)，會(huì)有來自不同方向(開發(fā)，DevOps，運(yùn)維等)方向
2. 畢業(yè)生會(huì)在不同的部門，不同類型的項(xiàng)目上工作一段時(shí)間（如兩周），從事不同的角色，比如開發(fā)、運(yùn)維、DevOps等，體會(huì)不同團(tuán)隊(duì)、角色的工作方式，了解公司的文化，同時(shí)跟著一堆十年左右工作經(jīng)驗(yàn)的工程師結(jié)對完成事情。
3. 這一圈完成后才正式分配到具體的業(yè)務(wù)線、項(xiàng)目上，同時(shí)有專門的mentor去輔導(dǎo)他，team里面的delivery lead之類的人也會(huì)經(jīng)常找他聊聊天。
4. 除此之外，公司有各種各樣的guild以及workshop，對新人的學(xué)習(xí)幫助也很大。作為乙方的我，也經(jīng)常享受到這樣的福利 :)。
因?yàn)轶w驗(yàn)了不同的項(xiàng)目和角色，畢業(yè)生在遇到問題時(shí)，知道去請教不同的人，所以成長很快。我印象里面一個(gè)畢業(yè)生，在不到一年的時(shí)間內(nèi)就開始和我在一個(gè)業(yè)務(wù)線里面做DevOps相關(guān)的事情，表現(xiàn)很突出。我的職業(yè)生涯還比較短，效力的公司比較少，但是有一個(gè)感覺是國內(nèi)的公司更多是把人當(dāng)成工具和資源，以完成事情為目的，缺乏對人的個(gè)人技術(shù)能力的培養(yǎng)，我覺得但就這個(gè)方面來講，REA值得學(xué)習(xí)。
當(dāng)JC和Matt播放這頁P(yáng)PT，感謝曾經(jīng)對他們的成長有過很多幫助的人時(shí)，我的內(nèi)心也充滿了感激之情，因?yàn)槊麊紊弦灿袔椭^我的人，Cos，曾經(jīng)的Team Lead，資深Ops，現(xiàn)在的一些工作方式和很多運(yùn)維方面的知識(shí)都是從他那里學(xué)到的，Colin，前Sun工程師，REA的基礎(chǔ)設(shè)施團(tuán)隊(duì)Tech Lead，一直是把他當(dāng)做role model，向他看齊。
整個(gè)SRECon的最后一個(gè)話題來自Dropbox的SRE女經(jīng)理《Scaling Reliability at Dropbox: Our Journey towards a Distributed Ownership Model》，介紹Dropbox SRE文化發(fā)展，如何在業(yè)務(wù)快速發(fā)展時(shí)，逐漸處理好混亂的基礎(chǔ)設(shè)施團(tuán)隊(duì)，以及提升Dropbox的可靠性和可用性。整個(gè)Slides我比較感興趣的一頁是Dropbox對待postmortem會(huì)議的方式，和一般的會(huì)議流程單純按照時(shí)間軸去重現(xiàn)、分析根因不同，他們把會(huì)議探討的內(nèi)容分成了三個(gè)部分“Discovery”、“Recovery”和“Prevention”：
和國內(nèi)的很多公司不同，我接觸或者了解過的國外互聯(lián)網(wǎng)公司對錯(cuò)誤的包容程度都是比較高的，不會(huì)將錯(cuò)誤當(dāng)成一種災(zāi)難，然后把鍋蓋在某些人頭上，在這方面，阿里提供了很多的素材。Dropbox將錯(cuò)誤視作一種學(xué)習(xí)的機(jī)會(huì)(it should be!)，通過分析錯(cuò)誤，以及施行快速rollback、自動(dòng)修復(fù)、和強(qiáng)7*24的oncall措施，極大的降低了MTTR，提高了系統(tǒng)、數(shù)據(jù)庫的可靠性。
會(huì)議的結(jié)束詞簡直不能再簡單……就是歡迎大家關(guān)注其他的SRECon以及明年再來等，最后的話題結(jié)束大家瞬間都滾蛋了。吹捧完一番Dropbox的女經(jīng)理后，向她詢問了auto-remedition在Dropbox是否有專門的系統(tǒng)來解決問題，答案是沒有-_-!
在新加坡的最后時(shí)間，都是長青哥帶著我各種逛，去吃了這里的特色，松發(fā)肉骨茶，同時(shí)了解一些分布式內(nèi)存數(shù)據(jù)庫的知識(shí)，以及他以前做的一些事情，肅然起敬，同時(shí)把分布式內(nèi)存數(shù)據(jù)庫加到了今年要了解的技術(shù)列表中。晚上11點(diǎn)，座飛機(jī)離開了新加坡這座美麗的城市，帶著肉骨茶般的收獲，迎接明天的工作的挑戰(zhàn)(對，我就是這么喜歡工作 :wink:)。
