这是有赞的故障管理经验

2019-09-10 15:59:24 采集侠

线上故障是指提供给客户使用的IT服务全部或部分不可用,包括服务性能的降低,如:服务延迟导致用户体验变差。

在创业前期,为了抢占市场先机,产品新功能的发布速度追求往往优先于其质量,埋下了很多技术债务,部分技术债务的爆发会引起线上故障,造成客户的体验下降或经济损失。

故障管理的目标是“尽快恢复服务到正常运行,并且最小化对业务运营的不利影响,从而尽可能地保证服务质量和可用性的水平”。

在故障发生后,故障紧急处理小组会定位、分析和恢复故障,并在故障恢复后对故障进行Review和总结,制定出可执行的Actions,以提高故障处理效率和避免类似故障再次发生。

下面将为大家简单介绍有赞的故障管理实践。

故障处理流程介绍

有赞使用JIRA作为跨部门协作工具,线上故障管理也借助于JIRA。我们制定了下面的故障处理流程,故障JIRA工单遵循该工作流,而故障Action(s)会被建立在对应的故障JIRA工单子任务中,子任务的工作流为JIRA默认工作流。

这是有赞的故障管理经验

这是有赞的故障管理经验

确认故障与通知协调人

当收到客户、内部员工或监控上报的潜在故障时,报告人会尽快确认故障的有效性。

当确定是个故障后,会提交一个故障JIRA工单,并通知故障协调人(来自研发效率团队,主要负责业务与技术部门之间的信息同步和协调)。

协调人确保公司内业务部门、技术和产品部门被通知到位,同时将故障上报到“可用性保障微信群”里,故障原因排查和讨论会在该群里或拉单独的故障处理群进行。

定位/处理故障

为避免无关消息干扰,故障处理人组建故障紧急处理小组(在微信群里或坐在一起),以提高故障处理效率。

故障处理人在定位到问题后需将故障原因和预计多久修复同步给协调人。对于处理时间比较长的故障,紧急处理小组会每隔半小时对相关业务部门同步一次故障处理进展。

故障恢复

如确定是发布引起的故障,需将代码回滚到故障前的某个稳定版本。

故障恢复后,故障处理人需跟业务影响方确认是否有数据需要修复。如有,需将影响情况反馈给协调人,并配合业务方尽快修复数据。

组织故障Review

故障Review一般安排在故障处理结束后24小时内,包括故障过程回顾、故障原因分析、改进预防措施制定、故障定级等,其产出物为:

故障分析报告。故障定级分为P1、P2、P3和P4四个等级(依次降低),每个业务组都有特定的等级定义,主要从业务影响面和影响时间来确定。目前使用的故障报告模板如下:

这是有赞的故障管理经验

这是有赞的故障管理经验

同步故障报告

故障Review参与人一般是故障处理人、协调人、责任人及责任方组长,故障报告人视情况自愿参与。

为了让所有技术小伙伴都能了解到故障信息,故障责任人需将最终版的故障报告同步到产品技术群。

建立每个Action JIRA子任务

故障责任人在JIRA故障单下创建子任务,每个子任务对应一个故障Action,子任务的“到期日”字段需被更新成:Action的Deadline,并将其分配给Action执行人。

故障与故障Actions跟进

JIRA看板是个很直观的工具,支持在规定的工作流之间移动任务板。我们使用JIRA的kanban board来跟进故障及其Actions(如下图),顶部快速过滤器可以快速访问各技术业务组不同状态下的故障或Actions信息,横向上拆分成3个泳道:

故障、逾期故障Actions和待处理故障Actions。

如果某个Action的到期日已经到了,该Action任务板会显示在“逾期故障Actions”泳道中,否则会显示在“待处理故障Actions”泳道中,故障协调人会定期跟进下逾期故障Actions的执行,并将逾期的故障Actions同步到产品技术群里,以提醒Action执行人及时处理JIRA。