早上到達(dá)會(huì)場(chǎng)立莉，看到JC在Linkedin展臺(tái)前聊天绢彤，過(guò)去打了個(gè)招呼，他正在打算做Linkedin在hackerank上的挑戰(zhàn)題目蜓耻，拉我一起做題茫舶。安全起見(jiàn)我注冊(cè)了一個(gè)新的賬戶，做了一下刹淌，大概10道題饶氏，有理論有實(shí)踐，比昨天facebook的題目簡(jiǎn)單多了有勾，答完題還有T-Shirt和筆記本贈(zèng)送疹启，cool。

今天選擇的第一個(gè)話題來(lái)自Google的《Reliable Launch at Scale》蔼卡，聽(tīng)了一會(huì)才發(fā)現(xiàn)內(nèi)容好像是來(lái)自《Google SRE運(yùn)維解密》里面被的跳過(guò)的那章喊崖。當(dāng)時(shí)跳過(guò)的主要原因是我覺(jué)得為了發(fā)布這件事情專門搞一個(gè)職位或者角色出來(lái)是很奇怪的事情。Google的哥們還花了很長(zhǎng)時(shí)間講為什么他們要把這個(gè)類似于上線守門員的角色命名為L(zhǎng)LE(Launch Lead Engineers)。:facepalm:

在我看來(lái)荤懂，這個(gè)話題的比較有用的地方在于茁裙，上線之前的check list，從下面幾個(gè)角度來(lái)分析服務(wù)是不是做好準(zhǔn)備能夠上線了:
1. 架構(gòu)
2. 容量
3. 可靠性
4. 監(jiān)控
5. 自動(dòng)化程度
6. 增長(zhǎng)趨勢(shì)
7. 依賴的第三方（google內(nèi)部）服務(wù)是否準(zhǔn)備好
8. 上線
針對(duì)每一項(xiàng)都會(huì)有一系列具體的問(wèn)題节仿，比如在容量方面晤锥，上線會(huì)不會(huì)引起Spike，同時(shí)對(duì)應(yīng)問(wèn)題還有一些的解決的方案廊宪，比如為了防止spike矾瘾，可以先做壓力測(cè)試。所有的這些check list以及 action箭启，他們會(huì)統(tǒng)一的放在wiki中并且保持更新壕翩，對(duì)于不同的服務(wù)可以選擇適于自己服務(wù)的check list選項(xiàng)和action。除此之外册烈，還有Feature Flags戈泼，也就是代碼部署但是特性不用上線，也就是我們6年前玩過(guò)的feature toggle……赏僧。國(guó)內(nèi)對(duì)于這個(gè)玩的更深入些，比如灰度發(fā)布等扭倾，國(guó)外會(huì)叫做金絲雀發(fā)布等淀零，8月份的DevOpsDays，萬(wàn)金會(huì)介紹灰度發(fā)布相關(guān)的內(nèi)容膛壹。當(dāng)然Google也玩的很好驾中，比如很多年前就有Google實(shí)驗(yàn)室也是這么做的。

可能是每個(gè)公司情況不一樣吧模聋，我覺(jué)得亞馬遜應(yīng)該是沒(méi)有這樣的角色的肩民，任何做到持續(xù)交付的公司也不會(huì)有這樣的角色 :)。

