早上到达会场，看到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培训的内容，稍微期待下。
