「止めないシステム」というと、多くの人はこんなことを思い浮かべます。
- サーバーが落ちない。
- DBが止まらない。
- 障害が起きても自動で切り替わる。
たしかに、どれも大事です。
でも、ここで一度立ち止まって考えたいことがあります。
サーバーが動いていれば、本当に「止まっていない」と言えるのでしょうか。
たとえば、
- 注文ができない。
- 決済結果が分からない。
- 復旧後に大量の手作業が必要になる。
もしそうなら、サーバーは動いていても、業務は止まっています。
だから私は、「止めないシステム」が守っているのは、サーバーではなく業務の流れだと思っています。
もっと簡単に言えば、
"落ちない"より、"困らせない"を設計する話です。
この記事では、「止めないシステム」を設計するときに、まず何を見ればいいのかを整理します。
「サーバーは復旧しました。でも注文は受けられません」
システムの部品が元気でも、業務が止まっていたら意味がありません。
逆に、一部の部品で障害が起きても、ユーザーや業務への影響を小さくできていれば、それは障害に強い設計です。
たとえば、ECサイトで障害が起きたとします。
しばらくして、運用チームからは、こんな報告が来ました。
サーバーは復旧しました。
DBも正常です。
監視もグリーンになりました。
これだけ聞くと、「もう大丈夫そう」と思います。
でも、現場ではこんなことが起きているかもしれません。
- 注文ボタンを押してもエラーになる
- 決済が成功したのか分からない
- 同じ注文をもう一度してしまう人がいる
- サポート窓口には問い合わせが増えている
- 復旧後もデータ確認のために作業が止まっている
この状態を、「復旧した」 と言えるでしょうか。
サーバーは戻っています。でも、業務はまだ戻っていません。
つまり、「止めないシステム」を考えるときに見るべきなのは、サーバーが生きているかだけではありません。
ユーザーがやりたかったことを、どこまで続けられるか。
止まったとしても、どこまで早く、安全に戻せるか。
そこまで含めて考える必要があります。
障害は、機械の故障だけで終わらない
「でも、そこまで考える必要ある？」と思うかもしれません。
あります。
データセンターやIT障害を分析している Uptime Institute の Annual outage analysis 2026 では、2025年の年次調査において、直近の重大障害のコストが10万ドルを超えた回答者が57%、100万ドルを超えた回答者も5人に1人とされています。
もちろん、これはすべてのシステムにそのまま当てはまる数字ではありません。
システムの規模、業種、止まった時間、影響範囲によって被害は大きく変わります。
ただ、ここから分かるのはシンプルです。
障害の影響は、サーバーの中だけでは終わらない。
注文が止まる。
決済が止まる。
問い合わせが増える。
復旧後の確認作業が増える。
信頼が落ちる。
だから「止めないシステム」は、技術的にかっこいい構成を作る話ではなく、業務への影響をどこまで小さくするかの話になります。
なぜ、私たちはサーバーばかり見てしまうのか
サーバーやDBは、とても分かりやすい指標です。
- CPU使用率
- メモリ使用率
- 監視アラート
- フェイルオーバーの成功
- プロセスの起動状態
どれも数字やステータスで確認できます。
一方で、
- ユーザーは困っていないか
- 業務は元に戻ったか
- 復旧後の手作業は残っていないか
- データの整合性に不安はないか
こうしたものは、意外と測りにくいものです。
だから私たちは、システムの状態だけを見て「復旧した」と思ってしまいがちです。
でも、本当に確認したいのはそこではありません。
ユーザーが、やりたかった仕事を続けられるようになったか。
そこまで戻って、初めて業務が復旧したと言えます。
よくある誤解：冗長化していれば安心？
「止めないシステム」と聞くと、まず冗長化を思い浮かべる人は多いと思います。
- サーバーを2台にする
- DBを複製する
- 別の場所にも環境を用意する
- バックアップを取る
どれも大事です。
ただし、それだけで「止めない設計」になるわけではありません。
なぜなら、冗長化やバックアップはあくまで手段だからです。
本当に知りたいのは、こういうことです。
- その障害が起きたとき、どの業務は続けられるのか
- どのデータは絶対に失ってはいけないのか
- 何分、何時間なら待てるのか
- 復旧したあと、ユーザーはそのまま作業を再開できるのか
ここを決めずに構成だけ強くしても、「すごそうだけど、何を守れているのか分からない設計」になりがちです。
止めない設計で見るものは4つある
「止めない」をもう少し分解すると、見るべきものは大きく4つあります。
- 業務
- データ
- 時間
- ユーザー体験
難しそうに見えますが、最初に考えることはシンプルです。
まず、次の3つの質問に答えてみてください。
- 何を止めたら困る？
- どこまで失ったら困る？
- どれくらいなら待てる？
そして最後に、もう一つだけ確認します。
戻ったあと、ユーザーは安心して作業を続けられるか。
この4つがそろって初めて、「止めない」が見えてきます。
1. 業務：何を止めたら本当に困るのか
まず見るべきなのは、システムの部品ではなく業務です。
たとえば同じECサイトでも、
- 商品を検索できない
- カートに入れられない
- 注文できない
- 決済できない
- 注文履歴が見られない
では、影響の重さが違います。
全部を同じレベルで守る必要があるとは限りません。
逆に、絶対に止めてはいけないところを見誤ると、守るべき場所に投資できません。
だから最初の問いはこれです。
このシステムで、止まると本当に困る業務はどれか？
2. データ：どこまで失ったらアウトなのか
次に見るのはデータです。
障害が起きたあと、システムが戻ったとしても、直前の注文データや決済データが失われていたら大問題です。
ただし、ここでも「全部1件も失ってはいけない」と考えるだけでは設計が進みません。
もちろん、絶対に失えないデータもあります。
一方で、再取得できるログや、一時的なキャッシュのように、失っても業務影響が小さいデータもあります。
大事なのは、データを一括りにしないことです。
どのデータは絶対に失えないのか。
どのデータは再作成できるのか。
どの時点まで戻せれば業務として許容できるのか。
ここを分けて考える必要があります。
3. 復旧時間：どれくらいなら待てるのか
3つ目は時間です。
同じ障害でも、1分で戻るのか、30分かかるのか、半日止まるのかで、影響はまったく違います。
たとえば、
- 社内のレポート画面が30分見られない
- 決済システムが30分使えない
- 医療や金融の重要処理が30分止まる
では、同じ30分でも重さが違います。
つまり、復旧時間は技術だけで決めるものではありません。
その業務は、どれくらい待てるのか。
この問いが先にあります。
4. ユーザー体験：戻ったあと、ちゃんと使えるのか
最後に見落としやすいのが、ユーザー体験です。
システムが復旧しても、ユーザーから見るとこういう状態かもしれません。
- エラー画面のまま止まっている
- 再ログインが必要になる
- 入力途中の内容が消えている
- 注文が通ったのか分からない
- もう一度同じ操作をして二重処理が起きそうで怖い
これは「復旧した」と言えるでしょうか。
運用チームから見れば復旧済みでも、ユーザーから見ればまだ不安定です。
止めない設計では、システムが戻るだけでなく、使っている人がどこから再開できるかも大事になります。
“止めない”は、1個のスイッチではない
ここまで見ると分かるように、「止めない」は単純なオン/オフではありません。
止まるか、止まらないか。
生きているか、落ちているか。
それだけではなく、
- 業務をどこまで続けるか
- データをどこまで守るか
- どれくらいで戻すか
- ユーザーにどこまで影響を見せないか
を組み合わせて考えるものです。
そして、ここには必ずトレードオフがあります。
全部を最高レベルで守ろうとすると、構成は複雑になります。
コストも上がります。運用も難しくなります。
テストしないと、いざというとき本当に動くか分かりません。
だから「止めないシステム」は、ただ強そうな構成を選ぶ話ではありません。
何を守るべきかを決める設計です。
「止めない」は、障害をゼロにする魔法ではない
現実には、障害を完全にゼロにすることはできません。
ハードウェアは壊れます。
ネットワークは切れます。
人はミスをします。
外部サービスに依存していれば、自分たちの外側で問題が起きることもあります。
だから、強いシステム設計では、「障害を絶対に起こさない」だけを目指すのではなく、障害が起きたときに、困る範囲をどこまで小さくできるかを考えます。
落ちないことも大事です。
でも、それ以上に大事なのは、落ちたときにどうなるかです。
- 業務は続くのか
- データは守られるのか
- どれくらいで戻るのか
- ユーザーは混乱せずに再開できるのか
この問いに答えられる設計が、「止めない」に近づいていきます。
まとめ
「止めないシステム」は、障害をなくす魔法ではありません。
障害が起きても、
- 業務を続けられる
- データを守れる
- 必要な時間で戻れる
- ユーザーが安心して再開できる
その状態を設計する考え方です。
だから、「止めないシステム」が守っているのは、サーバーではなく業務の流れです。
そして、その考え方を一言で表すなら、
"落ちない"より、"困らせない"を設計する。
これが、「止めないシステム」を考えるときの出発点だと思います。