事故期间的只读模式：保留读取，阻止写入

当数据库压力大时，什么最先出问题

当数据库过载时，用户很少看到干净的“宕机”提示。更多的是超时、页面只加载到一半、按钮一直转圈、以及操作有时成功有时失败。一次保存可能成功，下一次就报错说“出了点问题”。这种不确定性让事故显得混乱。

通常首先受影响的是写入密集的路径：编辑记录、结账流程、表单提交、后台更新，以及任何需要事务和锁的操作。在压力下，写入变慢并互相阻塞，也可能通过持有锁或触发更多工作来拖慢读取。

随机错误比可控的限制更糟，因为用户不知道下一步该怎么做。他们会重试、刷新、重复点击，进而产生更多负载。支持工单暴增，因为系统看起来“有点能用”，但没人相信它。

只读模式在事故期间的目的不是追求完美，而是保留最重要的功能：查看关键记录、搜索、检查状态和下载用户继续工作的资料。你有意停止或延迟有风险的操作（写入），以便数据库恢复并保持剩余读取的响应性。

要明确预期。这只是临时限制，并不意味着数据被删除。在大多数情况下，用户现有的数据仍然安全——系统只是暂停更改，直到数据库恢复健康。

只读模式到底意味着什么

事故期间的只读模式是一个临时状态，产品在该状态下仍可用于查看，但会拒绝任何会改变数据的操作。目标很简单：在保护数据库的同时保持服务的可用价值。

通俗地说，人们仍然可以查找信息，但不能执行会触发写入的更改。通常这意味着浏览页面、搜索、筛选和打开记录仍然可用。保存表单、编辑设置、发布评论、上传文件或创建新账户会被阻止。

一个实用的判断方式是：如果某个操作会更新一行、创建一行、删除一行或写入队列，那就不允许。许多团队还会阻止“隐藏的写入”，比如存主数据库的分析事件、同步写入的审计日志以及“最后在线”时间戳。

当读取大致可用但写入延迟上升、锁争用变多或写入密集的积压拖慢一切时，只读模式是正确的选择。

当连基础读取都超时、缓存无法提供必要数据或系统无法可靠告知用户当前安全操作时，就应完全离线（下线）。

为什么这有用：写操作通常比简单读取成本高得多。写入可能触发索引、约束、锁以及后续查询。阻止写入还可以防止重试风暴，客户端不断重提交失败的保存操作会放大损害。

示例：在 CRM 事故期间，用户仍能搜索账户、打开联系人详情和查看近期交易，但“编辑”“创建”和“导入”等操作被禁用，任何保存请求都会立即以明确的信息被拒绝。

选定必须保留的读取和需要停止的写入

切换到只读模式时，目标不是“所有功能都可用”。目标是让最重要的界面仍能加载，而任何会增加数据库压力的操作都能快速且安全地停止。

先列出在糟糕情况下仍必须可用的少数用户操作。这些通常是能够解锁决策的小型读取：查看最新记录、检查状态、搜索短列表或下载已缓存的报告。

然后决定哪些可以暂停而不会造成重大伤害。大多数写入路径在事故期间属于“可有可无”：编辑、批量更新、导入、评论、附件、分析事件以及任何会触发额外查询的操作。

一个简单的分类方法是把操作分成三类：

• 必须保留：小、快速的读取，能够立即帮助用户决策
• 可暂停：增加负载或锁行的写入和重型读取
• 可降级：可以展示缓存数据或部分视图的功能

还要设定时间范围。如果预计是几分钟，可以严格阻止几乎所有写入。如果预计是几小时，考虑允许一小类安全写入（比如密码重设或关键状态更新），并将其他写入排队。

及早达成优先级共识：安全优于完整性。展示清晰的“更改已暂停”信息，比允许导致半成品写入并留下不一致数据要好得多。

何时决定启用只读模式

切换到只读是一种权衡：功能减少，但产品可用且数据库更健康。目标是在用户触发重试、超时和卡住连接形成螺旋之前采取行动。

