今天是会议的最后一天，日程的安排要更加简单些，彻底放弃了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:)。
