SRECon Day2 | 管中窥豹:从小热点看SRE大文章

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 相关阅读:

活动实录 | 京东金融 PE 谈如何颠覆应用运维认知

SRE :文化传奇不完全指南?

SRE 第一课: New to an SRE team?

SRE 系列教程 | 基于时间序列数据的监控实践

人永远不够用——在复旦大学分享 SRE 团队组织和管理

SRE 系列教程 | 孙宇聪:来自 Google 的 DevOps 理念及实践(上)

SRE 系列教程 | 孙宇聪:来自 Google 的 DevOps 理念及实践(下)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值