关注少量可以一句话解释的信号。如果同时出现两项或以上，就把它当做早期预警：

• 请求超时或跨越清晰的延迟门槛（例如 p95 从 300 ms 跳到 3 s）
• 数据库 CPU 持续高负荷多分钟，而非短时峰值
• 连接池耗尽（请求排队等待可用连接）
• 慢查询日志突然被同一类查询填满
• 由于锁等待、死锁或事务失败导致的错误率上升

仅靠指标不应是唯一触发条件。加入人工判定：值班人员声明事故状态并开启只读模式。这样可以在压力下避免争执，并使操作可审计。

把阈值设得易记且易于沟通。用“写入已暂停，因为数据库过载”要比“我们触及饱和”更清楚。同时定义谁能切换开关以及在哪里控制它。

避免频繁切换模式。添加简单的滞后机制：一旦进入只读，保持最短时间窗（比如 10 到 15 分钟），且仅在关键信号恢复一段时间后才切回。这防止用户看到表单一会能保存一会失败。

逐步操作：安全开启只读模式

把事故期间的只读模式当作受控变更，而不是慌乱中的临时修补。目标是通过停止写入来保护数据库，同时保留最有价值的读取。

安全的上线顺序

如果可能，先把代码路径部署好再切开关。这样，开启只读只是切换配置，而不是在生产中做代码变更。

1. 创建一个统一的事故切换（特性标志或配置项），全系统读取该值。保持全局且单一：READ_ONLY=true。避免多个相互不同步的标志。
2. 更新 UI 以防止写入尝试。禁用保存按钮、隐藏编辑表单、将输入改为只读文本。仍然展示数据以便用户继续查看（浏览、搜索、导出）。
3. 在服务器端强制执行，而不仅仅是 UI。把写入在一个位置统一阻止（中间件、控制器守卫或服务层），这样包括移动应用、API 客户端和自动化在内的所有客户端都会被覆盖。
4. 对被阻止的写入返回清晰一致的错误。使用专门的状态码和信息，比如："编辑已暂时禁用，我们正在稳定系统。你的数据是安全的，请稍后再试。" 不要返回看起来像数据丢失的通用 500。
5. 记录每次被阻止的写入尝试。捕获用户、端点和操作类型。日志中尽量减少敏感数据。此类日志有助于修补 UX 漏洞并在必要时重放关键操作。

一个能防止重复事故的小细节

启用只读时，应在触及数据库前快速失败。不要先跑一堆验证查询再阻止写入。最快的被阻止请求是从未触及你受压数据库的那个。

能减少混乱和支持工单的 UI 文案

启用只读模式时，UI 是修复的一部分。如果用户不断点击保存却得到模糊错误，他们会继续重试、刷新并提交工单。清晰的文案能降低额外负载和挫败感。

一个好做法是在应用顶部放一个明显且持久的横幅。保持简短且事实性：说明发生了什么、用户应期待什么以及现在能做什么。不要把信息放在会消失的提示中。

说明还能做什么、暂停了什么、下一步是什么

用户主要想知道是否还能继续工作。用明白易懂的语言把内容写清楚。对大多数产品而言，这通常包括：

• 仍然可用： 查看记录、搜索、下载、阅读仪表盘
• 已暂停： 创建、编辑、删除、上传、付款、发送消息
• 建议替代操作： 复制关键信息、导出视图、稍后重试
• 更新频率： “我们将在 15 分钟内在此处发布更新。”

简单的状态标签也有助于让用户理解进展，而不是猜测。“Investigating（调查中）”表示你还在查原因；“Stabilizing（稳定中）”表示正在减少负载并保护数据；“Recovering（恢复中）”表示写入即将恢复，但可能仍有延迟。

保持语气冷静且具体

避免责怪或模糊的文本，比如“出了点问题”或“你没有权限”。如果按钮被禁用，就标注原因："编辑已在我们稳定系统期间暂时暂停。"

