おっさんエンジニア

レガシー・サバイバル術 第5回:「止まらない設計は美しい」

〜冗長化より大切なもの〜

こんにちは、代表の片ケ瀬です。
インフラおじさんとして長年やってきましたが、
「冗長化してるのに止まる」現場、見たことありませんか?

💥 冗長化=止まらない、は幻想

構成図だけ見ると「完璧」に見えるけど、実際はこう:

  • VRRP両系ダウン → 両方MASTER化して通信不能
  • スレーブDBが壊れてて、切り替えた瞬間地獄
  • RAID1 → 1本死んで放置 → もう1本で昇天

冗長化は「止まりにくくする手段」
「絶対止まらない」ではない

🧠 本当に必要なのは「止まらない構え」

レガシーな現場でこう教わりました:

「止まらない」=自動切替じゃない。
止まりそうになったとき、誰かが対応できる状態。

🛠 止まらない設計に必要な要素

  • 手順書がある(誰でも動かせる)
  • ログが残る(トラブルの前兆が見える)
  • 切替が試せる(実際にやったことある)
  • 通知が飛ぶ(落ちたことに気づける)

📖 実録:止まらなかった理由は設計じゃなかった

ある日、NFSサーバがI/Oボトルネックで瀕死。

でも止まらなかった。
理由は「構成」じゃなく「運用」だった。

  • 手順書があった
  • 切替手順が試されてた
  • TTL60秒でDNS切替済み
  • 誰がやるか決まってた

止まらなかったのは、設計+人間の力

☯️ 冗長化 vs 止まらない設計

比較項目 冗長構成 止まらない設計
構成 複雑 シンプルでも可
コスト 高い 安くても可能
保守 設計者依存 チームで運用可
対応力 想定外に弱い 人が動ける

🧭 本当に止まらないとはどういうことか?

  • cronが落ちても仕組みが二重化されている
  • バッチ処理が失敗してもリトライ設計
  • 構成を変えずに“回復力”を持たせる

それが、現場の知恵と工夫でつくられる「美しい設計」です。

📌 まとめ:冗長化より大切なのは「想定力」

状態 弱点 補う方法
冗長構成 安心しすぎて対応遅れる 訓練・テスト
運用手順なし 属人化・現場が動けない ドキュメントと役割分担
通知なし 気づけない モニタリングと通知設計

🎖 美しい設計とは、
「止まらなかった」と後で言えること

止まらないのは技術力じゃない。
「止まる前提で準備していた力」こそが本当の実力。

🔮 次回予告:「レガシーを語る言葉が足りない」

次回は、システムや設計の背景を“語ること”の重要性について。

  • なぜこの構成にしたのか、ちゃんと伝えてる?
  • 設計意図がなければ、誰も引き継げない
  • レガシーを資産に変える“言葉の力”

いよいよシリーズ最終回!お楽しみに!

👋 最後にひとこと

冗長化は技術。
止まらない設計は思想。
──インフラは人の覚悟で守られる。

関連記事

コメント

この記事へのコメントはありません。

TOP