インシデント時の読み取り専用モード — 読み取りを維持し、書き込みを停止する

データベースが逼迫しているとき、まず何が壊れるか

データベースが過負荷になると、ユーザーが見るのはきれいな「停止」メッセージではありません。タイムアウト、途中までしか読み込まれないページ、ずっと回り続けるボタン、そして時々成功して時々失敗する操作です。保存が一度成功して、次は "Something went wrong." のようなエラーになる――その不確実さがインシデントを混乱させます。

最初に壊れるのは通常、書き込み中心の経路です：レコード編集、チェックアウト、フォーム送信、バックグラウンド更新、トランザクションやロックを伴う処理。負荷がかかると書き込みは遅くなり互いにブロックし、ロックを持つことで読み取りも遅くなります。

ランダムなエラーは制御された制限よりも悪く感じられます。ユーザーは次に何をすべきかわからず、リトライやリフレッシュ、再クリックを繰り返してさらに負荷を増やします。サポートチケットが急増し、システムが「まあまあ動いている」ように見えるため、誰も信用できなくなります。

インシデント時の読み取り専用モードの目的は完璧ではありません。最も重要な部分を使える状態に保つことです：主要なレコードの閲覧、検索、ステータス確認、必要なもののダウンロード。リスクのある操作（書き込み）を意図的に止めたり遅らせたりして、データベースを回復させ、残った読み取りを応答性のあるままにします。

期待値を明確に伝えてください。これは一時的な制限であり、データが削除されているわけではありません。ほとんどの場合、既存のデータは安全でそのままですが、データベースが健康になるまで変更を一時停止しているだけです。

読み取り専用モードが実際に意味すること

インシデント時の読み取り専用モードは、一時的に製品を閲覧可能なままにしつつ、データを変更するすべての操作を拒否する状態です。目的はシンプル：サービスを有用なままに保ちつつ、データベースに余計な負荷をかけないこと。

平たく言えば、参照はできるが変更はできない、ということです。通常、ページの閲覧、検索、フィルタリング、レコードを開くことは動作します。フォームの保存、設定の編集、コメント投稿、ファイルアップロード、新規アカウント作成はブロックされます。

実務的には、もし操作が行の更新、作成、削除、またはキューへの書き込みを伴うなら許可されません。多くのチームは監査ログの同期書き込みや、最後の閲覧時刻の更新、DBに保存する分析イベントのような「隠れた書き込み」もブロックします。

読み取り専用モードは、読み取りが大きくは動いているが書き込みレイテンシが上昇している、ロック競合が増えている、または書き込み中心のバックログが全体を遅くしているときに適切な選択です。

基本的な読み取りもタイムアウトする、キャッシュが必須の要素を提供できない、システムが安全に何をすべきかをユーザーに伝えられないようなら完全オフラインにしてください。

なぜこれが有効か：書き込みは単純な読み取りよりもはるかにコストが高いことがあります。書き込みはインデックス、制約、ロック、後続クエリを誘発します。書き込みをブロックすると、失敗した保存をクライアントが繰り返し送るリトライ嵐も防げます。

例：CRMのインシデント時、ユーザーはアカウント検索や連絡先詳細、最近の案件を閲覧できますが、編集・作成・インポートは無効化され、保存リクエストは明確なメッセージとともに即座に拒否されます。

維持すべき読み取りと停止すべき書き込みを選ぶ

インシデント時に読み取り専用モードに切り替える目的は「すべてを動かす」ことではありません。最も重要な画面が読み込めること、そしてデータベースに余分な負荷をかけるものは速やかに安全に停止することです。

まず、悪い日でも動かしておくべき少数のユーザー操作を名前で挙げてください。これは通常、小さな読み取りで意思決定を妨げないものです：最新のレコード閲覧、ステータス確認、短いリストの検索、キャッシュ済みのレポートのダウンロードなど。