碰巧昨天講安全的CloudFlare工程師也在同一個(gè)會(huì)場(chǎng)链方，主動(dòng)的跑上去找他聊了下持痰，重新確認(rèn)了昨天的解決方案，他們?cè)谂渲霉芾砉ぞ咧斜４鍾ealm String祟蚀，通過(guò)他們自己寫(xiě)的一個(gè)工具工窍，配合配置管理工具生成password以及key pairs。順便問(wèn)了下key的revoke等問(wèn)題前酿，同時(shí)問(wèn)他為什么考慮使用Harshicorp Vault來(lái)管理key患雏，他表示他們團(tuán)隊(duì)正在準(zhǔn)備考慮使用Vault，主要是為了在容器的服務(wù)的安全罢维，挺不錯(cuò)的思路淹仑。除此之外，我還表達(dá)了最近學(xué)習(xí)密碼學(xué)的遇到的主要問(wèn)題是數(shù)學(xué)問(wèn)題，這哥們笑著對(duì)我說(shuō)這些都不重要匀借，你只要知道怎么管理key以及PKI就可以了颜阐，看來(lái)也是面向解決問(wèn)題的工程師。多聊了幾句怀吻，一不留神滴滴的session《How To Provide a Reliable Ridesharing Service》已經(jīng)開(kāi)始了瞬浓，聽(tīng)到的部分就是標(biāo)準(zhǔn)化、多個(gè)cluster的實(shí)現(xiàn)蓬坡，以及他們?yōu)榱颂岣呦到y(tǒng)可用性的starflower項(xiàng)目猿棉。整體感覺(jué)滴滴做的還挺不錯(cuò)的，雖然像是藍(lán)綠部署這種實(shí)踐也是很多年前就有了屑咳，但是正在Lai Wei-Open Falcon的設(shè)計(jì)者所說(shuō)萨赁，實(shí)際上這些實(shí)踐本身的難度不大，但是如何推廣這些實(shí)踐是最大的問(wèn)題兆龙。老外對(duì)于滴滴為了提高可靠性對(duì)工程師罰款的行為感覺(jué)到很吃驚杖爽，我在session結(jié)束后還給講師提了feedback，其實(shí)當(dāng)時(shí)他們可以提如果有改進(jìn)的話獎(jiǎng)勵(lì)會(huì)更加豐富紫皇，遠(yuǎn)遠(yuǎn)超過(guò)Google SRE的Peer Bonus慰安，這樣他們就不會(huì)覺(jué)得有什么了。我最喜歡的一點(diǎn)在于他們的事故的的跟蹤和報(bào)告系統(tǒng)聪铺，這點(diǎn)很贊化焕，可以可視化的看到事故有沒(méi)有分析，有沒(méi)有后續(xù)的action以及改進(jìn)铃剔。

第三個(gè)話題選擇了Yahoo工程師的《Managing the Changes Seamlessly on Yahoo's Hadoop Infrastructure Servers》撒桨，基本的內(nèi)容是介紹yahoo的Hadoop SRE團(tuán)隊(duì)如何通過(guò)流水線利用Chef來(lái)管理45000臺(tái)hadoop服務(wù)器的部署。他們的Chef Server只是用來(lái)保存meta data以及配置键兜，而服務(wù)的安裝是通過(guò)RPM包凤类，Chef會(huì)讀取一個(gè)在流水線生成的包含應(yīng)用版本的rpm包list文件，根據(jù)這個(gè)列表針對(duì)具體的服務(wù)以及版本進(jìn)行安裝普气。這是我們6年前用過(guò)的方式谜疤，通過(guò)RPM的方式打包，那么運(yùn)行服務(wù)的所有依賴都自包含在其中棋电，其余的不同環(huán)境的配置保存在配置管理工具中茎截，只不過(guò)我們用的是puppet。Yahoo的這個(gè)案例里面赶盔，有一點(diǎn)可以改進(jìn)的地方就是使用類似Koji這樣的yum repository企锌，這樣可以用不同的tag來(lái)管理rpm包，避免維護(hù)一個(gè)專門的rpm list于未。我在提問(wèn)的時(shí)候給了這個(gè)建議撕攒，同時(shí)故意問(wèn)了下大概的chef master數(shù)量陡鹃，這樣我可以知道，單臺(tái)chef master到底能管理多少臺(tái)機(jī)器抖坪，結(jié)果三哥記不住具體的數(shù)據(jù)了萍鲸，但是看來(lái)維護(hù)一個(gè)比較大規(guī)模的集群是沒(méi)有問(wèn)題的。雖然我現(xiàn)在更加喜歡基于AMI或者docker image的不可變部署擦俐，并且我們?cè)诤芏嗄昵耙呀?jīng)放棄了Chef脊阴，但是從這些案例我們也可以看出，有時(shí)候工具不是那么重要蚯瞧，實(shí)踐做的好嘿期，也可以達(dá)到同樣的目的。

