一、ONCALL概念

1. 什么是ONCALL？

ONCALL是一个术语，通常用于描述某人或某些人在非工作时间，尤其是在紧急情况下，需要保持7x24小时待命已解决服务稳定性相关问题。

在国内ONCALL一般是指技术值班，处理告警比如事件单、问题单和故障单，保障系统7x24小时不间断运行。

2. 为什么需要ONCALL？

是否需要ONCALL这是与公司业务特性决定的，如果你们老板说服务的SLA不重要，那你们也不需要ONCALL。

基础设施平台、互联网公司提供对外服务的平台或应用、toB ToC用户规模百万级别以上、服务中断分钟级影响收入百万，这种业务类型都需要建立ONCALL机制，降低系统故障发生的概率和故障时间减少公司损失和负面影响。

所以需要ONCALL，目的是：

1. 预防故障的发生：小事件及时解决能规避大故障，比如磁盘告警，如果不及时理可能导程序无法写硬盘导致程序夯住，进而导致业务故障。

2. 可用性上：降低响应时间和故障恢复时间

3. 收入上：减少公司损失。时间就是金钱，减少故障或者不出故障就是为公司减少资损

4. 品牌上：降低服务不可用带来的负面影响。当我们出现网络问题基本上回去ping www.baidu.com，这就是做技术的对baidu这个品牌的稳定性高的信赖。

3. 怎么做好ONCALL？

首先，得到领导支持，在公司里管理层要支持这个事，如果老板比如CTO不支持，这个事也做不下去。

其次，建立ONCALL制度，搭建流程，形成公司ONCALL文化，培训宣讲ONCALL相关制度，故障处理流程，升级机制，应急处理制度等。

第三，搭建ONCALL团队，跟进公司相关ONCALL制度，组建ONCALL团队，做好团队分工，明确ONCALL人员职责。

第四，需要技术运营平台支撑，监控告警机制、舆情检测、公司内部反馈机制健全，流程平台化自动化。

第五，各种操作手册沉淀，SOP、EOP文档在值班过程中不断的补充修订

第六，定期培训，新人加入ONCALL之前需要培训相关制度、SOP和EOP等相关文档，定期ONCALL经验分享

第七，故障复盘，故障复盘的同时反过来检验我们ONCALL是否有成效，故障响应时效，故障处理时长，故障处理流程是否合规。

二、业务可用性

上面我们也说了，建立ONCALL机制，主要是为了保障服务的可用性。服务的可用性达到一个什么水平，是符合要求的呢，我们来看看可用性时间表。

1. 可用性时间表

服务可用性5个9全年不可用时间5.256分钟算到每天不可用时间是8s不可用，服务可用性99%服务全年不可用5256分钟算到每天是14.4分钟不可用。

服务稳定性并不是9越多越好，这个需要从成本、产品战略和稳定性上做一个权衡。

二八原则相信大家都听过，稳定性建设初期20%的投入带来80%的稳定性，后期80%的投入不一定有20%的稳定性提升，所以不一定是9越多越好，结合公司战略、营收和老板一起定一个合适的稳定性指标即可。

一般金融类的服务服务可用性要达到5个9，即一年故障不能超过6分钟，互联网公司服务可用性大概在99.95%到99.99%，你可以参考一下。

下面我们来了解一下SLA、SLO、SLI区别和联系。

2. SLA、SLO、SLI区别联系

SLA通常是一项正式协议，关注客户的需求和提供商的承诺。SLO是服务提供商内部的目标，用于管理服务团队的绩效。SLI是用于度量和监测实际服务性能的具体指标。这些术语通常在不同层次上相互关联，以确保服务达到期望的质量标准。

通常技术ONCALL会处理服务的SLI告警，根据对SLO的影响决定是否启动应急流程。

有的公司大家可能会听到ITSM里的一些概念，下面我们来看一下。

3. 事件单、问题单、故障单

事件单一般是触发了SLI指标阈值产生的，故障单一般对应的是服务可用性低于SLO标准触发的。SLO低于我们定义标准，需要故障复盘，输出故障单。

三、ONCALL值班落地

1. 值班方式

值班视团队人员情况、压力度和告警事件的的多少，选择按天值班或者按周值班。

按天轮值：如果压力大，告警事件多，推荐按天轮值。按天轮班制度意味着每天都会有新的人员承担值班责任，这有助于减轻个别人员的压力。