次に、重大な害を与えずに一時停止できるものを決めます。多くの書き込み経路はインシデント時には「あると良い」ものでしかありません：編集、大量更新、インポート、コメント、添付、分析イベント、追加クエリを引く操作など。

判断を単純にするため、操作を次の3つのバケットに分けるとよいです：

• 必ず維持：今すぐユーザーの意思決定を促す小さく高速な読み取り
• 一時停止可能：負荷やロックを増やす書き込みや重い読み取り
• 劣化可能：キャッシュや部分ビューで代替可能な機能

また時間の見込みも決めてください。数分程度の見込みならほとんどの書き込みを厳しくブロックできます。数時間を見込むなら、非常に限られた安全な書き込み（パスワードリセットや重要なステータス更新など）を許可し、その他はキュー化することを考えます。

優先度は早めに合意してください：完全性より安全性を重視する方が良いです。変更を明確に「一時停止中」と表示する方が、半端に成功してデータ不整合を招く書き込みを許可するよりも優れています。

いつ切り替えるかの判断

読み取り専用に切り替えるのはトレードオフです：機能は減るがプロダクトは使えるままでデータベースは健全になります。ユーザーがリトライやタイムアウト、スタック接続の悪循環を起こす前に行動するのが目的です。

ひとことで説明できる少数のシグナルを監視してください。2つ以上が同時に出たら早期警告として扱います：

• リクエストのタイムアウトや明確なレイテンシ閾値を越える（例：p95が300msから3sに跳ね上がる）
• 数分以上にわたってCPUが高負荷で張り付く（短いスパイクではない）
• コネクションプールの枯渇（接続がなくリクエストが待たされる）
• 同じいくつかの遅いクエリでスロークエリログが埋まる
• ロック待ちやデッドロック、失敗トランザクションによるエラーレート上昇

ただし指標だけを唯一のトリガーにしてはいけません。人的判断も加えましょう：オンコールがインシデント状態を宣言して読み取り専用をオンにする、という手順です。これがプレッシャー下での議論を止め、操作を監査可能にします。

閾値は覚えやすく伝えやすくしてください。「データベースが過負荷のため書き込みを一時停止しています」は「飽和に達しました」よりも明確です。また誰がスイッチを押せるか、どこで制御するかも定義しておきます。

モードを短時間で行ったり来たりしないようにヒステリシスを加えます：一度読み取り専用にしたら最低ウィンドウ（例えば10〜15分）は維持し、主要な指標がしばらく正常になってから戻すようにします。これによりフォームが動いたり動かなくなったりしてユーザーを混乱させることを避けられます。

安全に読み取り専用を有効にする手順

インシデント時の読み取り専用モードは慌てて行うものではなく、コントロールされた変更として扱ってください。目的は書き込みを止めてデータベースを保護しつつ、最も価値のある読み取りを維持することです。

安全なロールアウトの順序

できればスイッチを切る前にコードパスをデプロイしておきます。そうすれば読み取り専用をオンにするのはトグル操作だけで済み、ライブ編集を避けられます。

1. 単一のインシデント用トグルを作る（機能フラグや設定）。システム全体が参照するグローバルで単純なものにします：READ_ONLY=true。同期が外れる可能性がある複数のフラグは避けます。
2. UIを更新して書き込み試行を防ぐ。 保存ボタンを無効化し、編集フォームを隠すか表示を切り替え、入力をプレーンテキストにします。データは見せ続けて業務を進められるようにします（閲覧、検索、エクスポート）。
3. サーバー側で強制する。 ミドルウェア、コントローラガード、サービス層など、1か所で書き込みをブロックして全てのクライアント（モバイル、API、オートメーション）をカバーします。
4. ブロックされた書き込みには明確で一貫したエラーを返す。 専用のステータスコードとメッセージを使いましょう："編集は安定化するまで一時的に無効です。データは安全です。後で再試行してください。" 汎用の500のような応答はデータ損失の印象を与えます。
5. ブロックされた書き込み試行をすべてログに残す。 ユーザー、エンドポイント、操作種別を記録します。ログに含めるペイロードは最小限にして機密情報を避けます。これらのログはUXギャップの修正や重要な操作のリプレイに役立ちます。

