×

微信扫一扫,快捷登录!

SRE要确保长期关注研发工作

标签: 暂无标签
上文已经讨论过,Google将 SRE 团队的运维工作限制在50%以内。SRE 团队应该将剩余时间花在研发项目上。在实践中,SRE管理人员应该经常度量团队成员的时间分配,如果有必要的话,采取一些暂时性措施将过多的运维压力转移回开发团队处理。例如∶将生产环境中发现的Bug 和产生的工单转给研发管理人员去分配,或者将开发团队成员加入到轮值 on-call体系中共同承担轮值压力等。这些暂时性措施应该一直持续到运维团队的运维工作压力降低到50%以下为止。在实践中,这种措施实际形成了一个良性循环,激励研发团队设计、构建出不需要人工干预、可以自主运行的系统。只有整个产品部门都认同这个模式,认同 50%的安全线的重要性,才会共同努力避免这种情况的发生。

SRE 处理运维工作的一项准则是∶在每 8~12 小时的 on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件,这样SRE 可以正确地处理故障、恢复服务,并且要撰写一份事后报告。如果一次轮值过程中处理的问题过多,那么每个问题就不可能被详细调查清楚,运维工程师甚至没有时间从中学习。如果小规模部署下还无法做到合理报警,规模扩大之后这个情况就会更严重。相对而言,如果一个项目的紧急警报非常少,能够持续稳定运行,那么保持这么多 on-call 工程师可能就是浪费时间。

所有的产品事故都应该有对应的事后总结,无论有没有触发警报。这里要注意的是,如果一个产品事故没有触发警报,那么事后总结的意义可能更大∶ 因为它将揭示监控系统中的漏洞。事后总结应该包括以下内容∶事故发生、发现、解决的全过程,事故的根本原因,预防或者优化的解决方案。Google 的一项准则是"对事不对人",事后总结的目标是尽早发现和堵住漏洞,而不是通过流程去绕过和掩盖它们。




上一篇:我们要选择DevOps 还是 SRE ?
下一篇:在保障服务 SLO 的前提下最大化迭代速度
FYIRH

写了 198 篇文章,拥有财富 1122,被 1 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

手机版|小黑屋|最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部