举个小例子：在 CRM 中，保持联系人和交易页可读，但禁用“编辑”“添加备注”“新建交易”。如果用户仍尝试操作，弹出短对话框："当前已暂停更改。你可以复制此记录或导出列表，然后稍后再试。"

在不增加负载的前提下保留关键读取

切换到只读时，目标不是“让所有内容都可见”，而是“保留用户依赖的少数页面”，且不再给受压数据库增加额外压力。

首先精简最耗资源的页面。带大量筛选的长表、跨多字段的全文检索和复杂排序往往触发慢查询。在只读时让这些界面更简单：减少筛选选项、使用安全默认排序并限制可选的时间范围。

优先使用缓存或预计算视图来支撑重要页面。简单的“账户概览”从缓存或汇总表读取，通常比加载原始事件日志或多表联查要安全得多。

一些实用方法：

• 使用更小的分页并移除“显示全部”选项
• 用默认排序替代复杂排序（例如“按最近时间”）
• 推迟非必要读取，如分析、推荐和活动图表
• 优先使用缓存汇总而不是原始历史数据
• 如果有助于响应性，允许数据略有延迟

具体例子：在 CRM 事故中，保留“查看联系人”“查看交易状态”“查看最后备注”功能。暂时隐藏高级搜索、收入图表和完整邮件时间线，并提示数据可能滞后几分钟。

对作业、Webhook 和集成的处理

切换到只读时，最大的惊喜常常不是 UI，而是那些无形的写入者：后台任务、计划同步、管理员批量操作和第三方集成，它们会持续敲击数据库。

首先停止会创建或更新记录的后台工作。常见罪魁包括导入、夜间同步、发送邮件时写入投递日志、分析汇总以及不断重试导致重复失败更新的重试环路。暂停这些能迅速降低压力并避免第二波负载。

一个安全默认策略是暂停或限流那些写入密集的作业，以及任何会持久化结果的队列消费者；禁用管理员批量操作（批量更新、批量删除、大规模重建索引）；并对写入端点快速失败，返回清晰的临时响应而不是超时。

对于 webhook 和集成，清晰胜过乐观。如果你接受了 webhook 却无法处理，就会形成不一致和支持问题。当写入被暂停时，返回临时失败以便发送方稍后重试，并确保你的 UI 文案与后端行为一致。

谨慎对待“排队等候”缓冲。听起来友好，但可能造成积压，一旦你恢复写入便泛滥系统。只有在你能保证幂等、限制队列大小并向用户展示真实状态（待处理 vs 已保存）时，才缓冲用户写入。

最后，审计产品内的隐藏批量写入。如果某个自动化能更新成千上万行，即使其他部分仍能正常加载，该自动化也应在只读模式下被强制关闭。

常见错误会让事故更糟

把只读模式当成化妆式改动是让事故恶化的最快方式。如果你只在 UI 上禁用按钮，用户仍会通过 API、旧标签页、移动端和后台任务写入。数据库压力未减，用户也失去信任，因为有人在一个地方看到“已保存”，在另一个地方缺少更改。

真正的事故只读模式应有一条清晰规则：服务器拒绝所有客户端的写入请求，始终如一。

要警惕的错误

这些模式在数据库过载时经常出现：

• 只在 UI 上屏蔽编辑，而后端仍接受 POST、PUT、PATCH 和 DELETE
• 忘记隐藏路径：管理面板、内部工具、导入端点以及集成使用的公共 API
• 系统频繁在正常与只读之间抖动
• 显示模糊的提示如“出了点问题”
• 允许部分写入导致数据不一致

如何避免

让系统行为可预测。在服务器端实施单一开关，始终以统一响应拒绝写入。添加冷却时间，一旦进入只读就保持设定时间（例如 10 至 15 分钟），除非有操作人员主动变更。

严格保证数据完整性。如果某次写入无法完全完成，就整体失败并告诉用户下一步。一个简单的信息如“只读模式：可查看数据，变更已暂停。请稍后再试。”能显著减少重复重试。

事故前和事故期间的快速检查清单