再発を防ぐ小さな工夫

読み取り専用がアクティブなときは、データベースに到達する前に素早く失敗させてください。検証クエリを実行してから書き込みをブロックするのではなく、DBに触れない最速の失敗を返すことが重要です。

混乱とサポートチケットを減らすUIメッセージ

読み取り専用を有効にしたら、UIは修復の一部になります。人々が保存を押して漠然としたエラーを受け続けると、リトライやリフレッシュ、チケット作成が増えます。明確なメッセージは負荷と不満を減らします。

見やすく永続的なバナーをアプリ上部に表示するのが良いパターンです。短く事実を伝えます：何が起きているか、ユーザーは何を期待すべきか、今できること。消えるトーストに隠さないでください。

何が動き、何が停止し、次に何をするかを伝える

ユーザーは主に作業が続けられるかを知りたいだけです。平易な言葉で明記してください。多くの製品では次のようになります：

• 動くもの： レコードの閲覧、検索、ダウンロード、ダッシュボードの閲覧
• 停止中： 作成、編集、削除、アップロード、決済、メッセージ送信
• 代替策： 重要な情報をコピーする、ビューをエクスポートする、後で再試行する
• 更新予定： "15分後にここで更新を投稿します。"

簡単なステータスラベルも進捗を理解する助けになります。"Investigating"（調査中）は原因を探している状態、"Stabilizing"（安定化中）は負荷を下げている段階、"Recovering"（回復中）はまもなく書き込みが戻るが遅い可能性がある、という具合です。

落ち着いた具体的なトーンを保つ

"Something went wrong" や "権限がありません" のような曖昧で責任転嫁的な文言は避けてください。ボタンが無効になっているならラベルに理由を書きましょう："システム安定化のため編集は一時停止中です。"

小さな例：CRMでは連絡先や案件ページは読み取り可能に保ち、Edit、Add note、New dealを無効化します。ユーザーがそれでも操作を試みたら短いダイアログで："現在変更は一時停止中です。このレコードをコピーするかリストをエクスポートして、後で再試行してください。" と表示します。

負荷を悪化させずに重要な読み取りを維持する

読み取り専用に切り替えるとき、目標は「すべてを見せる」ではなく「人々が頼る少数のページを負荷を増やさずに維持する」ことです。

負荷の高い画面を削ぎ落とすことから始めましょう。多数のフィルタを備えた長いテーブル、複数フィールド横断のフリーテキスト検索、凝ったソートは遅いクエリを誘発します。読み取り専用時はこれらの画面を簡素化します：フィルタを減らす、安全なデフォルトソート、日付範囲の上限を設けるなど。

重要なページにはキャッシュや事前集計ビューを優先してください。イベントログを生で読み込んだり多数のテーブルを結合するより、キャッシュやサマリテーブルの方が安全です。

読み取りを維持しつつ負荷を増やさない実践例：

• ページサイズを小さくし、「すべて表示」を外す
• 複雑なソートをやめてデフォルト順（例："最新順"）にする
• 分析やレコメンデーション、アクティビティチャートのような非必須読み取りを後回しにする
• 生データではなくキャッシュ済みサマリを使う
• コアページの応答性を保つためにわずかに古いデータを許容する

具体例：CRMのインシデントでは、連絡先の閲覧、案件ステータス、最後のメモの表示は維持し、高度な検索、収益チャート、全メールタイムラインは一時的に隠し、データが数分古い可能性があることを明示します。

ジョブ、Webhook、統合はどう扱うか

読み取り専用に切り替えるとき、驚きはしばしばUIではなく見えない書き込み側にあります：バックグラウンドジョブ、定期同期、管理者の一括操作、サードパーティの統合などがデータベースを叩き続けることです。

