在工作过程中我们都会遇到不同的难点或者事故，那面对事故我们应该采取怎样的应对措施呢？或者应该怎样提前预防？一起来看看作者是如何分析的。

还记得某个请了事假的周五下午，处理完事情之后，我跟朋友北京城区内悠闲地吃个早午餐，没想到手机中的Teams突然响起，一看竟然是来自公司作战室的来电，心脏仿佛突然漏了一拍，只好放下手中的刀叉，接了起来……

对产品经理来说，处理事故是必修的课题，但如何「漂亮地处理事故」，则是需要不断与团队彼此磨合。有兴趣了解的朋友就一起往下看看吧！

一、什么是事故应变措施？

前阵子我看了一部被誉为人生必看的韩剧《浪漫医生金师傅》，剧中描写了许多医院急诊室的故事。

其实互联网服务的生产事故，就像在医院急诊室一样，得由一群经验老道，并且可以处理各式各样的医护人员进行第一步筛查，判断发生原因，然后再交由各科室的同仁进行详细处理。

因此，在产品服务面对用户之后，有一组非常重要又辛苦的互联网急诊室的守护者，就是SRE (Site Reliability Engineering)。

他们主要负责确保服务的稳定性，监控生产环境上的各种情况，一旦发生问题时，就要立刻召集相关人员排查、解决。

服务稳定性乍听之下可能不太起眼，但却至关重要。作为产品经理，为了能够提供更好的用户体验、保持市场竞争力，並追求更好的商业价值，我们总是不停地在「持续迭代」，而如何平稳、丝滑的调整，就依赖开发团队及SRE团队的合作。

互联网服务上，系统包含的范围非常广，业务应用服务、网路、数据库、云端服务或伺服器等等，每一个环节都有可能出现异常，问题真的千奇百怪。

小到用户不理解前端提示而误操作、网路波动影响接口调用失败、或是大到整体机房出现异常、流量被恶意拦截需要紧急抢救的…等等。

面对不同等级的故障，团队应该在事故的「处理时效」、「处理方式」、「通报范围」的不同维度达成共识。

二、为什么要搭建事故应变措施？

互联网金融服务相比于工具类的服务，服务的稳定性，在用户心智中很大程度与资金安全有所关联。试想看看，如果隔天就是房贷的缴款截止日了，但是金融服务突然不能用，身上也没有现金这多令人跳脚！

当有生产事故发生时，除了影响用户体验、公司收入、更甚者可能引发舆论而影响公司声誉。因此，在事故发生当下，除了排查问题、解决问题之外，与团队内部、外部合作方、外部用户、公关媒体的沟通，每一个环节都至关重要。

三、如何搭建事故应变措施？

1. 预想可能发生的事情

如同《浪漫医生金师傅》剧中，我们可以看到许多奇特的意外伤害而来到医院急诊室的病患，例如：连环车祸、滑雪受伤、误食农药、地震等各种天灾人祸皆有可能，而剧中的护理人员也会每天准备好急诊室常备用品，确保当有需求时，不会因为物品匮乏而延误抢救病患的最佳时间。

而反映在互联网服务上，我们不难找到许多有心者恶意利用漏洞，或是意外情况而导致的生产事故，团队可以预先想到可能发生的情况，也可以在经验中不断学习。

例如：系统流量超过可负荷的限额、流量被恶意拦截、依赖性系统突发异常、用户因不理解指引的误操作…等等。

2. 确定有哪些重要团队成员

如上述说的，在讨论生产事故处理机制时，我认为有这些角色的参与是非常重要的，每个角色可以从各自的角度提供专业建议与支持。

• 产品经理
• 架构师、开发、测试
• 客户服务团队
• 外部合作伙伴团队
• 公关团队
• 法务、合规团队

3. 建立团队成员对于事故等级的共识

你知道吗？在医院的急诊室中，并非先抵达的患者能够优先接受治疗，而是需要依照伤病的紧急程度进行优先级排序。

因此，团队成员的首要目标是拟定一套能够帮助判断「优先级」的指标架构，并且「达成共识」（当然内容可以依据业务发展而有所调整），毕竟当真的有P0、P1的紧急问题时，需要大家专心一致的解决。

这时候可不会希望因为彼此对标准理解不一致，降低了事故解决的效率。

（1）建立指标：可以参考以下不同维度

• 影响范围：评估事故对用户体验、业务运行、系统功能、或服务可用性的影响范围。
• 持续时间：事故持续影响时间。
• 重要性和紧急性：事故对业务运营的重要性和需要被紧急解决的程度。
• 合规性要求：思考事件对相关合规性要求的影响，如违背合规法务要求，可能会导致更严重的故事等级。
• 可用备份和恢复策略：考虑备份和恢复策略的可用性和有效性。

（2）为每个指标及事故等级定义数值

通常我们会与团队成员对于不同事故等级共同讨论相关指标维度，并建议「可快速量化」数值。例如：影响交易金额、事故持续时间、或受影响用户数。

也需要针对不同等级的事故定义响应时间以及目标处理时间，例如：P0的事故需要一天内解决，P1事故可以两天内解决，以此类推。

（3）为不同等级的事故，定义对应SOP（标准作业程序）

我们其实没有想像中的那么冷静。

还记得开头我提到的周六事件吧！我印象非常深刻，那天早上虽然是电话会议，但是我感觉许多人一进到电话里头就满脸「我是谁？我在哪？」的感觉。

每一次有新同事加入时，就要重新解释一遍问题、影响以及当前进度，然后想办法厘清原因、找到对应的处理方式。

SOP（标准作业程序）是一个非常好的工具，可以帮助团队在紧急的时候，有一个可以参考的依据。

「服务降级」也是一种常采用的方式，例如在大促活动的流量高峰时，仅维持重要的系统交互，避免过多的系统交互影响服务响应速度…等等。

4. 建立监测预警机制

监测与预警是预防、尽早掌握事故发生的重要工具。

例如：确保预先充值的云服务，会在额度快被用完之前会提供邮件或短信预警、定期监测主要核心流程是否有系统交互、流量请求（有时候没有系统请求是因为用户根本无法访问该页面），越早发现事故，也可以越快控制影响范围。

5. 事中优先解决问题，事后详细检讨

团队在事故发生的当下，仅需要专注于最快的速度解决问题。而在事故解决后，也需要十分详细地检讨原因。

每一次的生产事故对团队成员来说，都是极其宝贵的经验，而经验不仅需要时间积累，更需要被纪录与传承，避免重蹈覆辙，保持互联网的精神，小步快跑，在错误中学習。

四、结语

处理生产事故的时候，在时间与情绪的双重压力下，其实常常需要花费相当高的沟通成本。所以建立起团队的合作共识，持续地磨合出一些应变机制。我也时常跟同事分享一个正念思考的心态，「有生产问题，代表真的有用户在使用你的服务啊！」