1.确保关键角色在线。
这里的关键角色不是指一两个值班的运维或 SRE 人员，而是整个产品体系中的所有关键角色。比如电商就需要安排核心业务应用（如用户、商品、交易、优惠及支付等）的 Owner，或 Backup 中至少有一人参与 On-Call 轮班。不过，接收故障告警或第一时间响应故障的，一般是运维、PE 或 SRE 这样的角色，业务开发同事要确保及时响应 SRE 发起的故障应急。
2.组织 War Room 应急组织。
我们有专门处理故障的“消防群”（暗含着灭火的意思），会将这些关键角色纳入其中，当有故障发生时会第一时间在消防群通报，这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫（Page）。如果是工作日，对于严重故障，会立刻组织成立 War Room，责任人会马上聚到一起；如果是非工作时间，则会通过电话会议的方式拉起虚拟 War Room。
3.建立合理的呼叫方式。
我们建议使用固定的 On-Call 手机，建立手机与所有 On-Call 系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应 IDC 机房运维等等。这样我们在 On-Call 时就不再找具体的哪个人，而是手机在谁手中，谁就承担 On-Call 职责。除非问题迟迟得不到解决，或者遇到了疑难杂症，这种时候再呼叫其他同事参与进来。
无论是 SRE、架构师，还是一线开发，熟悉某个系统的最快最好的方式就是参与 On-Call，而不是看架构图和代码。所以，有效的 On-Call 机制，可以让团队更深刻地认识到目前系统的存在哪些问题，对自己的痛苦状态也会有更深刻的感受，进而对后面的改进措施才能更有针对性和落地性。同时，On-Call 也可以培养和锻炼新人和 Backup 角色，这也是让新人尽快融入团队和承担责任的最好的方式。
4.确保资源投入的升级机制。
这个跟前面几条有相关性，有很多团队认为 On-Call 就是设置几个人值班，所有的事情都交给这几个人做；最极端的还会认为所有的事情，都应该是冲在最前线的运维或 SRE 来完成。但是，在分布式架构这种复杂场景下，这种思路是明显不可行的。
这里最核心的一点就是要给到运维和 SRE 授权，当他发现问题不是自己或现有 On-Call 人员能解决的时候，他有权调动其他必要资源投入。如果故障等级偏高，一下无法明确具体找哪些人员投入的时候，SRE 或运维可以直接上升到自己的主管或相关主管那里，要求上级主管协调资源投入。必要时，还可以上升到更高级主管，甚至 CTO 或技术 VP 来关注。所以，授权非常关键，这一点的具体操作层面，我们会在后面的故障处理过程中再详细介绍。
5.与云厂商联合的 On-Call。
现在企业上云是大势所趋，绝大多数情况下，我们对问题和故障的处理，是离不开与云产品工程师一起高效联动的。所以，我们应该把云产品和云厂商作为我们系统的一部分，而不是单纯的第三方。而对于云厂商来说，也要考虑把客户业务作为自身业务的一部分，只有这样双方才能紧密合作。我们应该提前做好与云厂商之间的协作磨合，联合故障演练，必要的授权等等。
思：OnCall就是值班，移动互联网时代要求7*24小时保障，如何有效地做好OnCall也是很有套路的。
首先是要让关键岗位都能及时在线处理，金融一般是有专门的值班人员，互联网公司则是在线轮流值班，需要的时候会快速拉起应急群处置；
其次是拉群分析，也就是War Room，快速协同、分享进展，以最快的速度处置，恢复业务；
建立合理的呼叫方式是为了快速找到正确的人；
确保升级机制是为了能快速调动资源；
与云厂商协同也是在云计算时代如何快速利用资源。
总之，OnCall就是为了快速的协调资源解决问题。
此文章为8月Day2学习笔记，内容来源于极客时间《SRE实战手册 》，强烈推荐该课程
