1.故障和故障管理的定义业界的故障管理是基于ITIL演进的，流程是按照实际情况适应互联网的精益迭代。1、ITIL中故障的定义：①IT服务非计划中断，或IT服务性能下降。②配置项失效，即使不影响服务。故障管理：处理所有故障的过程。故障管理的目标：尽快恢复服务正常运行，将对业务运营的不利影响降到最低，尽可能保证服务质量和可用性水平。2、业界对故障有比较完善的定义：除用户环境或用户自身操作外，任何其他原因导致服务中断、服务质量下降或用户服务体验下降。故障管理：围绕故障生命周期的一系列活动和过程，包括故障级别定义、故障发现、故障响应、故障应急、故障恢复、故障复查和持续改进。故障管理的目标是防止可预见的问题，从不可预见的问题中快速恢复，并且不重复已经发生的问题。2.为什么需要故障管理无论是理论还是实践，都证明只要有故障的可能，故障就会一直发生。因此，为保证业务稳定，需要提前发现和化解风险，及时发现和定位原因，快速恢复故障。同时，为确保改进措施的有效实施，避免故障重复发生，需要建立可循的故障管理闭环体系。.3、如何做好故障管理故障管理就是对故障的整个生命周期进行管理，形成一个闭环系统，持续改进。无论是理论还是实践，都证明只要有失败的可能，就总会发生。因此，为保证业务稳定，需要提前发现和化解风险，及时发现和定位原因，快速恢复故障。同时，为确保改进措施的有效实施，避免故障重复发生，需要建立可循的故障管理闭环体系。.1.故障等级定义1.1故障顺序故障管理部门（如质量部门、NOC、运维管理部门等）可根据实际情况定义故障顺序。级别数越低，严重性越高。P（PRIORITY）序列：技术基础序列，故障排除的综合优先级。D（DATA）序列：数据质量序列、综合数据资产水平和数据影响因素。R(RISK)序列：舆情风险序列。S(SLA)序列：衡量影响SLA的严重性。1.2故障分级以P序列为例：故障分级建议分为通用型和业务型故障，业务线故障分级标准不应低于通用型故障分级标准.一般故障级别由故障管理部门定义，可以包括受影响用户数量、受影响业务数量、客户投诉增加量、经济损失等一般指标。当未涵盖业务线故障场景时，通用故障场景涵盖底线。业务类故障级别由故障管理部门和业务团队从用户角度共同定义。以下是业务类型故障分级的示例。内部工具也可以遵循此模板来定义事件级别以包含在事件管理中。2、监控告警的核心是定义与业务监控相关联的故障等级，以便及时发现故障。告警本身必须是智能的，以提高告警的准确性，如智能阈值、智能基线、根因算法等。3、故障紧急问题升级为故障后，故障管理部门会及时通知故障信息，发起故障处理小组/电话会议，协调、跟进、督促故障处理直至恢复。由于故障管理部门需要7X24应急响应，有条件的公司可以参考谷歌的SRE和阿里的GOC组建团队。成员分布在不同的时区，日出而作，日落而息。4.故障恢复故障发生后的首要任务是恢复业务。应急预案、重启、降级、隔离、流量切换、饱和应急都是可选方案。5.故障排除5.1.故障恢复时效性为保证问题和风险得到足够重视，及时制定改进措施，建议P1P2类故障1个工作日内完成恢复，P3P4类故障3个工作日内完成恢复。其他序列失效请参考P序列时效性。5.2.故障复查准备工作为了提高复查会议的效率，故障管理人员（复查会议主持人）在会前应梳理如下信息：故障处理流程：必须包括故障注入、故障发生、故障发现、故障响应、初始原因定位、恢复执行、故障恢复、根因定位等核心时间点和操作，其他关键时间点和操作根据实际情况补充。对业务的影响：具体到下跌的时间段、下跌的比例、亏损的金额。用户/业务影响：理论影响量、来电、在线咨询量故障根因及对应根因分类：设备故障、代码问题、流程规范、应急备灾、能力等5.3．故障恢复注意事项故障预防：是否更换触发器故障发现：发现时间、查找源头、监控优化应急响应：响应时间6、连续运行连续运行是一个广义的概念。除了故障数据、经验传承、文化弘扬等各个维度，最重要的是通过故障数据分析来识别故障。生命阶段的弱点和风险点对弱点和风险点有特殊的改善。比如如果没有灰度直接发布多次导致重大故障，是否可以对变更系统和平台进行强有力的管控；故障恢复主要看代码发布，导致恢复慢，能否营造及时恢复的文化，能否针对常见故障场景沉淀快速恢复计划等。4.对故障管理工作者的建议故障管理是一条漫长而艰难的道路，现给故障管理同学以下建议，希望能互相鼓励。1.积极主动，对风险认真负责，问题跟进不到位，故障不跟进，故障数量增加，影响扩大，故障根源不抓紧明确，改善措施可能无效，故障还会重现2.敢于质疑监控发现是否及时，故障处理流程是否可以优化，是否存在人为失误，业务影响面统计是否真实，故障原因是否是本次故障的根本原因，改进措施是否合理。3、自我改进故障管理人员不是统计数据，记录文员必须作为架构师严格要求自己，能够指出故障每个阶段存在的问题，并能够独立承担相应的优化项目。
