请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 285|回复: 0

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

[复制链接]
发表于 2020-11-25 20:10:27 | 显示全部楼层 |阅读模式
上文已经讨论过,Google将 SRE 团队的运维工作限制在50%以内。SRE 团队应该将剩余时间花在研发项目上。在实践中,SRE管理人员应该经常度量团队成员的时间分配,如果有必要的话,采取一些暂时性措施将过多的运维压力转移回开发团队处理。例如∶将生产环境中发现的Bug 和产生的工单转给研发管理人员去分配,或者将开发团队成员加入到轮值 on-call体系中共同承担轮值压力等。这些暂时性措施应该一直持续到运维团队的运维工作压力降低到50%以下为止。在实践中,这种措施实际形成了一个良性循环,激励研发团队设计、构建出不需要人工干预、可以自主运行的系统。只有整个产品部门都认同这个模式,认同 50%的安全线的重要性,才会共同努力避免这种情况的发生。8 Q+ x. W: q0 U/ }+ B/ q0 b, r
! ^1 ]- C% c' U. l1 t
SRE 处理运维工作的一项准则是∶在每 8~12 小时的 on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件,这样SRE 可以正确地处理故障、恢复服务,并且要撰写一份事后报告。如果一次轮值过程中处理的问题过多,那么每个问题就不可能被详细调查清楚,运维工程师甚至没有时间从中学习。如果小规模部署下还无法做到合理报警,规模扩大之后这个情况就会更严重。相对而言,如果一个项目的紧急警报非常少,能够持续稳定运行,那么保持这么多 on-call 工程师可能就是浪费时间。$ }+ N& F. y3 T1 S

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




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

本版积分规则

本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-1-20 07:29 , Processed in 0.151561 second(s), 30 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表