问题的定义

Problem is an issue that could cause an incident.

相比较于事故（Incident），问题描述的是一种可能产生事故的概率，是一种对于已知风险的量化表达。问题并不需要总是用来代表技术性的缺陷（如代码Bug），问题也不应该用来代表RCA的过程（Root Cause Analysis），而应该仅在RCA或Post Mortem完成后，记录和跟踪风险及风险的后续的修复或补偿措施。

问题的定级

基于问题的定义，因为问题是描述可能产生事故的风险，可以很容易理解问题定级的两个参考维度：

• 对应类型事故，有多大的可能产生？高频？低频？（Probability）
• 如果产生了该类型的事故，这个事故的影响有多大？（对应事故的定级，在问题中，描述为Criticality）

结合这两个维度，得出问题定级的矩阵（Matrix）。

经典风险管理理论中，风险的量化表达 = 风险的概率 * 风险的损失 * 时间跨度。因此，实质的风险在ITSM中可描述为 问题的定级（风险的概率 * 风险的损失） * 时间。

问题的定级约高，意味着相同的风险暴露时间内，对应的损伤相对企业来说约大，因此问题责任方有义务在更快的时间内修复或补偿该问题。定级约高，要求修复的时间应约快。而实际上，在此公式中，{问题的定级（风险的概率 * 风险的损失） * 时间} 对应的量化，应随着企业的整体风险偏好**（Risk appetite）**做调整——企业在某个阶段的风险偏好低，那么同样等级的问题要求的修复时效应该约低，反之亦然。

问题的降级

定级问题的修复往往随着问题的复杂度，修复难度，和修复问题所产生的其他风险，对应了“修复成本”，“修复时间”和现实情况的冲突。很多时候，对于已完成根因分析的问题（Known Issue），是存在经过验证的补偿性措施（Workaround）可以通过降低：

• 事故发生的概率（Probability）
• 事故发生的影响（Criticality）

中的一种，或两种同时，来降低问题对应的风险实质的敞口。基于补偿性措施就绪后，问题的实质性风险降低，通过重新的定级（一般是降级）后可获得对应的更长的修复时效，甚至无需修复（见后章节）。

例子：

• 对于某些内存泄漏问题（Memory Leak Caused Out Of Memory），在永久修复前，通过运维团队定期的重启服务器，可极大降低实际问题发生的概率。
• 对于某些程序缺陷造成的业务功能影响，在永久修复前，每次发生后通过固定的数据变更补丁，快速修复问题（降低MTTR），实际降低了事故发生的业务影响。实际操作上，一般会对这类补丁做一次性测试，纳入应急手册中，后续发生后无需经过开发团队，运维直接发起数据变更修复，对应MTTR较低。

问题的修复的要求

一般来说，对于企业的风险管理的角度，并不要求绝对的0风险。只有在风险敞口大于企业风险偏好的情况下，该风险应要求进行控制。问题的控制（Mitigation）可能是：

• 修复：即该风险完全消除
• 临时补偿（Workaround）：低成本的快速上线补偿性措施，问题降级，直到问题进入终态
• 无需修复：当修复成本大于风险带来的损失，或补偿性措施就绪后，风险降低到企业可以承担的风险偏好内，问题可认定为无需修复。

不是所有的问题都是需要永久修复的，因为不是所有的风险，都是能够被完全消除的。

问题的识别

为确保科技部门内的风险，能够有效的进入问题管理的流程，问题管理的一般实践会明确定义问题入口，即识别过程且部分识别过程是强制的。

• 重大生产事故必须进入问题管理的流程
• 问题管理经理可能分析历史事故（低级别），对高频事故提起问题甄别。
• 其他入口，如科技团队上报，经问题经理审批后，进入问题甄别。

具体方法论参考：

问题管理的有效性前提

• 严格制度：将公平合理的流程落入制度，明确问题归属和责任人。确保识别的问题在有效约束的工作流程内被控制和有效闭环的生命周期。
• 问题治理：由于问题的本质等同于一类科技风险，优秀的问题管理应该将开口问题纳入企业风险管理指标内，同时将问题关闭的时效，纳入对应团队的正向考核指标。