2025年10月02日·1 分钟
事故期间的只读模式：保留读取，阻止写入
了解为何在事故期间启用只读模式能阻止写入、保留关键读取并在界面中清晰告知用户，从而让数据库更容易恢复。
了解为何在事故期间启用只读模式能阻止写入、保留关键读取并在界面中清晰告知用户，从而让数据库更容易恢复。
当数据库过载时，用户很少看到干净的“宕机”提示。更多的是超时、页面只加载到一半、按钮一直转圈、以及操作有时成功有时失败。一次保存可能成功，下一次就报错说“出了点问题”。这种不确定性让事故显得混乱。
通常首先受影响的是写入密集的路径：编辑记录、结账流程、表单提交、后台更新，以及任何需要事务和锁的操作。在压力下，写入变慢并互相阻塞，也可能通过持有锁或触发更多工作来拖慢读取。
随机错误比可控的限制更糟，因为用户不知道下一步该怎么做。他们会重试、刷新、重复点击，进而产生更多负载。支持工单暴增，因为系统看起来“有点能用”，但没人相信它。
只读模式在事故期间的目的不是追求完美，而是保留最重要的功能：查看关键记录、搜索、检查状态和下载用户继续工作的资料。你有意停止或延迟有风险的操作（写入），以便数据库恢复并保持剩余读取的响应性。
要明确预期。这只是临时限制，并不意味着数据被删除。在大多数情况下，用户现有的数据仍然安全——系统只是暂停更改，直到数据库恢复健康。
事故期间的只读模式是一个临时状态，产品在该状态下仍可用于查看，但会拒绝任何会改变数据的操作。目标很简单：在保护数据库的同时保持服务的可用价值。
通俗地说，人们仍然可以查找信息，但不能执行会触发写入的更改。通常这意味着浏览页面、搜索、筛选和打开记录仍然可用。保存表单、编辑设置、发布评论、上传文件或创建新账户会被阻止。
一个实用的判断方式是：如果某个操作会更新一行、创建一行、删除一行或写入队列，那就不允许。许多团队还会阻止“隐藏的写入”，比如存主数据库的分析事件、同步写入的审计日志以及“最后在线”时间戳。
当读取大致可用但写入延迟上升、锁争用变多或写入密集的积压拖慢一切时，只读模式是正确的选择。
当连基础读取都超时、缓存无法提供必要数据或系统无法可靠告知用户当前安全操作时，就应完全离线（下线）。
为什么这有用：写操作通常比简单读取成本高得多。写入可能触发索引、约束、锁以及后续查询。阻止写入还可以防止重试风暴，客户端不断重提交失败的保存操作会放大损害。
示例：在 CRM 事故期间，用户仍能搜索账户、打开联系人详情和查看近期交易，但“编辑”“创建”和“导入”等操作被禁用，任何保存请求都会立即以明确的信息被拒绝。
切换到只读模式时，目标不是“所有功能都可用”。目标是让最重要的界面仍能加载，而任何会增加数据库压力的操作都能快速且安全地停止。
先列出在糟糕情况下仍必须可用的少数用户操作。这些通常是能够解锁决策的小型读取：查看最新记录、检查状态、搜索短列表或下载已缓存的报告。
然后决定哪些可以暂停而不会造成重大伤害。大多数写入路径在事故期间属于“可有可无”：编辑、批量更新、导入、评论、附件、分析事件以及任何会触发额外查询的操作。
一个简单的分类方法是把操作分成三类：
还要设定时间范围。如果预计是几分钟，可以严格阻止几乎所有写入。如果预计是几小时，考虑允许一小类安全写入（比如密码重设或关键状态更新），并将其他写入排队。
及早达成优先级共识：安全优于完整性。展示清晰的“更改已暂停”信息，比允许导致半成品写入并留下不一致数据要好得多。
切换到只读是一种权衡：功能减少，但产品可用且数据库更健康。目标是在用户触发重试、超时和卡住连接形成螺旋之前采取行动。
关注少量可以一句话解释的信号。如果同时出现两项或以上，就把它当做早期预警：
仅靠指标不应是唯一触发条件。加入人工判定：值班人员声明事故状态并开启只读模式。这样可以在压力下避免争执，并使操作可审计。
把阈值设得易记且易于沟通。用“写入已暂停，因为数据库过载”要比“我们触及饱和”更清楚。同时定义谁能切换开关以及在哪里控制它。
避免频繁切换模式。添加简单的滞后机制：一旦进入只读，保持最短时间窗（比如 10 到 15 分钟），且仅在关键信号恢复一段时间后才切回。这防止用户看到表单一会能保存一会失败。
把事故期间的只读模式当作受控变更，而不是慌乱中的临时修补。目标是通过停止写入来保护数据库，同时保留最有价值的读取。
如果可能，先把代码路径部署好再切开关。这样，开启只读只是切换配置，而不是在生产中做代码变更。
READ_ONLY=true。避免多个相互不同步的标志。启用只读时，应在触及数据库前快速失败。不要先跑一堆验证查询再阻止写入。最快的被阻止请求是从未触及你受压数据库的那个。
启用只读模式时，UI 是修复的一部分。如果用户不断点击保存却得到模糊错误，他们会继续重试、刷新并提交工单。清晰的文案能降低额外负载和挫败感。
一个好做法是在应用顶部放一个明显且持久的横幅。保持简短且事实性：说明发生了什么、用户应期待什么以及现在能做什么。不要把信息放在会消失的提示中。
用户主要想知道是否还能继续工作。用明白易懂的语言把内容写清楚。对大多数产品而言，这通常包括：
简单的状态标签也有助于让用户理解进展，而不是猜测。“Investigating（调查中）”表示你还在查原因；“Stabilizing（稳定中）”表示正在减少负载并保护数据；“Recovering（恢复中）”表示写入即将恢复，但可能仍有延迟。
避免责怪或模糊的文本，比如“出了点问题”或“你没有权限”。如果按钮被禁用，就标注原因："编辑已在我们稳定系统期间暂时暂停。"
举个小例子：在 CRM 中，保持联系人和交易页可读，但禁用“编辑”“添加备注”“新建交易”。如果用户仍尝试操作，弹出短对话框："当前已暂停更改。你可以复制此记录或导出列表，然后稍后再试。"
切换到只读时，目标不是“让所有内容都可见”，而是“保留用户依赖的少数页面”，且不再给受压数据库增加额外压力。
首先精简最耗资源的页面。带大量筛选的长表、跨多字段的全文检索和复杂排序往往触发慢查询。在只读时让这些界面更简单：减少筛选选项、使用安全默认排序并限制可选的时间范围。
优先使用缓存或预计算视图来支撑重要页面。简单的“账户概览”从缓存或汇总表读取，通常比加载原始事件日志或多表联查要安全得多。
一些实用方法：
具体例子：在 CRM 事故中，保留“查看联系人”“查看交易状态”“查看最后备注”功能。暂时隐藏高级搜索、收入图表和完整邮件时间线，并提示数据可能滞后几分钟。
切换到只读时，最大的惊喜常常不是 UI，而是那些无形的写入者：后台任务、计划同步、管理员批量操作和第三方集成，它们会持续敲击数据库。
首先停止会创建或更新记录的后台工作。常见罪魁包括导入、夜间同步、发送邮件时写入投递日志、分析汇总以及不断重试导致重复失败更新的重试环路。暂停这些能迅速降低压力并避免第二波负载。
一个安全默认策略是暂停或限流那些写入密集的作业，以及任何会持久化结果的队列消费者；禁用管理员批量操作（批量更新、批量删除、大规模重建索引）；并对写入端点快速失败，返回清晰的临时响应而不是超时。
对于 webhook 和集成，清晰胜过乐观。如果你接受了 webhook 却无法处理，就会形成不一致和支持问题。当写入被暂停时，返回临时失败以便发送方稍后重试，并确保你的 UI 文案与后端行为一致。
谨慎对待“排队等候”缓冲。听起来友好，但可能造成积压，一旦你恢复写入便泛滥系统。只有在你能保证幂等、限制队列大小并向用户展示真实状态（待处理 vs 已保存）时，才缓冲用户写入。
最后，审计产品内的隐藏批量写入。如果某个自动化能更新成千上万行，即使其他部分仍能正常加载，该自动化也应在只读模式下被强制关闭。
把只读模式当成化妆式改动是让事故恶化的最快方式。如果你只在 UI 上禁用按钮，用户仍会通过 API、旧标签页、移动端和后台任务写入。数据库压力未减，用户也失去信任，因为有人在一个地方看到“已保存”，在另一个地方缺少更改。
真正的事故只读模式应有一条清晰规则：服务器拒绝所有客户端的写入请求，始终如一。
这些模式在数据库过载时经常出现：
让系统行为可预测。在服务器端实施单一开关，始终以统一响应拒绝写入。添加冷却时间，一旦进入只读就保持设定时间（例如 10 至 15 分钟），除非有操作人员主动变更。
严格保证数据完整性。如果某次写入无法完全完成，就整体失败并告诉用户下一步。一个简单的信息如“只读模式：可查看数据，变更已暂停。请稍后再试。”能显著减少重复重试。
只读模式只有在易于切换且在所有地方一致行为时才有用。出问题之前，确保有一个单一切换（特性标志、配置或管理员开关），值班人员能在几秒内启用，无需部署。
当怀疑数据库过载时，做一次快速检查以确认基本功能：
在事故期间，保持一人专注于验证用户体验，而不仅仅看仪表盘。在隐身窗口里做快速核验能发现隐藏横幅、损坏表单或无限加载器等问题，这些问题会引发额外刷新流量。
在切换前就计划好退出标准。定义“健康”的含义（延迟、错误率、复制滞后），在切回后做短暂验证：创建一条测试记录、编辑它并确认统计与最近活动正确。
现在是上午 10:20。CRM 变慢，数据库 CPU 被占满。支持工单开始涌入：用户无法保存对联系人和交易的编辑。但团队仍需查找电话号码、查看交易阶段并在通话前阅读最近的备注。
你制定了一个简单规则：冻结所有写入，保留最有价值的读取。实际操作中，联系人搜索、联系人详情页和交易管线视图保持可用。编辑联系人、创建新交易、添加备注和批量导入被阻止。
在 UI 上，变化应明显且平静。在编辑页面，保存按钮被禁用，表单仍显示以便用户复制已输入内容。顶部横幅写着："只读模式已启用，因负载过高。可查看数据，更改已暂停。请稍后再试。" 如果用户仍通过 API 触发写入，返回清晰的信息并避免自动重试去冲击数据库。
在运维层面，保持流程简短且可重复。启用只读并验证所有写入端点都遵守；暂停会写入的后台任务（同步、导入、邮件日志、分析回填）；限流或暂停会更新的 webhook 与集成。监控数据库负载、错误率与慢查询；发布状态更新说明受影响的功能（例如：编辑）和仍可用的功能（例如：搜索和查看）。
恢复不仅仅是把开关切回。逐步放开写入，验证错误日志中是否有未完成的保存操作，并留意来自排队任务的写入风暴。然后清晰沟通："只读模式已关闭，保存已恢复。如果你在 10:20 到 10:55 之间尝试保存，请重新检查你的最新更改。"
只读模式在事故中的作用最佳表现就是它平淡且可复用。目标是遵循一套简短的脚本，明确责任人和检查项。
把手册控制在一页内。包括触发信号（少数能说明切换只读的指标）、你要切的确切开关以及如何确认写入被阻止、必须维持的关键读取列表、明确的角色（谁切开关、谁看指标、谁负责支持）和退出标准（恢复写入前必须满足的条件，以及如何耗尽积压）。
现在就写好并审批这些文字，这样在故障时就不用为措辞争论。通常一套简单文案已足够覆盖大多数场景：
在预发布环境演练切换并计时。确保支持与值班能快速找到切换按钮并且日志能清晰显示被阻止的写入。每次事故后回顾哪些读取是真正关键的、哪些是可有可无的、哪些不小心增加了负载，然后更新检查清单。
如果你在 Koder.ai (koder.ai) 上构建产品，将只读作为生成应用中的一等公民功能往往有帮助，这样在需要时 UI 与服务器端的写入守卫能保持一致。
通常是写操作路径先变差：保存、编辑、结账、导入以及任何需要事务的操作。在压力下，锁和缓慢提交会让写操作互相阻塞，而这些阻塞的写入也会通过占用锁或增加后续查询工作量来拖慢读取。
因为它让人感觉不可预测。如果操作有时成功有时失败，用户会不断重试、刷新和重复点击，这会增加负载并产生更多超时与卡住的请求。
这是一个临时状态，产品仍然可用于查看数据，但拒绝更改。用户可以浏览、搜索和打开记录，但任何会创建、更新或删除数据的操作都会被阻止。
默认阻止任何会写入主数据库的操作，包括“隐藏的写入”如审计日志、最后在线时间戳和存储在同一数据库的分析事件。如果它会改变行或排队后写入，按写操作处理。
当你看到写操作开始失控的早期信号时就打开它：超时、p95 延迟上升、锁等待、连接池耗尽或重复的慢查询。最好在用户发起重试风暴放大事故之前切换过去。
使用一个全局开关并由服务器强制执行，而不仅仅是在 UI 上禁用按钮。UI 应隐藏或禁用写操作，但每个写入端点都应在触达数据库前快速失败并返回统一响应。
显示一个持久的横幅，说明正在发生什么、哪些功能仍可用、哪些被暂停，用简明语言描述。把被阻止的操作明确写出来，避免用户持续尝试从而产生“大量‘出错’”的工单。
保留少量关键页面可用，并简化会触发慢查询的界面。优先使用缓存汇总、减少每页条目数、采用安全的默认排序，并允许略微过时的数据而不是复杂的过滤和昂贵的联表查询。
暂停或限流会写结果的后台任务、同步、导入和队列消费者。对于 webhook，不要接受你处理不了的工作；返回临时失败让发送方稍后重试，而不是悄悄造成数据不一致。
只在 UI 上禁用按钮是最常见的问题；API、移动端、旧标签页和后台任务仍会写入。另外一个常见问题是模式频繁切换；在只读时设置最低时间窗口，并在恢复后用真实的创建/编辑测试验证系统状态。