まずレコードを作成・更新するバックグラウンド作業を止めてください。典型的な加害者はインポート、夜間同期、配信ログを書き込むメール送信、分析ロールアップ、同じ失敗更新を再試行するループです。これらを止めると負荷は急速に下がり、二次的な負荷波を避けられます。

安全なデフォルトは、書き込みが重いジョブや結果を書き込むキューコンシューマーを一時停止またはスロットルし、管理者の一括操作（大量更新、バルク削除、大規模な再インデックス）を無効化し、タイムアウトさせる代わりに書き込みエンドポイントで素早く一時応答を返すことです。

Webhookや統合については、楽観的に受け入れるよりも明確にする方が良いです。Webhookを受け入れて処理できないと、不整合が生じサポートが増えます。書き込みを停止している間は一時的な失敗を返して送信側に後で再試行させ、UIメッセージと裏側の動作を一致させてください。

"後でキューする" バッファリングは親切に聞こえますが、書き込み再開時にバックログが一斉に流れ込みシステムを圧倒する可能性があります。ユーザー書き込みをバッファするなら冪等性を保証し、キューサイズに上限を設け、ユーザーに実際の状態（保留中と保存済み）を表示できる場合に限ってください。

最後に、自社製品内の隠れた一括書き込みを監査してください。自動化で何千行も更新できるなら、読み取り専用時には強制的にオフにするべきです。

インシデントを悪化させる一般的なミス

読み取り専用を見た目だけの変更と扱うと、最も早く状況を悪化させます。UIでボタンを無効にするだけだと、APIや古いタブ、モバイルアプリ、バックグラウンドジョブからはまだ書き込みが発生します。結果としてデータベースへの負荷は続き、ある場所では「保存された」と表示されるのに別の場所では変更がない、という信頼の喪失につながります。

インシデント時の本当の読み取り専用モードは一つの明確なルールを持つべきです：サーバーがすべてのクライアントに対して常に書き込みを拒否すること。

注意すべきミス

負荷時に繰り返し見られるパターン：

• UIだけで編集をブロックし、バックエンドはまだPOST/PUT/PATCH/DELETEを受け付けている
• 管理パネル、内部ツール、インポートエンドポイント、統合で使われる公開APIなど隠れた経路を忘れる
• 正常と読み取り専用を毎分のように切り替えるフラッピング
• "Something went wrong" のような曖昧な表示
• 部分的な書き込みを許してデータ不整合を生む

回避方法

システムを予測可能に振る舞わせます。一つのサーバー側スイッチで書き込みを明確に拒否し、同じ明確な応答を返すようにします。読み取り専用に入ったら設定された時間は維持するクールダウンを入れ、オペレータが変更しない限り短時間で戻らないようにします。

データ整合性には厳格に。書き込みが完全に完了できないなら操作全体を失敗させ、次に何をすべきかをユーザーに伝えます。"読み取り専用モード：閲覧は可能、変更は一時停止中です。後で再試行してください。" のような単純なメッセージは繰り返しのリトライを減らします。

インシデント前と中のクイックチェック

読み取り専用は簡単に切り替えられ、どこでも同じ動作をする必要があります。問題が起きる前に、フラグ（機能フラグ、設定、管理スイッチ）がオンコールによって数秒で有効にでき、デプロイなしで切り替えられることを確認してください。

データベース過負荷を疑ったら、次の簡単な確認を行います：

• 安全な環境でトグルを切って即座に効果があるか確認する
• いくつかの書き込み操作（保存、削除、インポート）を実行し、全て同じブロック応答とステータスコードが返るか確認する
• バナーテキストが主要画面に短く見やすく用意されているか確認する
• トップ3ページ（例：ログイン、ダッシュボード、レコード閲覧）を読み込み、ストレス下でもレンダリングされるか確認する
• サポートに「何が動き、何が停止中か」を説明する1段落のスクリプトを用意する

インシデント中は、ダッシュボードだけでなくユーザー体験の確認に1人を割り当ててください。シークレットウィンドウでの簡単なチェックは、非表示のバナー、壊れたフォーム、無限スピナーなどを見つけ、追加のリフレッシュトラフィックを未然に防ぎます。

