一点思考
对于绝大多数开发人员是不愿意参与 oncall，oncall 意味着 24h 随时待命，出现问题，一个人需要抗整个团队的压力，当然我们可以找别人帮忙，但是你也要把问题描述清楚，要想描述清楚，可能就需要牺牲个人休息时间来分析和定位问题。
但从另一个角度来说在高强度压力下能够从容处理和解决问题，也是个人能力的一种体现，特别对于新手，通过 oncall，能够快速熟悉和接手一个服务。
对于公司管理层来说，要考虑到员工的难处，连着 7X24 工作都会倦怠，所以要尽可能把 oncall 排班均分给每个人，在保证灵活性的前提下，尽可能公平，而不是每次总是那么几个人解决问题；对于参与 oncall 人员不参与当天的开发工作，如果休息时间参与 oncall，则给予一定实质上的鼓励，让团队成员愿意积极参与进去，共同寻找一种最优的问题解决方式，从而保证线上故障快速响应和处理。
以下是我在工作过程中的经验总结，分享给大家。
类别 | 内容 |
|---|---|
告警级别 | P1、电话 消息告警，可以要连续呼叫多人，需要 oncall 人员立即处理。这类服务一般会影响营收的项目，能够直接带来资损，常见的有购物下单付款等； |
P2、消息告警，可以隔几个小时或者一天处理。这类服务一般会影响用户体验或者出现问题会带来间接资损，比如评论、优惠劵等； | |
P3、邮件告警，可以不用处理或者分情况处理。不会带来任何损失，比如一些常见的 B 端产品或者公司内部使用的系统； | |
告警指标建设原则 | 非必要，不告警，比如告警之后无法处理或者做出动作，这种就没有必要进行告警；如果存在这种告警指标可以考虑降低告警级别或者直接删除；当然如果因为缺少了某种告警而导致事故则需要立即建设此种类型告警指标。 |
每条告警都要对应 SOP 或者说预案处理流程，一拨人认为应该宽泛笼统，这样预案不用经常变化，靠各位 oncall 人员根据流程延伸发挥；另一波人认为应该尽可能详细，以降级操作导致故障的变数，但问题总是以不一样的方式呈现出来；过于详细可能会导致把问题带偏，从而不能有效解决；我认为具体要根据服务实际情况处理；如果不怎么变化的部分就可以通过标准化、甚至自动化的流程处理；如果存在未知的问题，则要在特定流程下指导完成，无论怎样不要依赖直觉，在面临挑战时，依赖直觉往往会犯错误。 | |
告警来源 | 基础设施，比如服务器、K8S 集群、数据库、依赖第三方组件； |
核心服务、配置变更、SQL脚本执行，多数告警都是服务自身存在 bug 导致； | |
问题处理 | 查看最近变更，如果跟变更有关系，在保证安全的前提下回滚服务； |
在保证服务正常的前提下，通过开关关闭掉有问题的功能，这要求我们在上线没有十足把握的功能情况下，做好关闭的准备； | |
重定向到没有问题的集群； | |
如果跟这些都没有关系，那么就要进行故障升级，邀请多个人参与进来共同处理。通常来说可以通过线上会议的方式一人指挥，分工进行问题验证和故障恢复。 | |
看上去跟我们正常思维有点差异，比如你的服务是 P99.99 可用性，一个季度也就 15 分钟的停机时间，所以在保证安全前提下，恢复服务永远是第一优先级；剩下的才是假设故障点 --> 验证故障点 --> 修复故障点 --> 再次上线；这才是正常的标准化问题处理流程。 | |
问题记录 | 每次告警都要携带一个告警处理清单或者我们常用的 jira 单，把告警内容和处理过程写清楚； |
团队内部养成一个好的复盘文化，避免指责、保证不犯类似的错误，当有新人或者其他人解决类似问题时有一个可以借鉴和参考的问题处理手段，而不用老路重走一次，降低问题处理心智负担。 | |
故障演练 | 系统太稳定，容易让人松懈，当故障突然来临，会让人不知所措，所以要每月固定时间进行故障演练和恢复。 |
