从一场崩溃开始

上个月底，我们负责的客户服务平台突然出现连续三小时宕机。问题本身并不复杂——数据库连接池耗尽，但排查过程却花了将近两个小时。事后复盘时，大家才发现，早在系统告警触发前40分钟，已经有三条低级别日志提示连接回收异常，只是没人注意到。

这已经不是第一次因为‘信息淹没’导致响应延迟了。我们团队六个人，日常要盯五六个监控工具、三个工单系统和一个内部Wiki。每天早上10点的站会，名义上是同步进展，实际上变成了轮流念‘我昨天做了什么’的汇报表演。真正紧急的问题反而被埋在了口头陈述的缝隙里。

异常不是任务，它需要不同的处理逻辑

我们意识到，传统任务管理那一套——比如看板上的‘待办/进行中/完成’——对突发性、非计划内的异常处理几乎无效。一个bug修复可以拆成子任务排进迭代，但服务器内存泄漏不会等你开完晨会才发生。

于是我们尝试引入一种叫‘异常优先级标签’（Incident Priority Tag, IPT）的轻量机制。核心思路很简单：所有异常事件不进入任务流，而是打上动态标签，通过标签聚合暴露真实瓶颈。

具体做法是：

1. 定义四级标签：

   • P0-熔断：影响核心功能，需立即中断当前工作处理
   • P1-阻塞：影响部分用户，需在1小时内响应
   • P2-降级：功能可用但性能下降，需在当日跟进
   • P3-观测：潜在风险，记录并观察趋势

2. 标签附着于原始事件：无论是Zabbix告警、Sentry错误日志，还是客户反馈邮件，我们都用统一格式在标题前加标签，比如 [P1-阻塞] 支付网关超时率突增至12%。

   

3. 每日早间自动聚合：写了个小脚本，凌晨6点抓取过去24小时所有带IPT的记录，生成一份极简摘要，只包含三类信息：

   • 新增P0/P1数量
   • 持续超过24小时未降级的P2
   • 同一类型P3出现≥3次

这份摘要直接发到企业微信的专用频道，禁止回复，禁止讨论。它的唯一作用是让每个人睁眼就能看到‘真实的火情地图’。

站会消失了，但沟通反而变多了

最意外的变化是，我们取消了每日站会。起初担心会失去协作感，结果发现，原来站会上80%的时间都在解释‘为什么还没修那个bug’，而现在，P0/P1的处理状态直接体现在标签流转中。

比如，当某条[P0-熔断]被处理后，负责人只需在原消息后追加一句 [P0→P2] 连接池扩容完成，观察中，所有人 instantly get it。更妙的是，那些原本可能被忽略的P3标签，经过几次自动汇总后，我们发现了定时任务调度器的隐性内存泄漏——这个隐患按旧流程至少还要两个月才会浮出水面。

工具的选择：为什么不自己开发？

有人问为什么不直接用Jira或飞书项目来做这套标签体系。试过，但太重。Jira每建一个‘异常’都要填项目、模块、负责人、截止日……可很多异常连原因都没定位，强制结构化反而制造了录入负担。

后来我们用了蓝点通用管理系统，主要是看中它的两个特性：

• 完全自定义数据结构：我们搭了一个极简的‘异常日志’表单，只有字段：来源系统、原始信息链接、IPT标签、处理人、状态变更记录。没有多余字段。
• 支持外部触发更新：通过Webhook，Zabbix告警可以直接生成带P2标签的记录，Sentry错误自动关联对应标签等级，避免人工转录。

最关键的是，它不像传统OA那样要求‘完整流程闭环’。我们的异常记录允许长期停留在‘观测’状态，不关闭、不归档，像一块持续显示压力的仪表盘。

有次产品经理想把这套机制推广到需求管理，我们坚决拒绝了。不是所有事都该被管理成同一种形状。需求需要评审、排期、验收；而异常需要快速标记、暴露、遗忘（处理完就不再打扰）。混在一起只会互相污染。

标签会撒谎吗？

当然。曾有个实习生把所有告警都标成P2，理由是‘不想被半夜叫起来’。我们也遇到过两个资深工程师对同一事件是否算P1争执不下。

于是加了一条潜规则：任何人可在24小时内对标签提出‘挑战’，发起者需在15分钟内回应解释，否则自动降一级。这条规则没写进文档，但成了团队默契。比起权威裁定，我们更相信短平快的校准机制。

现在，每周一上午我们会花20分钟看一张图：过去七天IPT分布热力图。颜色越深代表同类异常越集中。上个月最深的一块是蓝色（P2），指向文件上传服务的临时目录清理机制——它从未触发过P0，但每月默默消耗运维两小时人工干预。这张图说服了技术主管批准重构，比写十页故障报告都管用。

它甚至改变了我们的休假文化

以前谁休假都得留个联系方式，生怕出事。现在只要确保休假期间没有P0标签落在自己负责的系统上就行。有位同事去西藏徒步两周，全程无信号，回来发现系统打了七个P3标签，但无人升级为P1以上，他知道：这套机制真的扛住了不确定性。