Google网站可靠性工程SRE

SLA<100%意味着会有服务中断，这是可以接受的。
但每次服务中断的处理，我们都有两个目标： • 减少损失 • 杜绝再犯
如何减少损失
尽可能缩短服务中断的时间。 - No NOC - 充分的诊断信息 - 多多练习、实践(灾备演练)
关于“多多练习”的方式
灾备演练并不是最酷的，最酷的是“幸运大转 盘（随机灾难）”
- 每件事故都要有事后分析
- 事后分析对事不对人
更多SRE资料：
/blog/wpcontent/uploads/2008/11/linuxworld-07-describesre.pdf
/blog/wpcontent/uploads/2008/11/thatcouldnthappentous.pdf
• 建立事故时间轴； • 搜集全部的事实； • 后续事宜用bug来跟踪；
总结SRE（网站可靠性工程）的内容，
简单说来包括：
- 招最合适的码农
- 提供的服务有SLA - 按SLA来评估、报告性能 - 使用“故障预算”，和质量一票否决制
- SRE和开发人员共享人才库 - 超额的OP工作转交开发人员 - SRE的运维负载不超过50% - 和开发团队共同承担5%的OP工作 - 值班团队需要8人，或6x2 - 值班交接时，未完事宜不能超过两件
SRE只招合适的码农
- 能和开发人员沟通无碍； - 了解机器能做什么； - 喜欢创新，改进运维方式；
日常运维工作的时间不超过50%，更多时 间做研发和探索
和DEV一起轮流做运维工作
让开发人员体验运维工作，了解他们的产 品在实际运作中的状况，可以提升产品敏 感性。
过多的运维工作就交给开发人员去承担；
SRE (google)
网站可靠性工程 Site Reliability Engineering
可靠性常常被误以为一件想当然的事情 ，但：
- 网站不能出故障；
- 服务不稳定时，大量问题会暴露出来；
- 是个长期工程，需要持续性投入，而不 能在系统崩溃时才想起来；
好吧，我们不太情愿地同意： SRE是很重要的。
所以，需要把故障预算用在上线，或不稳定的服务上；
规则是： 如果SLA符合，那就上线；如果不符，那就推迟上线，
直到攒够故障预算
“故障预算”带来两大好处
1，可以缓解SRE-DEV冲突，将主观 问题转化为客观问题； 2，开发团
多一个SRE，就会少一个Dev 运维更充分，新功能更少，从而最终 形成“自调节系统”
所以冲突和问题是不可避免的！
但SRE不负责评估上线风险、防止断电、设置发布规 则等
答案是 故障预算 （Error Budget），当然 首先需要一个
SLA
故障预算：
如果SLA是三个9，对于每月10亿次查询量的服务来说，只能承 受100万次查询错误
- 变化是故障的首要原因； - 上线是变化的源头；
但那是OP的事吧？Op和Dev是 不是经常有争执？
Google Chrome Canary金丝雀版
谷歌之所以称之为“金丝雀版”，是因为金 丝雀曾在矿井中被用于早期预警，而该版本 的浏览器在某种程度上也起到相似的作用。 金丝雀版采集到的反馈数据，特别是崩溃统 计可以帮助谷歌更快的找到并修复问题。
- 开发人员发布的新版本里会包含新功能，但同 时也包含了：UI或流程改变， 代码里的新坑旧 坑，以及一些新的实验内容； - OP作为对代码理解最少的人，却需要按时将 新版本上线
关于“杜绝再犯”的做法
1. 处理问题； 2. 撰写事故分析报告； 3. 清理和重置
• 交班时移交问题不宜过多； • 值班人数不宜过多，8x1或6x2较合适；
“事故分析”时要注意以下几点
“事故分析”是无可非议的流程，不用羞愧； 假定大家都是聪明的、善意的提出意见、建议
； 专注在流程和技术层面，对事不对人；