攻击正在进行的时候，第一目标不是找出对方是谁，而是让业务恢复可用、损失停止扩大。常见的动作包括切换流量、临时关闭受影响的入口、启用备用节点。选择哪一种，取决于当时能不能判断影响范围。
慌乱中最容易做错的是直接重启或者重装。这样做可能让服务恢复，但证据同时消失，后续既无法确认对方是怎么进来的，也无法判断有没有留下后门。
所以处置顺序上，先做能保留现场的动作：记录当前的连接和进程、复制日志、保留可疑文件。这些动作花不了几分钟，却决定了后面能不能查清楚。
影响范围包括技术面和业务面。技术上要确认是单个服务、单台机器，还是整个链路；是数据被读取，还是被篡改，或者只是服务不可用。业务上要确认哪些功能受影响、多少用户受影响、有没有产生费用。
数据是否外泄是最需要判断的一项。可以从访问日志、数据库操作记录、文件下载记录里找线索。确认不了的时候，宁可按照可能泄露来准备后续动作。
同时要判断对方是否还在活动。如果异常请求仍在持续，说明入口还没被堵住，优先处理这一项，其他工作可以并行安排。
判断过程中要有一个人统一协调，避免多人同时改动系统，互相覆盖对方的操作。
恢复的顺序是先堵住入口，再修复受影响的系统。入口没处理干净就恢复服务，很可能马上被再次利用。修复完成之后，用干净的备份或者重新部署来恢复数据，而不是直接用当前状态继续运行。
恢复之后要做验证：功能是否正常、数据是否完整、异常请求是否停止。确认之后才算告一段落，而不是服务能打开就算结束。
通知环节容易被忽略，但它同样影响损失。对用户、合作方和内部相关人员的告知要提前准备好口径，说清楚发生了什么、影响了什么、正在做什么。含糊的说明会带来更多猜测。
如果涉及个人信息或者监管要求，要按流程在时限内处理。这部分工作越早启动越主动。
事件结束之后整理一份完整的时间线：什么时候发现、采取了什么动作、影响范围多大、最后怎么恢复。时间线是复盘的依据，也是对外说明时的材料。
从时间线里找出可以改进的位置：为什么没有更早发现、为什么处置花了这么久、哪些环节依赖某一个人的经验。这些都是下次能变快的地方。
再把这次的处理经验更新到预案里。预案的价值只有在真的用过之后才会提高，靠凭空写出来的流程，执行时往往会发现对不上。
演练也是必要的。半年左右做一次桌面推演，让参与的人知道流程怎么走，真出事时能少几分慌乱。
预案写出来之后，要在平时确认它是否还成立：联系人的电话有没有变、备用节点的配置是否可用、日志的留存时间够不够。这些内容会随着时间失效，不检查就不知道。
把关键动作写成可以照着执行的形式，比如一份明确的检查步骤和命令清单，而不是一段描述。事情发生的时候，照着做比理解一段原则快得多。
角色分工也要明确。谁负责判断、谁负责操作、谁负责对外沟通，提前说清楚，真出事时才不会几个人同时做同一件事。
复盘不是找人担责，而是找出流程中可以更快的地方。发现时间能不能缩短、判断依据能不能更早出现、处置动作能不能并行安排，这些才是值得讨论的问题。
把复盘结论落到具体改动上：加一条监控、改一处配置、补一种记录方式。只讨论不改变，下次遇到同样的问题还是会慢。
处置时最耗时间的往往不是技术动作，而是找东西：登录信息在哪里、联系人是谁、上一次的配置备份存在哪。把这些内容提前整理到一处，注明更新时间和负责人，出事时能省下不少时间。
备份要确认能恢复，而不只是存在。隔一段时间实际还原一次到测试环境，才知道它是否可用。
售后客服
企业微信
