文章作者：姜南(Slyar) 文章来源：Slyar Home (www.slyar.com) 转载请注明，谢谢合作。
受邀参加了一个Google SRE举办的活动 SRE : A Backstage Tour，在他们的Sunnyvale campus，每次从237路过都能看到一个楼上有着巨大的Google Cloud Logo，想必就是那里了，这次正好有机会去参观一下。
活动是下午5点开始的，索性PayPal离Sunnyvale也不太远，下班以后开车过来还挺快的。举办活动的楼是MP5，门口有一个Google Cloud的牌子，不太清楚是不是Sunnyvale所有的楼都属于Cloud，财大气粗哈哈。
签到之后来到一间教室，凳子上已经摆好了swag包，好评。
又碰到Andrew Widdowson了，去年参加的那个Google活动也碰到他了，真是巧。虽然来之前就看到介绍里有他，这次的title里好像新加了一个Tech Lead of SRE EDU，从名字里看这好像是个SRE专有的培训项目？不愧是SRE的发源地，羡慕。那个Oncall for Google Search看起来非常高大上，虽然我的也不差Oncall for PayPal哈哈哈。
基本介绍一下SRE (Site Reliability Engineering) 在Google是干什么的，虽然我觉得现场来的应该都是SRE背景，都懂。
简单提了一下Proactive和Reactive方法在Google SRE的应用，在2018年应该属于非常常识的概念了。
Proactive就是主动防御，在问题发酵成事故之前就将其扼杀在摇篮里。人都会犯错，很多生产事故也都是人造成的，那就用自动化替代人工操作；评估审视现有的系统架构，找到那些容易产生事故的点，比如SPOF (single point of failure，单点故障) 并将其解决；定期模拟事故看系统如何反应以及能否自动恢复，比如把一些依赖服务关掉，把某个数据中心关掉，自己攻击自己，等等，在可控的范围内模拟可能发生的事故然后优化自动化解决方案。
Reactive就是被动防御，在Proactive无法避免的事故发生的时候如何以最快的速度发现问题并减少损失，如何快速准确地找到问题的根源并解决。这里主要靠监控和报警，高效稳定的监控和报警可以在第一时间通报系统事故，在小问题发酵成大事故之前通知SRE处理，往往这类问题都是前所未见的新问题，所以需要有经验的SRE工程师来解决，如果最后发现这类问题可以通过自动化解决，SRE的另外一项工作就是编写自动化代码来处理类似的问题。
这部分讲的是基础设施 Infrastructure SRE，应该是属于Google Cloud的。"very high toil risk"，看起来他们有很多重复的需要手工操作的活。
Observation and Failure at Scale，这部分讲如何发现并处理以前没有见到过的新问题。
对事不对人的问责机制，核心是把关注点放在问题为什么发生，我们哪里做得好，哪里做的不好，如何防止此类问题再次发生。
之后还有一个session降了Google的DR test机制 "DiRT: Breaking Google, Before Google Breaks You, and how that helps everyone"，就是我之前提到的模拟事故然后看系统如何反应的机制。
这次活动感觉还不错，讲了很多干货，虽然没什么新东西，但至少知道了我们的SRE思路和实践跟Google SRE大致一样，回去继续搬砖了。