2025年10月02日·1 分
インシデント時の読み取り専用モード — 読み取りを維持し、書き込みを停止する
インシデント時の読み取り専用モードで書き込みをブロックし、重要な読み取りを維持しつつUIで明確に伝える方法を解説します。
インシデント時の読み取り専用モードで書き込みをブロックし、重要な読み取りを維持しつつUIで明確に伝える方法を解説します。
データベースが過負荷になると、ユーザーが見るのはきれいな「停止」メッセージではありません。タイムアウト、途中までしか読み込まれないページ、ずっと回り続けるボタン、そして時々成功して時々失敗する操作です。保存が一度成功して、次は "Something went wrong." のようなエラーになる――その不確実さがインシデントを混乱させます。
最初に壊れるのは通常、書き込み中心の経路です：レコード編集、チェックアウト、フォーム送信、バックグラウンド更新、トランザクションやロックを伴う処理。負荷がかかると書き込みは遅くなり互いにブロックし、ロックを持つことで読み取りも遅くなります。
ランダムなエラーは制御された制限よりも悪く感じられます。ユーザーは次に何をすべきかわからず、リトライやリフレッシュ、再クリックを繰り返してさらに負荷を増やします。サポートチケットが急増し、システムが「まあまあ動いている」ように見えるため、誰も信用できなくなります。
インシデント時の読み取り専用モードの目的は完璧ではありません。最も重要な部分を使える状態に保つことです：主要なレコードの閲覧、検索、ステータス確認、必要なもののダウンロード。リスクのある操作（書き込み）を意図的に止めたり遅らせたりして、データベースを回復させ、残った読み取りを応答性のあるままにします。
期待値を明確に伝えてください。これは一時的な制限であり、データが削除されているわけではありません。ほとんどの場合、既存のデータは安全でそのままですが、データベースが健康になるまで変更を一時停止しているだけです。
インシデント時の読み取り専用モードは、一時的に製品を閲覧可能なままにしつつ、データを変更するすべての操作を拒否する状態です。目的はシンプル：サービスを有用なままに保ちつつ、データベースに余計な負荷をかけないこと。
平たく言えば、参照はできるが変更はできない、ということです。通常、ページの閲覧、検索、フィルタリング、レコードを開くことは動作します。フォームの保存、設定の編集、コメント投稿、ファイルアップロード、新規アカウント作成はブロックされます。
実務的には、もし操作が行の更新、作成、削除、またはキューへの書き込みを伴うなら許可されません。多くのチームは監査ログの同期書き込みや、最後の閲覧時刻の更新、DBに保存する分析イベントのような「隠れた書き込み」もブロックします。
読み取り専用モードは、読み取りが大きくは動いているが書き込みレイテンシが上昇している、ロック競合が増えている、または書き込み中心のバックログが全体を遅くしているときに適切な選択です。
基本的な読み取りもタイムアウトする、キャッシュが必須の要素を提供できない、システムが安全に何をすべきかをユーザーに伝えられないようなら完全オフラインにしてください。
なぜこれが有効か：書き込みは単純な読み取りよりもはるかにコストが高いことがあります。書き込みはインデックス、制約、ロック、後続クエリを誘発します。書き込みをブロックすると、失敗した保存をクライアントが繰り返し送るリトライ嵐も防げます。
例：CRMのインシデント時、ユーザーはアカウント検索や連絡先詳細、最近の案件を閲覧できますが、編集・作成・インポートは無効化され、保存リクエストは明確なメッセージとともに即座に拒否されます。
インシデント時に読み取り専用モードに切り替える目的は「すべてを動かす」ことではありません。最も重要な画面が読み込めること、そしてデータベースに余分な負荷をかけるものは速やかに安全に停止することです。
まず、悪い日でも動かしておくべき少数のユーザー操作を名前で挙げてください。これは通常、小さな読み取りで意思決定を妨げないものです：最新のレコード閲覧、ステータス確認、短いリストの検索、キャッシュ済みのレポートのダウンロードなど。
次に、重大な害を与えずに一時停止できるものを決めます。多くの書き込み経路はインシデント時には「あると良い」ものでしかありません：編集、大量更新、インポート、コメント、添付、分析イベント、追加クエリを引く操作など。
判断を単純にするため、操作を次の3つのバケットに分けるとよいです：
また時間の見込みも決めてください。数分程度の見込みならほとんどの書き込みを厳しくブロックできます。数時間を見込むなら、非常に限られた安全な書き込み（パスワードリセットや重要なステータス更新など）を許可し、その他はキュー化することを考えます。
優先度は早めに合意してください：完全性より安全性を重視する方が良いです。変更を明確に「一時停止中」と表示する方が、半端に成功してデータ不整合を招く書き込みを許可するよりも優れています。
読み取り専用に切り替えるのはトレードオフです：機能は減るがプロダクトは使えるままでデータベースは健全になります。ユーザーがリトライやタイムアウト、スタック接続の悪循環を起こす前に行動するのが目的です。
ひとことで説明できる少数のシグナルを監視してください。2つ以上が同時に出たら早期警告として扱います：
ただし指標だけを唯一のトリガーにしてはいけません。人的判断も加えましょう：オンコールがインシデント状態を宣言して読み取り専用をオンにする、という手順です。これがプレッシャー下での議論を止め、操作を監査可能にします。
閾値は覚えやすく伝えやすくしてください。「データベースが過負荷のため書き込みを一時停止しています」は「飽和に達しました」よりも明確です。また誰がスイッチを押せるか、どこで制御するかも定義しておきます。
モードを短時間で行ったり来たりしないようにヒステリシスを加えます：一度読み取り専用にしたら最低ウィンドウ（例えば10〜15分）は維持し、主要な指標がしばらく正常になってから戻すようにします。これによりフォームが動いたり動かなくなったりしてユーザーを混乱させることを避けられます。
インシデント時の読み取り専用モードは慌てて行うものではなく、コントロールされた変更として扱ってください。目的は書き込みを止めてデータベースを保護しつつ、最も価値のある読み取りを維持することです。
できればスイッチを切る前にコードパスをデプロイしておきます。そうすれば読み取り専用をオンにするのはトグル操作だけで済み、ライブ編集を避けられます。
READ_ONLY=true。同期が外れる可能性がある複数のフラグは避けます。読み取り専用がアクティブなときは、データベースに到達する前に素早く失敗させてください。検証クエリを実行してから書き込みをブロックするのではなく、DBに触れない最速の失敗を返すことが重要です。
読み取り専用を有効にしたら、UIは修復の一部になります。人々が保存を押して漠然としたエラーを受け続けると、リトライやリフレッシュ、チケット作成が増えます。明確なメッセージは負荷と不満を減らします。
見やすく永続的なバナーをアプリ上部に表示するのが良いパターンです。短く事実を伝えます：何が起きているか、ユーザーは何を期待すべきか、今できること。消えるトーストに隠さないでください。
ユーザーは主に作業が続けられるかを知りたいだけです。平易な言葉で明記してください。多くの製品では次のようになります：
簡単なステータスラベルも進捗を理解する助けになります。"Investigating"（調査中）は原因を探している状態、"Stabilizing"（安定化中）は負荷を下げている段階、"Recovering"（回復中）はまもなく書き込みが戻るが遅い可能性がある、という具合です。
"Something went wrong" や "権限がありません" のような曖昧で責任転嫁的な文言は避けてください。ボタンが無効になっているならラベルに理由を書きましょう："システム安定化のため編集は一時停止中です。"
小さな例：CRMでは連絡先や案件ページは読み取り可能に保ち、Edit、Add note、New dealを無効化します。ユーザーがそれでも操作を試みたら短いダイアログで："現在変更は一時停止中です。このレコードをコピーするかリストをエクスポートして、後で再試行してください。" と表示します。
読み取り専用に切り替えるとき、目標は「すべてを見せる」ではなく「人々が頼る少数のページを負荷を増やさずに維持する」ことです。
負荷の高い画面を削ぎ落とすことから始めましょう。多数のフィルタを備えた長いテーブル、複数フィールド横断のフリーテキスト検索、凝ったソートは遅いクエリを誘発します。読み取り専用時はこれらの画面を簡素化します：フィルタを減らす、安全なデフォルトソート、日付範囲の上限を設けるなど。
重要なページにはキャッシュや事前集計ビューを優先してください。イベントログを生で読み込んだり多数のテーブルを結合するより、キャッシュやサマリテーブルの方が安全です。
読み取りを維持しつつ負荷を増やさない実践例：
具体例：CRMのインシデントでは、連絡先の閲覧、案件ステータス、最後のメモの表示は維持し、高度な検索、収益チャート、全メールタイムラインは一時的に隠し、データが数分古い可能性があることを明示します。
読み取り専用に切り替えるとき、驚きはしばしばUIではなく見えない書き込み側にあります：バックグラウンドジョブ、定期同期、管理者の一括操作、サードパーティの統合などがデータベースを叩き続けることです。
まずレコードを作成・更新するバックグラウンド作業を止めてください。典型的な加害者はインポート、夜間同期、配信ログを書き込むメール送信、分析ロールアップ、同じ失敗更新を再試行するループです。これらを止めると負荷は急速に下がり、二次的な負荷波を避けられます。
安全なデフォルトは、書き込みが重いジョブや結果を書き込むキューコンシューマーを一時停止またはスロットルし、管理者の一括操作（大量更新、バルク削除、大規模な再インデックス）を無効化し、タイムアウトさせる代わりに書き込みエンドポイントで素早く一時応答を返すことです。
Webhookや統合については、楽観的に受け入れるよりも明確にする方が良いです。Webhookを受け入れて処理できないと、不整合が生じサポートが増えます。書き込みを停止している間は一時的な失敗を返して送信側に後で再試行させ、UIメッセージと裏側の動作を一致させてください。
"後でキューする" バッファリングは親切に聞こえますが、書き込み再開時にバックログが一斉に流れ込みシステムを圧倒する可能性があります。ユーザー書き込みをバッファするなら冪等性を保証し、キューサイズに上限を設け、ユーザーに実際の状態（保留中と保存済み）を表示できる場合に限ってください。
最後に、自社製品内の隠れた一括書き込みを監査してください。自動化で何千行も更新できるなら、読み取り専用時には強制的にオフにするべきです。
読み取り専用を見た目だけの変更と扱うと、最も早く状況を悪化させます。UIでボタンを無効にするだけだと、APIや古いタブ、モバイルアプリ、バックグラウンドジョブからはまだ書き込みが発生します。結果としてデータベースへの負荷は続き、ある場所では「保存された」と表示されるのに別の場所では変更がない、という信頼の喪失につながります。
インシデント時の本当の読み取り専用モードは一つの明確なルールを持つべきです：サーバーがすべてのクライアントに対して常に書き込みを拒否すること。
負荷時に繰り返し見られるパターン：
システムを予測可能に振る舞わせます。一つのサーバー側スイッチで書き込みを明確に拒否し、同じ明確な応答を返すようにします。読み取り専用に入ったら設定された時間は維持するクールダウンを入れ、オペレータが変更しない限り短時間で戻らないようにします。
データ整合性には厳格に。書き込みが完全に完了できないなら操作全体を失敗させ、次に何をすべきかをユーザーに伝えます。"読み取り専用モード：閲覧は可能、変更は一時停止中です。後で再試行してください。" のような単純なメッセージは繰り返しのリトライを減らします。
読み取り専用は簡単に切り替えられ、どこでも同じ動作をする必要があります。問題が起きる前に、フラグ（機能フラグ、設定、管理スイッチ）がオンコールによって数秒で有効にでき、デプロイなしで切り替えられることを確認してください。
データベース過負荷を疑ったら、次の簡単な確認を行います：
インシデント中は、ダッシュボードだけでなくユーザー体験の確認に1人を割り当ててください。シークレットウィンドウでの簡単なチェックは、非表示のバナー、壊れたフォーム、無限スピナーなどを見つけ、追加のリフレッシュトラフィックを未然に防ぎます。
オンにする前に終了手順を計画してください。「健康」とは何か（レイテンシ、エラーレート、レプリケーション遅延）を定義し、戻す際には短い確認を行います：テストレコードを一つ作成・編集して、件数や最近のアクティビティが正しいことを確認します。
午前10:20。CRMが遅く、データベースCPUが張り付いています。サポートに「連絡先や案件の編集が保存できない」という報告が増えます。しかしチームは電話前に電話番号や案件のステージ、最後のメモを見たい状況です。
単純なルールを採ります：書き込みはすべて凍結し、最も価値ある読み取りは維持する。実務では連絡先検索、連絡先詳細、案件パイプラインの表示は使えるままにし、連絡先編集、新規案件作成、メモ追加、インポートはブロックします。
UIでは変化を目立たせつつ落ち着いた表現にします。編集画面では保存ボタンを無効化し、フォームは表示したままにしてユーザーが入力内容をコピーできるようにします。上部にバナーを表示して："高負荷のため読み取り専用モードが有効です。閲覧は可能ですが変更は一時停止中です。後でもう一度お試しください。" と伝えます。ユーザーがAPI経由で書き込みを試みた場合は明確なメッセージを返し、データベースを叩く自動リトライは避けます。
運用面では手順を短く反復可能にします。読み取り専用を有効にしてすべての書き込みエンドポイントがそれを尊重しているかを検証します。書き込むバックグラウンドジョブ（同期、インポート、メールログ、分析バックフィル）を停止します。Webhookや統合をスロットルまたは停止し、データベース負荷、エラーレート、スロークエリを監視します。影響範囲（編集は停止）と維持される機能（検索と閲覧）をステータスに投稿します。
回復は単にスイッチを戻すだけではありません。書き込みを段階的に再有効化し、失敗した保存のログを確認し、キュー化されたジョブからの書き込み嵐に注意します。その後、明確に伝えます："読み取り専用モードは解除されました。保存が復旧しました。10:20〜10:55の間に保存を試みた場合は、最後の変更を再確認してください。"
読み取り専用モードは退屈で反復可能であるほど有効です。目標は短い台本に従い、明確な担当とチェックを持つことです。
1ページに収めてください。トリガー（読み取り専用にする少数のシグナル）、切り替える具体的なスイッチと書き込みがブロックされていることを確認する方法、維持すべき読み取りのリスト、役割（誰がスイッチを押すか、誰が指標を見るか、誰がサポートを担当するか）、終了条件（書き込みを再有効化する前に何が満たされるべきか、バックログの流し方）を含めます。
障害時に文言で揉めないよう、今のうちに文言を作成・承認しておきます。基本的なセットがあれば多くのケースに対応できます：
ステージングで切り替えを練習し、実行時間を計ってください。サポートとオンコールがトグルを素早く見つけられること、ログにブロックした書き込みが明確に残ることを確認します。インシデントごとに、どの読み取りが本当に重要だったか、どれが単にあると良いだけだったか、どれが誤って負荷を増やしたかをレビューしてチェックリストを更新してください。
もしKoder.ai (koder.ai)上でプロダクトを構築しているなら、生成されたアプリで読み取り専用をファーストクラスのトグルとして扱うと、UIとサーバー側の書き込みガードが最も必要なときに一貫して動くようになります。
通常は書き込みパスが最初に劣化します：保存、編集、チェックアウト、インポートなど、トランザクションが必要な操作です。負荷がかかるとロックやコミットの遅延で書き込み同士がブロックし、それが読み取りも遅くすることがあります。
動作がときどき成功したり失敗したりすると予測できず不安になります。ユーザーはリトライやリロード、再クリックを繰り返してさらに負荷を増やし、タイムアウトやスタックしたリクエストが増えます。
データの閲覧はできるが変更は受け付けない一時的な状態です。ブラウズ、検索、レコードの表示は可能ですが、作成・更新・削除といった書き込みはブロックされます。
主データベースに書き込むすべての操作をブロックするのが基本です。監査ログや最終アクセス時刻、DBに保存する分析イベントのような「隠れた書き込み」も対象にしてください。行を変更するか、後で書き込むようなキューを発行するものは書き込みとみなします。
書き込みが連鎖的に悪化している兆候を見たらオンにします：タイムアウト、p95の急上昇、ロック待ち、コネクションプール枯渇、同じ遅いクエリの増加など。ユーザーのリトライ嵐が発生する前に切る方が良いです。
一つのグローバルトグルを使い、サーバー側で強制することです。UIでボタンを無効にするだけでは不十分です。全ての書き込みエンドポイントがデータベースに触れる前に早期に失敗するようにします。
恒常的なバナーで現在の状態、何が使えるか、何が停止中かを短く伝えてください。ブロックされた操作は明示的に示し、ユーザーが繰り返し試みないようにします。
重要なページの小さなセットに絞り、重いクエリを引く画面は簡素化します。キャッシュ済みの要約、ページサイズ縮小、安全なデフォルト並び順、やや古いデータを許容するなどで応答性を保ちます。
書き込みを行うバックグラウンドジョブ、同期、インポート、キューコンシューマーは停止またはスロットルしてください。Webhookは受け取って処理できない状態にせず、一時的な失敗を返して再試行を促す方が整合性を保てます。
UIだけでボタンを無効化するのは最大のミスです。APIやモバイルクライアント、古いタブはまだ書き込めます。また、通常と読み取り専用を頻繁に切り替えるフラッピングも避けてください。最低滞留時間を設け、指標が安定した後に戻します。