下午的第一個(gè)話題來(lái)自Facebook埋合，花了20多分鐘就講了一件事情备徐，你應(yīng)該為你的bash腳本、python和ruby腳本甚颂，以及Chef腳本寫(xiě)單元測(cè)試蜜猾。也就是中間有一些工具推薦還稍微有一點(diǎn)點(diǎn)用處。不可否認(rèn)他的presentation的能力很強(qiáng)振诬，但是這個(gè)話題的內(nèi)容也就是個(gè)日常Meetup的水平蹭睡。讓我對(duì)facebook的SRE的水平產(chǎn)生了極大的懷疑:) （雖然昨天做的題我可能跪了）。

因?yàn)檫@個(gè)話題實(shí)在太短赶么，我趕緊又跑到隔壁Linkedin的幾個(gè)印度工程師介紹的《Event Correlation: A fresh Approach towards Reducting MTTR》棠笑，可惜只聽(tīng)到后面的big picture和key takeway，對(duì)于理解整個(gè)話題沒(méi)有什么幫助禽绪。剛好JC在聽(tīng)，于是趕緊問(wèn)了下他話題具體內(nèi)容洪规，他說(shuō)他也沒(méi)咋聽(tīng)-_-!印屁，但是他大概知道這里面講的是Linkedin之前做的一個(gè)叫做Nurse的自動(dòng)矯正系統(tǒng)。晚上回到酒店后大致看了下斩例，是通過(guò)Nurse這個(gè)系統(tǒng)雄人，處理一些low level的運(yùn)維問(wèn)題，它會(huì)根據(jù)報(bào)警的類型以及相關(guān)的信息念赶，推斷出問(wèn)題根本原因础钠。它是學(xué)習(xí)了Facebook的FBAR，我覺(jué)得明天還是找這幾個(gè)工程師聊下叉谜，再了解下細(xì)節(jié)旗吁，有助于我理解這個(gè)解決方案。

下一個(gè)話題是PayPal的工程師介紹的《Automated Troubleshooting of Live Site Issues》停局，講師是印度人很钓，PPT的文字多而小香府，架構(gòu)圖也都太小，同時(shí)這個(gè)人講話很快码倦，完全get不到點(diǎn)企孩。只能在結(jié)束后主動(dòng)去提問(wèn)，首先假惺惺的吹捧了一番袁稽，就說(shuō)覺(jué)得你的話題講的很好啊勿璃，但是中間有一點(diǎn)我每怎么聽(tīng)明白，能不能再介紹下推汽。這個(gè)印度哥們還是很認(rèn)真的回答的我的問(wèn)題补疑，實(shí)際上他們解決的問(wèn)題是，當(dāng)反饋的問(wèn)題出現(xiàn)在工單系統(tǒng)中是民泵，系統(tǒng)會(huì)自動(dòng)的分析內(nèi)容癣丧，并且從不同的數(shù)據(jù)源，如日志等地方進(jìn)行數(shù)據(jù)的搜索和關(guān)聯(lián)栈妆，從結(jié)果中推理出導(dǎo)致這個(gè)問(wèn)題最可能的原因胁编。非常不錯(cuò)的思路。

中間的休息環(huán)境鳞尔，我又到了linkedin展臺(tái)嬉橙，打算多拿幾件T恤給同事，沒(méi)想到印度小哥很豪爽寥假，直接就給了我市框。十分感動(dòng)，順便和他們聊了下糕韧。這次來(lái)的是Linkedin印度地區(qū)的SRE枫振，他們和北美的SRE一樣，負(fù)責(zé)同樣的服務(wù)萤彩，公司內(nèi)部的運(yùn)維的架構(gòu)大概是這樣:
1. Hardware Ops做機(jī)房的硬件的provision
2. Sysadmin SRE做基礎(chǔ)系統(tǒng)的安裝
3. Horizontal SRE接管后面的部分粪滤，服務(wù)的部署維護(hù)等

