xx类故障
如果故障有多种类型，或者涉及多个组件，需按照类型或者组件先进行分类，便于快速查找相应的故障处理指导。如果单个组件的故障类型比较多也可以先按照不同的组件进行分类，组件中再按照不同的故障类型进行分类。
xxx故障处理
现象描述（必选）
故障现象的详细描述，说明什么情况或条件下会产生什么故障。
对系统的影响（必选）
描述当前故障产生后，对系统的影响程度。对系统没有任何影响可写为“无”。
描述时应该让客户能判断下一步是否需要采取措施，不宜写得太模糊。比如：“可能影响业务”则不够清晰，应说明什么情况下影响业务，是中断业务还是业务质量下降。
描述系统自处理过程，描述系统内部在发生此告故障时是如何处理的。只写对客户有用的信息。比如：描述发生当前故障后，系统进行的一些保护性措施，如进行虚拟机迁移等。如果没有系统自处理过程，可以不写。
可能原因（必选）
发生当前故障的所有可能原因，要分析全面，避免遗漏。每条原因用一句话简短描述，根据可能性从高到低排序。
如果仅有一个原因，则使用p标记直接说明原因； 如果有多个原因，使用无序列表描述，格式如下：
可能原因 1。
可能原因 2。
可能原因 3。
排查思路（可选）
如果当前故障处理过程比较复杂（处理步骤超过15步），且故障通常由多个可能的原因导致（可能原因大于3个），需要逐一进行排查确认时，必需提供处理当前故障时整体的故障排查思路和排查思路说明图。排查思路总体可以分为两类：并列排查和顺序排查。
并列排查：排查步骤根据原因的可能性进行排序，高频原因先排查，排查所有可能原因仍无法解决，再引导用户联系技术支持。
顺序排查：排查步骤按照一定的逻辑顺序排查，或由简单步骤到复杂步骤排查。
【样例】
图 1-1 备份失败排查思路（并列排查）
图 1-2 网站无法访问排查思路（顺序排查）
前提条件（可选）
描述进行具体的故障处理操作前需要完成工作、获取的信息、准备的工具等先决条件。如已获取故障节点的IP地址，登录的账户密码等。
操作步骤（必选）
处理步骤写作原则：
采用step by step方式写作，一个步骤一个动作。步骤要具体、可操作，例如：不能写“检查xx状态是否正常”，要写“执行xx命令检查xx状态是否正常”。
原则上针对每一个可能原因都要给出对应的排查方法和处理方法，直到故障处理结束或者联系技术支持。处理步骤顺序与可能原因顺序一致。
对于多种原因的故障处理，允许步骤跳转，但必须有超链接指明跳转的哪一步。
处理步骤不能太简单，允许部分可能原因没有处理方法，但是不能所有可能原因都没有处理方法；不允许还没排查就直接让联系技术支持处理，原则上步骤不小于3步。
对业务有影响的操作步骤，在操作之前给出警示或者注意。
涉及参数、命令的操作，给出在什么地方或通过什么命令，完成什么事情。
需要等待的步骤，在处理步骤中给出等待的时间。
无法恢复故障，需要联系技术支持时，需要让用户收集故障或日志信息。收集的信息要明确，步骤可执行，下载的日志内容要有说明。
处理步骤中原则上不建议参考其他手册或章节，必须一次性按照处理步骤能够清除该故障，如果故障非常复杂，必须参考其他手册或章节，则按照下述方法处理。
参考其他产品文档的某个章节时，如果该产品资料单独上网，则必须给出“手册名称+章节名称”。
参考本文档附录或者FAQ，该附录或FAQ必须跟单部件的故障处理手册一起打包发布。
【样例】
步骤 1 在Service OM界面，选择“监控 > 告警 > 告警列表”，查看是否有关于重新安装主机的告警。
- 是，执行xx。
- 否，执行xx。
步骤 2 执行以下命令，恢复xx。
nova ext-resize-revert server migration_id
步骤 3 检查xxx。
- 是，处理完毕。
- 否，执行步骤4。
步骤 4 通过xxx方法收集故障信息，联系技术支持处理。
---结束