线上故障管理

http://tech.youzan.com/you-zan-xian-shang-gu-zhang-guan-li-shi-jian-chu-tan/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

线上故障是指提供给客户使用的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。

故障数据分析

通过分析故障数据，我们可以发现问题在哪里，并进行改进。目前故障数据主要记录在JIRA和Confluence上，我们会将其按特定格式备份到Numbers中，从不同角度分析这些故障数据，如：每月故障数对比、每月故障处理时间对比、近两月故障等级占比分布、近两月故障类别占比分布、近两月故障来源对比和近两月各业务组故障数对比等。

结合每月发布数据和线上问题数据的综合数据分析，我们得出了“发布次数很多的月份，其线上问题和故障数也相对较多”的结论。为了减少故障发生率，我们需要减少发布频率和规范发布流程。

添加笔记：感觉现在是发布频率太高，故障频出。

小结

根据当前存在的问题制定出一套流程不难，难在对流程执行的跟踪和监督。有赞线上故障处理流程由研发效率团队负责跟踪和监督，确保了每个故障都能经过Review，并形成完整的故障分析报告，同步给所有技术小伙伴。同时，每个故障Action都是可执行的，且有明确的执行人和Deadline。经过一年多的故障管理，我们不仅沉淀了宝贵的故障数据，为改进方向提供了参考，也增强了小伙伴的故障意识，对线上环境的敬畏之心和对故障的紧急处理意识。

关于“故障管理”，我们只迈出了一小步，还有诸多待改进的地方。例如，我们目前主要管理了线上的故障，对公司内部系统故障并没有管理起来；目前大家了解故障信息的途径是：JIRA、Confluence和技术报表，缺乏一个公共的故障检索和自动生成故障报表平台；我们的事件管理（Event Management）水平还很低，很多故障是由客户上报，而不是由监控系统先发现。