SRE Google运维解密 第11章 on-call轮值

on-call轮值

保证可以随时相应紧急问题，不管工作时间还是非工作时间

on-call 工程师的一天

1. on-call工程师承诺在分钟级别执行生产系统的维护需求，一般面向终端用户5分钟，非紧急30分钟。
2. 响应时间与业务可靠性有关
3. 收到报警信息，工程师必须ack,on-call 工程师即使定位并尝试解决问题，或可联系其他团队，或者升级请求支援
4. 有主on-call 和副on-call ，相辅相成

on-call工作平衡

1. on-call 工作质量和数量有明确的要求，数量是某个工程师在on-call 事务上花费的具体时间，质量通过每次on-call轮值发生的事故数量决定

数量上保持平和

1. SRE 规定25%为上限 ，每次轮值需要两名工程师 ，7*24 on-call轮值制度至少需要8名工程师，每次on-call 值班长度为1周，每名工程师只需要每月轮值一次

质量上保持平衡

每12小时的轮值周期内最大发生两个紧急事件（每个紧急事件处理需要6小时），如果一个季度不断超过这个界限，需要采取修正措施将运维压力降到可持续水平

补贴措施

安全感

1. 理性，专注，有意识地进行人之类活动

2. 缓解on-call 压力资源

   1. 清晰的问题升级路线
   2. 清晰定义的应急事件处理步骤
   3. 无指责，对事不对人的文化氛围

3. 启动正式的应急事务处理流程，自动化大部分操作，可以专注于解决问题

4. 进行评估，书写事后报告，详细记录所有事件发生的时间线

避免运维压力过大

运维压力过大

1. 从其他团队临时抽调有经验的SRE
2. 运维压力过载量化，如处理的工单数<5，每次轮值报警事件<2
3. 每条报警有实际操作性，低优先级报警忽略
4. 分组汇总报警，禁止重复无关报警，修改重报警
5. SRE与研发团队一起努力
6. 停止支持某个服务，该服务由开发人员负责on-call 轮值

奸诈的敌人——运维压力不够

1. 系统太稳定会导致信心问题
2. 控制SRE团队大小，保证每个工程师每个季度参与oncall 一次，最好两次
3. Google每年举办一次持续数天的全公司灾难恢复演习（DiRT）针对理论性和实际性的灾难进行演练