旅宿的网站突然无法显示。按下预订按钮也无法继续。WordPress管理画面出现「严重错误」——营业期间遇到这些情况，急着修好的心情容易让人接连尝试更新、重新启动和停用插件。
然而，故障刚发生时，重要的并不只有修复速度。先维持与有意住宿的客人之间的联系、记录症状并防止进一步损害，再交由相关人员调查原因，才是关键。
本文依时间顺序说明，不熟悉IT的旅宿经营者如何使用Codex或Claude Code作为辅助，在最初30分钟进行初步应急响应。
结论：最初30分钟要「维持营业、记录、停止、联系」
故障应急响应的优先级如下。
0〜5分钟 确保预订、咨询的替代渠道
5〜10分钟 记录症状及发生时间
10〜20分钟 停止追加变更，确认影响范围
20〜30分钟 将必要信息交给负责人，决定恢复方针
这不代表必须在这30分钟内恢复服务。目标是避免因慌张而增加问题，让维护人员能安全调查。
0〜5分钟：维持预订、咨询的入口
首先要确认的不是WordPress管理画面，而是客人是否能与旅宿联系。
- 电话是否接得通
- OTA上的旅宿页面与预订受理是否正常
- 自家预订系统是否能独立于WordPress打开
- 是否能通过官方SNS发布通知
- 是否能联系已有预订的客人
如果只有WordPress停止运作，而OTA或外部预订系统仍正常，可以暂时引导客人使用这些预订渠道。反之，若预订系统或付款也停止，不要凭推测告知空房或价格，应改成先通过电话受理、确认后再回电的做法。
暂时通知示例
目前官方网站显示发生异常。
预订及咨询暂请使用［电话号码／目前可用的预订渠道］。
恢复情况将在本通知更新。
原因、预计恢复时间、是否有个人信息外泄，都不能在确认前断言。在尚无依据时，也不要使用「网络攻击」「数据丢失」等措辞。
5〜10分钟：记录画面与时间
故障画面是调查原因的线索。请在重新加载或变更设置导致画面消失前记录。
要记录的内容
- 发现日期与时间
- 发生问题的URL
- 使用的是电脑或智能手机
- 确认时使用的网络，例如Wi-Fi或移动网络
- 画面上的简短错误消息及编号
- 登录与退出登录状态的差异
- 刚才进行的更新或设置变更
- 最后一次正常运作的日期与时间
- 预订、咨询及管理画面的状态
屏幕截图可能包含管理画面URL、用户名、电子邮件地址、预订编号、浏览器标签页等。在交给外部人员或AI之前，只裁切必要部分，并遮蔽秘密信息和个人信息。
使用另一部设备也只确认一次
厘清问题只发生在自己的浏览器，还是一般客人也会遇到。
- 使用无痕窗口打开
- 使用智能手机的移动网络打开
- 直接打开发生问题的URL
反复提交表单或进行预订操作，可能产生重复咨询或暂时预订。功能测试应先确认方法再进行。
10〜20分钟：停止追加变更，区分影响范围
以下操作先暂停。
- 追加更新WordPress、主题或插件
- 一次停用所有插件
- 切换正式网站的主题
- 修复、替换或还原数据库
- 重新启动服务器
- 同时清除缓存和变更设置
- 只为隐藏错误而新增代码
- 删除旧备份或日志
若有已开始的作业，请记录「做了什么」「何时」「从哪个画面」执行。某些处理中途强制停止会引起其他问题，因此要将目前状态告知维护人员。
将影响范围分成四个阶段
| 阶段 | 示例 | 初步应急响应的思考方式 |
|---|---|---|
| 部分显示 | 只有图片或装饰版面异常 | 记录并确认预订动线，再进行调查 |
| 部分功能 | 预订、表单或菜单无法运作 | 告知替代渠道，优先调查 |
| 整个网站 | 白画面、严重错误、500等 | 停止追加变更，联系负责人 |
| 多个服务 | 电子邮件、预订及服务器也停止 | 包括服务商的故障信息在内，紧急联系 |
若是外观版面异常，可以接着参考主题、插件与缓存的问题排查。整个网站停止时，不要直接认定只是显示问题。
20〜30分钟：决定将什么信息交给谁
使用的服务器服务不同，联系对象也不同。
虚拟主机、托管式WordPress
- 确认主机服务商的故障及维护信息
- 联系管理画面的客服窗口
- 确认合同持有人及支持范围
- 确认是否提供还原服务，以及可还原至哪个时间点
VPS、云端
- 联系WordPress维护人员或服务器管理员
- 以只读方式确认服务器、Web、PHP及数据库的运作状态
- 重新启动或还原前，决定影响范围及回滚方法
- 确认对预订、电子邮件等同机服务的影响
主机服务商可能不支持WordPress内部修正，而网站制作公司可能无法访问主机服务账号。平时就记录各方负责范围很重要。
什么是WordPress的恢复模式
WordPress在检测到主题或插件等造成致命PHP错误时，有时会将恢复模式链接寄到管理员邮箱。这是一种通过特殊管理会话确认问题组件的机制。
收到邮件后，请确认以下内容。
- 收件地址是否为WordPress登记的管理员邮箱
- URL的域名是否为自己的网站
- 是否没有可疑附件
- 画面列出的主题、插件名称
恢复模式不是所有故障都会启动，也不是永久修复。不要因为没收到邮件，就慌忙变更管理员地址，或从搜索结果打开可疑链接。请向主机服务商或维护人员咨询。
交给AI的是状况整理与安全调查计划
AI在初步应急响应时能协助以下工作。
- 将记录内容整理成时间轴
- 列出受影响的URL与功能
- 建立不变更正式环境的确认项目
- 对比更新记录与发生时间
- 根据错误消息寻找应查阅的官方资料
- 撰写给主机服务商、维护人员的咨询内容
- 建立恢复后的检查清单
- 建立故障记录模板
另一方面，不要在故障刚发生时，把重新启动、数据库还原、停用全部插件、权限变更或删除文件全权交给AI。
可复制使用的初步应急响应提示词
最初的状况整理
旅宿的WordPress发生故障。请先不要修正。
发现日期与时间: ［日期与时间］
发生问题的URL: ［URL］
症状: ［简短错误消息、显示状态］
刚才的作业: ［更新或设置变更］
目前可用的预订渠道: ［电话、OTA等］
一开始只进行只读调查及状况整理，
请区分营业影响、已确认事实、可能原因、未确认事项，
以及接下来需要由人确认的项目。
请不要执行更新、停用、重新启动、还原、删除或设置变更。
撰写给客服的咨询内容
请针对以下WordPress故障，撰写要寄给主机服务商或维护人员的
咨询内容。
［发生日期与时间、URL、症状、刚才的变更、确认设备、受影响功能、已完成的确认］
不要断定原因，请简洁说明紧急程度及希望确认的内容。
不要包含密码、私钥、内部路径、顾客或预订信息。
比较恢复方案
通过只读调查，已确认以下事实。
［已确认的事实］
请先不要执行。
请比较修正、暂时停用组件、回滚旧版及从备份还原的
影响范围、可能丢失的数据、所需时间、恢复原状的方法，
以及恢复后的确认。
请明确指出需要由人批准的操作。
不要急着决定是修复还是还原
回到故障前状态的方法有多种。
- 只回滚有问题的设置
- 将更新过的主题、插件回滚至已验证版本
- 暂时停用造成问题的组件
- 只回滚文件
- 从备份还原，包括数据库
若将整个数据库还原到较早时间点，备份取得后的文章、咨询、预订及设置可能丢失。先确认哪里损坏、需要回滚到什么范围。备份状态也可参考还原演练文章。
恢复后要确认的事项
不要只因「首页打得开」就结束。
- 电脑与智能手机都能打开主要页面
- 预订按钮及外部预订目的地正确
- 价格、方案及空房信息正确
- 已安全确认咨询表单
- 合法管理员能登录管理画面
- 图片、CSS及JavaScript没有缺漏
- 已确认邮件寄送正常
- 监控及备份已重新开始
- 暂时通知已更新为恢复通知
- 已记录原因、处理、所需时间及防止再次发生的措施
更新前后的画面对比可使用Playwright自动对比。
平时准备的「故障应急卡」
为避免故障时四处寻找信息，请将以下内容整理在纸上或安全的共用位置。
- 公开网站与预订页面的URL
- 电话、OTA、SNS等替代联系方式
- 主机服务商与合同持有人
- WordPress维护、网站制作及预订系统的联系方式
- 哪些人能发布暂时通知
- 最后一份已验证备份的确认方法
- 故障记录的存储位置
- 能批准重新启动、还原及删除的人员
不要将密码或私钥直接写在卡片上，只记载如何前往组织指定的安全管理位置。
旅宿经营者检查清单
- [ ] 已确认电话、OTA等替代预订渠道
- [ ] 已发布给客人的暂时通知
- [ ] 已记录发生时间、URL及画面
- [ ] 已使用另一部设备、另一种网络确认一次
- [ ] 已停止追加更新及临时拼凑的修正
- [ ] 已区分显示、预订、电子邮件及管理画面的影响
- [ ] 已联系主机服务商或维护人员
- [ ] 已先请AI进行只读调查
- [ ] 还原前已确认可能丢失的数据
- [ ] 恢复后已由人确认预订及咨询
参考的官方信息
总结
WordPress故障后的最初30分钟，不是盲目修复的时间。这段时间应维持客人的预订与咨询渠道，记录症状、停止追加变更，并将信息交给适当的负责人。
AI能协助整理时间轴、分类影响范围、撰写咨询内容及建立确认表。旅宿经营者负责营业优先级、对外通知、变更批准，以及价格与预订的最后确认。平时先确定这些分工，发生故障时就比较不会困惑于「该从哪里开始」。
