本文主要介绍什么是故障。
定义
在日常运营中，无论什么原因导致业务服务中断、服务品质下降或用户服务体验下降的现象，称为故障，但不包括用户侧环境或用户自身操作引起的问题。
“用户体验下降”说明故障的核心要关注用户感受，可通过客服渠道获知用户投诉，也可通过监控渠道推知用户端的使用情况。
“服务中断、服务品质下降”说明即使用户没有投诉（甚至没有用户使用），但是如企业提供的服务出了问题，也是故障。
“无论什么原因”指无论是企业自身原因，还是第三方如供应商、运营商的原因，只要影响到了用户，就都是故障。
故障等级
每个故障以P1-P4级别来区分重要程度，以获得不同的处理方式和关注度。P1为最高优先级，P4最低。
定义故障等级的原则为：
不同服务/业务可依据自身的特点为每一级别设定定义，定义可由企业技术支持角色召集开发、运维、测试、PD、客满、运营等角色一起制定。确定版本需得到各方认同方能发布。
故障等级由影响程度来确定：影响程度以受影响产品/服务/功能的重要性+影响面（如受影响用户数、损失的金额、外部舆情等）+故障时间来确定。
功能重要性：分核心、次核心和非核心。
次核心功能和非核心功能的故障级别，相比核心依次降一级、二级。
除主动维护停服务外，导致业务/服务全局不可用的事件均为P1 故障。
与 P1、P2 级别相关的定义要做到可监控。
核心功能
故障应急：支持故障全局应急通告，电话、短信、邮件、IM多种通知渠道，确保故障关键进展及时通知至相关人员，加快信息流转。
故障收敛：支持按时间/次数进行告警收敛，将告警收敛到一个故障中统一处理。
故障追踪：支持对故障的最新进展、故障影响面（影响服务）、舆情反馈、Timeline时间线进行在线化管理、协同，基于统一视角协同处理故障，提升故障处理效率。
故障复盘：基于最佳实践经验，沉淀了对故障进行深度复盘的结构化要求，形成了线上检查点，以产品的方式承载流程落地。包括根因检查点（如故障原因、最近活动、注入方式、恢复方式等）、故障变更检查、监控检查，并需要对每一个故障明确到责任人及团队。
故障改进：支持对故障制定明确的改进及验收措施、责任人及完成时间，确保每个深度复盘后的故障都能对业务连续性形成改进，避免历史同类故障重复发生。