确保长期关注研发工作-SRE研发问题
确保长期关注研发工作-SRE研发问题之前已经说过，谷歌将SRE团队的运维工作限制在50%以内，SRE团队应该将剩余时间花在研发项目上，在实践中 SRE管理人员。应当经常度量团队成员的时间分配，如果有必要的话，采取一些暂时性措施，将过多的运维压力转移，回开发团队处理，例如将生产环境中发现的bug和上产生的工单转给研发管理人员去分配，或者将开发团队成员加入到轮值，On-call体系中共同承担轮值压力等等这些暂时性措施，应该一直持续到运维团队的运维工作，压力降到50%以内才行。
在实践中注重措施实际形成了一个良性的循环，激励研发团队设计，构建出不需要的人工干预可以自主运行的系统，只有整个产品部门都认同这个模式，认同50%的安全线的重要性，才会共同努力避免这种情况的发生。
SRE处理运维工作的一项准则是，在每8~12小时的On-call轮值期间最多多只处理两个紧急事件报警时间这个准则保证了，on-call工程师有足够的时间跟紧急事件，这样sre可以正确的处理故障恢复服务，并且撰写一份世界报告出发，人工审核，如果一次轮值过程中处理的问题过多，那么每个问题就不可能被详细的调查清楚，运维工程师甚至没有时间从中学习，如果小规模部署下还无法做到合理报警，规模扩大之后这种情况就会更严重，相对而言，假如一个项目的紧急警报非常少，能够持续稳定运行那么这么。 On-call工程师可能就是浪费时间。
所有的产品事故都应当有对应的事后总结，无论有没有触发警报，这里要注意的是，如果一个产品事故没有触发警报，那么事后总结的意义可能更大，因为它将揭示监控系统中的漏洞，事后总结应该包括以下内容事故发生，发现解决了全过程事故的根本原因，预防或优化的解决方案，谷歌是一项准则，对事不对人事后总结的目标是尽早发现和堵住漏洞，而不是通过流程饶过和掩盖他们。人工审核不能确定的问题在入上级提交更高层次的审核。
页:
[1]