那次宕机事故，让我在公司年中会上被点名。那天上午十点，支付系统再次中断，客户投诉暴增，CEO直接拨通我电话，只问了一句：“这个问题上次不是解决了吗？”我一时语塞。是的，三个月前，我们刚因为同样的数据库连接错误停过一次服务。当时我们加了监控、优化了脚本，所有人都觉得问题解决了，可显然，我们只是治了“症”，没治“病”。
事故恢复后，我在办公室坐了很久。不是因为技术没搞明白，而是因为我终于意识到：我们根本没有真正的问题管理机制。每次出事，大家忙着抢修、写报告、关工单，却没人问“为什么会发生”。那种循环让我想起一个词——救火文化。救火时所有人都英勇，灭完火大家都松口气，然后继续等下一次火警。我们似乎把“能快速修复”当成能力，却忘了“让故障不再发生”才是成熟。
我召集团队开了一场不太愉快的会议。有人说：“我们已经很努力了。”我点头：“没错，但努力不代表有效。”有经验的同事提醒：“问题太多，追根太慢。”我回答：“那是因为我们还没建立追根的机制。”这次我决定彻底改变处理方式。
过去我们处理事件的方式非常标准：告警、确认、分派、解决、关闭。但在ITSS框架里，事件只是表象，问题才是根源。事件管理关注的是“服务尽快恢复”，而问题管理关注的是“如何防止重演”。这两者的逻辑不同，思维也不同。前者是短跑，后者是长跑。可惜，我们的组织文化一直更喜欢短跑——快、有成就感、立竿见影；没人愿意花时间复盘，因为复盘看起来“不生产结果”。
我让团队回顾过去六个月的重大事件记录。结果发现，58%的重大事件都与重复性问题有关；其中70%的重复问题没有对应的根因分析报告。我们只是简单写了“已修复”“脚本优化”，但从未验证问题是否真的根除。更糟的是，很多事件的初步处理方案被当成“标准解法”，下次再遇到同类问题，大家直接照搬。这种“习惯性修复”反而让系统陷入更大的风险。
我那时突然理解了ITSS提出问题管理的意义：它不是为了做文档，而是为了让组织从“解决问题”走向“理解问题”。我们开始按照ITSS的五步问题管理流程重新构建体系：问题识别、根因分析、临时解决、永久修复和持续改进。每一步都要求有证据、有复盘、有归档。听起来繁琐，但那正是区别于“经验主义”的地方。
本文由艾拓先锋ITSS官方授权认证培训讲师熊健淞原创，未经许可谢绝转载。我在授课时常举这个案例告诉学员——问题管理并不是锦上添花的补充，而是体系化运维的灵魂。如果你每次事故后都只想着“恢复”，那你永远在做被动工作；但如果你学会追问“为什么”，你就踏上了改进之路。
我们决定先选一个典型问题来验证新流程。那是支付系统的连接中断问题。以往我们总认为是网络波动造成的，但这次我让工程师逐层分析，从数据库日志到中间件队列，再到后端服务。结果发现，根因竟是负载均衡器的连接数阈值被误配置。那次发现震惊了所有人，因为这个配置参数在两年前系统上线时就设错了，而那次“偶发性宕机”，其实早就有迹可循。
这次之后，我们引入了“问题复盘会”。每次重大问题解决后，由问题经理主持会议，邀请相关技术人员、业务代表和质量团队参与。会议上必须回答三个问题：第一，问题为什么发生？第二，为什么没有提前发现？第三，怎样保证不再重演？没有数据支撑的解释不算答案，没有行动计划的问题不算结束。刚开始，大家觉得太严格，但几次之后，会议成了大家最期待的时刻，因为每次复盘，都会有新的学习和洞见。
接着我们建立了“问题登记系统”。任何一次重复性故障或潜在风险都要录入系统，系统自动关联相关事件和变更。通过数据聚类分析，我们能看出哪些问题类型最频繁、哪些模块最脆弱。一个季度后，我们发布了第一份“问题热力图”，上面清楚地标出问题集中区——网络设备、存储性能、应用接口。这张图成为后来预算申请的关键依据。
真正让团队转变的，是“预防”两个字。过去大家等事故发生再反应，现在他们学会提前识别“潜在问题”。我们建立了一个每月一次的“问题预测例会”，所有事件经理汇报最近趋势，分析潜在风险。那种会议的气氛完全不同，大家不是在追责，而是在思考“下一步怎么不出错”。
我记得有一次，开发团队提出新版本上线计划。以前我们只是审查测试报告，这次我要求他们在上线前提交“潜在问题清单”。他们列出了五个风险点，其中一个是缓存同步机制。于是我们提前部署了验证脚本。结果上线当天，脚本果然捕捉到异常，我们在用户未感知前就修复完成。那天我在报告上写了一句：“问题管理的最高境界，不是复盘事故，而是预见事故。”
问题管理改变的不只是流程，更是心态。过去我们的文化是“出了问题，赶紧修”；现在变成了“有问题，赶紧学”。我常说，成熟的团队不是没有问题，而是从问题中变聪明。真正可怕的不是错误，而是同一个错误反复发生。
半年后，我们统计数据：重复性故障减少了68%，平均恢复时间缩短了40%，知识库新增问题案例142条，团队满意度提高到92%。这些数字固然重要，但更让我欣慰的是一种无声的转变——没人再把问题当负担，大家开始把问题当素材，当老师。每一次故障，都是一次成长。
成熟的组织，学会把问题当老师。