オンにする前に終了手順を計画してください。「健康」とは何か（レイテンシ、エラーレート、レプリケーション遅延）を定義し、戻す際には短い確認を行います：テストレコードを一つ作成・編集して、件数や最近のアクティビティが正しいことを確認します。

例：CRMを読み取り可能に保ちつつ編集をブロックするインシデント

午前10:20。CRMが遅く、データベースCPUが張り付いています。サポートに「連絡先や案件の編集が保存できない」という報告が増えます。しかしチームは電話前に電話番号や案件のステージ、最後のメモを見たい状況です。

単純なルールを採ります：書き込みはすべて凍結し、最も価値ある読み取りは維持する。実務では連絡先検索、連絡先詳細、案件パイプラインの表示は使えるままにし、連絡先編集、新規案件作成、メモ追加、インポートはブロックします。

UIでは変化を目立たせつつ落ち着いた表現にします。編集画面では保存ボタンを無効化し、フォームは表示したままにしてユーザーが入力内容をコピーできるようにします。上部にバナーを表示して："高負荷のため読み取り専用モードが有効です。閲覧は可能ですが変更は一時停止中です。後でもう一度お試しください。" と伝えます。ユーザーがAPI経由で書き込みを試みた場合は明確なメッセージを返し、データベースを叩く自動リトライは避けます。

運用面では手順を短く反復可能にします。読み取り専用を有効にしてすべての書き込みエンドポイントがそれを尊重しているかを検証します。書き込むバックグラウンドジョブ（同期、インポート、メールログ、分析バックフィル）を停止します。Webhookや統合をスロットルまたは停止し、データベース負荷、エラーレート、スロークエリを監視します。影響範囲（編集は停止）と維持される機能（検索と閲覧）をステータスに投稿します。

回復は単にスイッチを戻すだけではありません。書き込みを段階的に再有効化し、失敗した保存のログを確認し、キュー化されたジョブからの書き込み嵐に注意します。その後、明確に伝えます："読み取り専用モードは解除されました。保存が復旧しました。10:20〜10:55の間に保存を試みた場合は、最後の変更を再確認してください。"

次のステップ：読み取り専用モードをプレイブックの一部にする

読み取り専用モードは退屈で反復可能であるほど有効です。目標は短い台本に従い、明確な担当とチェックを持つことです。

小さく実用的なプレイブックを作る

1ページに収めてください。トリガー（読み取り専用にする少数のシグナル）、切り替える具体的なスイッチと書き込みがブロックされていることを確認する方法、維持すべき読み取りのリスト、役割（誰がスイッチを押すか、誰が指標を見るか、誰がサポートを担当するか）、終了条件（書き込みを再有効化する前に何が満たされるべきか、バックログの流し方）を含めます。

必要になったときに備えてUI文言を用意する

障害時に文言で揉めないよう、今のうちに文言を作成・承認しておきます。基本的なセットがあれば多くのケースに対応できます：

• バナー："パフォーマンス回復中のため読み取り専用モードです。データは閲覧できますが、変更は一時的に無効になっています。"
• ブロックされた操作での文言："現在保存は一時停止中です。変更は適用されていません。数分後に再試行してください。"
• ステータス詳細："最終更新 HH:MM。次回更新は10分後。"

ステージングで切り替えを練習し、実行時間を計ってください。サポートとオンコールがトグルを素早く見つけられること、ログにブロックした書き込みが明確に残ることを確認します。インシデントごとに、どの読み取りが本当に重要だったか、どれが単にあると良いだけだったか、どれが誤って負荷を増やしたかをレビューしてチェックリストを更新してください。

もしKoder.ai (koder.ai)上でプロダクトを構築しているなら、生成されたアプリで読み取り専用をファーストクラスのトグルとして扱うと、UIとサーバー側の書き込みガードが最も必要なときに一貫して動くようになります。