サーバを立てる。
アプリをデプロイする。
画面が表示される。
ここで安心してしまう人が多いです。
でも本当に怖いのは、
「とりあえず動いた状態」
です。
【① 環境の再現性を考えているか】
ローカルでは動く。
でも本番では動かない。
よくある話です。
原因の多くは、
・ライブラリのバージョン違い
・環境変数の未整理
・依存関係の曖昧さ
です。
再現できない環境は、
仕組みとは呼べません。
Dockerを使うのも、
便利だからではなく、
「同じ環境を何度でも作れるようにするため」
です。
【② ログを見れる状態にしているか】
エラーが出たとき、
原因をすぐ追えますか？
・どこで落ちたのか
・いつ落ちたのか
・何が入力されたのか
これが追えない構成は危険です。
動いていることよりも、
「壊れたときに追えること」
の方が重要です。
サーバ設計は、
正常時より異常時を想定します。
【③ 責任の分離ができているか】
フロントエンド
バックエンド
インフラ
これが曖昧だと、
修正のたびに全体を触ることになります。
・表示の修正なのか
・ロジックの修正なのか
・サーバ設定の問題なのか
境界がはっきりしていると、
変更に強くなります。
構成設計は、
“機能追加のため”ではなく、
“変更に耐えるため”にあります。
サーバ構築は、
動かすことがゴールではありません。
・再現できる
・追跡できる
・分離されている
この3つが揃って、
初めて「設計」と言えます。
コードを書くことよりも、
どこでどう動かすかを決めること。
ここを間違えると、
あとから何度も作り直すことになります。
今後も業務自動化・Linux・Docker関連の実践的な内容を発信していきます。
