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