先判断是回滚还是就地修
出事了第一反应别是修，先判断。判断标准很简单：这个故障影响不影响用户正常使用，能不能在几分钟内定位原因。能定位、影响小，就地修；定位不了、影响大，立刻回滚。
还有一种情况必须先回滚再分析：数据已经开始错乱。比如订单金额算错、用户数据被覆盖，这种时候每多跑一分钟就多一批脏数据，回滚要放在第一个动作。
回滚不是认错，是止血。很多人的心理障碍是觉得回滚显得自己没本事，结果硬扛着修了半小时，用户早就走光了。先止血再复盘，这是专业和业余的分界线。
标准回滚动作清单
第零分钟：确认现象。看一眼错误日志、看一眼监控，确认这不是偶发抖动。别因为一个用户报错就全线回滚，也别因为只看到一个报错就忽略。
第一分钟：停掉新版本。如果是代码改动，切回上一个版本的代码。如果有版本管理，这是一条命令的事；手工传文件的那种，就该反思部署方式了。
第二分钟：清缓存。代码回退了但缓存还留着新版的页面，用户看到的还是坏的。这一步最容易漏，漏了就白回滚。
第三分钟：验证。打开首页、打开核心页面、走一遍关键流程。别只看状态码 200 就宣布恢复，要真的点到能用的地方。
第四分钟：看监控回落。错误率、响应时间有没有回到正常水平。指标没回落说明故障不只在这一层，继续往下查。
第五分钟：通知。如果站点有用户群或者公告位，发一条简短说明。用户看到你在处理，比看到页面 500 什么都没说，观感完全不同。
事前该准备好的
部署方式要能一键回退。用 git 部署的，回退是一条命令；用面板上传覆盖的，回退就得重新传一遍，五分钟根本不够。部署方式决定了你的恢复能力，这件事值得花时间改造。
数据库改动必须可逆。改表结构前想清楚怎么改回去，加字段容易回退，删字段和改类型就是不可逆的。涉及不可逆改动的上线，先备份整表。
关键配置要留一份副本。nginx 配置、PHP 配置、站点配置，改之前复制一份带日期的备份。出问题时把备份换回去，比重写一遍快得多。
监控要在故障前就有。事后再想起来看日志，很多信息已经滚掉了。基本的错误告警、可用性监控，是必须提前装好的。
恢复之后的收尾
先确认数据有没有受损。回滚只解决了代码，中途产生的脏数据还在。把故障时间段的请求日志拉出来，逐条确认哪些操作需要补偿或者回退。
再写一份事故记录。什么时间、什么现象、怎么定位、怎么处理、根因是什么、下次怎么避免。这份记录不用给外人看，但一定要写，因为下一次故障往往和这一次同源。
最后把暴露的问题补上。每次故障都会暴露一个流程漏洞：可能是没有备份、可能是没有监控、可能是部署方式太原始。修掉它，别等着下次再踩。
平时就该演练
回滚流程要演练。找一个人少的时段，把一个非核心的改动全量上线，然后故意回滚一次，计时。你会发现真实操作比想象的慢，很多步骤平时没注意。
演练能暴露具体的卡点：权限不够、备份路径不知道、命令记不清。这些在真出事的时候都是致命的，在人少的时候发现就只是练习。
演练完把步骤写成一个清单，放在手边。真出事的时候人的判断力会下降，照着清单走比凭记忆可靠。航空业靠检查单飞了几十年，运维这件事也一样。
最后一个心态上的建议：把故障当成常态来准备。站点跑得越久，出事的概率越接近必然。提前准备好回滚，不是诅咒自己会出事，是承认这件事迟早会来。
几类典型故障的处理差异
页面白屏或者 500。先看错误日志的最后几十行，多数情况能直接看到报错文件名和行号。如果是刚改过的文件，先把它换回旧版本；如果找不到原因，整站回退到上一个版本。
数据库连不上。先确认数据库进程还在不在、磁盘满没满、连接数是不是打满。这三种原因最常见，而且处理方式完全不同：进程挂了重启，磁盘满了清日志，连接数满了要查是谁在泄漏连接。
图片全部打不开。八成是目录权限或者路径规则问题。检查 uploads 目录的属主和权限，检查 nginx 的静态文件规则有没有被改过。这类问题不影响页面打开，但会显得整个站很破。
页面能打开但样式全丢。看 CSS 文件是不是 404，多半是缓存目录被清、或者 CDN 回源失败。这类问题看着吓人，实际影响有限，处理优先级可以排在后面。
和用户沟通的分寸
故障期间要说一句，不要沉默。哪怕只是在页面顶部挂一条正在维护的提示，用户知道你在处理，就不会直接判定这是个废站。
说明要简短。别在故障中写长篇解释，用户不关心技术细节，只关心什么时候能用。一句话加一个预计时间就够。
恢复后可以补一句说明。如果故障持续了比较久，恢复后简单说清楚原因和处理结果，这份坦诚会换来信任。什么都不说反而让人怀疑你根本不知道出了什么事。
把预案变成肌肉记忆
预案写在文档里没人看，要写成能直接执行的清单。每一步做什么、在哪个目录、用哪条命令，写清楚到不需要思考的程度。
关键命令做成脚本。回退代码、清缓存、重启服务，这几个动作合成一个脚本，一条命令执行完。真出事的时候少敲一条命令就少一次出错的机会。
定期看一眼脚本还能不能用。路径变了、服务名改了，脚本就失效了。半年检查一次，比出事时发现脚本跑不通要好。
