Google网站可靠性工程SRE.pptx

;;;可靠性是产品最重要的特性，为什么呢？;;;可靠性常常被误以为一件想当然的事情，但： 网站不能出故障； 服务不稳定时，大量问题会暴露出来； 是个长期工程，需要持续性投入，而不能在系统崩溃时才想起来；;Part I：欢喜冤家;双方争执的核心是：- 开发人员希望上线一些更炫，更广为人知的新功能- Op则是希望一切平安，减少动荡（尤其他值班时）;双方有些事情并没有讲明：- 上线审查- 产品的深度理解- 发布待检列表- 扩展的金丝雀流程（灰度发布）;软件开发有着自己的隐语：;SRE该做什么呢？;;;; “故障预算”带来两大好处 1，可以缓解SRE-DEV冲突，将主观问题转化为客观问题； 2，开发团队可以依据它进行自我监督；;Part II：人员配比,及工作量; “SRE+DEV”统一人力资源池 多一个SRE，就会少一个Dev ??维更充分，新功能更少，从而最终形成“自调节系统”; SRE只招合适的码农 能和开发人员沟通无碍； 了解机器能做什么； 喜欢创新，改进运维方式； 日常运维工作的时间不超过50%，更多时间做研发和探索; 和DEV一起轮流做运维工作 让开发人员体验运维工作，了解他们的产品在实际运作中的状况，可以提升产品敏感性。 过多的运维工作就交给开发人员去承担；;Part III：死亡、税、系统故障; 如何减少损失 尽可能缩短服务中断的时间。 No NOC 充分的诊断信息 多多练习、实践(灾备演练); 关于“多多练习”的方式 灾备演练并不是最酷的，最酷的是“幸运大转盘（随机灾难）”; 关于“杜绝再犯”的做法 处理问题； 撰写事故分析报告； 清理和重置 交班时移交问题不宜过多； 值班人数不宜过多，8x1或6x2较合适； ; “事故分析”时要注意以下几点 “事故分析”是无可非议的流程，不用羞愧； 假定大家都是聪明的、善意的提出意见、建议； 专注在流程和技术层面，对事不对人； 建立事故时间轴； 搜集全部的事实； 后续事宜用bug来跟踪； ;招最合适的码农 提供的服务有SLA 按SLA来评估、报告性能 使用“故障预算”，和质量一票否决制 SRE和开发人员共享人才库 超额的OP工作转交开发人员 SRE的运维负载不超过50% 和开发团队共同承担5%的OP工作 值班团队需要8人，或6x2 值班交接时，未完事宜不能超过两件 每件事故都要有事后分析 事后分析对事不对人;Thanks