感覺(jué)這種結(jié)構(gòu)和原本的組織結(jié)構(gòu)區(qū)別不大，差別大的部分也許是人的能力和解決問(wèn)題的思路吧雀扶。

因?yàn)楸容^關(guān)注安全相關(guān)的問(wèn)題杖小，所以選擇聽(tīng)了Dropbox的《Merou: A Decentralized Audited Authorization Service》，聽(tīng)了就覺(jué)得后悔了愚墓，感覺(jué)這哥們就是造了個(gè)輪子予权，實(shí)現(xiàn)的和華為電子流類似的東西，權(quán)限審批浪册、管理以及審計(jì)扫腺。回頭看了github议经，幾十個(gè)star斧账，感覺(jué)太坑了……谴返，而且后來(lái)問(wèn)他們和IAM的集成，也是最原始的那種咧织，通過(guò)API請(qǐng)求來(lái)判斷是否添加用戶嗓袱、權(quán)限等 :(。

最后一個(gè)話題選擇了微軟的《Azure SREBot： More Than a Chatbot - an Intelligent Bot to Crush Mitigation time》习绢，話題的內(nèi)容大概是這樣子渠抹，通過(guò)收集來(lái)自各種信息來(lái)源，比如生產(chǎn)環(huán)境的遙測(cè)闪萄、日志中的錯(cuò)誤等等梧却，通過(guò)他們的智能引擎來(lái)分析具體的錯(cuò)誤發(fā)生在那些服務(wù)，然后將報(bào)警通過(guò)bot在skype败去、slack中發(fā)給具體的團(tuán)隊(duì)放航。實(shí)際上這個(gè)和PayPal的話題有點(diǎn)類似，從中我們可以發(fā)現(xiàn)一點(diǎn)趨勢(shì)圆裕，對(duì)于大部分的報(bào)警的問(wèn)題广鳍，可能都是很簡(jiǎn)單、頻繁出現(xiàn)吓妆、對(duì)運(yùn)維人員沒(méi)有價(jià)值的東西赊时，所以根據(jù)過(guò)往的經(jīng)驗(yàn)，可以由系統(tǒng)自動(dòng)化的解決這個(gè)問(wèn)題行拢。

會(huì)議的舉辦方Usenix在酒店后面的河邊組織了晚宴祖秒，大家吹著小風(fēng)，喝著飲料舟奠，吃著料理竭缝，然后抓著不同的人社交、聊天沼瘫，非常好的安排歌馍。我是屬于很內(nèi)向的人，不是因?yàn)樘厥獾脑蛟稳担话悴粫?huì)找別人聊天，但就是因?yàn)橹鬓k方搞了好多這種讓大家互相認(rèn)識(shí)的機(jī)會(huì)暴浦，才讓我和更多的人聊天溅话，交流，包括微軟的SREBot的講師歌焦，通過(guò)和他聊天我了解到他們目前的工作還是比較初級(jí)的飞几，團(tuán)隊(duì)人并不多，智能引擎這部分的數(shù)據(jù)如何存儲(chǔ)它都不知道独撇，所以對(duì)于他們來(lái)說(shuō)屑墨，還有很長(zhǎng)的路要走躁锁。期間和澳洲的Goggle的工程師還聊了會(huì)，土澳的發(fā)音時(shí)省略一部分還是挺煩人的:(卵史。

今天沒(méi)有像昨天有讓我特別驚喜的話題战转，明天的話題看上去能稍微靠譜點(diǎn)，有Google的人介紹gRPC的部分以躯，還有JC和Matt介紹DevOps培訓(xùn)的內(nèi)容槐秧，稍微期待下。