一个群里同时装故障、缺陷和咨询，最后的结果通常只有两种：所有事都按最急的处理，技术被问答拖死；或者所有事都按最慢的排，闸机停了半天没人接。分开计之前得先分开判，判的标准不能是感觉，要能一句话判掉。

一、故障按小时计，判定权放在现场值班人手里。定义写成能被直接判掉的形式：只要出现通行受阻、出票受阻、日结出不来三类之一，就按故障走，不需要先找原因。影响单个通道和全场不通的等级不同，响应从约定小时数起算，计时起点是现场在工单里点了报障的那一刻，不是在群里发消息的那一刻。故障期间现场必须有临时降级动作：改用手持检票机人工核验、窗口按离线方式出票、单通道双向放行，这三条要贴在应急卡片上。

二、缺陷按版本排，判定人必须是双方各一个技术接口人。能复现、不影响当天营业、需要改代码才能好的，归缺陷。留痕三件：复现步骤、发生频次、日志包。是频次决定它排在哪个版本，不是谁嗓门大。要防的是把缺陷临时当故障处理——用配置绕过去掩盖了问题，同一个位置下一个旺季还会再出一次，而且更难查。

三、咨询按工单走，答复口径要有人负责。问"这个字段在哪""这样配行不行""报表能不能多一列"，都属咨询，判据是现有功能仍然可用。当天给答复、给一条可执行的操作路径就闭环，不做代码改动。一旦确认是缺陷，就转缺陷单重新计时，不沿用最初报障的时间点，否则一个问了两天的咨询会把缺陷的排期也拖乱。

四、三类各有升级路径，而且升级要落到具体人。故障超过约定响应仍未到场、或未给出可用的临时方案，自动升到项目负责人，同时通知现场值班负责人；缺陷连续两个版本未处理且频次上升，升到需求评审；咨询超过约定时限无人应答，转缺陷流程判定性质。升级路径要写出责任人姓名和联系方式，只写"升级到上级"等于没写，真出事时没人认领。

五、混在一个群里会出四件事。一是没有计时起点，事后争"到底什么时候报的"；二是漏单，消息被顶下去就再没人登记；三是口头改需求，一次咨询变成一次没经过评审的功能改动；四是无法统计，年底看不出问题集中在哪一类、哪个模块。分开计不是为了走形式，是为了让每一类各有各的起止时间和各自的留痕位置。

六、私有化部署下，边界要提前讲明白。现场自己就能做的动作——重启服务、切备用通道、清缓存、导出日志——要有一页清单和授权范围；需要远程接入处理的，必须经现场授权，留下接入时间段和操作记录。一次部署、终身使用的模式下这条边界最容易松，一松，真出问题时就变成两边各等对方先动手。

三类各留一张表：故障单看响应与恢复时间，缺陷单看排入的版本与复现次数，咨询单看答复时限以及是否转成了前两类。年底回看三张表的分布，才知道这套系统在自己这里到底欠在哪一处，明年的整改顺序也就有了依据。