工作突发状况怎么处理？先别急着当英雄

2023年4月18日周二，上午10:07，我们公司40多人的SaaS团队，企业微信突然弹出客户群消息：后台打不开，登录转圈。 我当时负责运营，不是技术，但客户第一个@的是我。 十分钟内，销售、客服、老板都在问“多久能好”。 我后来复盘，发现真正拖慢我们的不是故障本身，而是没人知道谁该拍板、谁该对外说话、谁去拉日志。 那天我们用了2小时17分才恢复，事后看，如果先做分级，至少能省40分钟。

我的独立观点：处理突发，核心不是解决，是降级

很多教程一上来就讲“冷静、沟通、复盘”，太正确了，正确到没用。 我的观点是：突发状况处理的核心不是“解决”，而是“降级”。 把P0降成P1，把“全网挂了”降成“部分用户登录失败”，把“老板要追责”降成“先恢复再算账”。 怎么降？先定分级：P0=核心业务不可用，5分钟内拉群，15分钟内指定事故指挥官，30分钟给第一次对外口径；P1=主要功能受损，30分钟响应，2小时内给方案；P2=个别客户/非核心，当天处理；P3=记录，排期。 别小看这几个数字，PagerDuty、Google SRE 都强调 incident command，不是让最懂技术的人一边修一边回消息。

真实场景对比：线上宕机 vs 汇报前文件损坏

真实场景里，最常遇到的不是线上宕机，而是“汇报前30分钟，PPT打不开”“客户提前到，主讲人堵在路上”“同事离职，文件密码没人知道”。 我遇到过一次：周五下午4点，老板说明天给投资人讲，让我把Q2数据更新进一份87页的腾讯文档。 结果共享链接被误设成“仅指定人可编辑”，我只有查看权限。 当时我干了三件事：第一，用企业微信语音找文档所有者，同时发短信，别只发微信；第二，从历史版本里导出PDF，先保证能看；第三，把关键12页数据复制到新文档，重新做目录。 18:40搞定。后来我强制团队：所有关键文件必须有一份在飞书/钉钉知识库，命名带YYYYMMDD，权限至少两个负责人，重要文档开自动保存和版本历史。

救火型团队和防火型团队，差的不只是流程

对比一下“救火型团队”和“防火型团队”。 救火型：出事先骂人，群里30个人，19个在问“好了没”，最后靠一个技术半夜修好，第二天发个红包，下次继续。 防火型：有值班表，有升级路径，有status page（内部也行），有error budget。 Google SRE 那套 error budget 说白了就是：如果99.9%可用性目标，每月只能坏43分12秒，坏超了就冻结新功能，先还债。 小团队不用照搬，但可以抄三个动作：1）把“谁联系谁”写在在线表格，每季度更新；2）每起P0/P1都做RCA，48小时内交，不追责，只追改进项；3）用5 Whys问到底，但别问成“为什么你粗心”，要问“为什么流程允许这个错误发生”。

我自用的突发30分钟清单，直接抄

最后给一个我自用的“突发30分钟清单”。 0-5分钟：确认影响面，拉一个5-8人小群，别拉30人；指定三个人——指挥官、技术处理、对外沟通。 5-15分钟：能回滚先回滚，能降级先降级，别追求完美修复；写第一版对外话术，模板：我们注意到X问题，影响Y，正在处理，下次更新Z时间。 15-30分钟：如果还没恢复，升级，叫上更懂的人，同时准备备用方案。 30分钟后：每30分钟同步一次，别让老板在群里猜。 恢复后：24小时内写时间线，48小时内出RCA，7天内把改进项排进迭代。 工具上，PagerDuty适合有值班的团队，小团队用企业微信/飞书+腾讯文档也能跑；备份记住3-2-1：3份数据，2种介质，1份异地。 别等出事才收藏，先存下来。