文章作者:姜南(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大致一样,回去继续搬砖了。