这是一个创建于 3182 天前的主题，其中的信息可能已经有所发展或是发生改变。
SRECon 第二天，还未倒过时差的我们早早就起身前往会场，幸亏提前预订了 Uber 门到门的接送，科技确实让生活更加便利。
SRECon 紧凑的演讲信息量确实很大，回顾两天的会议内容我想给大家带来的 key words 就是 MTTR 、 MTTD 、 Automation 和 Communication 。
PS ：手机照片拍的不美丽，莫怪......
来自 SRECon数人云CTO 老肖
会场
一大早就看到了本次的大会主席之一，来自谷歌的 Google SRE Manager ， Liz Fong-Jones 。赶紧掏出手机拍一张。
Traps and Cookies
开篇 Session 题目是《Traps and Cookies》，内容很出乎意料。
该 talk 围绕“避免让一些小小的技术债务成为工作中的雷区”展开，比如文档和运维习惯，算是一个以小见大的选题。从陷阱的角度来讲，就是不要自以为是地错误地运行命令。一定要看下文档，熟悉文档才能保证你的操作是正常操作，不会出错。
演讲者 Tanya Reilly ，依然是一位来自 Google 的女性 SRE 。听 Google 的华人软件工程师说起有两位华人女性 SRE 在 Google 也做到了很高阶的职位，看来女性技术人员以后可以考虑往 SRE 方向发展。
Observability,in the Era of Cambrian Stack
演讲人是来自创业公司 honeycomb.io 的创始人 Charity Majors ，之前曾在 Facebook 负责管理庞大的数据库集群。他介绍了从一个工程师的视角如何去看待如寒武纪爆炸一般的基础设施复杂性。在他看来系统必须是可观测的，我们可以通过工具来理解、探索和解释系统。
可观测性文化的根基在于现在监控和时序图已经发展得非常成熟，但是我们需要具备的是排错能力。监控面板更多是为业绩 KPI 做准备的，这个观念是比较新颖的，反应了数据驱动的一个新境界，需要更多人能理解的数据和行为，排错活动成为一种社区活动。
Reducing MTTR and False Escalations
这次会议上出现频率很高的一个术语是 MTTR(平均维修时间)，来自 LinkedIn 的 Production-SRE Michael Kehoe 就此展开了讨论。
在题为《Reducing MTTR and False Escalations: Event Correlation at LinkedIn》的演讲中， Michael Kehoe 提到 LinkedIn 的生产堆栈是由超过 900 个应用程序和超过 2200 内部 API 构成。为了防止错误扩散，需要把关键修复的时间缩短。但是服务越复杂，学习曲线越高， MTTR 就越长。那么 Linkedin 在解决这个问题上用了两个工具，一个是 Drilldown + Site-Stablizer 来做时间序列的指标分析，另一个工具是 inVisualize 。
Anomaly Detection in Infrequently Occurred Patterns
SRECon 唯一的中国讲师是来自百度的首席架构师王栋，之前在贝尔实验室和 Google 工作过多年，也带领百度 SRE 团队完成过许多重要的项目，是目前国内非常资深的 SRE ，他带来了一个比较专业的话题。
王老师分享的题目为《Anomaly Detection in Infrequently Occurred Patterns》，讲的比较高深，主要场景是在春节这样突发的流量下，如何避免误报，漏报信息等，估计也只有百度有这个体量能做异常检查。
SRE 的解决办法都是在实际问题的基础之上提出方案，百度场景下提供的方案可以参考。
Building Real-time@Facebook
接下来， Facebook 的两位工程师介绍了 Facebook 如何搭建 Real-time 架构。
先是给出 2016 年以前的架构:
又给出了现在架构:
为了实时系统的高可靠，架构师把订阅的业务逻辑放在了网关层。总结一下经验：先走走看，从大局出发来设计系统。
Chaos Engineering
个人特别感兴趣 Netflix 这个的经典 Chaos Engineering 话题。什么是 Chaos Engineering ，它是解决分布式系统的可靠性验证工具。据了解， Netflix 把这个概念发扬了光大。
实时的可视化工具看着也非常酷炫。从中我们可以知道，对于可靠性系统来说，可视化的数据展示是非常重要的能力， SRE 的工作大量在围绕以人为中心来解决问题，可视化数据是一个。
接下来的几个议题也都非常有意思
这个话题是怎样在不靠谱的网络里面构建一个值得信任的网络。一般的网络都是在数据中心之间使用 VPN 来保障可用性，但是 VPN 的不靠谱是没法保障业务的。所以，本话题是去掉 VPN ，直接在架构层面来保证系统的信任。
完全基于公网的条件，在架构上设计的更加稳定，保障系统之间是全自动的。自动化是一个重要关键词。
在《Killing Our Darlings: How to Deprecate Systems》的话题中，主张多沟通，防止不靠谱的事情发生，多沟通能解决很多客户的问题。
发现一个 LinkedIn 开源项目（ AMBRY ）挺不错，是存储小多媒体文件的分布式文件系统的。 LinkedIn 用它每天存 1T 的数据，大概用了快一年了，已经存储了 300 多 T ，国内有需要的可以关注下。
写在最后
SRECon 紧凑的演讲信息量确实很大，回顾两天的会议内容我想给大家带来的 key words 就是 MTTR 、 MTTD 、 Automation 和 Communication 。
在这里只能抓一些要点为大家放送，更多详尽内容可以一周后前往 SRECon 官网查看演讲 Slides 和视频。
此次 SRECon 之旅也遇见了一些关注 SRE 领域的国内小伙伴，分别来自百度、华为等国内知名企业，数人云希望和业界的朋友们一起将 SRE 理念在国内进行传播并落地。
SRE 相关阅读：
 | 1 litao6550652 2017-03-16 19:06:07 +08:00 蚂蚁金服 sre 团队招人中，有兴趣的可以联系我内推 |
Select Language