Chế độ chỉ đọc khi sự cố: giữ đọc, chặn ghi

Khi cơ sở dữ liệu bị căng, cái gì hỏng trước\n\nKhi cơ sở dữ liệu bị quá tải, người dùng hiếm khi thấy một thông báo "đang sập" rõ ràng. Họ thấy timeout, trang tải nửa chừng, nút quay mãi, và hành động đôi khi thành công đôi khi thất bại. Một lần lưu có thể thành công, lần sau báo lỗi "Có lỗi xảy ra." Sự không chắc chắn đó là điều khiến sự cố cảm thấy hỗn loạn.\n\nNhững thứ hỏng trước thường là những đường dẫn nặng về ghi: chỉnh sửa bản ghi, quy trình thanh toán, gửi form, cập nhật nền, và bất cứ việc nào cần transaction và lock. Dưới áp lực, ghi chậm lại, chặn lẫn nhau, và cũng có thể làm chậm đọc bằng cách giữ khóa và tạo thêm công việc cho hệ thống.\n\nLỗi ngẫu nhiên gây cảm giác tệ hơn so với một giới hạn có kiểm soát vì người dùng không biết phải làm gì tiếp theo. Họ thử lại, làm mới, bấm tiếp, và tạo ra nhiều tải hơn. Ticket hỗ trợ tăng vọt vì hệ thống trông "có vẻ hoạt động," nhưng không ai có thể tin tưởng.\n\nMục tiêu của chế độ chỉ đọc khi sự cố không phải là hoàn hảo. Mà là giữ những phần quan trọng nhất có thể dùng được: xem bản ghi chính, tìm kiếm, kiểm tra trạng thái và tải về những gì cần để tiếp tục công việc. Bạn chủ ý dừng hoặc trì hoãn những hành động rủi ro (ghi) để cơ sở dữ liệu phục hồi và phần đọc còn lại vẫn phản hồi tốt.\n\nHãy đặt kỳ vọng rõ ràng. Đây là giới hạn tạm thời, và không có nghĩa là dữ liệu bị xóa. Trong hầu hết trường hợp, dữ liệu hiện có của người dùng vẫn an toàn — hệ thống chỉ tạm dừng thay đổi cho đến khi DB khỏe lại.\n\n## Chế độ chỉ đọc thực sự nghĩa là gì\n\nChế độ chỉ đọc khi sự cố là trạng thái tạm thời trong đó sản phẩm vẫn dùng được để xem, nhưng từ chối mọi thứ làm thay đổi dữ liệu. Mục tiêu đơn giản: giữ dịch vụ hữu ích trong khi bảo vệ cơ sở dữ liệu khỏi công việc thêm.\n\nNói ngắn gọn, người ta vẫn có thể tra cứu, nhưng không thể thực hiện thay đổi gây ghi. Thường thì duyệt trang, tìm kiếm, lọc và mở bản ghi vẫn hoạt động. Lưu form, chỉnh sửa cài đặt, đăng bình luận, tải lên tệp, hoặc tạo tài khoản mới sẽ bị chặn.\n\nCách thực tế để nghĩ: nếu một hành động cập nhật một dòng, tạo một dòng, xóa một dòng, hoặc ghi vào queue thì nó không được phép. Nhiều đội cũng chặn các "ghi ẩn" như sự kiện analytics lưu trong DB chính, log kiểm toán ghi đồng bộ, và timestamp "last seen".\n\nChế độ chỉ đọc là lựa chọn đúng khi đọc vẫn còn hoạt động phần lớn, nhưng độ trễ ghi tăng, tranh chấp khóa tăng, hoặc tồn đọng công việc nặng về ghi làm chậm mọi thứ.\n\nHãy đi hoàn toàn offline khi ngay cả các truy vấn đọc cơ bản cũng timeout, cache không thể phục vụ thiết yếu, hoặc hệ thống không thể nói rõ với người dùng cái gì an toàn để làm.\n\nTại sao điều này hữu ích: ghi thường tốn nhiều tài nguyên hơn đọc đơn giản. Một ghi có thể kích hoạt index, ràng buộc, khóa và các truy vấn tiếp theo. Chặn ghi cũng ngăn các retry storm, khi client liên tục gửi lại các lưu thất bại và nhân lên thiệt hại.\n\nVí dụ: trong một sự cố CRM, người dùng vẫn có thể tìm kiếm tài khoản, mở chi tiết liên hệ, và xem giao dịch gần đây, nhưng các hành động Chỉnh sửa, Tạo và Nhập khẩu bị vô hiệu và mọi yêu cầu lưu bị từ chối ngay lập tức với thông điệp rõ ràng.\n\n## Chọn những đọc phải giữ và những ghi cần dừng\n\nKhi bạn chuyển sang chế độ chỉ đọc trong sự cố, mục tiêu không phải "mọi thứ hoạt động." Mục tiêu là những màn hình quan trọng nhất vẫn tải được, trong khi mọi thứ tạo thêm áp lực cơ sở dữ liệu dừng nhanh và an toàn.\n\nBắt đầu bằng việc liệt kê vài hành động người dùng cần duy trì ngay cả trong ngày tệ nhất. Chúng thường là các đọc nhỏ giúp đưa ra quyết định: xem bản ghi mới nhất, kiểm tra trạng thái, tìm kiếm danh sách ngắn, hoặc tải báo cáo đã cache.\n\nRồi quyết định những gì bạn có thể tạm dừng mà không gây hại lớn. Hầu hết đường dẫn ghi rơi vào nhóm "hay có" trong thời kỳ sự cố: chỉnh sửa, cập nhật hàng loạt, nhập khẩu, bình luận, tệp đính kèm, sự kiện analytics, và bất cứ gì kích hoạt thêm truy vấn.\n\nMột cách đơn giản để quyết định là phân loại hành động thành ba nhóm:\n\n- Phải giữ: các đọc nhỏ, nhanh giúp người dùng ngay lúc này\n- Có thể tạm dừng: các ghi và đọc nặng làm tăng tải hoặc khóa hàng\n- Có thể suy giảm: tính năng có thể hiển thị dữ liệu cache hoặc chế độ xem một phần\n\nCũng đặt một khoảng thời gian. Nếu bạn dự kiến chỉ vài phút, bạn có thể nghiêm ngặt và chặn hầu hết ghi. Nếu dự kiến vài giờ, hãy cân nhắc cho phép một số ghi an toàn rất giới hạn (ví dụ đặt lại mật khẩu hoặc cập nhật trạng thái quan trọng) và xếp hàng phần còn lại.\n\nĐồng thuận ưu tiên sớm: an toàn hơn đầy đủ. Tốt hơn hiển thị rõ "các thay đổi đang tạm dừng" hơn cho phép một ghi nửa vời và để dữ liệu không nhất quán.\n\n## Làm sao để quyết định khi nào bật\n\nBật chế độ chỉ đọc là một đánh đổi: ít tính năng hơn ngay bây giờ, nhưng sản phẩm có thể dùng được và DB khỏe hơn. Mục tiêu là hành động trước khi người dùng kích hoạt vòng lặp retry, timeout và kết nối kẹt.\n\nTheo dõi một vài tín hiệu mà bạn có thể giải thích trong một câu. Nếu có hai tín hiệu trở lên xuất hiện cùng lúc, xem đó là cảnh báo sớm:\n\n- Yêu cầu timeout hoặc vượt ngưỡng độ trễ rõ rệt (ví dụ p95 từ 300 ms lên 3 s)\n- CPU DB sử dụng cao liên tục vài phút, không chỉ spike ngắn\n- Pool kết nối cạn kiệt (yêu cầu xếp hàng vì không có kết nối)\n- Slow query log đầy đột ngột với cùng vài truy vấn\n- Tỉ lệ lỗi tăng do chờ khóa, deadlock hoặc transaction thất bại\n\nChỉ dựa vào metrics không nên là kích hoạt duy nhất. Thêm quyết định con người: người đang on-call tuyên bố trạng thái sự cố và bật chế độ chỉ đọc. Điều đó dừng tranh luận giữa lúc áp lực và làm cho hành động có thể kiểm toán.\n\nLàm cho ngưỡng dễ nhớ và dễ truyền đạt. "Ghi tạm dừng vì cơ sở dữ liệu quá tải" rõ ràng hơn "chúng ta chạm ngưỡng." Ngoài ra xác định ai có quyền gạt công tắc và ở đâu nó được điều khiển.\n\nTránh bật tắt liên tục giữa các chế độ. Thêm hysteresis đơn giản: một khi vào chế độ chỉ đọc, ở đó tối thiểu một cửa sổ (khoảng 10–15 phút) và chỉ trở lại khi các tín hiệu ổn định trong một thời gian. Điều này ngăn người dùng thấy form hoạt động một phút rồi lỗi phút sau.\n\n## Bước theo bước: bật chế độ chỉ đọc an toàn\n\nXử lý chế độ chỉ đọc như một thay đổi có kiểm soát, không phải chạy đua. Mục tiêu là bảo vệ DB bằng cách dừng ghi, trong khi giữ các đọc có giá trị nhất hoạt động.\n\n### Trình tự triển khai an toàn\n\nNếu có thể, đưa đường dẫn code trước khi gạt công tắc. Như vậy, bật chế độ chỉ đọc chỉ là chuyển đổi, không phải sửa trực tiếp khi đang chạy.\n\n1. Tạo một công tắc sự cố duy nhất (feature flag hoặc cấu hình) mà toàn hệ thống đọc. Giữ nó toàn cục và đơn giản: READ_ONLY=true. Tránh nhiều flag có thể bị lệch nhau.\n2. Cập nhật UI để ngăn thử ghi. Vô hiệu hóa nút Lưu, ẩn form chỉnh sửa, và chuyển input về dạng văn bản tĩnh. Vẫn hiển thị dữ liệu để người ta tiếp tục làm việc (xem, tìm kiếm, xuất).\n3. Áp dụng ở phía server, không chỉ UI. Chặn ghi ở một chỗ (middleware, controller guard, hoặc service layer) để mọi client đều được bảo vệ, bao gồm app di động, người dùng API và automation.\n4. Trả về lỗi rõ ràng, nhất quán cho các ghi bị chặn. Dùng mã trạng thái và thông điệp riêng như: "Chỉnh sửa tạm thời bị vô hiệu trong khi chúng tôi ổn định hệ thống. Dữ liệu của bạn an toàn. Vui lòng thử lại sau." Đừng trả 500 chung chung khiến người dùng nghĩ dữ liệu mất.\n5. Ghi lại mọi lần cố gắng ghi bị chặn. Bắt thông tin người dùng, endpoint và loại hành động. Giữ payload tối thiểu để tránh thông tin nhạy cảm trong log. Những log này giúp bạn sửa lỗ hổng UX và có thể phát lại hành động quan trọng sau này nếu cần.\n\n### Một chi tiết nhỏ ngăn tái phát sự cố\n\nKhi chế độ chỉ đọc kích hoạt, fail nhanh trước khi chạm DB. Đừng chạy các truy vấn kiểm tra rồi mới chặn ghi. Yêu cầu bị chặn nhanh nhất là yêu cầu không bao giờ chạm vào cơ sở dữ liệu đang căng.\n\n## Thông điệp UI giảm nhầm lẫn và ticket hỗ trợ\n\nKhi bật chế độ chỉ đọc trong sự cố, UI là một phần của giải pháp. Nếu mọi người cứ bấm Lưu và nhận lỗi mơ hồ, họ sẽ thử lại, làm mới và mở ticket. Thông điệp rõ ràng giảm tải và giảm bực bội.\n\nMột mẫu tốt là banner hiển thị, cố định ở đầu app. Giữ ngắn và thực tế: chuyện gì đang xảy ra, người dùng nên mong đợi gì, và họ có thể làm gì bây giờ. Đừng giấu nó trong toast tự tắt.\n\n### Nói rõ những gì hoạt động, tạm dừng và bước tiếp\n\nNgười dùng chủ yếu muốn biết họ còn làm được gì. Hãy ghi ra bằng ngôn ngữ đơn giản. Với hầu hết sản phẩm, điều đó nghĩa là:\n\n- Vẫn hoạt động: xem bản ghi, tìm kiếm, tải xuống, đọc dashboard\n- Đang tạm dừng: tạo, chỉnh sửa, xóa, tải lên, thanh toán, gửi tin nhắn\n- Thay vào đó làm: sao chép thông tin quan trọng, xuất view, thử lại sau\n- Cập nhật: "Chúng tôi sẽ cập nhật ở đây sau 15 phút."\n\nMột nhãn trạng thái đơn giản cũng giúp người dùng hiểu tiến trình mà không đoán mò. "Investigating" nghĩa là đang điều tra. "Stabilizing" nghĩa là đang giảm tải và bảo vệ dữ liệu. "Recovering" nghĩa là ghi sẽ sớm trở lại nhưng có thể chậm.\n\n### Giữ giọng điệu bình tĩnh và cụ thể\n\nTránh văn phong đổ lỗi hoặc mơ hồ như "Có lỗi xảy ra" hay "Bạn không có quyền." Nếu một nút bị vô hiệu, gắn nhãn rõ: "Chỉnh sửa tạm thời bị tạm dừng trong khi chúng tôi ổn định hệ thống."\n\nVí dụ nhỏ: trong CRM, giữ trang liên hệ và giao dịch có thể đọc được, nhưng vô hiệu hóa Edit, Add note và New deal. Nếu ai đó vẫn thử, hiện hộp thoại ngắn: "Các thay đổi đang tạm dừng. Bạn có thể sao chép bản ghi này hoặc xuất danh sách, rồi thử lại sau."\n\n## Giữ các đọc chính mà không làm nặng thêm tải\n\nKhi chuyển sang chế độ chỉ đọc, mục tiêu không phải là "giữ mọi thứ hiển thị." Mà là "giữ vài trang người ta dựa vào," mà không tạo thêm áp lực lên DB.\n\nBắt đầu bằng việc cắt bớt những màn hình nặng nhất. Bảng dài với nhiều bộ lọc, tìm kiếm toàn văn nhiều trường, và sort phức tạp thường gây truy vấn chậm. Trong chế độ chỉ đọc, làm những màn hình đó đơn giản hơn: ít tùy chọn lọc hơn, sort mặc định an toàn, và hạn chế phạm vi ngày.\n\nƯu tiên các view đã được cache hoặc tính toán trước cho những trang quan trọng. Một "tổng quan tài khoản" đọc từ cache hoặc bảng tóm tắt an toàn hơn là tải raw event log hoặc join nhiều bảng.\n\nCách thực tế giữ các đọc sống mà không làm nặng hơn:\n\n- Dùng kích thước trang nhỏ hơn và bỏ nút "hiển thị tất cả"\n- Thay sort phức tạp bằng thứ tự mặc định (ví dụ "mới nhất trước")\n- Hoãn các đọc không cần thiết như analytics, gợi ý, và biểu đồ hoạt động\n- Ưu tiên tóm tắt cache hơn lịch sử thô\n- Cho phép dữ liệu hơi cũ nếu giúp các trang cốt lõi phản hồi\n\nVí dụ cụ thể: trong sự cố CRM, giữ Xem liên hệ, Xem trạng thái giao dịch, và Xem ghi chú gần nhất. Tạm ẩn Tìm kiếm nâng cao, biểu đồ doanh thu và toàn bộ timeline email, và cho biết dữ liệu có thể lùi vài phút.\n\n## Xử lý job, webhook và tích hợp\n\nKhi bật chế độ chỉ đọc, bất ngờ lớn thường không phải UI mà là các writer vô hình: job nền, sync theo lịch, hành động admin hàng loạt và tích hợp bên thứ ba vẫn đập vào DB.\n\nBắt đầu bằng việc dừng công việc nền tạo hoặc cập nhật bản ghi. Thủ phạm phổ biến là nhập khẩu, sync đêm, gửi email ghi log giao nhận, rollup analytics, và vòng retry lặp lại cố cập nhật thất bại. Tạm dừng các việc này giảm nhanh áp lực và tránh làn sóng tải thứ hai.\n\nMặc định an toàn là tạm dừng hoặc điều tiết các job nặng về ghi và mọi queue consumer ghi kết quả, vô hiệu hóa hành động admin hàng loạt (cập nhật hàng loạt, xóa hàng loạt, re-index lớn), và trả lỗi nhanh cho endpoint ghi với phản hồi tạm thời thay vì để timeout.\n\nVới webhook và tích hợp, rõ ràng tốt hơn là lạc quan. Nếu bạn chấp nhận webhook mà không thể xử lý, bạn sẽ tạo mismatch và công việc hỗ trợ. Khi ghi tạm dừng, trả lỗi tạm thời để bên gửi thử lại sau, và đảm bảo thông điệp UI khớp với điều bạn làm phía sau.\n\nCẩn thận với việc "đưa vào hàng đợi chờ sau". Nghe có vẻ thân thiện, nhưng có thể tạo backlog mà dội lên hệ thống ngay khi bạn bật lại ghi. Chỉ buffer ghi của người dùng nếu bạn chắc idempotency, giới hạn kích thước queue, và hiển thị trạng thái thực cho người dùng (đang chờ vs đã lưu).\n\nCuối cùng, audit các writer hàng loạt ẩn trong sản phẩm của bạn. Nếu một automation có thể cập nhật hàng nghìn dòng, nó nên bị bắt tắt trong chế độ chỉ đọc ngay cả khi phần còn lại của app còn tải được.\n\n## Các sai lầm phổ biến làm tồi tệ thêm sự cố\n\nCách nhanh nhất làm sự cố tồi tệ hơn là coi chế độ chỉ đọc là thay đổi trang trí. Nếu bạn chỉ vô hiệu nút trong UI, người ta vẫn có thể ghi qua API, tab cũ, app di động và job nền. DB vẫn chịu áp lực, và bạn cũng mất uy tín vì người dùng thấy "đã lưu" ở chỗ này nhưng thiếu thay đổi ở chỗ khác.\n\nChế độ chỉ đọc thực sự cần một quy tắc rõ ràng: server từ chối mọi ghi, mọi lúc, cho mọi client.\n\n### Sai lầm cần tránh\n\nNhững mẫu sau thường xuất hiện khi DB quá tải:\n\n- Chỉ chặn chỉnh sửa ở UI trong khi backend vẫn chấp nhận POST, PUT, PATCH, DELETE\n- Quên các đường dẫn ẩn: bảng admin, công cụ nội bộ, endpoint import, và API công khai được tích hợp sử dụng\n- Để hệ thống bật/tắt liên tục giữa bình thường và chỉ đọc\n- Hiển thị thông điệp mơ hồ như "Có lỗi xảy ra"\n- Cho phép ghi một phần làm dữ liệu không nhất quán\n\n### Cách tránh chúng\n\nLàm cho hệ thống hành xử dự đoán được. Thi hành một công tắc server-side duy nhất từ chối ghi với phản hồi rõ ràng. Thêm cooldown để một khi vào chế độ chỉ đọc thì ở đó tối thiểu một khoảng thời gian (ví dụ 10–15 phút) trừ khi có người vận hành can thiệp.\n\nNghiêm ngặt về toàn vẹn dữ liệu. Nếu một ghi không thể hoàn tất, hủy toàn bộ thao tác và nói rõ người dùng phải làm gì tiếp. Một thông điệp đơn giản như "Chế độ chỉ đọc: xem được, thay đổi tạm dừng. Thử lại sau." giảm các lần thử lặp lại.\n\n## Kiểm tra nhanh trước và trong sự cố\n\nChế độ chỉ đọc chỉ hữu dụng nếu dễ bật và hành xử giống nhau ở mọi nơi. Trước khi có vấn đề, đảm bảo có một công tắc duy nhất (feature flag, config, admin switch) mà on-call có thể bật trong vài giây, không cần deploy.\n\nKhi nghi ngờ DB quá tải, làm một kiểm tra nhanh xác nhận những điều cơ bản:\n\n- Gạt công tắc trong môi trường an toàn và xác nhận nó có hiệu lực ngay lập tức\n- Thử một vài hành động ghi (lưu, xóa, nhập) và xác nhận mọi endpoint ghi trả cùng một phản hồi bị chặn và mã trạng thái giống nhau\n- Kiểm tra banner đã sẵn sàng, ngắn và hiển thị trên các màn hình quan trọng\n- Tải 3 trang hàng đầu của bạn (ví dụ: login, dashboard, view bản ghi) và xác nhận chúng vẫn render dưới áp lực\n- Đảm bảo support có đoạn script một đoạn miêu tả cái gì hoạt động, cái gì tạm dừng, và chỗ để xem cập nhật\n\nTrong sự cố, giữ một người tập trung kiểm tra trải nghiệm người dùng, không chỉ dashboard. Một kiểm tra nhanh ở cửa sổ ẩn danh bắt lỗi như banner ẩn, form hỏng, hoặc spinner vô tận tạo thêm traffic làm mới.\n\nLên kế hoạch cho việc kết thúc trước khi bật. Quy định "khỏe" nghĩa là gì (độ trễ, tỉ lệ lỗi, replication lag) và làm xác minh ngắn sau khi bật lại: tạo một bản ghi thử, chỉnh sửa nó, và xác nhận số lượng và hoạt động gần đây trông đúng.\n\n## Ví dụ sự cố: giữ CRM dùng được trong khi chặn chỉnh sửa\n\nLà 10:20 sáng. CRM chậm và CPU DB bị chiếm. Ticket hỗ trợ bắt đầu: người dùng không lưu được chỉnh sửa liên hệ và giao dịch. Nhưng đội vẫn cần tra số điện thoại, xem giai đoạn giao dịch và đọc ghi chú mới nhất trước các cuộc gọi.\n\nBạn chọn quy tắc đơn giản: đóng băng mọi thứ ghi, giữ các đọc có giá trị nhất. Thực tế là tìm kiếm liên hệ, trang chi tiết liên hệ và view pipeline giao dịch vẫn hoạt động. Chỉnh sửa liên hệ, tạo giao dịch mới, thêm ghi chú và nhập khẩu bị chặn.\n\nTrong UI, thay đổi phải rõ ràng và bình tĩnh. Ở màn hình chỉnh sửa, nút Lưu bị vô hiệu và form vẫn hiển thị để người dùng sao chép những gì họ đã gõ. Một banner trên cùng nói: "Chế độ chỉ đọc đang bật do tải cao. Có thể xem dữ liệu. Các thay đổi tạm dừng. Vui lòng thử lại sau." Nếu người dùng vẫn kích hoạt ghi (ví dụ qua API), trả thông điệp rõ ràng và tránh retry tự động đập vào DB.\n\nVề mặt vận hành, giữ luồng ngắn và lặp lại được. Bật chế độ chỉ đọc và xác nhận mọi endpoint ghi tuân thủ. Tạm dừng job nền ghi (sync, import, log email, backfill analytics). Điều tiết hoặc tạm dừng webhook và tích hợp tạo cập nhật. Giám sát tải DB, tỉ lệ lỗi và các truy vấn chậm. Đăng trạng thái với phần bị ảnh hưởng (chỉnh sửa) và cái vẫn hoạt động (tìm kiếm và xem).\n\nPhục hồi không chỉ là gạt công tắc lại. Bật lại ghi dần dần, kiểm tra log lỗi cho các lưu thất bại, và quan sát cơn bão ghi từ các job đang chờ. Rồi thông báo rõ: "Chế độ chỉ đọc đã tắt. Lưu đã khôi phục. Nếu bạn đã cố lưu giữa 10:20 và 10:55, vui lòng kiểm tra lại thay đổi gần nhất."\n\n## Bước tiếp theo: biến chế độ chỉ đọc thành một phần của playbook\n\nChế độ chỉ đọc hoạt động tốt nhất khi nó nhàm chán và lặp lại được. Mục tiêu là theo một kịch bản ngắn với người chịu trách nhiệm và các bước kiểm tra rõ ràng.\n\n### Xây playbook nhỏ, dễ dùng\n\nGiữ nó trong một trang. Bao gồm các trigger (mấy tín hiệu đủ để chuyển sang chỉ đọc), công tắc chính xác bạn gạt và cách xác nhận ghi bị chặn, danh sách ngắn các đọc phải giữ, vai trò rõ ràng (ai gạt công tắc, ai theo dõi metrics, ai xử lý support), và tiêu chí thoát (cần gì trước khi bật lại ghi, và cách xử lý backlog).\n\n### Chuẩn bị nội dung UI trước khi cần\n\nViết và phê duyệt văn bản ngay bây giờ để bạn không tranh luận về từ ngữ trong outage. Một bộ đơn giản thường bao phủ hầu hết tình huống:\n\n- Banner: "Chúng tôi đang ở chế độ chỉ đọc trong khi khôi phục hiệu năng. Bạn có thể xem dữ liệu, nhưng thay đổi tạm thời bị vô hiệu."\n- Khi hành động bị chặn: "Lưu đang tạm dừng. Thay đổi của bạn chưa được áp dụng. Vui lòng thử lại sau vài phút."\n- Chi tiết trạng thái: "Cập nhật lần cuối lúc HH:MM. Cập nhật tiếp trong 10 phút."\n\nDiễn tập chuyển đổi trong staging và bấm giờ. Đảm bảo support và on-call tìm công tắc nhanh và log thể hiện rõ các lần ghi bị chặn. Sau mỗi sự cố, rà soát các đọc thật sự quan trọng, cái là nice-to-have, và cái vô tình tạo thêm tải, rồi cập nhật checklist.\n\nNếu bạn xây sản phẩm trên Koder.ai (koder.ai), có thể hữu ích khi coi read-only là công tắc hàng đầu trong app được sinh để UI và guards phía server luôn nhất quán khi bạn cần nhất.