上周三下午4点17分，我经历了第3次线上事故
上周三下午4点17分，我正在改一个周四要交的PPT，企业微信突然弹了17条消息。点开一看，运营在群里喊“下单全挂了”，客服截图显示用户点支付一直转圈。我当时脑子嗡一下，第一反应是找运维老张，结果他电话占线——后来才知道他在另一个楼开会。我们团队一共8个人，负责一个日订单量大概2.3万的电商后台，没有专职SRE。这就是我第一次真正意识到：网上那些“应急响应SOP”放到小团队就是废纸。
对比大厂SOP：我们缺的不是流程，是信息降噪
我上一家公司是某二线互联网公司，故障处理有标准流程：P1事故5分钟内拉电话会，值班长建群，各模块负责人报状态，15分钟出第一次通报。到了现在这家创业公司，我照搬过那套，结果更乱——8个人拉了5个群，每个人都在@别人，消息刷屏，真正有用的信息被淹了。那次我们花了47分钟才定位到是第三方支付回调超时，阈值设的是3秒，而对方那天的平均响应到了8.2秒。后来我总结，突发状况下最稀缺的不是预案，是“信息降噪”：先砍掉无关群，只留一个3人决策群，一个技术执行群。
我自己的处理步骤（别照抄，按你们人数改）
第一步，先别急着定位，花30秒确认影响面。我们那次看监控：错误码500占比从0.3%飙到12%，QPS从3000掉到200，影响的是下单环节，支付和浏览正常。第二步，拉群只拉3个人：我、运维老张、后端小李。群里只发三种信息：现象、时间、谁在做什么。第三步，用最笨的办法——回滚。我们上一次发布是2小时前，直接回滚到上一个版本，4分30秒后错误率降到1%以下。第四步，事后写“反预案”：不是写“应该怎么做”，而是写“当时哪一步卡住了”。比如我们那次卡在“不知道第三方支付回调超时阈值在哪改”，后来把配置项路径贴在群公告。
一个反直觉的观点：突发状况暴露的不是能力，是协作断层
我复盘了三次事故：第一次是数据库连接池被打满（开发忘了改最大连接数，默认10），第二次是CDN证书过期（没人设提醒），第三次就是支付回调超时。三次都不是什么高深技术问题，但每次都有人问“这个谁负责”。我现在的做法是，每季度做一次“盲演”：不通知，随机挑一个服务，模拟挂掉，看谁先发现、谁先拉群、谁先说话。第一次演的时候，8个人里5个在等别人动。这比任何预案都真实。另外，别迷信“故障复盘会”，我们改成“故障回放”：把当时的聊天记录投屏，逐条看谁说了废话。
给同样小团队的三条土办法
第一，把“找谁”变成“找群”。我们建了一个只有8个人的“救火群”，置顶消息是：先发现象，再发截图，别发“在吗”。第二，每个服务必须有一个“回滚开关”，能在2分钟内操作，别管优雅不优雅。第三，事故结束后24小时内，把根因写成一句人话，贴到群公告，比如“支付回调超时是因为对方响应8.2秒，我们阈值3秒”。别写“加强监控”这种废话。