
レガシー・サバイバル術 第5回:「止まらない設計は美しい」
ktgs
〜冗長化より大切なもの〜
こんにちは、代表の片ケ瀬です。
インフラおじさんとして長年やってきましたが、
「冗長化してるのに止まる」現場、見たことありませんか?
💥 冗長化=止まらない、は幻想
構成図だけ見ると「完璧」に見えるけど、実際はこう:
VRRP両系ダウン → 両方MASTER化して通信不能
スレーブDBが壊れてて、切り替えた瞬間地獄
RAID1 → 1本死んで放置 → もう1本で昇天
冗長化は「止まりにくくする手段」
「絶対止まらない」ではない
🧠 本当に必要なのは「止まらない構え」
レガシーな現場でこう教わりました:
「止まらない」=自動切替じゃない。
止まりそうになったとき、誰かが対応できる状態。
🛠 止まらない設計に必要な要素
手順書がある(誰でも動かせる)
ログが残る(トラブルの前兆が見える)
切替が試せる(実際にやったことある)
通知が飛ぶ(落ちたことに気づける)
📖 実録:止まらなかった理由は設計じゃなかった
ある日、NFSサーバがI/Oボトルネックで瀕死。
でも止まらなかった。
理由は「構成」じゃなく「運用」だった。
手順書があった
切替手順が試されてた
TTL60秒でDNS切替済み
誰がやるか決まってた
止まらなかったのは、設計+人間の力。
☯️ 冗長化 vs 止まらない設計
比較項目 冗長構成 止まらない設計 構成 複雑 シンプルでも可 コスト 高い 安くても可能 保守 設計者依存 チームで運用可 対応力 想定外に弱い 人が動ける
🧭 本当に止まらないとはどういうことか?
cronが落ちても仕組みが二重化されているバッチ処理が失敗してもリトライ設計
構成を変えずに“回復力”を持たせる
それが、現場の知恵と工夫でつくられる「美しい設計」です。
📌 まとめ:冗長化より大切なのは「想定力」
状態 弱点 補う方法 冗長構成 安心しすぎて対応遅れる 訓練・テスト 運用手順なし 属人化・現場が動けない ドキュメントと役割分担 通知なし 気づけない モニタリングと通知設計
🎖 美しい設計とは、
「止まらなかった」と後で言えること
止まらないのは技術力じゃない。
「止まる前提で準備していた力」こそが本当の実力。
🔮 次回予告:「レガシーを語る言葉が足りない」
次回は、システムや設計の背景を“語ること”の重要性について。
なぜこの構成にしたのか、ちゃんと伝えてる?
設計意図がなければ、誰も引き継げない
レガシーを資産に変える“言葉の力”
いよいよシリーズ最終回!お楽しみに!
👋 最後にひとこと
冗長化は技術。
止まらない設計は思想。
──インフラは人の覚悟で守られる。
Related
