Google网站可靠性工程SRE.ppt

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