早上到達會場，看到JC在Linkedin展臺前聊天，過去打了個招呼，他正在打算做Linkedin在hackerank上的挑戰題目，拉我一起做題。安全起見我注冊了一個新的賬戶，做了一下，大概10道題，有理論有實踐，比昨天facebook的題目簡單多了，答完題還有T-Shirt和筆記本贈送，cool。
今天選擇的第一個話題來自Google的《Reliable Launch at Scale》，聽了一會才發現內容好像是來自《Google SRE運維解密》里面被的跳過的那章。當時跳過的主要原因是我覺得為了發布這件事情專門搞一個職位或者角色出來是很奇怪的事情。Google的哥們還花了很長時間講為什么他們要把這個類似于上線守門員的角色命名為LLE(Launch Lead Engineers)。:facepalm:
在我看來，這個話題的比較有用的地方在于，上線之前的check list，從下面幾個角度來分析服務是不是做好準備能夠上線了:
1. 架構
2. 容量
3. 可靠性
4. 監控
5. 自動化程度
6. 增長趨勢
7. 依賴的第三方（google內部）服務是否準備好
8. 上線
針對每一項都會有一系列具體的問題，比如在容量方面，上線會不會引起Spike，同時對應問題還有一些的解決的方案，比如為了防止spike，可以先做壓力測試。所有的這些check list以及 action，他們會統一的放在wiki中并且保持更新，對于不同的服務可以選擇適于自己服務的check list選項和action。除此之外，還有Feature Flags，也就是代碼部署但是特性不用上線，也就是我們6年前玩過的feature toggle……。國內對于這個玩的更深入些，比如灰度發布等，國外會叫做金絲雀發布等，8月份的DevOpsDays，萬金會介紹灰度發布相關的內容。當然Google也玩的很好，比如很多年前就有Google實驗室也是這么做的。
可能是每個公司情況不一樣吧，我覺得亞馬遜應該是沒有這樣的角色的，任何做到持續交付的公司也不會有這樣的角色 :)。
碰巧昨天講安全的CloudFlare工程師也在同一個會場，主動的跑上去找他聊了下，重新確認了昨天的解決方案，他們在配置管理工具中保存Realm String，通過他們自己寫的一個工具，配合配置管理工具生成password以及key pairs。順便問了下key的revoke等問題，同時問他為什么考慮使用Harshicorp Vault來管理key，他表示他們團隊正在準備考慮使用Vault，主要是為了在容器的服務的安全，挺不錯的思路。除此之外，我還表達了最近學習密碼學的遇到的主要問題是數學問題，這哥們笑著對我說這些都不重要，你只要知道怎么管理key以及PKI就可以了，看來也是面向解決問題的工程師。多聊了幾句，一不留神滴滴的session《How To Provide a Reliable Ridesharing Service》已經開始了，聽到的部分就是標準化、多個cluster的實現，以及他們為了提高系統可用性的starflower項目。整體感覺滴滴做的還挺不錯的，雖然像是藍綠部署這種實踐也是很多年前就有了，但是正在Lai Wei-Open Falcon的設計者所說，實際上這些實踐本身的難度不大，但是如何推廣這些實踐是最大的問題。老外對于滴滴為了提高可靠性對工程師罰款的行為感覺到很吃驚，我在session結束后還給講師提了feedback，其實當時他們可以提如果有改進的話獎勵會更加豐富，遠遠超過Google SRE的Peer Bonus，這樣他們就不會覺得有什么了。我最喜歡的一點在于他們的事故的的跟蹤和報告系統，這點很贊，可以可視化的看到事故有沒有分析，有沒有后續的action以及改進。
第三個話題選擇了Yahoo工程師的《Managing the Changes Seamlessly on Yahoo's Hadoop Infrastructure Servers》，基本的內容是介紹yahoo的Hadoop SRE團隊如何通過流水線利用Chef來管理45000臺hadoop服務器的部署。他們的Chef Server只是用來保存meta data以及配置，而服務的安裝是通過RPM包，Chef會讀取一個在流水線生成的包含應用版本的rpm包list文件，根據這個列表針對具體的服務以及版本進行安裝。這是我們6年前用過的方式，通過RPM的方式打包，那么運行服務的所有依賴都自包含在其中，其余的不同環境的配置保存在配置管理工具中，只不過我們用的是puppet。Yahoo的這個案例里面，有一點可以改進的地方就是使用類似Koji這樣的yum repository，這樣可以用不同的tag來管理rpm包，避免維護一個專門的rpm list。我在提問的時候給了這個建議，同時故意問了下大概的chef master數量，這樣我可以知道，單臺chef master到底能管理多少臺機器，結果三哥記不住具體的數據了，但是看來維護一個比較大規模的集群是沒有問題的。雖然我現在更加喜歡基于AMI或者docker image的不可變部署，并且我們在很多年前已經放棄了Chef，但是從這些案例我們也可以看出，有時候工具不是那么重要，實踐做的好，也可以達到同樣的目的。
下午的第一個話題來自Facebook，花了20多分鐘就講了一件事情，你應該為你的bash腳本、python和ruby腳本，以及Chef腳本寫單元測試。也就是中間有一些工具推薦還稍微有一點點用處。不可否認他的presentation的能力很強，但是這個話題的內容也就是個日常Meetup的水平。讓我對facebook的SRE的水平產生了極大的懷疑:) （雖然昨天做的題我可能跪了）。
因為這個話題實在太短，我趕緊又跑到隔壁Linkedin的幾個印度工程師介紹的《Event Correlation: A fresh Approach towards Reducting MTTR》，可惜只聽到后面的big picture和key takeway，對于理解整個話題沒有什么幫助。剛好JC在聽，于是趕緊問了下他話題具體內容，他說他也沒咋聽-_-!，但是他大概知道這里面講的是Linkedin之前做的一個叫做Nurse的自動矯正系統。晚上回到酒店后大致看了下，是通過Nurse這個系統，處理一些low level的運維問題，它會根據報警的類型以及相關的信息，推斷出問題根本原因。它是學習了Facebook的FBAR，我覺得明天還是找這幾個工程師聊下，再了解下細節，有助于我理解這個解決方案。
下一個話題是PayPal的工程師介紹的《Automated Troubleshooting of Live Site Issues》，講師是印度人，PPT的文字多而小，架構圖也都太小，同時這個人講話很快，完全get不到點。只能在結束后主動去提問，首先假惺惺的吹捧了一番，就說覺得你的話題講的很好啊，但是中間有一點我每怎么聽明白，能不能再介紹下。這個印度哥們還是很認真的回答的我的問題，實際上他們解決的問題是，當反饋的問題出現在工單系統中是，系統會自動的分析內容，并且從不同的數據源，如日志等地方進行數據的搜索和關聯，從結果中推理出導致這個問題最可能的原因。非常不錯的思路。
中間的休息環境，我又到了linkedin展臺，打算多拿幾件T恤給同事，沒想到印度小哥很豪爽，直接就給了我。十分感動，順便和他們聊了下。這次來的是Linkedin印度地區的SRE，他們和北美的SRE一樣，負責同樣的服務，公司內部的運維的架構大概是這樣:
1. Hardware Ops做機房的硬件的provision
2. Sysadmin SRE做基礎系統的安裝
3. Horizontal SRE接管后面的部分，服務的部署維護等
感覺這種結構和原本的組織結構區別不大，差別大的部分也許是人的能力和解決問題的思路吧。
因為比較關注安全相關的問題，所以選擇聽了Dropbox的《Merou: A Decentralized Audited Authorization Service》，聽了就覺得后悔了，感覺這哥們就是造了個輪子，實現的和華為電子流類似的東西，權限審批、管理以及審計。回頭看了github，幾十個star，感覺太坑了……，而且后來問他們和IAM的集成，也是最原始的那種，通過API請求來判斷是否添加用戶、權限等 :(。
最后一個話題選擇了微軟的《Azure SREBot： More Than a Chatbot - an Intelligent Bot to Crush Mitigation time》，話題的內容大概是這樣子，通過收集來自各種信息來源，比如生產環境的遙測、日志中的錯誤等等，通過他們的智能引擎來分析具體的錯誤發生在那些服務，然后將報警通過bot在skype、slack中發給具體的團隊。實際上這個和PayPal的話題有點類似，從中我們可以發現一點趨勢，對于大部分的報警的問題，可能都是很簡單、頻繁出現、對運維人員沒有價值的東西，所以根據過往的經驗，可以由系統自動化的解決這個問題。
會議的舉辦方Usenix在酒店后面的河邊組織了晚宴，大家吹著小風，喝著飲料，吃著料理，然后抓著不同的人社交、聊天，非常好的安排。我是屬于很內向的人，不是因為特殊的原因，一般不會找別人聊天，但就是因為主辦方搞了好多這種讓大家互相認識的機會，才讓我和更多的人聊天，交流，包括微軟的SREBot的講師，通過和他聊天我了解到他們目前的工作還是比較初級的，團隊人并不多，智能引擎這部分的數據如何存儲它都不知道，所以對于他們來說，還有很長的路要走。期間和澳洲的Goggle的工程師還聊了會，土澳的發音時省略一部分還是挺煩人的:(。
今天沒有像昨天有讓我特別驚喜的話題，明天的話題看上去能稍微靠譜點，有Google的人介紹gRPC的部分，還有JC和Matt介紹DevOps培訓的內容，稍微期待下。
