外企互联网金融产品——搭建事故应变措施

1 评论 2806 浏览 4 收藏 10 分钟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 预想可能发生的事情

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

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

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

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

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

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

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

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

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

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

(1)建立指标:可以参考以下不同维度

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

(2)为每个指标及事故等级定义数值

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

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

(3)为不同等级的事故,定义对应SOP(标准作业程序)

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

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

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

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

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

4. 建立监测预警机制

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

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

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

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

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

四、结语

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

本文由 @是安娜啊 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作为产品经理,要有一种要应对的能力,无论任何时候都要有一种转变思维。

    来自吉林 回复