這個時節新加坡溫差不大，一早上起來就有30度，而且濕度驚人，感覺比深圳都高，同時陰晴不定，隨時可能下雨，大早上起來就開始暴雨……。還好在SRECon會議開始之前雨就停了，這樣才可以不會狼狽的到達開會的酒店。
會議的登記注冊非常簡單，拿到牌子之后就可以去吃早餐了。會議總共三天時間，每天管早餐、午餐，午餐是百度贊助的，明天晚上好像還有個什么河邊散步的活動，安排的挺好，外面只有linkedin和facebook、baidu的宣傳，沒有國內會議那么熱鬧，人相對較少，但是找別人溝通、聊天干擾會少些，這點比較好。
會議的第一個話題來自Linkedin，《Linkedin SRE: From Inception to Global Scale》，由兩個哥們搭檔介紹Linkedin SRE發展的過程，以及他們如何把SRE的能力移植到印度的辦公室，除了印度英語不太好理解外，還是有些啟發作用的。提問環節看到了一個熟人，REA GIA團隊的JC，休息時間趕緊過去打了個招呼，大家都很吃驚，竟然能在這樣的會議上遇到，GIA還有一個Matt也一起過來了，還認識了Seek的Simon，彼此打聽了對方的情況，了解到REA目前正在逐漸向SRE的模型轉變，現在是將原有的Guild拆分成小的Guild，如監控等，然后由這些人去考慮從公司層面改進某些方面的問題?？瓷先ニ麄儸F在也開始關心讓業務通過數據來做出產品的決策，哈，這不就是我快離職前做的事情么？于是趕緊提了下我和Clayton做的數據流水線，接受了一番吹捧。
第二個話題來自百度，《Next Generation of DevOps: AIOps in Practice@Baidu》，其實上次我已經聽劉俊在北京的DevOpsDays講過一遍了，只不過這次是用英語，而且是一男一女搭配，Ha Jingjing同學的英文水平還是不錯的，可是提問的好多印度人，完全聽不懂在講什么，專門找了個人給講師翻譯才可以-_-! 話題里面介紹了百度的運維、DevOps平臺的發展過程，以及百度在AIOps的實踐，有些數據，比如外部流量切換大約10分鐘，內部的切換大約10s。這些REA也可以做到甚至更快，不過規模要小很多。百度的AIOps做的不錯，但是大部分的東西都是他們自研的，如果能在slides中給出開源的解決方案就更好了或者設計的細節就好樂，畢竟很少有公司能有這樣的實力去實現所有東西。休息期間和JC他們聊天的時候，他們也覺得這個挺牛逼的，雖然做事的方式他們不太能理解 :) 。
第三個話題來自Zendesk新加坡辦公室，《How Could Small Teams Get Ready For SRE》，我看了下這些實踐都太熟悉了，沒什么新意，就出去facebook和linkedin展臺，做題，拿點禮品，順便跟facebook的妹子吹吹華為，她說facebook正在快速發展，倫敦和都柏林加起來2000人了，我說我們西研所有1w多人，要進軍公有云，和Google、AWS一較高下，雖然內心有點虛，但是不能在未來的競爭對手面前示弱 :(。
上午的最后一個話題，我選擇了Facebook的《The Service Pyramid》，大概的內容是介紹facebook的服務金字塔模型，有點類似Google SRE的服務可靠性層級，由下往上分別是:
1. 硬件的provision
2. 服務器監控/生命周期
3. 服務監控
4. 伸縮/容災
5. 性能調優
6. 1%的問題(可用性99….%之外的問題)
每次有新的服務時，他們按照這個模型評審，然后看看那些方面存在問題，那些方面的問題去修復的收益更高，然后對癥下藥，顯然1%的問題和性能問題，都不在優先考慮的范圍，但是好的監控是必須要有的。期間了解到facebook已經有了9個數據中心，令人咋舌。
午餐和JC他們坐一起，同桌還有個facebook的哥們，聊了些家常，感覺幾個月沒講英語，有點不太靈光了。不過還記得facebook的哥們講的段子，說google和facebook的人互相看不上，google嫌棄facebook做的產品差，facebook嫌棄google做一個東西時間太長，還沒有面世可能就掛了-_-! 黑的好。
下午的第一個話題是來自阿里的Wang Zhaogang，《Smart Monitoring System for Anomaly Detection on Business Trends in Alibaba》，介紹了阿里通過監控系統來收集業務數據，分析和預測其中的趨勢，講師的英文很好，只不過愛學習的印度朋友又出來問問題了:(，因為對中間分析的模型有些疑問，結束后找Zhaogang溝通時才知道他們現在是在阿里所有業務數據的基礎上來做的，雖然現在有一些數據噪音的問題，但這個方向肯定是沒錯的，通過數據來做出/輔助業務決策，這和Clayton當初在REA發起數據流水線的想法是一致的。
下午的第二個話題我選擇了CloudFare一個工程師介紹的《Managing Server Secrets at Scale with a Vaultless Password Manager》，原因是隔壁在如何Scale Graphite，而我覺得Graphite的設計已經趕不上一些新的時間序列數據庫了……，同時因為最近業余時間在學習密碼學相關的東西，好奇它會介紹什么，因為以前我們都是用AWS的KMS，RatticDB或者Vault去管理密碼\密鑰的。果然，這個實現的角度非常清奇，它的基本原理是這樣:
1. 在UEFI(BIOS 2.0)中保存mater key seed
2. 服務器啟動后，配置管理工具每次用master key seed 通過KDF來生成新的密碼
3. Key pair 通過CSPRNG加密偽隨機數生成器來生成
這樣的好處在于，每臺服務器有不同的master key seed，它被加密在UEFI中，所有的key pair都是在本地保存，并不需要一個專門的密碼管理的服務如RatticDB、Vault，省去了維護的成本。可惜會后沒有找到他，不能繼續交流下細節，只能twitter提問-_-!希望明天還能見到他。
接下來我放棄了滴滴的關于《Open-Falcon》的話題，因為知道這個是小米基于zabbix開源的的監控報警工具，所以選擇了Google的Nolan的話題《Managing Critical State: Distributed Consensus for Reliability》，基本上都是在講分布式一致性算法發展歷史，Paxos等。沒想到Google SRE那本書關于分布式一致性的章節竟然是基于她的論文,whhat! 因為是妹子所以沒有好意思上去合影 :(，失去了和大神同框的機會。
最后一輪的話題我先去聽了七牛的一個妹子介紹的基于Ansible實現大規模調度的session，后來一想覺得ansible自己已經有一定了解，不如去聽聽隔壁講openstack，也許將來用的上。所以結束的話題我聽的是來自清華大學Xu Wei的《Talking to an OpenStack Cluster in Plain English》，感覺真是聽對了。他的問題場景大致是這樣，如果OpenStack管理的節點出現問題，那么查詢需要大量的命令組合以及知識，這樣的時間成本以及對人的要求很高。他解決的思路是通過自然語言去查詢機器的狀態，其次是通過最簡單的規則在系統中自動發現知識，這里用到了圖數據庫。具體的實現是通過日志以及服務器原始的狀態(通過OpenStack API)在圖數據庫中生成OpenStack的知識圖譜，通過標簽針對數據集去訓練模型，最后使用類似ChatOps/Hubot這樣的工具，將自然語言查詢轉化為模型的查詢，獲得結果。 這個話題值得和IaaS部門的同事分享下，同時，拋開OpenStack這個應用的場景，我可以認為這個過程是構建知識圖譜，機器學習，將自然語言轉化為API請求來從圖譜中獲得結果，適用于任何需要復雜操作才能獲得內容的場景。沒錯，我說的就是我菊的hi社區，回去之后可以嘗試針對它實現類似的事情，然后搞個機器人和espace集成。其實類似的事情在REA也做過，在hubot的基礎上擴展功能，用自然語言來實現對知識的查詢，功能比Xu Wei老師要簡單的多。
驚喜還沒有結束，因為在上次DevOpsDay認識了這次SRECon的組織者劉俊，很榮幸的被邀請到和一眾講師以及前Google SRE，《SRE運維解密》的譯者孫宇聰一起共進晚餐。除了找到講師問了一些今天講的話題細節，還認識了不少前輩，加完微信后才發現，好多人都在8月份的上海DevOpsDays的講師列表里……。更神奇的事情是，來自Linkedin的SRE竟然認識以前在REA一起工作的Reed Murphy，世界真是太小了……。
席間還有圈內海量八卦，內容和下面這個Chilli Crab 一樣豐富：
