71 lines
3.2 KiB
Markdown
71 lines
3.2 KiB
Markdown
# 第十一章 on-call轮值
|
||
|
||
on-call轮值是很多运维和研发团队的重要职责，这项任务的目标是保障服务的可靠性和可用性。
|
||
|
||
on-call工程师的响应时间通常跟业务的可靠性有关。不同的SLO响应时间不同。
|
||
|
||
## on-call工作平衡
|
||
|
||
SRE团队对on-call工作的质量(工作压力)和数量有明确的要求，这两个维度必须保持在一个可持续的水平上。
|
||
|
||
### 数量上保持平衡
|
||
|
||
SRE团队50%的时间花在软件工程上，其余的时间中， 不超过25%的时间来on-call，另外25%时间来处理其他运维工作。
|
||
|
||
SRE更多地推荐团队：
|
||
|
||
1. 避免夜间任务影响健康(多地时差)
|
||
|
||
2. 限制人员数量，保障对生产环境的熟悉程度
|
||
|
||
### 质量上保持平衡
|
||
|
||
每次on-call值班过程中，轮值工程师必须有足够的时间处理紧急事件和后续跟进工作,如写事后报告。
|
||
|
||
一系列根本原因或相关的事件和报警信息并且这些事件应该在同一个事后报告中讨论，这些事件称为紧急事件。
|
||
|
||
平均处理一个生产环境事件需要约6小时，所以每12小时最多2个紧急事件。
|
||
|
||
### 补贴措施
|
||
|
||
为保障团队按需参与on-call，同时避免过量on-call带来的问题(如项目开发时间不够或疲劳过度), 管理层需要考虑针对工作时间之外的on-call工作给予合理的补贴。
|
||
|
||
## 安全感
|
||
|
||
为确保on-call工程师保持理性、专注、有意识地进行认知类活动而不是依赖直觉、自动化、快速行动， 必须减轻on-call所带来的压力感。
|
||
|
||
让on-call可以使用以下资源来寻求外部帮助以减轻on-call压力：
|
||
|
||
- 清晰的问题升级路线
|
||
|
||
- 清晰定义的应急事件处理步骤
|
||
|
||
- 无指责，对事不对人的文化氛围
|
||
|
||
生产系统对应的开发团队也会参与on-call轮值，SRE团队永远可以寻求这些伙伴团队的帮助。
|
||
|
||
对于非常复杂，需要多团队参与，或经过一段时间调查仍不能确定恢复时间的问题，应考虑启用某种正式的应急事务流程。
|
||
|
||
在应急事件处理解释时，应总结处理事件过程中做的好与不好的地方， 并采取措施避免再次发生同样的问题。
|
||
|
||
## 避免运维压力过大
|
||
|
||
当SRE团队需要50%以上的时间来处理运维工作时，那么SRE团队的运维工作压力就过大。
|
||
|
||
通过以下途径解决运维工作压力过大的问题：
|
||
|
||
- SRE团队和管理层负责在季度工作计划中加入一些应对措施，如从其他团队临时抽调一名有经验的SRE。
|
||
|
||
- 运维压力过载应该是基于数据且可量化的。
|
||
|
||
- 确保监控配置没有错误，报警策略必须跟服务的SLO目标一致。
|
||
|
||
- 控制on-call工程师收到的针对同一起事故的报警数量。
|
||
|
||
- SRE和研发团队设立共同的目标，解决运维压力。
|
||
|
||
- 极端情况下，SRE可选择停止支持某个服务，由开发团队负责on-call轮值或者与开发团队共同承担运维压力直至运维压力降低。
|
||
|
||
## 避免运维压力不够
|
||
|
||
运维压力不够也是一个不良现象，应控制SRE团队的大小，保证每个工程师每个季度必须至少参与一次(最好两次)on-call，同时每年举办一次灾难恢复演习(DiRT) |