温故知新,来自Google的SRE分享《Keys to SRE》

春风春雨拂过原野,惊起漫漫绿色。五月,初夏时节,SRECON ASIA顶级盛会在“花园城市”新加坡举办。

关于SREcon

SRECon每年汇集了来自全球的系统工程师和大型分布式架构运维专家,齐聚一堂就系统工程的话题展开深入交流。大会力求倡导一种基于批判性思维、深刻技术洞见和持续改进创新的技术文化。SRECon17亚洲/澳洲欢迎各位深谙开发运维之道的工程师们前来分享经验和交流。
大会时间:5.22-24

SRE在中国

SRE是2016年开始进入中国逐渐被大家认知,而国外早在几年前就开始践行SRE实践。数人云作为SRE理念在国内的践行者和倡导者,搬运来了干货满满的来自Google的Ben Treynor在2014SRECon上的演讲,让国内的企业相关开发运维人员温故知新。

《Keys to SRE》

SRE是一个运维文化的开始。
如何成为SRE? 成为SRE的十大关键要素:

1、具有研发能力
2、设定服务的SLA
3、基于SLA做业绩衡量
4、预留有误差的预估
5、SRE与研发有共享的资源工具
6、SRE承担50%的运维工作量
7、值班团队至少有8个人,或者6*2
8、每个轮班最多看两个项目
9、每个故障都要做事后分析
10、无过错的时候分析不是人本身,并要聚焦于流程和技术。
为什么要有SRE团队? 可靠性是最重要的原因,很容易得到验证。 可靠性易于被当成理所当然的

  • 不就是不出错嘛
  • 但事实是,当服务不可用时,说明已经有一些事情出问题了
  • 所以,要一直注重可靠性,而不是四处救火时才想起来

Part Ⅰ: 出人意料的一对儿

好吧,我们可以勉强承认 SRE 是重要的, 但是,他们毕竟是 Ops,对吧? Ops 和 Dev 不是一直相爱相杀吗?
核心是什么?

核心是,研发想发布一堆功能而看到他们被广泛使用; 核心是,运维想保证一切都是平稳的。 但并没有说开了

  • 上线审核
  • 对产品的深度了解
  • 发布的 checklist
  • 扩展的 canary 升级流程 研发有自己的术语: 研发发布新产品,但是……

  • 功能额外增加

  • 旗帜快速反转
  • UI的改变
  • 20%的实验 或者说的更严峻一点儿

  • 极度的信息不对称

  • Ops 团队并不能真正了解代码
  • 对代码最不了解的团队,反而最有可能抵触上线

所以,冲突一定是不可避免的? 不是:)

SRE并不倾向于评估发布风险,或者是避免断档,以及设立发布规则
如何做?

错误成本界定! 首先你应该有一个SLA...... 一个100%SLA的例子 一个<<100%的SLA例子 如果SLA<100% 错误成本=1-SLA 示例:99.9% SLA—>0.1% 误差估计 对于1B query/month的服务,你将会有1M误差/每月花费 预算将花费到哪里?

变化是#1 电力中断的原因, 发布是大的资源变化。 解决方案:在发布中进行误差估计, …或者是在不稳定上的花费:( 规则: 如果服务在SLA范围内, 马上发布,很明显研发团队干的不错; 如果服务没有在SLA范围内,发布冻结,直到恢复到你的误差估计范围内。

两个误差估计的两个优点: 1、去除SRE-研发冲突的主要资源
这是数学问题,不是一个观点或者资源冲突 2、研发团队不是孤立的,也需要自我监督
Part Ⅱ : 员工、工作以及超负荷的运维

当然,在效能低下的系统中也可以工作,只是需要更多的手工劳动。 这些工作,我不会做,也不会让SRE做。 但是,它很迷人? 看见即全部 看不见的运维工作=不存在 放缓产品功能开发…… 这是另外一个问题, 有以下6点,我们来一一解释。 共享的资源分配工具 多一个SRE=少一个研发 运维工作越多,功能越少 更加自我规律的系统工具 SRE只招聘会写代码的人员
--他们与研发有着共同语言 --他们知道IT能做什么 --他们不喜欢重复性工作。 50%的是运维工作
如果你能将工作通过流量来做衡量, 代码减少了工作/流量的比例, 并留出足够多的时间给那些各种糟糕的情况。 保持研发的自我运转

“看见的即全部” 确保研发团队看到产品的各种状态 两者如果没有一致的漏洞优先级,就会像情侣一样吵闹的无休无止 聊聊开发和运维工作…… 过度的运维负担(标签、警报等等)总是分配给开发团队, 另一个自我规律的系统:) SRE的可移植性
不要求连带任何工程;事实上,不要求连带SRE 他们可以时刻监控,也可以时刻撤离 危险的是那些罕见被执行下去的系统,依然运行 Part Ⅲ : 崩溃,附加,和运行中断

SLA<100%意味着会出现运行中断。其实还好,这不是玩笑话,严肃的来说其实还好。
运行中断的两个目标: 1. 最大程度降低负面影响 2. 防止系统循环
损害最小化 尽可能缩短运行中断 对NOC说“不” 明确的诊断信息 实践是第一要务 一个词概括实践……

运维的时刻准备状态一点都不酷 什么才是酷的? 在灾难发生前悬崖勒马! 预防问题的复现

1、处理事故
2、写下事后分析
3、重置
结论: 每个值班最多处理两个事故 每个小组规模是8 * 1或者是6 * 2

事后分析

事后分析无可厚非, 假定团队是有才华的,并且聚焦于流程和技术, 可以设定时间表,理出所有的事实,发现随之而来的所有Bugs列表。

一小时快速获得11年从业经验

只招聘研发背景的,并且根据他们的意愿来选择项目; 有成文的SLA,并基于此来做业绩衡量; 使用错误预算作为发布的标准; 通用的人力资源分享工具,每个SRE就减少一个研发,并将5%的运维工作转到研发团队; 值班团队至少有8个工程师来处理1-2个事故; 反复演练,将做的更加正确; 事后分析无可厚非,更重要的是流程化和技术。

《Keys to SRE》作者:Ben Treynor

视频地址:https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre

结语

熟知SRE,应该源于一本书《SRE——Google运维解密 孙宇聪译》,数人云CEO王璞在书的赞誉中写道:随着DevOps在国内的宣传推广,国内的很多企业客户也逐渐接受了DevOps的理念,但是在具体落地实践DevOps的过程中缺乏实际案例作为参考,SRE这本书方便了国内广发IT人员在落地DevOps过程中参照Google的SRE实践。

同时,数人云积极与企业客户交流,为传统用户落地SRE提供思路,之后会陆续更新SRE落地实践。SRECon · 新加坡今日正在进行中,24日结束,数人云与大家一起关注。

了解更多大会详情,请戳 https://www.usenix.org/conference/srecon17asia

SRECon17旧金山站回顾
SRECon Day1 | 比起干货满满,更吸引我的是画风清奇

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