按周轮值：如果压力适当，告警事件一般，推荐按周轮值。按周轮值，较少的排班变动，管理相对较为简单，但需要更长时间来规划工作周期。

不建议按月轮值，长时间轮值对人心健康、身体压力造成不小的影响，甚至会导致员工离职。

非工作日值班，处理故障时间大于半天以上可以申请调休，这个视公司的制度而定，比如Google ONCALL时间是折算工时算钱的，国内一般都是调休或不算工时。

2. 搭建ONCALL团队

ONCALL团队构成：常见是由运维和研发团队组成，如果涉及安全问题也会涵盖安全等同学，对外服务故障需要对外公关还涉及市场公关人员。团队涉及角色如下：

上述角色根据公司情况进行制定，很多情况一人可能身兼数职，比如值班人员基本上都是专业人员。

3. ONCALL人员具备能力

ONCALL人员的能力因其工作性质和要求而异，但通常需要综合运用技术、沟通、问题解决和管理技能。通常要求ONCALL人员具备能力：

1. 技术能力：ONCALL人员需要熟悉他们所负责的任务或系统，以有效地解决问题和提供支持。

2. 沟通能力：良好的沟通能力是关键，他们需要与客户、同事和上级保持有效的沟通，以确保任务得以顺利完成。

3. 问题解决能力：ONCALL人员通常需要快速而准确地识别和解决问题，这需要具备分析和解决问题的能力。

4. 知识更新：由于技术和领域的不断发展，ONCALL人员需要不断学习和更新知识，以跟上最新的趋势和最佳实践。

5. 压力管理：ONCALL人员经常在紧急情况下工作，因此他们需要具备有效的压力管理技能，以确保能够冷静地应对各种挑战。

6. 团队合作：ONCALL人员可能需要与其他团队成员协作，因此团队合作能力也是重要的。

4. ONCALL任务

常规任务：

1. 告警事件处理，问题排查，修正告警阈值，扩容，重启等

2. 短时间不能解决的事件对业务没有影响，升级为问题单，持续跟进

3. 记录文档SOP，Oncall成员需要记录问题、解决方案和行动，以维护知识库和提供后续分析。

应急任务：

1. 故障处理，当系统或服务出现问题或故障时，Oncall团队需要迅速响应，并采取必要的措施来解决问题，以尽快恢复正常运行。

2. 协调和通讯，Oncall成员需要与其他团队成员、管理层和客户进行有效的沟通，包括通知问题、报告解决进展和协调问题的解决。

3. 跟进故障，故障复盘，补充EOP。

四、应急故障通知机制

当出现较高级别故障时，需要安抚客户，对公司内外需要发故障通知，尽可能降低对公司商誉的影响。

故障通知机制分为以下三个阶段，半小时内的不用发对外公告，超过半小时需要对外发布公告，故障恢复后发布对外故障报告。

第一个阶段（半小时内）

1. CRITICAL告警立即在IM问题处理群里同步信息，立即恢复故障

2. 故障持续时间大于5min，由值班人发起故障处理群，组织运维和研发同学等成立应急小组，进会议室封闭处理(如不在公司则组织视频会议)

3. 故障结束，在当天进行复盘会议，并将结果同步到相关IM群

第二个阶段（半小时-结束前）

1. 公告对内，故障持续30min以上视情况业务线负责人通过IM群发内部公告告知故障情况，To B，对内，业务业线负责人每半小时发送一次通知，包括IM公告（公告内容需要与销售或客户服务TL）和群通知，用于同步进度；

2. 对外，由商服或客户服务部门来触达客户，可以按照公告内容酌情处理。To B 公告内容格式请参考下面"文案 TO B”。

3. To C，对内，业务业线负责人每半小时发送一次通知，包括IM公告（公告内容需要与市场部TL确认）和群通知，用于同步进度；

4. 对外，由业务业线负责人和市场负责人决定是否发布。To C 公告内容格式请参考下面"文案 TO C”。

第三个阶段（结束后）

业务线负责人通过IM群通知和IM公告方式通知内部员工故障原因（To B公告内容需要与销售或客户服务TL确认，TO C 由市场部TL决定是否官方微博或其他渠道发公告）

文案TO B

一、故障发生第一次通告 

标题：【故障公告】{{某某产品}}故障通告-{{日期}} 