只读模式只有在易于切换且在所有地方一致行为时才有用。出问题之前，确保有一个单一切换（特性标志、配置或管理员开关），值班人员能在几秒内启用，无需部署。

当怀疑数据库过载时，做一次快速检查以确认基本功能：

• 在安全环境切换开关并确认立即生效
• 测试若干写操作（保存、删除、导入），确认每个写入端点都返回相同的被阻止响应和状态码
• 检查横幅文案是否就绪、简短并在常用页面可见
• 加载你的前三个关键页面（例如：登录、仪表盘、记录视图），确认在压力下仍然能渲染
• 确保支持团队有一段话脚本，说明哪些可用、哪些暂停、在哪看更新

在事故期间，保持一人专注于验证用户体验，而不仅仅看仪表盘。在隐身窗口里做快速核验能发现隐藏横幅、损坏表单或无限加载器等问题，这些问题会引发额外刷新流量。

在切换前就计划好退出标准。定义“健康”的含义（延迟、错误率、复制滞后），在切回后做短暂验证：创建一条测试记录、编辑它并确认统计与最近活动正确。

示例事故：在阻止编辑的同时保持 CRM 可用

现在是上午 10:20。CRM 变慢，数据库 CPU 被占满。支持工单开始涌入：用户无法保存对联系人和交易的编辑。但团队仍需查找电话号码、查看交易阶段并在通话前阅读最近的备注。

你制定了一个简单规则：冻结所有写入，保留最有价值的读取。实际操作中，联系人搜索、联系人详情页和交易管线视图保持可用。编辑联系人、创建新交易、添加备注和批量导入被阻止。

在 UI 上，变化应明显且平静。在编辑页面，保存按钮被禁用，表单仍显示以便用户复制已输入内容。顶部横幅写着："只读模式已启用，因负载过高。可查看数据，更改已暂停。请稍后再试。" 如果用户仍通过 API 触发写入，返回清晰的信息并避免自动重试去冲击数据库。

在运维层面，保持流程简短且可重复。启用只读并验证所有写入端点都遵守；暂停会写入的后台任务（同步、导入、邮件日志、分析回填）；限流或暂停会更新的 webhook 与集成。监控数据库负载、错误率与慢查询；发布状态更新说明受影响的功能（例如：编辑）和仍可用的功能（例如：搜索和查看）。

恢复不仅仅是把开关切回。逐步放开写入，验证错误日志中是否有未完成的保存操作，并留意来自排队任务的写入风暴。然后清晰沟通："只读模式已关闭，保存已恢复。如果你在 10:20 到 10:55 之间尝试保存，请重新检查你的最新更改。"

下一步：把只读模式写进你的应急手册

只读模式在事故中的作用最佳表现就是它平淡且可复用。目标是遵循一套简短的脚本，明确责任人和检查项。

制定简明可用的演练手册

把手册控制在一页内。包括触发信号（少数能说明切换只读的指标）、你要切的确切开关以及如何确认写入被阻止、必须维持的关键读取列表、明确的角色（谁切开关、谁看指标、谁负责支持）和退出标准（恢复写入前必须满足的条件，以及如何耗尽积压）。

在需要前准备好 UI 文案

现在就写好并审批这些文字，这样在故障时就不用为措辞争论。通常一套简单文案已足够覆盖大多数场景：

• 横幅："我们处于只读模式以恢复性能。你可以查看数据，但更改暂时被禁用。"
• 被阻止操作提示："当前暂停保存。你的更改未被应用，请在几分钟后重试。"
• 状态详情："最后更新于 HH:MM。下次更新在 10 分钟后。"

在预发布环境演练切换并计时。确保支持与值班能快速找到切换按钮并且日志能清晰显示被阻止的写入。每次事故后回顾哪些读取是真正关键的、哪些是可有可无的、哪些不小心增加了负载，然后更新检查清单。

如果你在 Koder.ai (koder.ai) 上构建产品，将只读作为生成应用中的一等公民功能往往有帮助，这样在需要时 UI 与服务器端的写入守卫能保持一致。