内容：{{时间}}{{某某产品}}发生故障，{{业务功能模块}}等功能受到影响不能正常使用，相关技术同事已在第一时间介入进行排查分析处理，{{故障原因，若有}}。

本次故障预计影响{{影响客户范围}}。预计在{{修复时间，若有}}内恢复。

后续进展会以公告的形式即时同步给大家。再次抱歉给大家使用产品的影响，感谢大家的包容，理解和支持。

二、故障中更新通告 

标题：【故障进展】{{某某产品}}故障进展通告-{{日期}} 

内容：{{时间}}{{某某产品}}发生故障，{{业务功能模块}}等功能受到影响不能正常使用，相关技术同事已在第一时间介入进行排查分析处理。{{修复进展}}。预计在{{修复时间，若有}}内恢复。

后续进展会以公告的形式即时向大家同步，请耐心等待。再次抱歉给大家使用产品的影响，感谢大家的包容，理解和支持。

三、故障解决后通告 

标题：【故障恢复】{{某某产品}}故障通告-{{日期}} 

内容：{{时间}}{{某某产品}}发生故障，现已全面恢复，故障持续时间为{{持续时间}}。

本次故障原因为{{故障原因}}，{{故障处理过程简述}}。{{故障恢复时间}}，确认故障全面恢复。{{故障影响范围}}。再次抱歉给大家使用产品的影响，感谢大家的包容，理解和支持。

文案 TO C

一、故障发生第一次通告 

标题：【故障公告】{{某某产品}}故障通告-{{日期}} 

内容：{{时间}}，由于{{引发故障表象}}，导致{{影响的服务范围}}。目前我们正在紧急排除故障中，如果有进一步的消息，我们将随时更新。

二、故障中更新通告 

标题：【故障公告】{{某某产品}}故障进展通告-{{日期}} 

内容：{{时间}}，{{是否}}定位本次故障原因，{{解决措施}}。请大家耐心等待。非常感谢！

三、故障恢复通告 

标题：【故障公告】{{某某产品}}故障恢复通告-{{日期}} 

内容：{{时间}}，经{{解决人员}}全力抢救，现在{{某某产品}}已经恢复正常使用。此次故障原因已经定位，因{{原因}}，从而影响了部分用户。今日{{故障发生时间}}的故障对大家的日常工作造成了极大的影响。我们深感抱歉，我们后续将采取更多措施以保障服务的稳定。感谢大家的包容，理解和支持。

五、故障复盘模版

故障复盘，也称为“事故分析”或“事故回顾”，是一项非常重要的实践，用于分析和评估发生的故障、问题或事故，以便从中吸取经验教训、改进流程和减少将来类似问题的发生。

一般故障复盘最好是故障恢复后当天组织干系人进行复盘，复盘前需要组织者准备好故障单。故障单包括如下内容：

故障单：

故障标题：反应当前故障的titile

处理时间： 这里主要有几个点需要重点关注一下，首次告警时间、响应时间、处理时间（拉群），恢复时间。

处理过程： 要记录详细告警处理流程，通过故障处理流程我们可以检验我们的监控告警是否完善、应急机制是否执行到位

故障原因： 知道故障原因，后续改进措施会比较好对症下药，这块可能是花的时间比较长去定位的。

影响范围： 影响的产品、影响用户等

故障级别： 根据影响范围、时长，来定性此次故障级别。

改进措施： 如何避免 重复再出现，这个是重点。一定要有改进措施，改进措施的时间点，方便后续跟进。

六、总结

本文围绕ONCALL概念、ONCALL文化、怎么建设ONCALL机制以及ONCALL人员值班是遇到的各种事件或告警进行阐述。

值班期间各种事件可能是普通的事件单、也可能是短时间不能解决问题单、亦或者是最紧急的故障，不同事件的应对方式和事后处理流程。

最后给出故障应急常用的故障通知流程和事后故障复盘模版，希望对你的ONCALL建设有帮助。

服务的稳定性离不开ONCALL人的努力、奋斗和持之以恒的精神，向ONCALL人致敬。

来源：https://mp.weixin.qq.com/s/LcZpll6tyPBavOo9NwL_JQ

安志合个人博客，版权所有 丨 如未注明，均为原创 丨 转载请注明转自：https://chegva.com/5852.html | ☆★★每天进步一点点,加油!★★☆ |